Robot Simulation Speed Is Not the Physics Step: Record Both Before Comparing Runs

A robot simulation can display motion smoothly and still run slower than a real clock, or produce different contact behavior when its physics settings change. When a student compares two runs, the step size, achieved simulation speed and physics configuration need to be recorded alongside the robot model. A fast animation is not evidence that the simulated robot has been validated against physical hardware.

Separate simulated time from elapsed time

Simulation time is the time advanced by the simulated world. Wall-clock time is the time experienced outside the simulator. Their ratio is often called the real-time factor: a simulation advancing more slowly than the clock has a factor below one. Gazebo Classic's graphical interface tutorial describes this distinction and the relationship between iterations and the step size.

A learner might run an identical scene on two computers and observe different elapsed durations. Before attributing the difference to a robot model or controller, record the achieved real-time factor, the software version, the scene and the hardware load. A requested rate and an achieved rate are different observations. The interface and available tools differ between Gazebo releases, so use the documentation for the version actually installed.

Understand what a physics step represents

In a fixed-step simulation, each physics update advances the simulated world by a defined time increment. That increment is not the same thing as the rate at which a screen refreshes or a controller publishes messages. A smaller step can change the number of calculations required to cover the same simulated interval. It may also affect the behavior observed in a numerical simulation, depending on the model, solver and contact conditions.

Gazebo Classic's physics parameter tutorial explains maximum step size, update rate, real-time factor and several solver settings in its own version and engine context. Its defaults and engine-specific options should not be assumed to apply unchanged to a modern Gazebo release or another simulator.

Record the engine and solver with the scene

For a reproducible exercise, note the simulator release, physics engine, relevant solver configuration, step size, model revision, initial pose and any controller settings that affect the test. Record whether the world was paused before starting and how the initial state was established. If contact is part of the exercise, note the collision geometry and material settings as well. A comparison that changes several of these at once cannot identify which change produced a different result.

Suppose a simulated gripper appears to slip in one run and hold a virtual object in another. This observation does not immediately prove that either setting represents the real gripper. The team can first check whether the engine, contact geometry, friction assumptions, time step and object properties match the intended exercise. It should then document a limited test rather than adjusting several values until the animation looks convincing.

Measure progress in the right time base

When comparing a task's duration, state whether the reported interval uses simulated time or wall-clock time. A task that takes ten simulated seconds may require more or less wall-clock time depending on the achieved factor. If a controller or external system relies on a particular clock source, record that separately; simulator speed alone does not establish how every connected process measures time.

Try a short repeatable test: start from the same documented state, run for a specified simulated interval, record the achieved factor and save the observed result. Repeat after changing one documented parameter. Report the computer and software context, any variation between runs and the fact that the observation is a simulation. Do not present an illustrative test as a measured result from physical equipment.

It can also help to distinguish an experiment's target from the condition actually observed. For example, a scene may request a particular update rate but achieve less when the computer is busy. Record the achieved rate or factor during the relevant interval, and identify interruptions such as pausing the world. If the available monitoring tool reports an average, note its window or limitation instead of assuming every instant of the run advanced at precisely that rate.

Use simulation as a question, not a safety certificate

A simulation can help reveal a possible modeling issue or make a hypothesis easier to examine, but it does not by itself validate a real robot's stopping distance, contact force or safe operation. Physical validation requires appropriate engineering methods, manufacturer information and site-specific safety controls. If a model lacks a measured parameter, mark it as an assumption in the experiment record.

For related model checks, see our discussion of visual meshes and collision models and the robot simulation learning collection. Documenting the time base and physics settings makes results easier to reproduce and helps reviewers understand what a simulation does and does not show.