Mecanum Drive Simulator: Strafe, Slip and Drift

Controls

Every control replays the whole manoeuvre on input, so the paths track a slider as you drag it. There is nothing to start.

The left panel is the floor. Dashed is the manoeuvre as commanded, solid is where the robot actually went, dotted is where its own encoders believe it went. The right panel is the four wheel rim speeds against time, with the motor’s ceiling marked. A trace sitting flat on that line is a wheel that has run out of motor; slip shows up in the left panel instead, as the gap between the solid line and the dotted one.

Theory

A mecanum wheel can only put force into the floor along its rollers’ axles. Every other direction, the roller simply turns and nothing is transmitted. Those axles sit at 45° to the wheel, so one wheel’s ground force is pinned to a single line on the floor and no amount of motor torque moves it.

Four of those lines, alternating hand, sum to anything. Write the wheel’s rim speed against the chassis twist ξ = (vx, vy, ω) and you get one row per wheel:

vᵢ = vx + sᵢ·vy + (sᵢ·xᵢ − yᵢ)·ω        sᵢ = ±1, the roller hand

Stack the four rows into a matrix A and the whole drivetrain is v = A·ξ. Three consequences, and the lab exists to make each one visible:

Four equations, three unknowns. A rigid chassis whose wheels are all gripping cannot produce arbitrary rim speeds — the extra equation says FL + FR = RL + RR, always. The residual of that check is a free slip detector you can compute from encoders alone. It fires on asymmetric slip — one wheel off the ground, one wheel on a wet patch, one wheel in the wrong corner — and is completely blind when all four slip together, which is why mecanum odometry degrades quietly.

Traction costs 1/√2. The motor’s useful drive force runs along the rolling direction, but the actual ground force is √2 times that, pointed along the roller axle — and friction caps the whole vector. So the per-wheel limit is μN/√2 and the robot’s acceleration ceiling is:

a_max = μ·g / √2

At μ = 0.85 that is 5.9 m/s² against 8.3 m/s² for the same robot on plain wheels. The mass cancels out of both, so ballast changes nothing — the opposite of a pushing robot, where weight is the whole strategy.

Diagonals cost 1/√2 too. A 45° command puts vx + vy onto two wheels and zero onto the other two, so the busy pair saturates while the robot is only moving at V_MAX / √2. Faster motors move that ceiling; nothing removes it.

The full derivation, including the odometry inverse, is in mecanum wheel kinematics.

Algorithm

Each 5 ms step, in this order. The two pose integrations at the end are deliberately separate — that separation is the odometry lesson.

1. Read the stick for this point in the manoeuvre.
2. Rotate into the robot frame if field-oriented: vx' = vx·cos θ + vy·sin θ, vy' = −vx·sin θ + vy·cos θ. Robot-oriented skips this entirely.
3. Inverse kinematics — v = A·ξ, using the matrix the firmware believes in, which is always the correct one. A mis-fitted wheel is not something firmware can know about.
4. Limit — scale the whole vector by the worst wheel, or clip each wheel on its own.
5. Wheel lag — each rim chases its target with a 0.1 s first-order response, because a velocity loop is good, not instant.
6. What the wheels demand — least-squares forward kinematics on the rim speeds, using the matrix of the robot that actually got built.
7. Solve for the forces that would make the chassis match, then apply two ceilings in order: the motor’s (there was only ever so much torque) and the floor’s (μN/√2 per wheel).
8. Whatever the floor refuses spins the rim instead. That surplus accelerates the wheel away from its commanded speed, which is wheelspin, and it is the only symptom of slip an encoder can ever report.
9. Integrate the truth from the forces that were actually applied.
10. Integrate the odometry from the rim speeds, through the firmware’s matrix — because the encoder is bolted to the wheel, not to the floor.

Nothing in there looks for slip or inserts it. Slip is step 7 refusing a force, and the drift you see is step 10 never finding out.

Guided experiments

Each one isolates a single variable. Run them in order; they build.

1. The thing you bought mecanum wheels for

Load A square that closes. The robot drives forward a metre, right a metre, back and left, and comes home 17 mm from where it started with the heading readout never moving off 0.0°. Now switch the manoeuvre to square, turning at the corners — the same square, driven the way a differential-drive robot has to. It closes too, to 4 mm. Remember that both of them work here.

What to observe: the strafing square translates in two axes and spends no heading at all doing it. No differential drive can attempt that.

2. Take the floor away

Drag floor grip from 0.85 down to 0.25, keeping the strafing square. Then do the same to the turning square.

What to observe: watch the heading, not the distance. Both robots slide and both miss home; the strafing one misses while still pointing exactly where it started, because it never commanded a rotation in the first place. The turning one loses its heading and then drives its next leg in the wrong direction, which is how a small slip becomes a large error. Every spin is a fresh chance to lose the plot, and the holonomic base simply does not take them.

Distances in this experiment move around between runs at different settings, and that is the honest answer rather than a bug: a robot sliding on all four wheels is a stick-slip system and does not land twice in the same place. Heading does not have that problem.

3. Watch the encoders lie

Load Same square, greasy floor and look at the two lines on the left panel. The dotted odometry line drives a tidy square; the solid line does not. The robot finishes 225 mm from home while its own encoders put it 133 mm somewhere else, after 1.27 m of ground passed under the wheels without moving the robot at all.

Now watch the Encoder disagreement readout. It stays at 0.000 the whole time.

What to observe: the free residual check — FL + FR should equal RL + RR on any rigid chassis — catches one wheel slipping and is completely blind to all four slipping together. That blindness is exactly why mecanum odometry fails quietly. Put an IMU on it, or dead wheels, and stop trusting the drive encoders for position.

4. The √2 ceiling

Load Diagonal dash. Stick speed is 0.60 m/s and so is the wheel top speed, so the command should be achievable. It is not: the command is clipped for 91% of the run and the robot tops out at 0.424 m/s — which is 0.60/√2 to three decimal places, reached exactly.

What to observe: on the right panel, two traces sit flat at zero while two are pinned at the ceiling. A 45° command puts vx + vy on two wheels and nothing on the other two, so the busy pair saturates at V_MAX / √2. Raise the wheel top speed and the ceiling moves with it — the 71% never changes.

5. Scale versus clip

Switch the manoeuvre to drive while spinning, push stick spin to 240 °/s, and flip Over the limit between the two settings. The path changes shape.

What to observe: scaling gives up speed on every axis and keeps the direction. Clipping keeps the forward speed and loses 27% of the rotation — the robot turns through 127° over the run instead of 92° — so it curls differently than it was asked to. Then go back to the diagonal dash and try the same switch: nothing happens, because the idle wheels were already inside the limit. That is how this bug survives testing.

6. Fit a wheel backwards

Load One wheel fitted backwards, or press W on the plots. Nothing about the code has changed.

What to observe: the robot is no longer doing anything like what it was told, and this time the residual readout does fire — large and steady rather than bursty. Note which column has exact numbers and which does not: with one wheel fighting the other three the robot is sliding continuously, so its end pose is chaotic. The residual is the number that survives, which is exactly why it is the one worth putting on a telemetry line. That is the one symptom you can read on a real robot with no IMU and no external reference. Look at the drawn robot too: the mirrored corner’s hatching points the wrong way, and the four roller lines no longer make an X.

7. Field-oriented, in one keypress

Load Field-oriented while spinning, then press O to switch back to robot-oriented and O again to return.

What to observe: robot-oriented, a forward stick held while spinning draws a rosette: the robot travels 2.34 m of path and ends up 0.30 m from where it started — 13% of its effort went anywhere. Field-oriented, the same stick travels 2.03 m and ends 2.03 m away: a dead straight line, 100%, with the body spinning the whole way along it. Six lines of trigonometry separate the two, and it is the difference between a robot a human can drive and one nobody can.

What you should observe

Pulling the seven together:

• Forward is free; sideways and diagonal are not. Every wheel contributes fully to forward motion. A diagonal uses half of them.
• Two root-two penalties, from the same 45°. Speed on a diagonal, and traction in every direction. Neither can be bought off with bigger motors.
• Mass cancels. The acceleration ceiling is μg/√2 whatever the robot weighs, which is the opposite of a pushing robot.
• Holonomic beats differential when the floor is bad, because the spins are where the error comes from.
• Odometry is the price. Not a tuning problem, not a better-encoder problem — the wheel slipping is how the drivetrain works.

Taking it to hardware

The lab is worth the twenty minutes mostly for experiment 6. Fitting a wheel backwards costs nothing here and half a day on the bench, and it is the failure you are most likely to build.

Source code

The whole drivetrain is these two functions. Geometry lives in exactly one place.

const float LX = 0.075f;      // half the wheelbase, m (wheel centre to wheel centre / 2)
const float LY = 0.085f;      // half the track, m
const float K  = LX + LY;
const float R  = 0.0485f;     // wheel radius, m
const float V_MAX = 0.60f;    // rim speed the motors can actually hold, m/s

// Inverse kinematics + saturation. vx forward, vy LEFT, omega counter-clockwise.
void driveMecanum(float vx, float vy, float omega) {
  float w[4] = {
    vx - vy - K * omega,      // front left
    vx + vy + K * omega,      // front right
    vx + vy - K * omega,      // rear left
    vx - vy + K * omega,      // rear right
  };

  float peak = 0;
  for (int i = 0; i < 4; i++) peak = max(peak, fabsf(w[i]));
  if (peak > V_MAX) {                    // SCALE, never clip
    float s = V_MAX / peak;
    for (int i = 0; i < 4; i++) w[i] *= s;
  }

  for (int i = 0; i < 4; i++) wheelLoop[i].target = w[i];   // hand to the velocity loops
}

// Forward kinematics for odometry, and the free diagnostic.
float updateOdometry(const float rim[4], float dt) {
  float vx    = ( rim[0] + rim[1] + rim[2] + rim[3]) * 0.25f;
  float vy    = (-rim[0] + rim[1] + rim[2] - rim[3]) * 0.25f;
  float omega = (-rim[0] + rim[1] - rim[2] + rim[3]) * 0.25f / K;

  theta += omega * dt;
  poseX += (vx * cosf(theta) - vy * sinf(theta)) * dt;
  poseY += (vx * sinf(theta) + vy * cosf(theta)) * dt;

  // Four equations, three unknowns. On any rigid, gripping chassis this is zero.
  // Large and steady => a wheel is in the wrong corner. Bursty => something slipped.
  return (rim[0] + rim[1]) - (rim[2] + rim[3]);
}

The derivation of those four rows, and why the residual works, is in mecanum wheel kinematics. Making wheelLoop[i].target mean something is closed-loop wheel velocity control. Building the thing is the mecanum omnidirectional robot.