Kinewright is a house of motion engines, and Wheels is its second engine: how a body with exactly four wheels moves. This article is the plan for Wheels as it stood in October 2026, written down once and left as it is: what the engine does itself, what it deliberately takes from outside, which published criteria and data it leans on and how they are allowed in, and what comes next, in which order and why.
I will not update this article. The living version is the pinned post on r/Kinewright; it changes when a stage closes or the order moves. There are no dates here, on purpose.
One sentence, one level
Wheels turns a vehicle profile, a drive intent, a seed and time into a canonical vehicle pose, articulation and support state. It produces motion state, not pixels.
Its level is physics-informed, through exactly two named assumptions and nothing else: the bound past which a kinematic model stops being honest, and the threshold at which a rigid body would tip. Both are computed every frame and announced when crossed; nothing past them is simulated. Every stage below stays kinematic. The sensing and avoidance stages add models and decisions above the kinematics, not physics underneath it. The ladder is the one the human engine uses:
| Level | Meaning |
|---|---|
| Kinematic | poses and supports meet declared geometric and timing checks; this establishes no forces and no physical validity |
| Physics-informed | kinematic motion bounded by named physical identities, without simulation |
| Static balance checked | a four-wheel body is statically stable by construction; only the tip threshold applies here |
| Dynamically checked | momentum and contact forces pass declared checks; this needs a dynamics provider |
| Simulated on | a named slice ran on a named dynamics provider build |
| Hardware validated on | validated on exactly named hardware through a separately proven physical stack |
A drive that passed a kinematic or visual gate is never described as physically validated, and nothing that passes in the engine's own simulation carries over to hardware.
What the engine owns, and what it is meant to own
Built and accepted today:
The shell. Exactly four wheels in a 2×2 layout; wheelbase, two tracks and each wheel's radius and width as declared profile numbers; four steering layouts: front, rear, both axles, skid. Two- and three-wheel bodies are outside the scope entirely.
The negotiation. Every manoeuvre-and-shell pairing resolves to native, adapted, fallback or unsupported, with a reason, and the answer is predicted before the code that runs it. Clamping a command without reporting it is a defect, not a degraded success.
The drive. One intent type, from a keyboard, a scripted scene or a behaviour layer; a controller that maps it onto each profile's declared limits by a written policy; nine manoeuvres that can be invoked, interrupted, resumed and dropped.
Determinism. Closed-form arc integration, a fixed tick, a versioned journal, and replay verified byte for byte in a separate process: bytes within one JavaScript engine, twelve significant digits across engines.
The honesty bounds. The two assumptions above, reported every frame.
Mount points. A rigid transform per declared mount, so a trailer, a sensor or, much later, a seated actor can attach without rewriting the schema.
Meant to own, in the order of the table below: deterministic models of a small rover's sensors; a short local map and the avoidance decision above the same kinematics; a caution policy around moving objects; behaviour under faults and one intent contract between a scene, a test bench and a real car; a trailer.
What it will consume, by design
Tyres, suspension, traction, powertrain and brakes as physics. Never written here. A dynamics provider may own them later under an explicit contract, one named slice at a time. Until then a manoeuvre that depends on traction binds unsupported and says so.
Rendering. The engine does not draw. The videos use a plain Canvas 2D reference renderer; a Three.js lane comes later and shares nothing with the motion model.
Sensors. Models built from public datasheets of a small rover class, with their angles, rates, ranges, latency, blind cases and noise written down. No device is chosen; a real one is a separate decision.
Path planning and autonomy. Not here. Avoidance is a reactive skill with a time-to-live over a short local map: not a planner, not a perception stack.
Hardware. The engine never claims to drive a robot from a browser. The bridge is one intent contract with an expiry; calibration against a measured car is its own stage, after a car exists.
The human engine. The same world frame and the same house package for the three primitives both engines share. A seat, a steering wheel and pedals as actor contacts are a reserved seam, not a stage.
Where the data comes from, and how it is allowed in
At the start, nothing is measured. Every profile number is an engineering choice or an estimate and carries that tag. "Measured" is reserved for what a source reports; a value read off a run, a turning radius, an off-tracking, a swept width, is traced, never measured. The small platform is a generic hobby-grade front-steer body, estimated because none was bought; the paper sedan is an engineering profile. No third-party data pack enters the engine, and what is admitted enters as aggregates, never as raw rows, files or clips.
Published criteria, used as bounds and not as data
| Criterion | What it does here | Source |
|---|---|---|
Kinematic honesty bound, ∣a_y∣ ≤ 0.5·μ·g
|
the line past which a single-track kinematic model stops being honest; announced when crossed; the controller holds the shell under 0.9 of it | Polack, Altché, d'Andréa-Novel and de La Fortelle, 2017; fitted on one nine-degree-of-freedom model of one class of car, not validated for small platforms |
Tip threshold, a_y/g ≤ t/(2h)
|
a rigid-body figure for a narrow track and a high centre of mass; reported as a geometric bound, never as a safety limit | the static stability factor; real vehicles roll over about 15 % earlier because they lean |
Admitted for the moving-objects stage, aggregates only
| Source | What it provides | Licence |
|---|---|---|
| THÖR-MAGNI v2.0 | pedestrian speeds, distances and approaches around a moving platform | CC BY 4.0 |
| Jülich Pedestrian Dynamics Data Archive | the fundamental diagram of pedestrian flow, read against Weidmann's; any constant comes from the values the group itself published | CC BY 4.0, with attribution |
People are moving objects in this engine, never recognised persons.
Planned
Sensor datasheets of a small rover class, for the obstacle stage. A measured car, when one exists, for the calibration stage: its turning radius and its stopping distance on two or three surfaces. Then, and only then, a profile number may be called measured.
The plan as it stood: stages and dependencies
A stage gets a size only after its definition of ready is frozen, and every stage of this engine so far came in well under its planning band. Sizes here are the kind of work and a rough band, not a calendar.
| # | Stage | What it delivers | Kind of work | Band |
|---|---|---|---|---|
| ✓ | Kinematic baseline | a shell of exactly the declared dimensions drives; changing the wheelbase changes the turning radius by exactly R = L / tan δ
|
profile schema, arc integration, journal, replay | closed |
| ✓ | Capability contract | four shells and a locked one, nine manoeuvres, every pairing bound as predicted before the code | shells, skills, the binder, a frozen lattice | closed |
| ✓ | Driveable shell | a person drives two shells with keys; manoeuvres interrupt and resume; steering turns while rolling; the records replay on three machines | controller and policy, session, drive journal, browser scene | closed |
| 1 | Obstacle scene and sensor models | static obstacles and deterministic models of a small rover's sensors: a zoned time-of-flight cone, a single time-of-flight or ultrasonic beam, a 360° scanning range-finder, a radar of targets with their speed, a bumper contact, wheel encoders and an inertial unit, each with documented angles, rates, ranges, latency, blind cases and noise, so everything above them runs headless and replays | scene, sensor models from datasheets | medium |
| 2 | Reactive avoidance | observations become a short local map, a polar histogram or a small occupancy grid; candidates of speed and curvature are carried by the engine's own arc integration over a horizon and checked as swept corridors against the obstacles, with stop and slow-down zones and the time to collision, so what the vehicle decided and what it did share one kinematics and one replay | skills above the existing engine | medium |
| 3 | Moving objects and a caution policy | objects' speed estimated from scans without a camera, a moving-or-static class, and a policy with its numbers: a lower speed, wider safety fields, yield or wait, never cut across a moving object's course | estimation, policy, fixture scenes | medium |
| 4 | Faults and the one contract to a car | injected faults, a stale sensor, a lost heartbeat, a brown-out, a disconnected computer, a stop and its re-arm, under each of which the vehicle goes neutral; one intent contract with an expiry between a scene, a test bench and a car | fault injection, the contract | small to medium, the software half only |
| 5 | Articulation | a trailer as a full four-wheel body on two axles, on-axle and off-axle hitches, the articulation angle as state, off-tracking, reversing, and jackknife as a graded state with a margin and a reason | kinematics again, one body more | medium |
The order is deliberate: the stated purpose of this engine is a small rover, and a rover needs sensing, avoidance, caution and fault behaviour before it needs a trailer. No stage depends on hardware existing. No hardware has been chosen, and the calibration half of stage 4 waits for a car. A first playable scene after stage 1 is a separate decision, not a row.
Corrections between stages are not rows of this table. The steering ramp of the accepted shell, full lock to straight in 75 ms with no bound on how fast that rate changes, is already an input to the next stage's definition; it will be fixed there, and the pinned post will say so.
What this article is not
It is not a promise of dates. It is not a physics claim; the ladder above is the only vocabulary for that. It is not a code release; that is a separate decision with its own gate. It is not the map of the human engine, which has its own article. And it is not the current plan: it is the plan at the start. Feedback is research input we read our results against; a change of order is a decision recorded with its reason; both show up in the pinned post, which is the only version of this map that moves.
How to help
Watch the clips and answer one question: does it drive like a car of exactly these dimensions? Then say what you saw. That is how every stage of this engine is accepted, and it is how this plan will change.
