My team is getting mecanum wheels this year and I wanted to start coding autonomous functions. I’m planning for a 6-motor drive where L1, L3, R1, and R3 are mecanum wheels and L2 and R2 are omni wheels. My question is if I need the sin(pi/4) for the mecanum wheels because the force is at a 45-degree angle or if rotating a mecanum wheel brings the robot forward the circumference of the wheel (4pi inches).
This is my code right now
//Drive Foreward or Reverse
void Drive(int inch){
L1.spinFor((inch*90/M_PI/sin(M_PI/4)),deg,false);
L2.spinFor((inch*90/M_PI),deg,false);
L3.spinFor((inch*90/M_PI/sin(M_PI/4)),deg,false);
R1.spinFor((inch*90/M_PI/sin(M_PI/4)),deg,false);
R2.spinFor((inch*90/M_PI),deg,false);
R3.spinFor((inch*90/M_PI/sin(M_PI/4)),deg,true);
}
//Strafe Right or Left
void Strafe(int inch){
L1.spinFor((inch*90/M_PI/sin(M_PI/4)),deg,false);
L3.spinFor((inch*-90/M_PI/sin(M_PI/4)),deg,false);
R1.spinFor((inch*-90/M_PI/sin(M_PI/4)),deg,false);
R3.spinFor((inch*90/M_PI/sin(M_PI/4)),deg,true);
}
//Turn Right or Left
void Turn(int degree){
L1.spinFor((degree*4),deg,false);
L2.spinFor((degree*4),deg,false);
L3.spinFor((degree*4),deg,false);
R1.spinFor((degree*4),deg,false);
R2.spinFor((degree*4),deg,false);
R3.spinFor((degree*4),deg,true);
}
Given that mecanum are very resistant to pushing… why add complexity/drag/etc?
What drag is being added @turbodog?
Friction between wheels/floor. Axle/bearing friction. More inertia when accelerating/decelerating.
As far as your question goes… mecs are 40%(?) slower in forward/back movement than omnis, so yeah, you’re going to have to do a little math.
Where did you get the 40% number. And don’t all drivetrains have to deal with axle friction. Also the drivetrain would have the same max rpm regardless of wheels so the inertia isn’t any different.
You’ll spin your omni wheels and mecanum wheels the same amount to drive forward, since they have the same radius.
It’s from memory, which is why I put a “?” behind it. I think your omnis are going to be a problem if you want to use the mecs to move diagonally, or other non-orthagonal directions.
Best advice for running mecs… get a driver that can take advantage of their benefits. If you drive them as omnis, they are worse. If your driver has quadcopter experience… that’s a good place to start. especially if they can nose-in hover, fly figure 8 patterns, etc.
But the mec’s rollers will turn somewhat, lowering your speed.
Build it and test it if you want to be certain.
1 Like
I have and am. I don’t post half-baked info. Otherwise I indicate so. The magnitude of the speed impact is from memory, hence the question mark on the 40% mentioned above.
Very cool! Maybe you could send a video when you get the chance?
I found this chart on an old post but strafing with mecs moving the robot at the same speed as a normal wheels feels wrong to me, would be apriciated if someone who has them could confirm.
1 Like
The graphic is correct; I’ve come up with a reasonable visual proof.
Imagine unwrapping a mecanum wheel’s outer surface and laying it on the ground. It works the same, just not wheel shaped. This is the black rectangle with a length of 4pi. The lines sort of represent the rollers.
Then imagine sliding the floor sideways underneath the unwrapped wheel. You can imagine that sliding the floor sidways 4pi inches would push the wheel forward 4pi inches, since the line that defines this motion is at a 45 degree angle. If this were a wheel, and not an unwrapped wheel, 4pi inches would correspond to one rotation of the wheel. So rotating the wheel forward once would slide the robot sideways by the circumference of the wheel e.g. the ratio between forward motion and sideways motion is 1:1.
Usually, mecanum wheels strafe much slower than they travel forward (and they do travel forward at the same speed as omnis if built well 
) due to inefficiencies, not math.
3 Likes
The ratio is sqrt of 2.
Last year, we used macanum with gear up. It’s very complicated.
Read the above posts for a good explanation of why the ratio is 1:1.
@2775Josh. Based on this graphic wouldn’t the robot move sqrt 2 times faster in the diagonal direction because it goes along the diagonal line which is sqrt 2 times as long?
Mecanums move slower by a factor of sqrt2 when going diagonally (as mentioned in the graphic you sent).
In that case, if I set up the drivetrain so the mecanum wheels are in a square and the omni wheels are in the middle of each side (as shown here) then the mecanum wheels have to spin exacly twice as fast because they move sqrt(2) times slower but have to move sqrt(2) times as much because its on the diagonal of the square. So the new problem becomes how do I have the omni wheels move half as fast as the mecanums with a PID runing in the background.
current code with pid below
struct Motor{
int dis=0;
int error;
int P=0;
int I=0;
int Deg;
int PID(){
error=(dis/abs(dis))*(abs(dis)-abs(Deg));
P=error*.5;
if (error<5&&error>-5){
I=(error+I)*.5;}
else{
I=0;}
return P+I;}};
Motor l1;
Motor l2;
Motor l3;
Motor r1;
Motor r2;
Motor r3;
void Move(int Drive, int Strafe, int Turn){
L1.setPosition(0,deg);
L2.setPosition(0,deg);
L3.setPosition(0,deg);
R1.setPosition(0,deg);
R2.setPosition(0,deg);
R3.setPosition(0,deg);
l1.dis=((Drive*90/M_PI)+(Strafe*90/M_PI)+(Turn*3.5));
l2.dis=((Drive*90/M_PI)+(Turn*3.5));
l3.dis=((Drive*90/M_PI)-(Strafe*90/M_PI)+(Turn*3.5));
r1.dis=((Drive*90/M_PI)-(Strafe*90/M_PI)-(Turn*3.5));
r2.dis=((Drive*90/M_PI)-(Turn*3.5));
r3.dis=((Drive*90/M_PI)+(Strafe*90/M_PI)-(Turn*3.5));
do{
l1.Deg=L1.position(deg);
l2.Deg=L2.position(deg);
l3.Deg=L3.position(deg);
r1.Deg=R1.position(deg);
r2.Deg=R2.position(deg);
r3.Deg=R3.position(deg);
L1.setVelocity(l1.PID(),rpm);
L2.setVelocity(l2.PID(),rpm);
L3.setVelocity(l3.PID(),rpm);
R1.setVelocity(r1.PID(),rpm);
R2.setVelocity(r2.PID(),rpm);
R3.setVelocity(r3.PID(),rpm);
wait(20,msec);
}while (l1.error+l2.error+l3.error+r1.error+r2.error+r3.error);}
Still no.
In the drive setup you’re discussing, the speed of the left omni wheel is simply the average of the speeds of the left front and left back mecanum wheel, and the same for the right side. (This is not that obvious, but I encourage you to draw out a vector diagram to convince yourself that it’s true!)
If you find that difficult to code, maybe consider going for an all mecanum or all omni drive.
If the mecanum wheels move (1/sqrt 2) times as fast diagonaly, and the circle that they are moving across is sqrt 2 times bigger, wouldent having the omni wheels going at the same speed make the omnis spin too far and the mecanum wheels skip which would lose accuracy. The omni wheels being the same speed as the avarage of the mecanums on its side is true for going forward (1+1/2) and strafing (1-1/2) but it isn’t for turning where they have to move differnet distances. I apolagize if I am just misunderstanding how mecanum wheels work but I don’t have them yet so I can’t test myself.