The RumiCar Simulator is a development environment where you write and run autonomous-driving algorithms entirely in your browser. It reproduces the same sensor setup as the real RumiCar vehicle — three front ToF distance sensors plus wheel encoders — and executes C / Python / JavaScript programs as-is. This article looks back over its development, dated, using only the public record: the release notes and community posts on GitHub.
Design pillars
- Zero binary assets — vehicles, courses, and effects are drawn procedurally at runtime; there is not a single image file
- Zero external libraries or CDNs — no npm packages either
- Deterministic — the same input reproduces the same result, byte for byte. 52 verification gates ship with the repository; anyone can run
node wf_run_all.mjsand check with their own hands - Real-car compatible — Arduino C++ programs written in the simulator run unmodified on a real RumiCar
A development timeline, from the public record
June 14, 2026 — the first outside review. An AI (Claude) operating the simulator in a browser posted a first-impressions review, calling the physics “honest” and proposing optional sensor-noise injection and a friction-circle overlay — both later implemented.
July 5, 2026 — the third-generation driving engine, “Precise Dynamics v2”. A ground-up rewrite to four-wheel (two-track) physics with per-wheel loads and momentum-exchange contact (development report #28). Its defining stance: “don’t pray for compatibility — prove it every time.” The default physics stayed byte-identical and every past race record’s verification hash still held, machine-checked on every commit throughout the rewrite. The measurement-first style was also established here: “can drifting beat grip?” was answered with a 20-cell measured NO — negative results published with their mechanisms.
July 13, 2026 — v4.0.0: performance and correctness. Changing the numerical integration scheme cut computation steps to about one-ninth, and the slope-gravity model was corrected from “looks plausible” to physically directed (behind-the-scenes #29). Opt-in realism arrived too: the update rate and outliers of the real ToF sensor (VL53L0X). The default teaching physics remained untouched.
August 2, 2026 — the public GitHub repository opens (v5.0.0). Full source, the verification gates, and the Docker setup were published, so anyone can clone it and run their own instance.
August 5, 2026 — v7.3.0. The release notes document the journey from v5.1 to v7.3. Highlights:
- Faster startup (first course drawn: 700 → 608 ms) and a wide-screen layout
- C arrays, plus C ports of two advanced samples — machine-verified identical to their Python versions across all 12,863 frames
- A real-device ToF optics model, rain tires, gearing, suspension DOF, and continuous steering — all optional equipment; with the defaults, not a single byte changes
- Banked corners (superelevation), whose limit speed matches the closed-form theory to 10-16
- “Learn and grow” features: championships, per-language ladders, challenge badges, and sector-time comparison
August 7, 2026 — the English README. The full picture is now accessible to developers worldwide.
What this development stands for
Reading the public reports end to end, a consistent stance emerges. Compatibility is proven, not hoped for (byte-identical teaching physics, hash-reverified records). Negative results are published (“drifting is never faster” — with 72 measured cells to show for it). Measurement over intuition (a feature’s effect is isolated to its source before it is credited). The development is carried out by an AI (Claude) under human supervision and approval — and that process itself is public on GitHub.
Try the simulator here — free, no installation. The source is on GitHub, and questions and proposals are welcome as issues, in English or Japanese.