Chainless Mecanum Drive

[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).

If I'd say anything it's to make sure you guys are very, very critical of your final project and to make sure the advantages are actually called for in your design process, and that the disadvantages are not absolute. I would say a lot of teams that build mecanum drives get a little distracted by the whole coolness factor and build it without regard to the realities of pushing and whether or not strafing is required.

[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.

[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

[Chris is me]

With the Nonadrive, I would say the mechanical complexity in design would be in making the pivot modules rigid enough for FRC applications. In particular, when resisting pushing a moment is applied through the modules (I think?) since the traction wheel is on a module, so the forces are transferred through the chassis via the pivot axle. It seems a lot esaier to make a standard 6wd than to make a Nonadrive. The extra weight assumes a lack of sheet metal capability and having to use thicker sideplates due to a lack of ability to add flanges among other things like that.

I would argue that Nonadrive is simpler to code because it basically takes zero programming, but basic robot centric mecanum code is not a tough challenge either.

@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)

[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.

[EricH]

The only reason it worked when 330 used it in 2009 was those two extra wheels that all robots had to have. The trailer kept the robot body from being a big old turret.

[Ether]

Originally Posted by apalrd

Nonadrive:
...
Here is how it works:

There are four omni wheels on the perimeter of the robot, driven in standard tank drive. Each wheel is on a "pod" with a high-traction wheel, and the pods are pneumatically moved so the traction wheels can either provide traction or float above the ground.

In the middle there is a single omni wheel, driven by a single CIM, which is sideways (to cross the bumps, 148 and 217 pneumatically lifted this wheel a few inches to give them the center clearance necessary to cross the bumps).

This provides the "standard" amount of power (4 CIM's, or around 1.2 kw) in the forward/backward direction, while allowing non-pushing motion sideways. Since omni wheels are push-able, they can lower the perimeter wheels to push or avoid being pushed.

Originally Posted by Chris is me

I would argue that Nonadrive is simpler to code because it basically takes zero programming

so robot-centric nonadrive in tank mode looks something like this:

Left-side motor(s) = Y1

Right-side motor(s) = Y2

Center_motor = X or zero, 
depending on whether traction wheels 
are raised or lowered

... plus code to respond to commands 
and decide when to raise and lower the traction wheels,
and set flags to let the center motor code know 
what state the traction wheels are in

and robot-centric mecanum in tank mode looks something like this:

motor1 = Y1 + X

motor2 = Y2 - X

motor3 = Y1 - X

motor4 = Y2 + X

... plus code to normalize the motor commands to the range -1 to +1

Frankly, I don't see where nonadrive is simpler.

[Alan Anderson]

Originally Posted by Ether

Frankly, I don't see where nonadrive is simpler.

That's because you're adding things that aren't required. For a basic nonadrive, three joystick axes directly control three motor outputs, and one joystick switch directly controls one solenoid output. Sure, you can make it fancy with toggle functions and motor limiting, but you don't need to.

A basic mecanum drivebase is certainly easy, but the connection between inputs and outputs is not one-to-one, and you have to do some post-processing to scale motor values if you don't want unexpected behavior at high speed.