The first car I put in Precision Parking could rotate on the spot. Hold a direction key and the heading swung round while the speed readout sat at zero, which made all thirteen bays equally pointless. A car that turns wherever it stands has no geometry to solve.
The replacement is the kinematic bicycle model, and it is two wheels instead of four: one at the rear axle, one at the front axle, joined by a rigid bar the length of the wheelbase. It rests on two assumptions, and the sources below state both before any equation appears. The tyres never slip sideways, so each wheel's velocity lies in the plane of that wheel. The car is slow enough that this stays true.
Under those two assumptions the entire simulation is one line, and this is the line the game runs:
carA += (carV / wb) * Math.tan(wheelNow) * dt;
Heading in radians, speed in pixels per second, wheelbase in pixels, steering angle in radians, and dt from the fixed timestep everything else on this site uses. Position is just the heading resolved into cosine and sine afterwards. There is no contact solver and no per-wheel test, and the car cannot turn unless it is rolling, which was the whole point of the exercise.
The turning circle is the wheelbase over the tangent
Every wheel on the car travels a circle around one shared point. Draw a line perpendicular to each wheel and the two lines cross at that point — the instantaneous centre of rotation, which sits somewhere on the rear axle line, because the rear wheels never steer. The teaching notes I worked from derive the intersection exactly that way and then read the radius off the triangle.
That leaves a right triangle with the wheelbase on one side and the radius on the other. The wheelbase is opposite the steer angle, the radius is adjacent to it, so tan(delta) = L / R and rearranging gives the whole model:
R = L / tan(delta)
Two consequences fall out immediately. Steering is a curvature control rather than a rate control, and the relation is a pure ratio, so it does not care whether the numbers are metres or pixels or furlongs. The same formula applied at a 1:8 scale gives a 1:8 circle, which is why the game could pick its own unit and never revisit the decision.
| Steering angle | tan(delta) | Radius, L = 2.6 m | Radius, L = 0.3302 m |
|---|---|---|---|
| 10 degrees | 0.176 | 14.7 m | 1.87 m |
| 20 degrees | 0.364 | 7.1 m | 0.91 m |
| 30 degrees | 0.577 | 4.5 m | 0.57 m |
| 40 degrees | 0.839 | 3.1 m | 0.39 m |
The 2.6 m column is a wheelbase I picked, and nothing in the model depends on the car being any particular size. The 0.3302 m column is the wheelbase quoted for the F1TENTH research platform on the page in the sources; the radii beside it are the same tangent applied to that number. The two columns differ by a constant factor of 7.87, which is the ratio of the wheelbases and also, exactly, the ratio of every pair of radii.
The bottom-left entry is the one worth staring at. A radius of 3.1 m from the centre of the car is a tight parking manoeuvre and nothing else, and the model is honest about that rather than flattering: the yaw rate is the speed multiplied by the curvature, so the time a turn takes falls as the car speeds up and the size of the turn does not change at all.
The same formula in pixels, with a handbrake
Precision Parking works in canvas pixels. The car is 70 px long, the wheelbase is 46 px, and full lock is 0.53 radians. The code comment says that combination gives a centre-line radius of 78, and the tangent says 78.5, so the comment was right to within half a pixel.
| Wheel angle | Wheelbase | Radius from the centre line | In car lengths |
|---|---|---|---|
| 0.10 rad | 46 px | 458.5 px | 6.6 |
| 0.25 rad | 46 px | 180.2 px | 2.6 |
| 0.40 rad | 46 px | 108.8 px | 1.6 |
| 0.53 rad (full lock) | 46 px | 78.5 px | 1.1 |
| 0.53 rad (handbrake) | 30 px | 51.2 px | 0.7 |
The handbrake is the one place I bent the model rather than extending it. Instead of faking a slide, it swaps the 46 px wheelbase for a 30 px one, which tightens the circle to 51 px for real — under three quarters of a car length. The cost shows up in the same arithmetic. The handbrake also caps speed at 85 px/s, so a full circle takes 3.8 seconds against 2.9 seconds at full throttle and full lock. The circle shrinks, and the lap gets slower, and there was no way to have both.
Reverse needed no code at all, which is the part I did not expect. Speed appears in the numerator of the yaw term, so a negative speed flips the sign of the rotation and the tail swings toward the direction the wheel is pointed. The parking game's reverse bays are the fastest ones on the lot for exactly that reason, and the model handed that over without a single conditional.
The reference point is a choice, not a detail
The form above is written about the rear axle, which is the convenient choice because the rear axle's velocity points straight along the car's heading. Write the same model about the centre of mass and that stops being true, so a sideslip angle appears in the position equations:
beta = atan( lr * tan(delta) / L ), with L = lf + lr
With the centre of mass halfway along a 2.6 m wheelbase, 30 degrees of lock puts beta at 16.1 degrees. That is a large angle for a quantity that the rear-axle form does not mention. The centre of mass then rides an arc of 4.69 m where the rear axle rides 4.50 m, and if the two forms are handed the same speed number they disagree about the yaw rate by 4%. Hand them the speed each point actually travels and they agree exactly. The choice of reference point is not a modelling assumption that can be left implicit; it decides what the speed variable means, and mixing two conventions in one file is how a car ends up steering from its boot.
Where the kinematic assumption stops being true
The model only holds while the tyres stay gripped, and grip runs out with speed. A racing control paper that uses this exact model for a small electric car and abandons it for a tyre-slip model on a full-size one gives the reason in one line: at higher speed the lateral slip becomes considerable and the kinematic model stops describing the vehicle. That failure is the subject of the piece on slip angle, and it is why the fast games here do not use this model.
A kinematic car has no weight transfer, no understeer, no oversteer and no drift, because it has no forces in it at all. Push a game like Highway Rush 3D through a corner at racing speed with this model and the car will hold a perfect line forever, which is a lie that a player feels within one corner.
The honest summary is that the model buys a turning circle, a wheelbase and a truthful reverse for four lines of trigonometry, and it charges the price of every behaviour that depends on the tyres being asked to do too much. For a car park, that is not a compromise. It is the design.
Pros and cons
Pros
- The whole vehicle state is one multiply, one tangent and one add, so a physics engine never has to exist.
- Reverse, the handbrake and the parking geometry all fall out of the same equation rather than being special cases.
- It is scale-free, so the unit of length is a presentation decision instead of a tuning decision.
- The turning radius can be predicted on paper and checked against the running game, which makes the model testable.
Cons
- Nothing above walking pace is modelled correctly, so the same file cannot serve a racing game.
- A stopped car cannot rotate at all, which means a player wedged against a wall has exactly one escape and it is the reverse key.
- It needs a wheelbase and a maximum lock as inputs, so the handling is authored rather than discovered.
- Every slip-driven behaviour, from a drift to a lockup, has to be faked on top or left out.
Sources
- MSU Autonomous Vehicles — Vehicle Models — the instantaneous centre of rotation, the derivation of tan(delta) = L / R from the zero-slip assumption, and the 0.3302 m wheelbase used in the second column above.
- barc: system models — the centre-of-mass form with the beta term, its citation of Rajamani's Vehicle Dynamics and Control chapter 2, and the note that the model is only good while the slip angle is a few degrees.
- Towards Safety Assured End-to-End Vision-Based Control for Autonomous Racing — the yaw-rate term as it appears in a working controller, and the statement that the kinematic model assumes no tyre slip at low speed.