# V1 simulator modernization research — October 15, 2026

Implementation and local review complete; beta release evidence is recorded separately. The user requests modern physics/models, review of real-site requirements, and deployment to **beta**. Production is outside this release. This work changes simulation, not robot hardware, cost or field qualification.

## Requirements read and precedence

Read current V1 specification/control contract/assembly guide/decision history; site-fit and site-mapping strategy; April simulator architecture, city-data and fidelity research; October8 route/georeference audit; HIL plan and its August supersession; current GitHub issues [50](https://github.com/DregsBane-Systems/dregsbane-product/issues/50), [47](https://github.com/DregsBane-Systems/dregsbane-product/issues/47), [43](https://github.com/DregsBane-Systems/dregsbane-product/issues/43), [45](https://github.com/DregsBane-Systems/dregsbane-product/issues/45), [51](https://github.com/DregsBane-Systems/dregsbane-product/issues/51).

The August plan supersedes the April Rapier architecture: Newton/MuJoCo supplies recorded dynamics; a browser replays those states, with optional official MuJoCo WASM interaction. Current V1 replaces old 13-inch-wheel/claw assumptions with the selected supported68mm drives, two50.8mm casters, plywood jaw, side battery and removable bin. Initial V1 is remotely operated; active pickup/transfer remains deferred. Historical autonomous collection, multi-robot throughput and8.4-hour targets are not acceptance claims for this beta.

Site requirements survive that hardware change: metric coordinate frame, separate visual/collision layers, dated provenance, recorded route/coverage evidence and explicit unknowns. Existing park route annotations are misaligned; georeference was corrected but their gates/paths are not surveyed. Do not promote them to drivable routes. The full target market also includes Harlem/DC/private properties; these two retained parks are examples, not evidence of market-wide access.

## Engine selection

| Option | Evidence and decision |
|---|---|
| Newton1.7 + MuJoCo3.15 | Retains the recorded architecture. Official package metadata pins Newton's simulation extra to the3.15 line. Use an isolated current-V1 environment; do not silently upgrade the historical3.10 model. CPU MuJoCo backend is available on this Mac; GPU performance and cross-device determinism remain untested. |
| Official MuJoCo WASM3.15 | Same model format and engine line in browser and CPU tests. Single-thread build fits the existing static beta host without COOP/COEP infrastructure changes. Bindings remain a work in progress, so test real browser loading, typed-array access and cleanup. |
| Rapier | Supports articulated joints/motors and is suitable for browser rigid-body interaction. Keeping two independently authored V1 models would create extra drift; retain the old demo as historical. It is not the source of V1 numerical results. |
| Isaac/Gazebo | Useful broader robotics environments, but neither is needed to deliver this static beta. Retain the documented GPU/VRAM-gated Isaac annex and avoid installing a ROS/framework stack for the present task. |

Sources: [Newton installation](https://newton-physics.github.io/newton/latest/guide/installation.html), [Newton MuJoCo solver](https://newton-physics.github.io/newton/latest/solvers/mujoco.html), [Newton1.7 package metadata](https://pypi.org/pypi/newton/1.7.0/json), [official WASM bindings](https://github.com/google-deepmind/mujoco/blob/main/wasm/README.md), [Rapier joints](https://rapier.rs/docs/user_guides/javascript/joints/), [Gazebo comparison](https://gazebosim.org/docs/latest/comparison/).

## Modeling choices

Generate a current MJCF and articulated visual asset from current CAD sources, with source hashes. Use distinct collision proxies and detailed visual meshes. Rigid-body inertias must be positive and derived from a documented distribution; do not assign solid-density mass to hollow packaging envelopes. Carry the existing unmeasured component-mass ranges into sensitivity runs. Model both driven wheels, caster swivel/rolling joints and the actual single jaw hinge. Apply bounded motor torque, not commanded chassis velocity. Motor catalog entries are internally inconsistent: the affine torque/speed curve is a sensitivity hypothesis, not a fitted motor model. The actuator's force, speed, lever arm and holding assumptions need their own explicit bounds.

MuJoCo's tree/joint representation, actuator force limits and contact parameters support this without a custom physics engine. Use a fixed time step, bounded catch-up, nonfinite-state stop and repeatable reset. Contact friction/rolling resistance are different quantities; friction units must follow the engine, and any extra rolling-loss approximation must not be silently counted twice. A rendered camera is a synthetic view, not detector accuracy or completed Pi HIL.

Sources: [MuJoCo modeling](https://mujoco.readthedocs.io/en/stable/modeling.html), [computation](https://mujoco.readthedocs.io/en/stable/computation/index.html), [XML/actuator reference](https://mujoco.readthedocs.io/en/stable/XMLreference.html), current `motor-performance-inputs.json`, `design.json`, `load-and-cost.json`, `perception-config.json` and V1 control contract.

## Real sites and uncertainty

Reuse retained City of Fredericksburg2022 orthophotos with their **returned** ArcGIS extents and checked image hashes, rather than requested bounds. Transform geographic coordinates through a metric projected/local frame; keep source CRS, origin and round-trip checks. Retained GIS polygons can supply mapped surfaces/boundaries, but a source label does not establish current access, curb height, gate state or traction. Any generated route must identify its source and exclusions. Drawn/site annotation routes are priors only.

Investigate USGS elevation as a coarse terrain prior. Raster resolution and vertical accuracy do not resolve this robot's8mm lip clearance or68mm wheels. Missing terrain values remain missing, not measured flat ground. Site models must distinguish coarse sourced elevation from assumed microterrain. Rendering orthophotos is not a photogrammetric reconstruction.

Sources: [ArcGIS export behavior](https://developers.arcgis.com/rest/services-reference/enterprise/export-map/), [city imagery service](https://maps.fredericksburgva.gov/arcgis/rest/services/Imagery/Aerial2022Basemap/MapServer), [PROJ local coordinates](https://proj.org/en/stable/operations/conversions/topocentric.html), [USGS elevation accuracy](https://www.usgs.gov/faqs/what-vertical-accuracy-3d-elevation-program-3dep-dems), retained `imagery-provenance.json` and route audit.

Issue51 requires at least five photos registered into a scaled reconstruction with localization error, and a planned Newton run. Issue45 requires capture imagery, control distances and a splat/proxy alignment; issue43 requires measured scale evaluation. No such verified capture/measurement package has been found in the inspected sim assets. Preserve these as open requirements rather than fabricate reconstruction, cm-level localization or real litter placements. Synthetic litter must remain labeled and must not trigger probabilistic “successful pickup” counters.

## Validation and release plan

Check CAD dimensions/articulation against generated model, positive mass/inertia, gravity/rest/contact behavior, bounded actuation, steering and jaw travel, timestep sensitivity, repeatability and mass/friction sensitivities. Exercise native and browser engines on matched inputs within declared tolerances. Record headless trajectories and provenance so browser replay does not recompute recorded metrics. Check site CRS/image alignment and keep unsurveyed terrain/access outside qualification. Review desktop/mobile controls, input release/blur/stop/reset, failure UI, network isolation and beta cache/version behavior.

Deploy only a reviewed static artifact to existing `dregsbane-beta-sim` / CloudFront `E360FCO454J5FW`. Preserve historical assets and record a release manifest/rollback keys. Production remains unchanged. Purchases, robot operation and physical tests are not authorized by this sim release.

## Checked implementation and failed approaches

Native model/site tests:12 passed. Browser controller tests:3 passed. Official WASM/native matched-input test:1 passed, maximum generalized-position difference6.83e-11 over4s; energy difference1.01e-13Wh. Newton CPU versus direct native MuJoCo on the32s bench exercise differs at most0.02253m in root position (declared0.03m integration tolerance). These share MuJoCo and do not provide independent solver or hardware validation. Browser review covers desktop/mobile, all three scenes, replay scrub, WASM drive/stop/blur/jaw, loaded model, export and WCAG A/AA scan with no errors/violations.

Saved corrections, so they are not rediscovered next time:

- Native numpy float32 telemetry initially failed JSON serialization; convert controller inputs to Python floats at the boundary.
- Inline MJCF elevation uses image-top row order while MuJoCo's compiled array uses south-first rows. Reverse the saved south-first grid only when serializing XML. Tests compare the compiled raster and an asymmetric ray-height probe, not just a rendered image.
- Register SolverMuJoCo custom attributes before MJCF import and explicitly author gap=0. Newton otherwise introduced its0.1m default contact gap; this, plus an unsynchronized initial body pose, made the first park attempt invalid. Evaluate initial forward kinematics and reject numerical warnings/excessive state velocity. Never publish the earlier invalid trajectory.
- The largest mapped-path polygon's representative point put the dog-park start on steep DEM terrain. Its run exceeded the validity bound in native MuJoCo too; this was not solely a Newton failure. Select the lowest DEM-gradient sample inside an inset mapped path and retain its slope as a prior. The current dog-park exercise still rolls faster than the commanded speed: terrain/traction uncertainty remains visible, not hidden by imposing chassis velocity.
- A low turning command did not produce the initially expected yaw in the chosen caster/contact model. The full-turn contact test passes; low-speed steering response remains a sensitivity requiring physical calibration. Do not weaken/replace the robot's actual safety controller based on this sandbox.
- Three0.186 removed PCFSoftShadowMap and GLTFLoader added SkeletonUtils; ship the actual dependency set and use supported PCFShadowMap. The initial missing license URL was corrected using the matching official Python package's retained LICENSES_THIRD_PARTY.md.

Unresolved: exact firmware/SIL binding, measured motor/contact/actuator calibration, real heat/endurance/load tests, GPU parity and five-photo metric reconstruction. Those requirements remain open, with no extra V1 hardware procurement. Do not resume the rejected second Rapier model or misaligned route annotations without new evidence.