Mecanum Drive control

[Ether]

Originally Posted by TylerHarmon

Mecanum wheels slip, which completely destroys the value/quality of the ticks that your encoder returns. How many times a mecanum wheel turns cannot directly be translated into distance.

Whenever I see someone post "Mecanum wheels slip" I always wonder what they think that means.

[Oblarg]

Originally Posted by Ether

Whenever I see someone post "Mecanum wheels slip" I always wonder what they think that means.

Well, their effective COF is decreased by a factor of 1/sqrt(2), so I suppose they are more prone to actually slipping.

[Ether]

Originally Posted by Oblarg

Well, their effective COF is decreased by a factor of 1/sqrt(2), so I suppose they are more prone to actually slipping.

Is that what you meant, Tyler? They're more prone to slipping in a pushing match or hard acceleration? But most of the time, if you're careful, they won't slip?

Or did you mean they slip all the time, which completely destroys the value/quality of the ticks that your encoder returns, and therefore how many times a mecanum wheel turns cannot directly be translated into distance?

[TylerHarmon]

Originally Posted by Ether

Is that what you meant, Tyler? They're more prone to slipping in a pushing match or hard acceleration? But most of the time, if you're careful, they won't slip?

Or did you mean they slip all the time, which completely destroys the value/quality of the ticks that your encoder returns, and therefore how many times a mecanum wheel turns cannot directly be translated into distance?

Hi Ether,

When I say that mecanums slip, what I mean is that the rollers on mecanums do not consistently spin. While you can control how far a mecanum wheel spins, the free-spinning rollers that make up the wheel do not regularly spin.

In both pushing matches and hard acceleration, the rollers on mecanum wheels tend to spin in irregular ways, which essentially results in an inconsistent measure of speed and position.

I think that mecanums can be very useful for strafing and maneuverability, but trying to precisely control their motion can be very difficult if not impossible because of the free-spinning rollers.

[Ether]

Hi Tyler,

Thank you for taking the time to respond to my question.

Some of the things you wrote are still a bit ambiguous to me. I think it would be enlightening to discuss it further. Would you be interested in doing that? I don't want to pester you if you don't want to do that.

[berkleyfanatic]

In 2015 my team used encoders and a gyro for mecnuam and I'm pretty sure it worked out good for us

[AriMindell]

Originally Posted by Ether

Tyler,
Some of the things you wrote are still a bit ambiguous to me. I think it would be enlightening to discuss it further. Would you be interested in doing that? I don't want to pester you if you don't want to do that.

I, for one, would love to see that discussion

[Ether]

Originally Posted by AriMindell

I, for one, would love to see that discussion

OK, I'll kick it off with this.

If you make certain simplifying assumptions (which under certain adverse conditions may not be too realistic; more on this if there is interest), mecanum wheels do not "slip" unless they are torqued so hard that they lose traction. And yes, they lose traction more easily than normal wheels because of the nature of the reaction forces between the floor and the rollers.

Under these assumptions, the rollers are rolling, not slipping. The rolling of the rollers is what makes mecanum do what it does.

The computation to turn a driver command of a simultaneous combination of forward/reverse plus strafe_right/left plus rotate_CW/CCW into four wheel speeds is called inverse kinematics. The four wheel speeds resulting from this computation will cause the desired robot motion, if the resulting reaction forces between the roller and floor are less than the available traction so that the rollers roll without slipping.

On the other hand, taking 4 instantaneous measured wheel speeds (one for each wheel) and turning them into the corresponding instantaneous robot motion (forward/reverse plus strafe_right/left plus rotate_CW/CCW) is called forward kinematics.

If the rollers are not slipping, it is possible to do the forward kinematic computation. And in theory, you could integrate the resulting instantaneous robot motion over time to find the robot position and heading. I do not know if any teams have done this with a fruitful degree of success.

[Oblarg]

I could be wrong, but I believe he's suggesting that mecanum rollers are prone to "sticking" and not rolling freely (this would be consistent with my experience of certain brands/models of mecanum wheel). Under these conditions, the wheels of a strafing mecanum robot could be said to "slip," and throw off the correspondence between encoder readings and movement.

[TylerHarmon]

Originally Posted by Ether

Hi Tyler,

Thank you for taking the time to respond to my question.

Some of the things you wrote are still a bit ambiguous to me. I think it would be enlightening to discuss it further. Would you be interested in doing that? I don't want to pester you if you don't want to do that.

Sure, if you want to discuss it further we can. My main point is that the rollers on mecanum wheels...
... freely spin, which allows a robot to strafe, but results in inconsistent data when used with an encoder.

[AriMindell]

Originally Posted by TylerHarmon

Sure, if you want to discuss it further we can. My main point is that the rollers on mecanum wheels...
... freely spin, which allows a robot to strafe, but results in inconsistent data when used with an encoder.

Ether posted the following code for determining robot position based on the wheel velocities of mecanum wheels in another thread:

FWD = r*(w1+w2+w3+w4)/4

STR = r*(w1-w2+w3-w4)/4

Wv  = (1/k)*(w1+w2-w3-w4)/4

r is wheel radius
k is |trackwidth/2| + |wheelbase/2|
w1,w2,w3,w4 are FL,BL,BR,&FR wheel speeds in rads/sec
Wv is robot clockwise rotation rate in radians per second

The implicit assumption is that the velocity vector applied to the robot by a mecanum wheel spinning at constant velocity is constant.

are you arguing that the velocity vector created by a mecanum wheel spinning at a constant velocity is not constant or predictable, therefore that equation provides an unreliable estimate of robot position?

[TylerHarmon]

Originally Posted by AriMindell

Ether posted the following code for determining robot position based on the wheel velocities of mecanum wheels in another thread:

FWD = r*(w1+w2+w3+w4)/4

STR = r*(w1-w2+w3-w4)/4

Wv  = (1/k)*(w1+w2-w3-w4)/4

r is wheel radius
k is |trackwidth/2| + |wheelbase/2|
w1,w2,w3,w4 are FL,BL,BR,&FR wheel speeds in rads/sec
Wv is robot clockwise rotation rate in radians per second

The implicit assumption is that the velocity vector applied to the robot by a mecanum wheel spinning at constant velocity is constant.

are you arguing that the velocity vector created by a mecanum wheel spinning at a constant velocity is not constant or predictable, therefore that equation provides an unreliable estimate of robot position?

I understand all of this logic, but it just doesn't work in practice. You simply cannot achieve the precision of tank drive with mecanum wheels because the rollers on mecanum wheels sometimes spin and sometimes do not. In other words, there is a large amount of slop in the system that cannot be removed with programming.

If you show me an example of you consistently driving a set distance and/or turning a certain amount without a gyroscope, only with encoders then I will accept that mecanums can be well controlled with encoders. However, based on the mechanical nature of mecanum wheels, such motion cannot practically be controlled.

[TylerHarmon]

Yes, that is what I'm saying. The force vectors are not reliable in practice, only in theory. The variable "rolling" of the rollers causes this effect. Because those force vectors change (not only in magnitude, but also in direction) you simply cannot achieve precise motion control of a robot running on mecanums.