mecanum vs. omni

[tseres]

hey everyone!
we (1565) are working on developing a drive system for next year. so far we're thinking of omni wheels (we almost did them this year). i don't know much about these drive systems, and i was wondering about the pros and cons of omni vs. macanum wheels.

[Kelly]

Omni wheels are cheaper, and allow for truly omni-directional motion. The programming is really not that difficult. My team built a holonomic drive train this year and it was one of the best decisions we've ever made.

[thefro526]

Assuming that you are using off the shelf components a Mecanum drive is easier to make. Omni-Drives require precise angles (60° for a Kiwi and 90° for a Holonomic) and if you are not near perfect your robot will have some strange driving characteristics. Also it is much easier to climb ramps with Mecanums. To my understanding Mecanums are also more efficient in forward and reverse directions (like a normal wheel) while still giving you lateral mobility. Omni-Drives have a much lower efficiency (~50%) in all directions but they will give you true omnidirectional motion. Also Omni-Drives require much more skill to drive than a Mecanum Drive. Still, you should test out both drives to see what works better for your application and to suit the game.

[s_forbes]

I think the one major advantage that mecanum wheels have over omni-wheels is that they can fit in a normal frame set up. Omni wheels have to go on in a way that requires more fabrication while you can simply drop some mecanum wheels into a kitframe.

[4throck]

The one real problem with these drives that we discovered was victor bias. The values that come out are not symmetric, linear, or normal by any means. We ended up using look up tables, ask Kelly for more information about how we did it.
And for the record, it's not hard to line up the wheels at angles that are close enough to 90 for all practical purposes.

[The Lucas]

Originally Posted by 4throck

The one real problem with these drives that we discovered was victor bias. The values that come out are not symmetric, linear, or normal by any means. We ended up using look up tables, ask Kelly for more information about how we did it.

The "center" of the Victor 884 range is NOT 127. It is more like 132 or 133. Some example ranges are provided in this thread in the IFI Forum. I suggest testing your own speed controllers by giving them steady known values (from a pot or wheel and reading it on the dashboard) and looking at the lights.

This makes reversing the motor direction in software difficult, so I suggest just simply reversing the polarity at the Victor output. The motors will still have different power output in forward vs. reverse (that is inherent to the motor) but at least the input electric power will not be the problem. Wheel encoder and yaw rate sensor feedback can correct the former problem.

Here is another good programming link for Jester Drive

[Sean Schuff]

Originally Posted by thefro526

Also it is much easier to climb ramps with Mecanums.

I have to disagree. Mecanum wheels tend to wander side-to-side when trying to negotiate a ramp, even one that is relatively small. One of our alliance partners at nationals struggled to get on our lifts which had 1.5" (very low) ramps. Their robot had difficulty driving in a straight line, something that was required to get up on our lifts.

Perhaps the problem was with some other component in the drive system of their robot but it has caused our team to shift our focus from mecanum to crab for experimentation.

Spend the 2 cents wisely!

Sean

[Kelly]

Originally Posted by thefro526

Omni-Drives require precise angles (60° for a Kiwi and 90° for a Holonomic) and if you are not near perfect your robot will have some strange driving characteristics. Also it is much easier to climb ramps with Mecanums.

Actually, if you understand the math, it's okay if your angles are not perfect, as it's fairly easy to fix in code. The ease of climbing ramps is determined by the type of omni wheel you buy. Unfortunately, most of the off the shelf omni wheels our team found had lousy traction, although it would be possible (mabye not feasible?) to manufacture your own.

[tseres]

also, programming wise, which is easier? i'm the new team programmer...
i don't know why, but for some reason i like the idea of mechaum wheels better than omni....maybe they look like they get better traction (i dont know if they do). we originally wanted a crab drive, but today we came to the conclusion that omni would be easier and better for our first time. i'm just wondering the differences so that we make the right choice...

[Alan Anderson]

Originally Posted by tseres

also, programming wise, which is easier? i'm the new team programmer...

From the point of view of the software, a straightforward Mecanum drive is identical to a typical omniwheel setup with 45-degree-angled wheels at the corners. They're equally easy.

On the other hand, they're equally difficult. To be able to drive a holonomic platform easily requires tight feedback control of wheel speed. Giving the driver complete responsibility for motor power is simple, and works fine for demonstrations, but if you want to do something tricky like climb a ramp it's probably going to have to be a bit fancier.

[Alex.Norton]

Our team has used a holomonic for the last 3 years. I would strongly suggest that you use some for of feedback is this system. We had no luck with it untill we put a gyro in the base. This would apply for both holomonic and mechanum because both depend on the motor speeds.

In terms of which to use I would suggest holomonic much more than mechanum. I don't like mechanum for two reasons: 1. Much more expensive 2. because of the roller set up on mechanums, even when driving forward or backward there is a side force placed on the bearings. This year we could find a washer to captivate our wheel (all of the lateral force on the wheel is placed on this piece). We decided to cut them on a laser engraver out of 16th inch acrylic (shatter prone) and we have had no problems with the wheels or anything to do with the drive train. I could not have done this on a mechanum because, in the most simplistic view, for every pound of forward force there would be one pound of sideways force and the washer would have shattered the first time the machine took off.

Just a couple of thoughts

[tseres]

just surious, why did you use the gyro? i mean, why is it needed? can't you just do everything in the programming?

[Lil' Lavery]

Originally Posted by tseres

just surious, why did you use the gyro? i mean, why is it needed? can't you just do everything in the programming?

It depends on the style on control you want really. For a robot-centric drive (push up on the joysticks, the robot moves to its "front"), a gyro isn't always necessary, but for a field-centric (push up on the joystick, the robot moves away from the driver), a gyro, accelerometer, and/or other sensor packages are almost required.

[tseres]

o ok....now i get it....so when the robot isnt facing you it still steers like it is.....ya...that would be cool

[Lil' Lavery]

Originally Posted by tseres

o ok....now i get it....so when the robot isnt facing you it still steers like it is.....ya...that would be cool

In addition, field-centric steering is virtually the only way to achieve both rotational and straight lateral motion at the same time ("frisbeeing" in a direction). If the controls are robot centric, the rotational motion will result in the translation to become an arcing motion, rather than a straight line.
See one of the programming related threads I posted earlier.