Mecanum Drive - Help

[Smoking_Gun]

Hi,
Our team wants to use Mecanum Drive this year!
We have a few questions to ask before we could buy this.
We would appreciate if a team that has used this drive system would contact us by email (dark_key@walla.com) or post thiers in here.

Thanks!
Tal Saiag #Neat-Team 1943

[AdamHeard]

I strongly urge you to wait at least until the day of kickoff before deciding this. A majority of games were not well suited for mecanum drives, and it would be tragic to lock your team into a mecanum drive for a game it is very ill suited for.

[MrForbes]

I agree with Adam! Mecanum drive is very interesting, and you would learn a lot by making a robot with it. The problem is that one thing you would learn is that most other robots will be able to push your robot wherever they want to.

Our team made a mecanum drive robot for promotional use (we bring it to fundraising events mostly), and to learn how mecanum robots work. It is very educational, fun to drive, and people like to watch it. If the 2008 game requires a nimble robot that can go any which way, then it might be a good choice to use a mecanum. If you need to be able to push other robots around or to keep your robot in one place to score, then it would not be so good.

http://www.chiefdelphi.com/forums/sh...ad.php?t=59027

[Rupnick]

Originally Posted by Smoking_Gun

Hi,
Our team wants to use Mecanum Drive this year!
We have a few questions to ask before we could buy this.
We would appreciate if a team that has used this drive system would contact us by email (dark_key@walla.com) or post thiers in here.

Thanks!
Tal Saiag #Neat-Team 1943

Yes, Wait until kickoff to decide. My Team will hopefully be doing Mecanum Drive again this year unless the game calls for a different drive. things to remeber with mecanum is that you have almost no ability to climb anything like ramps or any of that. Most of the time you could get pushed around ,but we avoided that this year by just using that fancy sideways movment to go around others. Another thing, most people would probly say you can't play defence with mecanam but, this year we (1675) proved that wrong. Althought you may not be able to push other robots around it is very easy to just get in the way and stay there. If the robot you are defenceing has a normal tank style drive it's pretty much impossible for them to get away.

If you have any questions just email me G.Rupnick@gmail.com Either I can help or i can refer you to another member of the team who can if I can't.

[JesseK]

The biggest lesson to learn about mecanum drive:

If your ability to score in the game is hindered, it's going to be a loooong tournament. Your manipulator, ramps, elevators, shooters, or whatever else better work well.

Also, mecanum wheels are pretty terrible at driving up inclines. The only reason a mecanum bot could drive up 1885's ramps last year was due to the side rails that kept other teams from sliding off sideways, and even then they had to gun it and pray.

Even with all of what everyone has said, it never hurts to get started. In CD-Media look for the white paper called "strafing.pdf". Mecanum drive is described in detail in there and it has the end results of a robot-centric motor output equations. Coming up with the control system will take the longest, so if you're interested in mecanum start with that and buy parts after Jan 5th if the game fits it.

[EricH]

Mecanums aren't necessarily the worst at inclines, they just need a lot of grip.

A little story from personal experience: In one competition, there were two teams. Both had a similar age AND similar robots. One had a mecanum, one did not. The one with a mecanum tended to go out, orient, and slide into scoring position--a time-consuming process. The team without charged into position and turned if necessary. These two teams faced off in a qualification match. The mecanum team lost. The other team went on to win the whole event.

The problem was not necessarily the drivetrain, but its use. Had the team using the mecanum drive treated it like a four-wheel system and only used the sideways motion for small corrections, they could certainly have been up at the top. By using the (much slower) sideways motion for distance movement, they effectively lowered their scoring potential.

It's not the drivetrain that's the potential issue--it's how you use it. I don't care if you have a two-wheel caster robot, a six-wheel dropped center, a mecanum, or any other type of drive; all have their weaknesses. All have their strengths. You need to use the drive to maximize strengths and minimize weaknesses. And what type of drive you use should be a function of what the game calls for. Choose a drive to fit the game strategy you employ--then use the off-season to investigate other drive systems.

[JesseK]

By using the (much slower) sideways motion for distance movement, they effectively lowered their scoring potential.

There should be no reason a mecanum drive moves sideways slower than it does forward/backward, unless the team was using rollers that were a.) not at 45 degrees or b.) tightened to gain more forwards/backwards grip at the cost of sideways speed or C.) flawed via code that wasn't producing the maximum PWM signal when it should have been -- I saw that in a VEX algorithm at this weekend's Va. FTC tournament. In either case it was a design decision that also hurt them in their implementation, not necessarily just the driving decisions.

Ideally, mecanums should be able to produce truely holonomic drive trains; FRC simply lacks the processing on the controller to properly calculate the unit vectors for smooth movement. As a reault most teams settle for a 16-sector lookup table or dump that altogether and stick with robot-centric (normal skid + a bit of lateral sideways movement).

[EricH]

Originally Posted by JesseK

There should be no reason a mecanum drive moves sideways slower than it does forward/backward, unless the team was using rollers that were a.) not at 45 degrees or b.) tightened to gain more forwards/backwards grip at the cost of sideways speed. In either case it was a design decision that also hurt them in their implementation, not necessarily just the driving decisions.

Roller slip is the main reason. (It's also why a mecanum is easy to push if you can get to it.) See, going full bore forwards, the rollers aren't going to want to slip very much, due to a limited amount of resistance. But going sideways, every roller wants to slip because of the resistance from the opposite wheel on its side--which, combined with the 45-degree angle, results in sideways motion.

[JesseK]

Originally Posted by EricH

Roller slip is the main reason. (It's also why a mecanum is easy to push if you can get to it.) See, going full bore forwards, the rollers aren't going to want to slip very much, due to a limited amount of resistance. But going sideways, every roller wants to slip because of the resistance from the opposite wheel on its side--which, combined with the 45-degree angle, results in sideways motion.

I still don't see how the slip is different between front vs sideways if it was a 45-degree angle and the rollers were allows to roll freely. The force vectors from the wheels are the same -- half of the force "slips" with the roller, half is applied to friction. The only difference in going sideways is that the motors may turn the opposite direction (assume equal magnitude motor output), causing the force vectors to be opposite in direction but equal in magnitude. Thus the bot should have moved at the same speed sideways.

If it's "diagonal" lateral movement, the forces should STILL be roughly the same magnitude since none of the force vectors cancel each other out. The difference has to do with a divisor of sqrt(2) in a coefficient somewhere, but my notes/calculations on this are at home. I wish there was a way to compare notes publicly without just giving away answers to teams who are looking to figure things out for themselves.

I suppose the OP should gather from both of these posts that there is more behind the scenes than just building a mecanum bot.

[EricH]

Vector attack! Assume you have a mecanum drive arranged this way:
(front)
/// \\\
\\\ /// roller pattern, 45-degree rollers.

Now, going forwards, the vectors will go:
\/
/\ with the arrows pointing towards the front. The sideways components cancel, producing:
^^
^^

Now, for sideways:
Vectors will go
.^...v
..\.../
../...\
v....^
(45 degree angles; v's are arrows)
The front-to-back cancel (obviously), so you should get the same speed sideways in theory. The problem is that when the robot is going forwards, the rollers "jam" better than when two wheels are going opposite directions.

Also, I have noticed this on several mecanum robots. Can it be compensated for? Sure. Is it easy to program a mecanum in the first place? No. I think the current controller is adequate for the job.

For some empirical evidence: My team once decided to try out mecanum drive. So we put one on a Kitbot. We tested it against an old 4WD robot. Speed forwards was about equal (once the mecanum was revved up a bit), even with relatively slick rollers. With the mecanum going sideways, though, the 4WD would win every time. Before the mecanum got to where we wanted it, the 4WD was there, every time.
(And, if you really want to make sure you translate sideways as fast as you go forwards, try an omni-drive.)

[alex1699]

What is the type of drive that has 2 motors one that powers the wheel and the other that turn the wheel left and right, like a cars front wheel? i just built this type of system on a vex robot and i was wondering what this drive system was called. thanks

[EricH]

Originally Posted by alex1699

What is the type of drive that has 2 motors one that powers the wheel and the other that turn the wheel left and right, like a cars front wheel? i just built this type of system on a vex robot and i was wondering what this drive system was called. thanks

Crab drive or swerve drive, depending on who you ask. One motor to turn the wheels, one+ to drive (depending on how you want to do it).

[alex1699]

Originally Posted by EricH

Crab drive or swerve drive, depending on who you ask. One motor to turn the wheels, one+ to drive (depending on how you want to do it).

Thanks !!

[lukevanoort]

Originally Posted by EricH

Vector attack! Assume you have a mecanum drive arranged this way:
(front)
/// \\\
\\\ /// roller pattern, 45-degree rollers.

Now, going forwards, the vectors will go:
\/
/\ with the arrows pointing towards the front. The sideways components cancel, producing:
^^
^^

Now, for sideways:
Vectors will go
.^...v
..\.../
../...\
v....^
(45 degree angles; v's are arrows)
The front-to-back cancel (obviously), so you should get the same speed sideways in theory. The problem is that when the robot is going forwards, the rollers "jam" better than when two wheels are going opposite directions.

Also, I have noticed this on several mecanum robots. Can it be compensated for? Sure. Is it easy to program a mecanum in the first place? No. I think the current controller is adequate for the job.

For some empirical evidence: My team once decided to try out mecanum drive. So we put one on a Kitbot. We tested it against an old 4WD robot. Speed forwards was about equal (once the mecanum was revved up a bit), even with relatively slick rollers. With the mecanum going sideways, though, the 4WD would win every time. Before the mecanum got to where we wanted it, the 4WD was there, every time.
(And, if you really want to make sure you translate sideways as fast as you go forwards, try an omni-drive.)

I've read your argument several times and it still doesn't make sense to me. Unless your wheels are messed up in some way or the transmission is off that behavior should not be present. In AM Mecanum wheels, I can definitely see this happening due to over-tightening the roller bolts. On a more Airtrax-style wheel, I can also imagine this happening for the same reason (depending on how the rollers are attached to the wheel). However, in both of those cases the speed difference is a result of reducing the effectiveness of the bearings due to user error--not something intrinsic to mecanum designs. Of course, I imagine many mecanum robots experience something like the aforementioned problems, but I don't think the difference would be major enough to driving sideways to be a poor strategic choice. In fact, in the situation you describe it appears that the mecanum robot's problems are not caused by the team's choice of a mecanum drive, but more due to inadequate programming or driver practice--essentially, the drivers were not comfortable controlling a holonomic robot.

[MrForbes]

Let's see if I understand it.....going forward or backward (in the direction of the wheels), the rollers do not need to turn relative to the wheels. Going sideways (perpendicular to the direction of the wheels), the rollers always need to turn relative to the wheels.

The "lost motion" of the rollers turning when going sideways, indicates to me that this is a less efficient way to move, compared to going forward/backwards with the rollers just "going along for the ride".

Do I have it right? My old brain has trouble grasping new concepts, so I would not be surprised if I don't understand it all....but I do have a little mecanum wheel here to play with.