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]. It also replaces hardware that does not yet exist or cannot be broken on purpose: the MSL flight software team ran its code against a workstation-only avionics model so that developers did not queue for hardware testbeds [13]. What a simulation predicts depends on the model underneath it, and the families in use differ by orders of magnitude in cost and validity domain.

Four families of simulation serve space robotics, and they answer different questions. Vehicle and terrain contact simulation predicts slip, sinkage and drawbar pull. Entry, descent and landing (EDL) simulation propagates a dispersed ensemble of trajectories to bound landing error and loads. Avionics and flight software simulation lets code run against modeled devices. Digital twins and hardware-in-the-loop (HIL) setups join a model to a real operator or a real sensor. Flown systems have been checked against flight data in the EDL family only; contact models have been checked against terrestrial testbeds and a small amount of parabolic-flight data, and the twin and HIL work below is laboratory work.

Why the field converged on a few tools

Simulation in spaceflight began as a crew and software necessity. The NASA history of spaceflight computing records that the Apollo flight computer program required its own simulator, which in turn required a simulator of its own to keep crews trained [28]. By the 2000s the JPL lineage had settled on one multibody engine, DARTS, with Dshell above it, and two products built on that base: ROAMS for rovers and DSENDS for EDL [1][21]. Open-source robot simulators arrived from a different direction: Gazebo was introduced in 2004 as an ODE-based multi-robot dynamics simulator developed alongside Player and Stage, with informal case studies in legged gait design and sensor development rather than planetary work [29]. NASA Ames later built its lunar driving simulator on that base [3].

The consolidation around a few engines follows from validation cost. A contact model earns trust through years of comparison with testbed data, and a mission team reuses the model that already has that record. The shift since 2020 is from tuned single-point contact toward GPU-resident continuum and particle models whose parameters come from soil mechanics rather than from curve fits [5].

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 [1]
DSENDS	Real-time HIL EDL testbed built on DARTS and Dshell, used with the POST trajectory tool in a division of labor that later Mars EDL work inherited [21]
WorkStation TestSet (MSL)	Software-only avionics simulator that runs unmodified flight software under VxWorks on a Linux workstation, sharing simulation objects with HIL testbeds [13]
DLR Rover Simulation Toolkit	Modelica and Dymola multibody toolkit, used for the MMX rover separation analysis [23]
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][29]
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]. The overview reports adoption in a student simulation exercise, an ESA facility and NASA’s Artemis Base Camp work, but gives no timing or scalability measurement for any federation [10].

Entry, descent and landing simulation

EDL is the one family where simulation predictions have been scored against flight. The 2002 Mars Smart Lander study paired a POST trajectory simulation at Langley for Monte Carlo dispersion with DSENDS for real-time HIL checkout, and ran 2000 cases of a 70 degree trim shelf configuration in which every case met the touchdown velocity metrics of under 4 m/s vertical and 2 m/s horizontal; the vehicle was a concept that never flew, and the paper reports no cross-validation between the two tools [21]. The Genesis entry decision shows the same method under operational pressure: two propagators each flew 2000 dispersed entry states, and tuned integration tolerances and atmosphere tables let the ensemble finish inside the one hour window before the Go/NoGo [22].

Curiosity gave the first scored comparison. Most of the as-flown MSL sequence agreed with the pre-entry POST2 Monte Carlo within 1.5 sigma; three anomalies remained, in upper atmosphere deceleration, supersonic deceleration attributed to a tail wind of roughly 20 m/s, and a 450 microg error in assumed local gravity [26]. Mars 2020 repeated the exercise: an 8001-case DSENDS Monte Carlo was run for independent verification, and the flown reconstruction was placed against its percentiles, with velocity discrepancies between the reconstruction and the Monte Carlo left unresolved [17]. The full 830 page as-flown reconstruction reports pre-flight prediction against reconstructed flight data chapter by chapter [31]. A single landing yields one sample per parameter, so these scorecards bound a model’s error without establishing that it is unbiased [26].

The method carries to other bodies as preparation rather than as validation. Dragonfly’s Titan EDL simulation uses a POST2-based tool chain and adopted 10,000 Monte Carlo runs after a convergence study from 500 to 20,000, with aerodynamic models still being updated from drop tests [18]. Simulation also feeds the autonomy that flies the descent: the Mars 2020 Lander Vision System cut a 3.2 km initial position error to under 40 m in flight, and the Morpheus hazard detection timing was predicted by Monte Carlo before five free flights measured 11.3 to 12.9 s against a 14.1 s requirement, with several component predictions missing their bounds [27][19].

Avionics, flight software and hardware in the loop

Flight software is tested against modeled hardware long before the hardware is available. The MSL workstation simulator rests on three principles: the flight software must not be able to tell it is simulated, simulation objects are shared with the hardware testbeds so a missing device can be substituted, and fault injection reaches down to individual bits in a device packet, which hardware testbeds cannot do without breaking flight hardware [13]. It reports no defect counts and no comparison of defects found per hour against the hardware testbeds [13].

Where a real sensor or actuator must be exercised, HIL replaces the rest of the world. JPL and Tech180 are building a motor simulator for the Europa Lander controller, an FPGA motor model driving four-quadrant amplifiers in place of real motors, a proposal-stage design that has not flown [30]. DLR’s EPOS 2.0 facility closed a guidance loop on real camera hardware with simulated dynamics, holding a rendezvous from 18 m to 1.8 m under a 2 to 3 s delay in two reported runs [20]. Stanford’s twinning framework runs the same low Earth orbit proximity scenario from 75 km to 7 m in software and then on RF and optical testbeds, so that the difference between the two is the measure of the testbed error; it is orbital work with no surface content [12].

Multibody Monte Carlo is used to check mechanisms. The MMX rover separation analysis ran 100,000 samples of a simplified model and found ejection velocity meeting its requirement only within about 2 sigma, with the detailed four-release model producing more outliers from asynchronous opening [23]. Its range for the release impulse rests on one usable test and its distributions are uniform by convenience [23].

Digital twins as operator tools

A digital twin in the surface robotics literature is mostly a training and planning tool, not a physics predictor. A between-subjects laboratory study of 24 participants found that a practice run on a twin before teleoperating a small rover with an arm to align antenna units gave 28 percent faster completion and 85 percent fewer unrecoverable errors [11]. The task was a single simple one in a lab room, with low latency, student participants and no lunar terrain, so the result bears on operator practice, not on lunar fidelity [11]. No flown surface mission is documented in the held corpus as running a twin in this sense.

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 generalizable than an empirical relationship fitted to one test case [4].

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].

ROAMS shows the same boundary from the engineering side. Its contact model is a single point contact with a probabilistic rolling to slipping transition, chosen for faster than real time execution; predicted slip matched measured slip within 1 to 2 percent on level to 10 degree slopes on a tilt table, but at 20 degrees measured slip ranged from 10 to 60 percent and the prediction diverged [16].

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]. The authors’ conclusion is that gravity offload alone gives a misleading preparation for the mission [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 [3].

Particle models and their cost

DEM is the accuracy reference and its cost is the reason it is not the default. Against single-wheel experiments on a Martian simulant, DEM matched drawbar pull, torque and sinkage trends better than either a static or a dynamic Bekker model, at about 8.5 hours of compute per second of simulated wheel motion on 8 cores against 43 ms per slip ratio for the static Bekker model [25]. A 3D DEM of a MER wheel in JSC-1A converged on the physical wheel test as grain shape moved from spheres to ellipsoids to poly-ellipsoids, with shear modulus reduced three orders of magnitude to enlarge the time step, so contact stiffness is not physical [15].

Gravity is the open question for particle models. A parallel-particles DEM formulation was tested against parabolic-flight single-wheel data in ES-2 Martian simulant, where drawbar pull coefficient averaged about 20 percent lower in lunar gravity than on Earth; the model could not match sinkage and drawbar pull at once, leaving drawbar pull about 45 percent below experiment when sinkage was matched, and the author attributes this to omitted particle rotation [14]. A DEM calibrated against the ISS Hourglass experiment at 0.063 G to 2 G needed a van der Waals adhesion term to reproduce the competition between gravity and adhesion, but it models hopper flow in silica sand, not wheel-soil interaction, and omits electrostatic force [24].

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 are the other route to affordable fidelity. One trained on about 10,000 Soil Contact Model samples estimated the sinkage exponent to within 1.9 percent against 3.8 percent for a Bekker-based surrogate, at 5.2 ms against 10.5 ms per filter iteration; the reference is a model, not measurement, and the clay terrain and vehicle are terrestrial [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]. Stereo visual odometry on the synthetic imagery beat fused wheel and star tracker odometry for camera rotations of 50 degrees or less, and the authors call the result preliminary, to be rerun once a flight camera is selected [3].

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].

Material fidelity. A simulant stands in for regolith on mechanical similarity only. NASA’s figure of merit approach, extended to asteroid simulants, gives a way to say how much of a test’s value survives the substitution: a figure of merit of 0.75 means a mechanical test retains 75 percent of the value it would have with matching material [32].

What is not established

No terrain model has been validated against lunar surface measurements, and the reduced-gravity data that exist are seconds of parabolic flight or terrestrial analogs [3][14]. The Gazebo slip variance on flat terrain is unexplained [3], the ROAMS contact model is bounded at about 20 degrees on a paving-stone tilt table [16], and the best reduced-gravity DEM test failed to match sinkage and drawbar pull together [14]. The learned surrogate has been checked against another model only [9]. The EDL scorecards rest on single landings [26][17]. The held evidence for digital twins as operator training is one laboratory study with students and no communication delay [11], and the held corpus has no flight record of a surface twin or a measured SpaceFOM federation [10].