Robotics simulation: choose the model for the question

Robotics simulation computes what a modeled robot and environment would do under chosen inputs. Its value depends on whether those assumptions match the question you want to answer.

A path preview can assume exact velocity tracking. A braking study needs the forces and delays that determine stopping motion. A camera-policy test also needs observations that the policy could receive.

This guide separates those choices with one force-driven cart. You will compare an exact solution, a coarse numerical approximation, and a changed physical assumption. The example contains no measured robot data or claim of hardware validation.

Start with the question your simulation must answer

Write down the decision first: check geometric reachability, estimate acceleration, test a perception system, or evaluate a policy's complete behavior. Then identify which modeled quantities could change that decision.

Question	Model ingredients it can require	What a simpler model leaves unresolved
Can this path fit through a doorway?	Robot footprint, geometry, pose, collision checks	Tracking error, braking, and contact forces
Can the actuator reach the target speed?	Mass or inertia, force limits, losses, control dynamics	What an ideal velocity command hides
Does the camera policy detect the target?	Camera pose, image formation, scene variation, observation timing	Performance when the policy receives exact object coordinates
Does a policy finish the task?	Action-dependent state updates, observations, resets, outcome rules	Whether sensible actions on a recording lead to success

Choose fidelity for that decision. Adding detail can increase computation and introduce more parameters to estimate. A detailed model still needs evidence that its relevant predictions match the intended use.

Separate the model components

Choose the model for the question

Inputs, simulation loop, and evidence

The first panel compares two command meanings. The next panels show a feedback loop and the checks needed to assess its predictions.

1. Declare the command and model

2. Close the observation loop

3. Check equations and physical evidence

These are conceptual diagrams. The numerical example uses a fixed force, so its sensor reading does not feed a controller.

A simulation usually combines a state, rules for how it changes, an input interface, and outputs. Physical parameters describe the modeled system. Numerical settings describe how the software advances that system.

The MuJoCo 3.3.5 overview separates bodies, joints, geometry, actuators, sensors, and visualization settings. Those distinctions help you inspect an experiment even when you use another engine. For example, a body's mass and its visible material describe different properties.

Record at least these choices:

• Initial positions and velocities, with units and coordinate frames.
• Geometry, masses, losses, contact assumptions, and actuator behavior.
• Controller inputs, sensor outputs, and their update times.
• Integration method, step size, and solver settings.
• Resets, random draws, and the outcome you will score.

The three panels organize those choices. They show a conceptual feedback loop, followed by the kinds of evidence needed to assess a model.

To express the cart equations as a reusable dynamic model, continue with state-space models. That lesson separates the internal position and velocity from an output such as measured position or modeled acceleration.

Use kinematics for prescribed motion

A kinematic model relates configuration and motion without solving for the forces that cause it. For a point robot on a line, one simple model accepts a velocity command v_cmd in meters per second:

Starting at x = 0, a constant command of 1 m/s for 1 s produces x = 1 m. This update is exact for the declared constant-velocity model. It assumes the robot tracks that command immediately, including at the beginning of the interval.

That assumption can support a geometric path study or isolate policy logic. It leaves acceleration, required force, and actuator limits unspecified. A wheeled model can still impose turning constraints; differential-drive kinematics gives one example.

A force of 1 N cannot enter the velocity-command slot. Modeling a velocity-controlled physical cart also requires the inner controller and actuator assumptions that make its velocity follow the command.

Use dynamics when forces determine motion

A dynamic model uses forces and mass or inertia to determine motion. Consider a horizontal cart with mass m = 2 kg, viscous damping b = 1 N·s/m, and an ideal applied force F = 4 N.

The force stays constant from t = 0 through t = 1 s. Initially x = 0 and v = 0. The cart has no spring, obstacle, actuator lag, or force limit; viscous damping supplies the only modeled resistance.

The damping term bv has units of newtons and opposes motion. For positive m and b, this constant-force model approaches velocity F/b. Its time constant m/b equals 2 s here.

From rest, the exact solution is:

At t = 1 s, v = 1.573877 m/s and x = 0.852245 m, rounded to six decimals. Differentiating the expressions recovers both rate equations and their zero initial values.

Now change the physical assumption to b = 0, while keeping the mass, force, and initial state. Constant acceleration gives v = Ft/m = 2 m/s and x = Ft²/(2m) = 1 m at one second. The position difference, about 0.147755 m, comes from removing damping.

Neither result tells us which model fits an actual cart. That requires measurements. The earlier prescribed-velocity example also reaches 1 m, but its command and physical assumptions differ from both force-driven calculations.

Separate numerical error from model error

An integrator approximates the solution to selected equations. Keep b = 1 N·s/m and use forward Euler with step h. Both updates read the old state:

For h = 0.5 s, the first step gives (x₁, v₁) = (0 m, 1 m/s). The second gives (x₂, v₂) = (0.5 m, 1.75 m/s). The coarse method underestimates position and overestimates velocity at t = 1 s.

Damped model calculation at t = 1 s	Position (m)	Velocity (m/s)
Exact solution	0.852245	1.573877
Forward Euler, h = 0.5 s	0.500000	1.750000
Forward Euler, h = 0.25 s	0.689453	1.655273
Forward Euler, h = 0.01 s	0.846163	1.576918

These rows use the same damped equations and initial state. Reducing h brings this calculation closer to its exact reference. It cannot add a missing force, correct a wrong mass, or establish agreement with a physical robot.

MuJoCo 3.3.5 documents numerical integration as a separate state-advancement step. Its explanation includes explicit Euler for teaching and states that the engine does not implement that method. The table above is our own calculation, not a MuJoCo benchmark.

For general systems, step refinement also needs attention to stability, contact events, and solver tolerances. The numerical-integration lesson compares methods and error measures in more detail.

Distinguish state, observations, and rendering

The simulated state describes the world inside the model. An observation is what a sensor model exposes to the controller. Giving a policy exact state can simplify a test, but it also changes the information available to that policy.

For the cart, define a position measurement with fixed bias δ:

At t = 1 s, the exact damped model has x = 0.852245 m. With δ = +0.10 m, the sensor reports y = 0.952245 m. The applied force remains fixed, so this biased reading does not change the cart's trajectory in this example.

If a controller reads y and changes the force, the bias can affect future motion. Keep the observation model attached to the control path when testing that behavior. Feedback control demonstrates the distinction between true and measured error.

Rendering can generate camera observations or show an animation to a person. A camera-based policy depends on the former. A display-only change need not change its observations or the simulated forces.

The Gazebo Harmonic sensor tutorial specifies sensor frames, generated outputs, and update rates, including a lidar example at 10 Hz. That is a concrete reminder to model the sensor's measurements and timing. Visual detail alone does not establish their accuracy.

Connect the controller with explicit timing

A policy command may request position, velocity, torque, or force. The actuation model determines what physical input follows. MuJoCo's 3.3.5 actuation documentation separates control input, actuator force, and optional internal actuator state.

Keep three schedules explicit: physics advancement, sensor sampling, and command updates. For example, a setup might advance physics every 1 ms, generate observations every 20 ms, and issue a command every 20 ms. Those are declared example settings, with no claim that they suit every robot.

State what happens between commands: does the actuator hold a force, track a position target, or execute a motion segment? State when each observation becomes available, including any modeled delay. Controller discretization works through sampled measurements and held inputs.

The control-loop diagram includes a sensor-to-controller return path. The worked cart calculation uses a constant force and never reads y to choose F. It therefore isolates motion and sensing assumptions without simulating a feedback controller.

Define what a simulated result measures

A simulated outcome answers a question about the implemented model and test conditions. Specify the reset, task goal, time limit, and any path or effort constraints before collecting results. Record failures and interventions as part of the outcome.

The distinction between open-loop replay and closed-loop simulation determines whether the candidate's actions affect its next observation. It is separate from whether the motion model is kinematic or dynamic. A velocity-driven kinematic simulator can still close that interaction loop.

Simulation also supports policy training, synthetic observation generation, and controlled parameter sweeps. Keep training conditions separate from final evaluation conditions. Domain randomization changes the training distribution; it does not by itself validate the simulator's physical predictions.

For the cart, we report position and velocity at one second. We have no success threshold, collision check, measured deployment distribution, or hardware trials. Those six-decimal outputs describe the arithmetic precision of this example.

Verify the calculation and validate the model

Computational verification asks whether the software follows the chosen equations well enough for the task. Compare against a known solution, check units, and refine numerical settings while holding the physical model fixed. The damped-cart comparison performs this kind of check.

Physical validation asks whether the model predicts relevant measurements from an actual system under stated conditions. Calibration uses measurements to choose parameters, such as mass, damping, or sensor bias. Keep separate measured trials for assessing the resulting model.

A possible cart study could fit damping from some force-response runs, then predict position and velocity on held-out runs at other declared forces. It would need an identified measurement reference, timing alignment, and uncertainty for the measurements. This guide does not perform that study.

Two independently implemented simulators can agree because they share the same missing effect. Numerical convergence can also settle on the solution to an inaccurate physical model. Report what the evidence checks and the conditions it covers.

The sim-to-real transfer lesson separates simulated mismatch tests from hardware evidence. Begin with one prediction that matters to your application, and define the measured experiment that could reject it.

Reproduce the cart comparison in Python

This standard-library program reproduces the damped reference, the undamped model, the Euler refinements, and the biased sensor output. It runs our equations directly and uses no simulation engine. Python's simultaneous assignment keeps both Euler updates tied to the old state.

from math import expm1

mass, damping, force, duration = 2.0, 1.0, 4.0, 1.0
one_minus_decay = -expm1(-damping * duration / mass)
v_exact = (force / damping) * one_minus_decay
x_exact = (force / damping) * (
    duration - (mass / damping) * one_minus_decay
)
print(f"Exact damped: x={x_exact:.6f} m, v={v_exact:.6f} m/s")
print(f"Exact undamped: x={force * duration**2 / (2 * mass):.6f} m, "
      f"v={force * duration / mass:.6f} m/s")

for steps in (2, 4, 100):
    h = duration / steps
    x, v = 0.0, 0.0
    for _ in range(steps):
        x, v = x + h * v, v + h * (force - damping * v) / mass
    print(f"Euler h={h:.2f} s: x={x:.6f} m, v={v:.6f} m/s")

bias = 0.10
print(f"Biased observation: y={x_exact + bias:.6f} m")

Expected output:

Exact damped: x=0.852245 m, v=1.573877 m/s
Exact undamped: x=1.000000 m, v=2.000000 m/s
Euler h=0.50 s: x=0.500000 m, v=1.750000 m/s
Euler h=0.25 s: x=0.689453 m, v=1.655273 m/s
Euler h=0.01 s: x=0.846163 m, v=1.576918 m/s
Biased observation: y=0.952245 m

Try it yourself

Exercise 1. For the damped cart, take the first forward Euler step with h = 0.5 s from rest. Compute position and velocity, then compare position with the exact solution at 0.5 s. Does the Euler value imply that the modeled cart truly stays still for the first half-second?

Show the time-step solution

The old acceleration is (4 N − 1 N·s/m × 0 m/s)/(2 kg) = 2 m/s². Euler gives v₁ = 1 m/s and x₁ = 0 m, since the position update uses the old velocity of zero.

The exact position is 4[0.5 − 2(1 − exp(−0.25))] = 0.230406 m. Exact velocity is 4(1 − exp(−0.25)) = 0.884797 m/s. The zero Euler position reflects its coarse old-slope approximation; the continuous model starts moving as its velocity increases after t = 0.

Exercise 2. At one second, the exact damped model predicts x = 0.852245 m and the biased sensor reports y = 0.952245 m. Classify three changes: halve Euler's step, subtract 0.10 m from the reading, or set damping to zero. Which change alters the exact cart trajectory under the fixed force, and what extra evidence would justify a claim about a physical cart?

Show the model and evidence solution

Halving the step changes the numerical approximation to the same damped equations. Subtracting 0.10 m gives a corrected reading of 0.852245 m in this declared bias model. It does not change the fixed applied force or exact state trajectory.

Setting b = 0 changes the physical model. Its exact state at one second becomes x = 1 m and v = 2 m/s. If its sensor retains the same bias, that model reports y = 1.1 m.

Hardware validation would need actual measured motion with known inputs, declared sensing and timing, and trials separate from parameter fitting. Exact arithmetic and a smaller step establish none of those measurements. In a feedback experiment, correcting the observation could also change the controller's future commands.

Sources and further study

These official documentation versions support the component distinctions in this guide. They are references for model structure, without a simulator ranking or an installation recipe.

• MuJoCo 3.3.5 overview and model elements.
• MuJoCo 3.3.5 computation: actuation and numerical integration.
• Gazebo Harmonic sensor tutorial.

Read open-loop vs closed-loop simulation next to see how the evaluation loop changes a policy's observations and outcomes. For your own test, write down the command's units before choosing the motion model.