Chainless Mecanum Drive

[EricH]

Originally Posted by Chris is me

Actually, Eric, I'd say they're doing exactly the right thing by trying it now. There's really no better of a time to see if you can get it working and learn about the drawbacks of such a system. I mean, one could say the very same thing about a six wheel drop prototype (ignore for a minute that 6 wheel drop has been consistently very successful).

Which is exactly what I said in the second paragraph (right after pointing out the key words).

I also pointed out that just because you have an uber-widget doesn't mean that you should use it, but having it is nice because if you should use it, you can do it very quickly.

OK, so I also suggested a comparison test that should be easy to whip up come build season...

[Ether]

Originally Posted by spiffyspleen

Our main reason for trying them now is so that we have experience with them if we decide to use them for the FRC season. We bought them last year but decided not to use them for FRC because we didn't have any experience with them and we didn't think they would work well on the ramp. We want to learn how to use them because they are one of the most manueverable drive trains. From what I saw at the Portland regional last year the teams that used them were able to position themselves very well with the ball and goal and ended up doing pretty good. Basically, we think that they could be advantagous in this years competition and we want to be able to use them if they are.

Well, there's a lot of information here on the CD forums about mecanum wheels, both pro and con. If you haven't yet searched the forums and read the links, you might want to consider doing that.

[JesseK]

Spot on about the direct-drive Mecanum setups. It's very efficient, though be sure to clean the rollers every couple of matches.

An interesting thing about nonadrive is the penta drive configuration. 5 omni wheels can be driven by 3 motors for a team with limited resources that wants agility.

- Less code complexity than most non-standard (skid) drive systems
- Less expensive than Mecanum or Killough (traditional 4-wheel Omni)
- Arguably more traction than "out-of-the-box" Mecanum, and definitely more traction than Killough
- In recent years, it would leave at least 1 CIM available for other things
- Can be used in 4WD or 6WD skid configurations, though that is highly coupled with need-based strategy

I've toyed with a concept that uses 5 wheels in nonadrive's pentadrive configuration with the middle wheel being a traction crab module that pivots via pneumatic linkage (pneumatic to keep the code simple). This concept gives a mid-grade complexity while also potentially providing some of the agile+tractive advantages of nonadrive without the weight. Of course it doesn't have the natural anti-turn capability of nonadrive, but that's the trade off. The concept was inspired by nonadrive and the limited pictures I've seen of 330's 2009 bot.

Unfortunately I've been overruled for our offseason prototype due to team survivability, so maybe another team will prototype it?

[Chris is me]

I would suggest that a slide drive config that wants at least 1 CIM for something else use 1 CIM + 1 FP in the drivetrain instead of just 1 CIM. Acceleration is helped a pretty good amount.

[AdamHeard]

Originally Posted by JesseK

I've toyed with a concept that uses 5 wheels in nonadrive's pentadrive configuration with the middle wheel being a traction crab module that pivots via pneumatic linkage (pneumatic to keep the code simple). This concept gives a mid-grade complexity while also potentially providing some of the agile+tractive advantages of nonadrive without the weight. Of course it doesn't have the natural anti-turn capability of nonadrive, but that's the trade off. The concept was inspired by nonadrive and the limited pictures I've seen of 330's 2009 bot.

Unfortunately I've been overruled for our offseason prototype due to team survivability, so maybe another team will prototype it?

I don't think this would work at as well as you'd hope. The crab module would only have so much normal force on it, based on CG location. On top of that, if someone to to try to rotate the robot, it wouldn't be nearly as difficult as trying to rotate a 4wd/6wd, etc... You'd also have to design carefully to ensure that when the module rotates, the module rotates relative to the floor, not the module stays in place and the robot rotates around it.

I'm making the assumption that the crab module would raise under normal operation.

Really, the best way to answer the question without building it is to do a full Free body diagram and look at the forces involved.

[spiffyspleen]

Originally Posted by Ether

12.75:1 seems to be a reasonable compromise between speed and torque (more or less depending on the game, of course)

What ratio do the Andy Mark gear boxes come in? We have several assembled from last year so would we actually have to change them?

Also, I am new to mechanical and am not too familiar with gearboxes. What does 12.75:1 actually mean?

[Ether]

Originally Posted by spiffyspleen

What ratio do the Andy Mark gear boxes come in? We have several assembled from last year so would we actually have to change them?

They are 12.75:1

Also, I am new to mechanical and am not too familiar with gearboxes. What does 12.75:1 actually mean?

It means that for every 12.75 turns of the motor shaft, the gearbox output shaft turns once. You are trading speed for torque.

[apalrd]

12.75:1 is the default gear ratio for the AM toughboxes and toughbox-derived gearboxes (Nano, etc.)



12.75:1 is the ratio between the input (in this case the output of a CIM motor) and the output (The output shaft sprocket or direct-driven wheel). With it you can find the output speed and torque of a gearbox if you know the speed and torque of the motors going into it.

If you need the long output shafts (you might not) you would have to get new long output shafts from AndyMark and put them in the existing toughboxes.

Edit: Beaten to it

[spiffyspleen]

Thank you guys! It looks like doing the mecanum drive is going to be a lot easier than I originally thought

[JesseK]

Originally Posted by Chris is me

@JesseK: I was suggesting 1 CIM + 1 FP in each of the forward wheels and then just a CIM on the side wheel since strafing is secondary to forward motion for a slide drive (if it isn't secondary, you should probably be using a holonomic chassis). With a crab module in the center I would probably suggest 2 CIMs on that and 1 CIM + FP on the outsides (off the top of my head here, not based on math or anything)

Many teams get away with 1 CIM per side for a 10fps (or less) drive train and do just fine. Calculating the motor load based upon robot weight and gearing inefficiency puts the motor efficiency within a nominal amount of its maximum efficiency while just driving. If sound judgment is used on the drive train with respect to turning (wheel base for traction, or use of omnis, 6WD drop-center, etc), almost the same results would apply. Thus, as long as the team doesn't try to push another traction robot they'll be ok.

Your initial instinct is correct for what many teams want -- 11+ fps.

Originally Posted by AdamHeard

You'd also have to design carefully to ensure that when the module rotates, the module rotates relative to the floor, not the module stays in place and the robot rotates around it.

Good point, I didn't even think about that... It'd almost have to be an omni wheel at that point in order to prevent this completely.

Originally Posted by spiffyspleen

Thank you guys! It looks like doing the mecanum drive is going to be a lot easier than I originally thought

The first iteration of Mecanum is always easy! If you build your drive train in the off season, play around with some extra weight. Specifically, see the effects of pushing a robot when the contact point removes traction from the front (lifts your robot slightly), and see the effects of just driving when your c.g. is too close to one of the wheels. Some interesting behaviors come out.

[Andrew Schreiber]

Originally Posted by Chris is me

Not to take away from innovation and technical achievement, but I don't really see the Nonadrive as some kind of new Holy Grail in FRC drivetrains, and it is absolutely not something a team without the engineering resources to design a direct drive mecanum drive should do. It's not exactly a cheap, light, or simple drivetrain.

Actually, I would make the opposite argument. Mechanically a Nonadrive (one that does not need to cross bumps) is only slightly more complicated than a standard 6wd robot. Remember, the perpendicular wheel does not need to raise or lower if it is a flat field. From a programming standpoint it is much much simpler. The hardest part about mechanum drive machines is controlling them. It involves either lookup tables and interpolating results or using lots of sins and cosines or matrices (Thank you Ether). A nonadrive is simple in that for translation all you need to do put the Y component of your translation stick to the left and right drive motors and the X component to the cross drive motor(s) Rotation is a little trickier but you could just scale the left and right based on your rotation input. Either way, much simpler than mechanum.

It should also come out near the weight of a mechanum drive train. Remember mechanum needs 4 gearboxes, Nonadrive needs 3. Yes Nonadrive requires 4 cylinders but if you were planning on using air anyway that is not a ton of weight.

I will admit that the Nonadrive has, at least after a cursory glance, more failure points.

TLDR, there are benefits and drawbacks to both systems (like any systems) but neither one is inherently more complicated.

EDIT: Appended note about Ether's solution.

[Ether]

Originally Posted by Andrew Schreiber

From a programming standpoint it [nonadrive] is much much simpler. The hardest part about mechanum drive machines is controlling them. It involves either lookup tables and interpolating results or using lots of sins and cosines.

Programming mecanum is simple and straightforward.

No trigonometry or lookup tables are required.

You can find theoretical analysis and example programming here.

[Andrew Schreiber]

Originally Posted by Ether

Programming mecanum is simple and straightforward.

No trigonometry or lookup tables are required.

You can find theoretical analysis and example programming here.

I would still claim that it is not as simple and straightforward but it is an interesting solution to the problem. Thank you.

[JesseK]

Originally Posted by Andrew Schreiber

I would still claim that it is not as simple and straightforward but it is an interesting solution to the problem. Thank you.

For robot-centric steering, it is that simple. For field-centric steering (where pushing away on the joystick moves the robot away from the driver's station regardless of robot orientation) it can get quite complex.

Originally Posted by Chris is me

I would suggest that a slide drive config that wants at least 1 CIM for something else use 1 CIM + 1 FP in the drivetrain instead of just 1 CIM. Acceleration is helped a pretty good amount.

Do you mean for the sideways component? If so, that's a good point. A crab-style middle wheel would put 3 CIMs accelerating forward at a maximum, 2 minimum (which is acceptable under 11fps or so). The sideways movement would only ever have 1 CIM maximum, which may be a problem since should have the same speed as the forward-only wheels -- if the forward component is 12fps or more, then the single CIM moving sideways would cause some sluggishness.

[Ether]

Originally Posted by JesseK

For robot-centric steering, it is that simple. For field-centric steering (where pushing away on the joystick moves the robot away from the driver's station regardless of robot orientation) it can get quite complex.

It's a bit more work, but not at all complex.

And it's no more complex for mecanum than it is for nonadrive.

To do field-centric control, you must know the angle of the robot with respect to the field (using a gyro for example).

Use this angle to do a 2D coordinate rotation on the joystick X and Y inputs* . Then use these rotated values (plus the unmodified Z joystick value*) as inputs to your robot-centric code.


*assuming X and Y represent the strafe and fwd/rev commands, and Z represents the spin command