Simulation and Digital Twins

Simulation replaces the ground test where the environment cannot be reproduced, most of all reduced gravity acting on the soil as well as on the vehicle [6]. What the simulation predicts depends almost entirely on the contact model underneath it, and the three model families in use differ by orders of magnitude in both cost and validity domain.

Simulation frameworks

Framework	Origin and scope
DARTS and Dshell	JPL multibody dynamics engine and simulation framework in use for spacecraft simulations, and the base ROAMS and the Dsends entry, descent and landing tool are both built on [1]
ROAMS	Rover-specific extension of DARTS and Dshell, modeling the rover mechanical subsystem, sensors, onboard resources including the solar panel model, terrain and wheel-soil interaction, and onboard control software; usable standalone, in a closed loop with onboard software, with an operator in the loop, or with rover parameters varied for Monte Carlo work
Gazebo with ROS	Open-source robot simulator used with the ROS ecosystem; the basis of the NASA Ames and Open Robotics lunar rover driving simulator [3]
Chrono::CRM	Continuous Representation Model built on Chrono’s smoothed particle hydrodynamics framework, GPU accelerated, BSD-3 licensed [5]
Discrete element method codes	Particle-level granular simulation, the reference for accuracy and the most expensive [7]
HLA with the SpaceFOM	IEEE 1516 High Level Architecture plus the SISO Space Reference Federation Object Model, the interoperability standard NASA uses to join separately developed simulations into one distributed space systems simulation [10]

ROAMS renders camera imagery through the CAHV and CAHVOR pinhole camera models used for flight cameras, with shadowing computed so that pixels without direct line of sight to the Sun are darkened [2].

Joining separately developed simulations is a standards problem rather than a modeling one. The military distributed simulation standards, HLA with the Real-time Platform Reference FOM, were built for Earth-centric problems, and design decisions in the RPR FOM prevent it from working for space applications; the SISO Space Reference FOM was written to cover the space case, fixing reference frames, time management and the initialization and execution control that a-priori interoperability needs [10].

Contact model families

Tire-ground contact models divide into three categories: classical terramechanics using semi-empirical models that combine experimental data with theoretical principles; numerical models representing the ground either as a continuum or at the individual particle level, interacting with simulated wheel geometry; and empirical approaches fitted to a specific test case [4]. Model choice is a trade between capturing slip and deformation accurately and running fast enough for a real-time or embedded application, bounded by available computing resources. Semi-empirical models are lower fidelity than numerical and empirical approaches but more generalisable than an empirical relationship fitted to one test case.

Where the semi-empirical models break

The Bekker-Wong pressure-sinkage relation and the Janosi-Hanamoto shear relation run at a real time factor of 1 or below, which makes them the right choice for exercising autonomy software, state estimators and path planners [6]. Their results hold under three conditions: small wheel sinkage, low slip ratio, and a wheel close to a plain cylinder without lugs or grousers [6].

Outside those conditions the problems are structural rather than parametric :

• Gravitational acceleration does not enter the terrain model in common use, so the model cannot represent low-gravity terramechanics at all. Corrections have been attempted and required further empirical parameters that were hard to produce.
• Calibration is indeterminate. Several parameter combinations reproduce the same data, and the fit overfits to one regime.
• The bevameter test that produces the parameters is involved, not standardized, and requires a heavy apparatus; no bevameter result obtained on Earth has been correlated to low-gravity model parameters.
• The formulation was built for mobility only and has no context for digging, bulldozing or berming, which is what lunar ISRU requires [6].

Validation against physical testbeds

Chrono::CRM was validated against three physical tests including one with NASA’s MGRU3 rover, and benchmarked against a high-fidelity DEM simulation of RASSOR digging. Being GPU accelerated it reaches computational efficiency comparable to semi-empirical approaches, and an active-domains implementation handles terrain up to 10 km long with 100 million SPH particles at near-interactive rates [5]. Applied to VIPER, CRM results correlated with physical testing at the Glenn SLOPE lab, and the same simulator produced the quantified statement of the offload fallacy: the 73 kg MGRU3 climbs a 30 degree GRC-3b slope at about 42 percent slip on Earth while the 440 kg VIPER on the same terrain in lunar gravity would run near 85 percent [6].

Gazebo wheel slip. The lunar driving simulator implements slip through a plugin that adjusts a slip compliance parameter, tuned against two physical results: a Resource Prospector single-wheel drawbar pull test, and the MGRU lunar-mass-equivalent unit run in the Glenn SLOPE Lab on GRC-1 simulant. Slip compliance has units of inverse damping coefficient: zero gives infinite damping and no slip, positive values allow slip, and the value is the inverse slope of the slip curve near the origin [3].

Characterization used ramps at 2 degree increments with the rover commanded to drive 10 m forward, slip measured by comparing dead reckoning to ground truth, sweeping longitudinal compliance, physics engine solver iteration count and drive speed [3]. Aggregate behavior compared favorably with the MGRU testbed. At certain slope angles and compliance values, however, measured wheel slip varied widely, and the disparities were largest on flat terrain; the cause was unknown and under investigation at publication [3].

The stated remedy is also its own limit: raising fidelity for wheel sinkage and rover embedding would require replacing the plugin with a discrete element model, which is computationally expensive, and existing DEM solutions lack validation for lunar terrain.

Cost of the high-fidelity models

DEM is the accuracy reference and its cost is the reason it is not the default. Local particle refinement, keeping fine particles at the soil surface where interaction happens and coarsening below, was evaluated across 36 DEM beds with triaxial verification that bulk mechanical properties are preserved, then pressure-sinkage and shear-displacement comparison against homogeneous-resolution controls [7]. Depending on refinement aggressiveness it cut particle count by 2.3 to 25 times and simulation time by 3.1 to 43 times, with normalized errors of 3.4 to 11 percent against the high-resolution reference [7].

Neural network surrogates trained on terramechanics data are the other route to affordable fidelity, learning the deformable-terrain force response for use in estimation and control rather than solving the granular physics [9]. Grouser geometry is a specific case where the semi-empirical models have no representation and terrain deformation must be modeled directly for lunar rover simulation [8].

What simulation does not reproduce

Validated low-gravity terrain response. No DEM or continuum terrain model has been validated against lunar surface data, because the data does not exist; validation is against terrestrial testbeds in Earth gravity [3][6]. Granular scaling laws bridge the gap for steady-state macro-behavior only, and say nothing about transients [6].

Terrain resolution. Lunar digital elevation models are on the order of meters in resolution, far coarser than the features a rover interacts with, so the terrain a simulator drives on below that scale is synthesized: fractal enhancement of the DEM plus procedural placement of craters and rocks drawn from size-frequency distribution models, with rock geometry selected from a library and scaled [3].

Photometry and real-time rendering. The lunar visual environment is approximated by a Hapke-derived surface shader and a Lommel-Seeliger reflectance model, within the technical limits of real-time computer graphics. The consequence is measurable: simulated stereo point cloud quality degrades sharply when light sources sit near the cameras, because the Hapke model produces strong contrast-reducing backscatter, and the effect on visual odometry was not quantified [3]. Camera simulation also has to be refined once the flight camera is selected, which invalidates prior visual odometry test results.

Contact model above its validity domain. A semi-empirical model run at high slip, deep sinkage, or with grousers is outside the conditions its derivation assumes, and returns a number regardless [6].