mecanum vs. omni

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.

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.

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.

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.

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.

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! :slight_smile:

Sean

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.

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…

That’s a lot of generalizations.
Mecanum drives require just a much precision to make as holonomic (omni/kiwi) drives, but instead of worrying about how to place your wheels radially, you have to place them in facing the same angle (if this is off, you will once again experience incorrect driving, unless you account for it in programming). In addition, like a mecanum drive, you can account for any imperfections in wheel placement in a holonomic drive with programming.
In general cases, Mecanums are capable of climbing inclines/steps/bumps better than most holonomic drives, but it is possible for holonomic drives to climb them given the right wheels and/or suspensions (and the size of the inclines/steps/bumps).
Mecanums and Holonomic systems aren’t really any more efficient than eachother, they just function differently. Assuming a 45º roller placement on a Mecanum wheel (standard for FIRST purposes, used on the AM Mecanums), a Mecanum wheel delivers about 70% ([square root of 2]/2)](Shaw Communications) of the force applied in both the “vertical” and “lateral” directions. Each omni-wheel delivers 100% of the force in the direction it faces, but the over-all efficiency of the drive depends on the number of wheels used, direction of travel, and rotational movement. Basically, a mecanum system uses angeled rollers and straight wheels to achieve the same goal a holonomic system uses straight rollers and angeled wheels for.
As for the driver skill, I fail to see how one would be harder to drive than the other (when programmed properly). A common control style is using a single joy-stick to control the lateral movements of the robot (using both the x and y axis) and either a z-axis or a knob (pot) to control the rotational motion. I have seen this system applied both to holonomic and mecanum drives (and have driven it with a holonomic…with ease).

Neither system is truly “better”. They are very very similar systems, that function on the principle of vector translation. The programmers for either system should have a firm grasp on vectors and (preferably) kinematics in general. The efficiencies, torque, speed, traction, agility, cost, weight, size, and complexity vary greatly on the exact system you use (wheel choice, wheel placement, programming ability, etc.). Ideally both systems should have some form of suspension to ensure that all wheels remain in full contact with the driving surface, but teams have succeeded in the past with-out them.
I’d suggest you consult teams that have used each system for tips and lessons learned, as well as reading Ian Mackenzie’s whitepaper on the kinematics of omni-directional systems. http://www.chiefdelphi.com/media/papers/1836

Some existing threads on both systems:
http://www.chiefdelphi.com/forums/showthread.php?t=51582&highlight=mecanum
http://www.chiefdelphi.com/forums/showthread.php?t=49625&highlight=mecanum
http://www.chiefdelphi.com/forums/showthread.php?t=48817&highlight=mecanum
http://www.chiefdelphi.com/forums/showthread.php?t=48637&highlight=mecanum
http://www.chiefdelphi.com/forums/showthread.php?t=47204&highlight=mecanum
http://www.chiefdelphi.com/forums/showthread.php?t=41868&highlight=mecanum
http://www.chiefdelphi.com/forums/showthread.php?t=51676&highlight=omni
http://www.chiefdelphi.com/forums/showthread.php?t=49705&highlight=omni
http://www.chiefdelphi.com/forums/showthread.php?t=38370&highlight=omni
Programming emphasis:
http://www.chiefdelphi.com/forums/showthread.php?t=36205
http://www.chiefdelphi.com/forums/showthread.php?p=421092#post421092

one more thing: where can mecanum wheels be purchased and roughly how much do they cost?

http://andymark.biz/am-0083.html
$375 per set (plus shipping)

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.

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

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.

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.

on that note, it would probably be difficult to program…

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

Drive systems using Mecanum (note spelling) wheels are holonomic (note spelling). The only real difference between Mecanum and omniwheel systems is in the orientation of the axles. Nearly everything else can be analyzed identically. For example, I don’t see how a Mecanum wheel sees greater side forces than a traditional omniwheel. Can you explain your reasoning more completely?