Inspect the applied vehicle
In Studio → Vehicle, open Model fidelity & compatibility. Quarter-Car and Half-Car remain independent models, Full-Car Ride remains 7 DOF, and Planar Handling retains two dynamic DOFs plus three kinematic states. Generic 14-DOF studies use their own identified reference vehicles.
The ML65 assembly mapping target remains preparation only. The separately qualifiedML66 applied Full-Car workflow executes its prepared definition and provides physical 3D Motion. RK4/RK45 describe integration methods; TypeScript and native implementations are separate computational backends. Current applied execution defaults to the qualified ML68 moving-rack C++/WASM backend. The historical fixed-rack native ABI-v1 retains its separate scope.
Supply physical information explicitly
The preparation panel shows readiness and offers an exact default example for the unchanged default assembly. Import and JSON editing are under Advanced physical inputs; loading the example never replaces your vehicle. Check compatibility, prepare, then explicitly continue to Test and Run. Long identities remain available in the expandable preparation details.
Download the versioned physical-input template. Null entries are missing values, not defaults. Supply a full central body inertia tensor, explicit rotor inertias, spring free lengths, regular travel, axle design heights, physical racks and tie rods, gravity and four coupled-slip tire parameter sets. The template declares SI units and a body-CG frame with x forward, y left and z up. Review every mapping rule.
Assembly body mass, corner masses, dimensions, hardpoints and installed spring/damper rates are preserved. Roll/pitch coefficients are used as central tensor diagonals only under the explicit complement declaration. Vertical stiffness becomes an absolute support slope only under its declared rule; it is never converted to longitudinal or cornering stiffness. Right geometry reflects the source left hardpoints and rebuilds proper bases.
Each complement file binds to the canonical physical assembly SHA-256. A source mismatch requires explicit review and rebinding. The exact default example cannot silently populate a customized assembly.
Compatibility and preparation are different
Check physical compatibility reports missing inputs, unsupported topology, frame/units conflicts and physical/semantic errors. Only then can Prepare physical definition compile actual steering geometry, sample regular travel, solve loaded equilibrium and evaluate the moving mechanism/contact boundary. Failure publishes no prepared definition and does not change the applied assembly or existing studies.
Cancel or leave the inspector to terminate its Worker. Editing physical inputs invalidates prior exports. Project replacement and Save/Open reset supplemental session state. Complements and preparations are exported separately and are not saved in workspace-project.v2.
Supported subset and physical limits
The prepared subset uses mirrored Double-Wishbone axles with explicit physical tie rods, axisymmetric wheel rotors and flat loaded compliant point support. MacPherson dynamics, legacy wheel-rate-only geometry, alternate frames, missing inertia, invalid closure and unqualified tire parameters are unsupported. Passing a schema is not sufficient to publish physical preparation.
Ride and the coupled model have different equilibrium, steering, unsprung, contact and rotor semantics. Only a qualified small-angle body attachment relation uses pitchRH = −pitchRide and rollRH = rollRide; whole trajectories are not interchangeable. Qualification establishes mathematical and numerical consistency in a bounded domain, without measured-vehicle validation or arbitrary-vehicle support.
Reproducible qualification inputs
- Explicit default-assembly fixture
- Explicit customized-assembly fixture
- Mapping qualification summary
- Independent references and advancing readiness evidence
The ML66 completed result binds assembly, complements, prepared definition, model, scenario, numerical settings and source identity. Its Motion adapter uses actual stored generalized body/wheel states and physical rack geometry with proper frame transforms and unit scale. Camera controls do not change the physical record.