Programmed with Robot Mesh Studio. This isn’t your older sibling’s VEX kit…
That is a pretty fast base. Are you running all the motors at 200RPM?
All 200 RPM, yep. That’s the gear box the production motors will ship with with so we’ve been using those.
Wow, that is pretty fast. Much faster than I expected. Do you think 333 RPM will be a little overkill on a tank drive?
333 RPM? 5:3 step up off a 200 RPM gearbox? For a 2-motor drive it might wind up being under geared. I don’t expect many teams to do 4-motor drive trains like this base is using, as it eats up a full half of the motor budget in a game where there are good reasons to have two different scoring mechanisms.
For a 4-motor tank drive, though, you might be able to get away with a 5:3 step up. Just make sure you have enough traction to handle your acceleration! The robot in the video weighs 6.4 lbs., and it has a lot of trouble with wheel slippage when accelerating quickly, even on foam.
Ok, thanks for the info. I will probably be using 2 motors I guess, I will find out if that is enough torque by testing. However, do you think 333 would be too fast?
It’s not that hard to make your cap and ball systems each take two motors, especially with the strength of v5s .
I doubt it, this game seems to be all about zipping around the field scoring game objects, not at all like last year where subsystems were important. Of course if you don’t have the motors to go 333 rom you don’t have the motors…
@MannanG There is no too fast until you can’t control it. And if you can’t control it, you just need smarter code!
I will say I am pleasantly surprised how straight that drive goes with holonomic. Is that the V5 motors doing that or do you have any additional code that helps straighten it out?
Could I suggest trying to drive the robot onto the blue platform perpendicular to the direction being attempted? That would be from where the stationary robot is toward the central platform. That might eliminate the overshoot problem.
A quick way to help this is to set a reasonably large dead zone for the remote control. If each axis’s dead zone is sufficiently large, then you can pretty much guarantee trying to push only sideways or trying to push only forward/back will result in those instead of including a bit of the other as well. I can’t say that was done here, just that it will accomplish the straightening fairly simply.
@[TVA]Connor This is using the V5 motors’ built-in velocity PID, so the program is assigning velocities that the motors try to match. This makes it go a little straighter than just assigning raw voltages as long as the operator doesn’t ask for a velocity so large that the PID uses maximum torque and gets the wheels to slip. (Even at 6.4 lbs., this robot can get its wheels to slip on foam from a standing start. V5 motors have a lot of torque.)
@callen It would still have this problem on the center platform, though. It needs a small change so it can drive up slowly without bottoming out on the motor casings. As for the straightness, that’s just the velocity PID of the V5 motors and a steady hand. To deadband this I would probably write one that didn’t ignore anything once the stick was a sufficient distance from the center, but that’s personal preference and not necessarily best practice. Best practice is, of course, whatever your driver can most effectively use, and that varies slightly from driver to driver.
With the built-in intelligence, V5 motors are not just bigger 393s, but a whole new thing. Even something as simple as lifting an arm is better (and requires smarter programming) than a 393. The first V5 robot I built was Harvey (it was on display at Worlds), which had a tendency to tear its arm gears apart because I had not thought through the programming. I was simply using the power settings like a 393, rather than making smart use of the V5 controls to limit the range and intelligently apply power.
Tl;dr, don’t use the V5 motors like 393s. Study the motor’s methods and properties and program them accordingly.
So many "TYler"s now
The new intern is copying my NAme.
I blame the intern’s father for not teaching him better morals.
Yes. I was just suggesting this for the first platform with the current configuration.
Yup. I was just suggesting a way to use the deadband to get the desired behavior if the driver can’t pull it off without that. Since you’ll want a headband anyway, it’s a fairly simple way to do it.
If you only knew…