Simulating a Tracked Robot: Why We Deleted the Tracks and Added 12 Invisible Wheels
If your simulated tracked robot rotates at exactly 100% of the commanded yaw rate, is the model good?
We found out, by measurement, that our 100% was a bug. A real tracked vehicle scrubs hard when it turns — its tracks grind sideways and lose a large share of the commanded rotation. A model that turns perfectly is not a tracked vehicle; it is a well-behaved differential-drive robot.
This post walks through the four modelling approaches we tried for a tracked skid-steer platform (TR600, 80 kg class) in Isaac Sim, and the measured evidence behind adopting or abandoning each one.
Why simulate at all
The robot's autonomy stack is split across two machines. Isaac Sim runs on an x86 workstation and publishes ROS 2 topics; an NVIDIA Jetson AGX Orin subscribes to them and runs cuVSLAM (camera-based localisation) and Nav2 (path planning). The simulator's job is to let the Orin-side stack be developed and tested without hardware.
The boundary is a topic contract, not shared code. Topic names, frames, message types, and QoS match the real robot exactly, so the Orin-side stack cannot tell whether it is talking to the simulator or to the real chassis driver.
That framing yields an important consequence: it decides what the simulation must get right and what it may approximate.
| Must be faithful | Can be approximate |
|---|---|
| Camera imagery (the sole localisation input) | Exact contact mechanics |
| Topic names, frames, types, QoS | Motor thermal behaviour |
| Sensor timing and noise character | Battery/power modelling |
| Gross vehicle motion and odometry error | Cosmetic appearance |
Physics engines have no "track"
No mainstream physics engine simulates continuous tracks natively. A real track is a flexible rubber belt under tension, wrapping a driven sprocket and an idler, pressed onto the ground by sprung road wheels, with grousers that bite the ground differently along and across the belt. Nothing in PhysX, ODE, Bullet, or DART represents that primitive.
Every tracked-vehicle simulation is therefore an approximation, and the engineering question becomes: which approximation preserves the behaviour you actually care about?
Start from the real machine: the sprocket never touches the ground
Before modelling anything, we measured the track's bottom surface in the manufacturer's CAD (1st-percentile z per 15 mm bin — robust against stray hardware vertices). The findings:
- Six road wheels per side at a uniform ~113 mm pitch, independently corroborating the spec sheet's "12 sets of independent suspension".
- A 600 mm contact patch centred within 22 mm of the vehicle's base frame. The real vehicle pivots essentially about its own centre.
- The drive sprocket and the idler sit 68–154 mm above the ground. They drive and tension the belt; they never touch the floor.
This was the single most consequential discovery of the project — because our first simulation model took all of its traction from the drive sprocket, a part that never touches the ground on the real machine.
Method 1 — Kinematic motion: the robot glides
Set the chassis velocity directly from cmd_vel. No contacts, no friction, no wheels.
- Pros: trivial, fast, perfectly predictable, never gets stuck.
- Cons: no slip, no scrub, no terrain interaction, no odometry error. The robot glides as if on ice.
- Use when: the simulation exists purely to move sensors through a world — e.g. early cuVSLAM bring-up.
Method 2 — Multi-link track: the temptation and abandonment of 46 links
Model the belt as a chain of N rigid links. We evaluated a third-party asset built this way: 46 individually rigid-bodied chain links, one driven sprocket, 3 carrier rollers, 7 track rollers and a front idler — on a single side.
Abandoned. Findings, in order:
- It was a single-track undercarriage, not a vehicle — no chassis, no second track, no articulation root, so a
cmd_velbridge did not apply. - It required non-default solver settings: a 120 Hz timestep, 30 position iterations, 470 instanced prims, PhysX Fabric plus Scene Graph Instancing.
- Enabling Fabric silently broke measurement — plain USD transform reads returned bit-identical values while the track visibly moved.
- Around 21 joints reported "disjointed body transforms" and snapped violently at Play.
The general verdict: 46+ bodies and constraints per side is expensive, the solver is fragile, and it buys realism that navigation work does not need. Gazebo's maintainers rejected multi-link track support for the same reasons, and commercial tracked-UGV vendors ship their official Gazebo models wheel-based. Virtual wheels are not a workaround; they are the industry standard.
Method 3 — Four virtual wheels: a failure that looks like a triumph
Delete the track and replace it with a few invisible collision wheels at the track's effective rolling radius (sprocket radius + track thickness).
Our first model placed 2 driven, gripping wheels at the drive sprocket position (342 mm behind the vehicle centre) plus 2 frictionless contacts at the front for pitch support.
Measured results:
- Yaw capture of 99.5–102.8% — it turns exactly as commanded.
- Pivot radius 342.3 mm against a predicted 342 mm — within 1 mm, in both directions.
The numbers look like a victory, and that is precisely the failure mode. With only one gripping station, lateral force balance puts the instantaneous centre of rotation on the drive axle, and both contacts roll instead of scrubbing. Yaw becomes lossless at any friction value. A real tracked vehicle scrubs hard when it turns. This model had become a polite differential-drive robot, pivoting about a point 342 mm behind its own centre.
Method 4 — Twelve distributed virtual wheels (current)
Give every real road-wheel station a driven ground contact: 6 stations per side, 12 contacts, all driven at belt speed, with ground collision disabled on the sprocket and idler.
The rationale is simply how the real machine works: on a real track, every ground-contact point on a side moves at belt speed. With a uniform contact radius that is one identical velocity command per side, so the wheels cannot fight each other.
Measured comparison:
| 4-contact | 12-contact | |
|---|---|---|
| Pivot location | 342 mm behind centre | within 45–105 mm of centre |
| Pure-turn capture | ~100% | 29–32% |
| Straight-line efficiency | ~100% | 90–92% |
| Combined move + turn | ~100% | ~0% |
The pivot moving to the vehicle centre and yaw capture dropping to ~30% are both intended — that is realistic skid-steer scrub appearing in the model. Why no amount of friction tuning changes that number is derived in the companion post.
By contrast, combined move-and-turn collapsing to ~0% is not intended and remains our main open question. Our working hypothesis is that rigid Coulomb contacts lack the progressive slip behaviour of rubber, making the transition abrupt — but that is a hypothesis, not yet a measured fact.
We make the odometry wrong on purpose
One sensor-side decision deserves its own section. Wheel odometry is deliberately not taken from the simulator's ground truth. A separate ROS 2 node computes it from wheel-joint velocities exactly as the real MCU does. The real robot has only two encoders, both on the drive motors — so when the tracks slip, the encoders still report rotation that never became motion. The simulation reproduces that same slip-blind odometry. Ground-truth pose is published on a validation-only topic that Nav2 and the EKF never consume.
A simulator that reports perfect odometry cannot exercise the localisation stack that exists precisely to deal with odometry error.
Honest limitations of the 12-contact model
- The real road wheels are independently sprung; ours are rigid. Twelve rigid coplanar contacts on a rigid chassis are over-constrained, so the load distribution is chosen by the solver rather than by physics. We measured the excess at 1.27× the ideal scrub moment (the theoretical worst case is 2×) — the contact model is sound, but it is an approximation and should be stated as one.
- Coulomb friction has only two states, stick and slide, so the progressive build-up of lateral force that rubber exhibits under slip is absent.
- There is no belt tension or flexibility, so track throw and terrain conformance cannot be represented.
Summary
| Method | Cost | Slip/scrub | Terrain | Verdict |
|---|---|---|---|---|
| Kinematic | trivial | none | none | sensor transport only |
| Multi-link track | very high | full | full | fragile; rejected industry-wide |
| Virtual wheels ×4 | low | unrealistically low | yes | wrong pivot, no scrub |
| Virtual wheels ×12 | moderate | realistic magnitude | yes | current |
Two takeaways.
Simulation fidelity is not "does it look real" but "does it reproduce the errors the system under test will face on hardware." That is why we make the odometry wrong on purpose, and why 30% yaw capture is the correct answer.
A result that is too clean is not a cause for celebration; it is a cause for suspicion. The 4-contact model's 100% yaw capture was the entrance to a three-week detour.