We have released RumiCar Simulator v7.5.0. The release notes below are also available on GitHub.
v7.5.0
We re-measured, and corrected, both the reason behind “drifting cannot beat grip” and how far that statement actually reaches (its scope). The driving physics is unchanged down to the byte. Until now the notes gave two different reasons (§11 and §13.8 said “because steering is only left / centre / right”, §13.14 said “because of the car’s own recovery limit”), and never said which situations the claim covered. While looking into it we found that the drift driver used for the measurements still had the sign of the counter-steer the wrong way round (sideslip angle goes negative in a left-hand slide, but the test compared it on the positive side, so counter-steer was never applied at all), so all three measurement programs were fixed and every table was taken again. Five things came out of it. (1) The reason is not the three-state steering; it is the car’s own recovery limit. Continuous steering does not change it, and neither does making the servo 64x faster (measured back in v7.2.0). The two explanations in the notes are now one. (2) “Cannot beat grip” applies to holding a deep sideslip angle (35 to 60°) inside a corridor that grip driving can geometrically follow. In a tight wall-lined hairpin (8 cases: in 6 of them the corridor’s outer radius is under the 5.84 m minimum turning radius, and in the other 2 the radius is sufficient but the car’s own body will not fit), grip driving that traces a steady arc fails to complete the 180° in all 16 variations (8 cases x 2 drivetrains; the best-held line reached 121°). Actively sliding, on the other hand, got through 5 of those 8 cases with rear-wheel drive without touching a wall (0.03 to 0.71 m of clearance; all-wheel drive scores 0 of 8 on the same sweep). But the peak sideslip in those runs is only 12 to 15° — a shallow slide — and in none of the 5 was any counter-steer ever applied (the minimum angle the servo actually reached is 0%). So we cannot claim that a deep drift is the only way through, and getting through is not down to fixing the sign either: reverting just the sign to the original bug still gets through. What did the work was how the run is composed and how far the sweep reaches. (3) There is exactly one window in free space where drifting is faster than grip. Sweeping 36 cases found one (tightest radius x low-grip surface x 180° x rear-wheel drive), where the run went from 6.03 s to 5.32 s, 11.9% faster, and it held 3 out of 3 with entry speed varied by ±10% (peak sideslip there is 27°, which is not shallow). Of the remaining 35 cases, four are up to 6.9% faster on a single run but fall apart once entry speed moves by ±10% — what fails there is not speed but robustness. (4) What is fast is the shallow slide. Optimising a trail-braking style of driving beat grip in 7 of 8 cases (by up to 20.6%), and every one of those optima peaked at 14.8° of sideslip or less. Re-running the same search budget under a constraint to slide deeply (peak of 20° or more) produced nothing faster than the shallow optimum in all 16 rows that yielded a solution. In 5 of those 16 the deep solution still beats grip, though, so the accurate statement is not “sliding deeply loses to grip” but “sliding deeply never gets you the fastest time“. (5) With two cars on track, turning sideways to block the road makes you slower. The leader’s average lap went from 15.78 s to 23.19 s (+47%) and its position went from 582 m ahead to 69 m behind. Descending gradients were re-measured too, across 72 cases, and none of the 72 is faster than grip. What the gradient changes is the mechanism: on a low-grip 180° hairpin, rear-wheel drive spends its whole speed budget on every gradient and drops into a pivot on the spot, whereas all-wheel drive keeps some speed on a 10° descent (minimum speed while sliding is 0.11 to 0.57 m/s on the flat and at 5° — essentially stopped — against 1.67 to 2.04 m/s at 10°). Note that the figures in (3) and (4) come from --full (the systematic sweep, about 30 minutes) of the bundled gate wf_drift_reexam.mjs; the default run (about 2.5 minutes) uses a reduced grid and confirms the same conclusion in a fraction of the time. Every table is also the best result within a finite sweep grid — it means “not found within that grid”, and better conditions outside the grid cannot be ruled out. So that none of this has to be argued from impressions again, a permanent automated check, wf_drift_reexam.mjs, now ships with the simulator (the suite goes from 54 to 55 gates). Re-measuring also turned up two mistakes of our own, which are fixed (a unit mismatch in the recovery phase, and counting a car that was rolling backwards as having completed the corner). The physics notes (Japanese and English) and the in-app explanations were rewritten to match, and a machine check was added so the Japanese catalogue and the HTML body cannot drift apart. The driving physics, the tabletop determinism hashes f0-f3, the verifyHash of official records and share URLs are all unchanged.
Verifying this release yourself
cd Simulator
node wf_run_all.mjs # the full assertion-gate suiteThe suite runs from a fresh clone with no dependencies beyond Node.js.
The real-browser checks under Simulator/browser/ additionally need npm install and a display.