Mecanum Wheels - How do they work?

[Team3763 Adam]

My team and I are looking at using Mecanum wheels for this year's competition as a means of strafing. My few questions are:

• Could they be our only form of Drive wheels for forward and side movement, or would it be best to pair them with another set of wheels to allow for seperate forward and side movements?

• How do they work?

• How should they be mounted on a Robot Chassis. IE should the diagonal wheels be slanted in opposing directions - either away from the center of the robot or towards. ///-CenterOfRobot-\\\ OR \\\-COR-///

• What form of drive in LabVIEW would they be programmed with? Arcade but with different inputs on the joysticks? Or...

Any and all diagrams/pictures/screenshots of LabVIEW are welcome!

[Chris_Ely]

Mecanum wheels have rollers positioned at 45 degrees from the axis of rotation. This transfers the force from the rotation of the wheel by the motor 45 degrees from the axis of rotation. When you power each wheel independently and vary the speed and direction the wheels rotate, you can achieve omnidirectional motion. So, to answer you first question, you need 4 wheels (2 left, 2 right) to drive forward, backward, sideways, and anything in between. The rollers should be oriented such that they form an X when you look from above. If you search "mecanum" in the white papers section, you will find more in depth explanations and example code.

[Team3763 Adam]

What is the "White Papers Section," and with that answer arose another question - do each of the four wheels need to have their own motor/gearbox config.?

[Chris_Ely]

What is the "White Papers Section," and with that answer arose another question - do each of the four wheels need to have their own motor/gearbox config.?

The white papers section is located in CD-media, above the orange bar at the top of the page. Because each wheel needs to rotate independently, each wheel must have its own motor and gearbox.

[Team3763 Adam]

Originally Posted by luckof13

...each wheel must have its own motor and gearbox.

Ah there's the complications I was looking for! It's never that easy! Only kidding, but thank you for the help guys, with this knowledge I should be able to figure out everything I need.

[efoote868]

You'll also want some form of suspension or flex in your frame to keep each wheel in contact with the ground (at a minimum), you'll do best with an equal weight distribution on your wheels, and the wheels should be in a square.

Best of luck.

[Ether]

Originally Posted by efoote868

...and the wheels should be in a square

Why?

[efoote868]

Originally Posted by Ether

Why?

In my experience, it made it easier to rotate while driving in a straight line. Rectangles will do OK; the square part isn't as critical as keeping all wheels on the ground.

FIRST may try their best to keep the carpet flat, but every year there seems to be bumps and places to get hung up on. The kinematics aren't easy to resolve when only 3 of the 4 wheels touch the ground.

[Ether]

Originally Posted by efoote868

In my experience, it made it easier to rotate while driving in a straight line.

A more likely cause is that the rectangular bot had poorer weight distribution or the frame wasn't flexible enough to keep traction on all 4 wheels or the rollers were binding. There's no kinematic reason why mec needs to be square in order to rotate properly.

[efoote868]

Originally Posted by Ether

There's no kinematic reason why mec needs to be square in order to rotate properly.

Quickly sketching the vectors on a napkin, it looks like to me that wheels in a square will optimize spinning (maximize total torque on robot) for a particular wheel distance d from center of robot; perhaps you could comment? The other quick example I could think of is if the wheels were in a line. Then the total torque about center is 4*|F||d|*root(2)/2, versus 4*|F||d| with the wheels in a square.

[Ether]

Originally Posted by Ether

A more likely cause is that the rectangular bot had poorer weight distribution or the frame wasn't flexible enough to keep traction on all 4 wheels or the rollers were binding. There's no kinematic reason why mec needs to be square in order to rotate properly.

Originally Posted by efoote868

Quickly sketching the vectors on a napkin, it looks like to me that wheels in a square will optimize spinning (maximize total torque on robot) for a particular wheel distance d from center of robot; perhaps you could comment?

Let's consider the ideal case first, in order to understand the physics: mec wheels with no roller friction and no roller axial or radial free play; floor surface is non-compliant (ignore carpet compression and stretching).

Refer to attached sketch


First, the kinematics (ideal):

Let P be the perimeter of the rectangle formed by the centers of the 4 wheels:

P = 2*(Lwb+Ltw);

Let r be the wheel radius

For a given vehicle rotation speed omega_v (radians/sec) of a vehicle rotating in-place about the center of the aforementioned rectangle (i.e. Vx=0 and Vy=0), the wheel rotational speed omega_w (rad/sec) will be given by

omega_w = (1/r)*K*omega_v .... (see page 7 of my mec kinematics paper)

... where K = (Lwb+Ltw)/2 = P/4;

solving for omega_v and substituting for K:

omega_v = (1/K)*r*omega_w = (4/P)*r*omega_w;

So you can see that the vehicle rotation speed for a given wheel rotational speed, is the same for all rectangles with the same perimeter.




Now, the forces and torques (ideal):

wheel torque: tau;

carpet force component in plane of wheel and floor: Ff = tau/r;

total carpet force in direction of mec roller axis: Fr = Ff*sqrt(2) = (tau/r)*sqrt(2);

Let the ratio f be defined as: f = Ltw/Lwb;

theta = atan(f); .... (see sketch)

alpha = pi/4 - theta;

carpet force component in direction of vehicle rotation: Fv = Fr*cos(alpha) = (tau/r)*sqrt(2)*cos(alpha);

distance from center of rectangle to center of wheel: D = (1/2)*sqrt(Lwb^2+Ltw^2);

P = 2*(Ltw+Lwb) = 2*Lwb*(f+1) => Lwb = (1/2)*(P/(1+f)) & Ltw = f*(1/2)*(P/(1+f));

so D becomes:

D = (1/2)*sqrt(((1/2)*(P/(1+f)))^2+(f*(1/2)*(P/(1+f)))^2);

D = P*sqrt(1+f^2)/(4*(1+f));

torque about center of rectangle: Tv = Fv*D;

Tv = ((tau*sqrt(2))/r)*cos(alpha)*(P*sqrt(1+f^2)/(4*(1+f)));

Tv = ((tau*sqrt(2))/r)*cos(pi/4 - theta)*(P*sqrt(1+f^2)/(4*(1+f)));

Tv = ((tau*sqrt(2))/r)*cos(pi/4 - (atan(f)))*(P*sqrt(1+f^2)/(4*(1+f)));

using:

cos(pi/4-atan(f)) = (1+f)/(sqrt(2)*sqrt(1+f^2));

... Tv simplifies to:

Tv = ((tau*sqrt(2))/r)*((1+f)/(sqrt(2)*sqrt(1+f^2)))*(P*sqrt(1+f^2)/(4*(1+f)));

Tv = (P*tau)/(4*r);

Now that I've done all that trig and algebra, here's a much quicker way:

carpet force component in plane of wheel and floor: Ff = tau/r;

total carpet force in direction of mec roller axis: Fr = Ff*sqrt(2) = (tau/r)*sqrt(2);

carpet force component in direction of wheel axis: Fa = tau/r;

torque around center of rectangle:

Tv = (tau/r)*(Ltw/2) + (tau/r)*(Lwb/w) = (tau/r)*(Ltw+Lwb)/2 = (tau/r)*(P/4);

So the torque on the vehicle is the same for all rectangles with the same perimeter.




Now consider the non-ideal case with roller free play, roller friction, and carpet compression and stretching.

This will be an intuitive explanation.

In the case where Ltw >> Lwb (very wide configuration), the fore/aft component of the wheel translational motion is much larger than the strafing component.

In the case where Lwb >> Ltw (very long narrow configuration), the strafing component of the wheel translational motion is much larger than the fore/aft component.

Since a non-ideal mec wheel is considerably less efficient in the strafing direction, you'll see more losses when trying to rotate when Lwb >> Ltw.


Bottom line:

For the small deviations from square typically seen with FRC mec bots, and for properly functioning mec wheels on a frame that's sufficiently flexible to maintain traction on all 4 wheels, the bot should turn fine - and certainly better than a skid-steer with the same dimensions.

[Chris_Ely]

Originally Posted by efoote868

You'll also want some form of suspension or flex in your frame to keep each wheel in contact with the ground (at a minimum), you'll do best with an equal weight distribution on your wheels, and the wheels should be in a square.

You don't need suspension. My team ran mecanum in 2011, which had a flat floor like this year, just fine. Our wheels were also in a rectangle orientation.

[Ether]

Originally Posted by luckof13

You don't need suspension.

He didn't say you need compression. He said you'll want compression or frame flex.

[Orion.DeYoe]

Originally Posted by Team3763 Adam

My team and I are looking at using Mecanum wheels for this year's competition as a means of strafing. My few questions are:

• Could they be our only form of Drive wheels for forward and side movement, or would it be best to pair them with another set of wheels to allow for seperate forward and side movements?

• How do they work?

• How should they be mounted on a Robot Chassis. IE should the diagonal wheels be slanted in opposing directions - either away from the center of the robot or towards. ///-CenterOfRobot-\\\ OR \\\-COR-///

• What form of drive in LabVIEW would they be programmed with? Arcade but with different inputs on the joysticks? Or...

Any and all diagrams/pictures/screenshots of LabVIEW are welcome!

When using mecanum wheels you need to put one on each corner with the axles parallel to the front bar of your frame (i.e. don't angle the wheels at all). Off the top of my head the rollers on the wheels should make an "x" pattern when viewing them from the top of the drivetrain. Check the documentation on www.andymark.com or www.vexrobotics.com/vexpro to be sure.
There is a good whitepaper here on Chief Delphi describing some of the physics concepts behind the wheel and clearing away some of the misconceptions about the wheels. It was written based off some of Ether's posts but I don't remember who it's by (can someone post a link to this whitepaper if you know which one I'm referring to?).
As for programming, there should be a "holonomic drive" VI in the WPI library VIs section that does the math for mecanum automatically. You have one joystick axis for forward and backward movement, one for strafing, and one for rotation (much like arcade).

[Team3763 Adam]

Originally Posted by Orion.DeYoe

As for programming, there should be a "holonomic drive" VI in the WPI library VIs section that does the math for mecanum automatically. You have one joystick axis for forward and backward movement, one for strafing, and one for rotation (much like arcade).

This shouldn't be too hard to figure out, then, and I will be looking in LabVIEW Friday.


Also to sketch a rough text-based diagram:
Where "///" represents the 45* rollers of the Mec Wheels.
And "|" "-" represent the Robot's Frame.

|---|------------|---|
|\\\|...............|///|
|....|...............|....|
|....|...............|....|
|....|...............|....|
|///|...............|\\\|
|---|------------|---|