Simulating Physical Systems

See a simulation as a flip book

Draw a bouncing ball in the corner of a notebook, one drawing per page. Flip the pages with your thumb and the ball moves. A simulation works exactly like that book. It never creates smooth motion. It creates one drawing after another, and each drawing is worked out from the drawing before it.

The stretch of time between two pages is the time step. A short step needs many pages for one second of motion, but each page sits close to its neighbour. A long step needs fewer pages, and the motion turns jumpy and can go badly wrong.

Another picture for the same idea: filling a bottle from a tap. The real world pours as a smooth stream. A simulation pours in cupfuls, one cup per page. Small cups track the stream closely. One huge cup overshoots the mark.

Adding up many small changes, page after page, has an old name: integration. The rule that turns one page into the next is the integration method. Different rules make different mistakes, and Step 3 puts two of them side by side.

Describe a moving system with state

What must be written on a flip-book page so the next page can be drawn? That list of numbers is the state. A cart moving along a rail needs position and velocity. A drone needs position, velocity, orientation and turning rate. The state should contain enough information to work out what happens next.

An input changes that state. For the cart, motor force creates acceleration. During one small time interval, acceleration changes velocity and velocity changes position. Repeating that update produces motion.

Choose a time step that keeps the answer useful

The time step is usually written as dt, short for a small difference in time. It is the cup size from Step 1. A smaller dt follows quick changes more closely but needs more calculations for the same second.

The integration method matters too. Explicit Euler moves the position using the old velocity. Semi-implicit Euler updates velocity first, then moves the position with the new velocity. Both are approximations. Both can fail when dt is too large for the fastest motion in the model.

Find the time step where the answer explodes

Push a playground swing at the same point of every pass and each small push stacks on the one before. The swing climbs on timing, not on strength. A too-large time step pushes a simulated spring in the same way. Each update overshoots slightly, the overshoot feeds the next update, and the motion grows with no real energy source.

A simulation is stable when small errors fade or stay small as the steps go on. It is unstable when every step makes the last error bigger. The border between the two is set by the time step and the fastest motion in the model. Running for longer does not move it.

Now give the model one slow part and one very fast part, like a heavy door on a very stiff hinge spring. You care about the slow door, but the fast spring sets the cup size. A model like this is called stiff. Its fastest piece forces tiny time steps even when the motion you want to watch is slow.

Keep units and coordinate frames explicit

A number such as 3.2 is incomplete until you know its unit and frame. Three metres east in the map frame is not three metres forward in the robot frame. The same point has different coordinates when the axes move or turn.

A transform converts coordinates between frames. For a flat robot, rotate the point by the robot heading, then add the robot position. In three dimensions, use a rotation matrix or quaternion rather than three angles patched together in different orders.

Give each body a shape, mass and inertia

A rigid-body model treats an object as a shape that does not bend. Its mass controls straight-line acceleration. Its moment of inertia controls turning acceleration and depends on where the mass sits, not only how much mass there is.

Simulation files often separate a detailed visual mesh from a simpler collision shape. That is useful. A small set of boxes, cylinders and convex shapes usually makes contact faster and more stable than thousands of tiny triangles.

Model contact, friction and wheel slip

Contact is where two shapes meet without passing through each other. A physics engine detects the overlap, estimates a contact force, and applies friction along the surface. Stiff contact behaves like the stiff spring in Step 4, so it needs small time steps or careful solving.

Coulomb friction gives a useful first model: maximum braking force is the friction coefficient multiplied by the normal force. Real tyres, carpets, dust and wet floors do not keep one fixed coefficient, so stopping distance belongs in a range.

Add the faults real sensors have

A perfect sensor gives a controller information it will never have on hardware. Useful models add random noise, a fixed or slowly changing bias, quantisation, delay, limited update rate and missing samples.

Add one fault at a time before combining them. Use a fixed random seed while debugging so the same run produces the same samples. Later, sweep many seeds to check that success was not luck.

Add limits and delay to actuators

A motor does not jump to a requested speed. It takes time to build current and torque. It may have deadband near zero, a maximum output, and a limit on how fast its command can change. It also grows weaker as the battery voltage falls.

These limits belong inside the plant model, not inside the controller. Otherwise the controller appears to achieve commands that the hardware cannot produce. Log requested output and achieved output as separate signals.

Put the simulator behind the hardware interface

The safest software boundary is simple: control code asks for sensor samples and writes actuator commands. In simulation, an adapter gets those values from the physics engine. On hardware, another adapter talks to drivers. The controller should not know which adapter is active.

Time is part of the boundary. Use timestamps from a clock interface instead of reading wall-clock time throughout the controller. A simulated clock can pause, run faster than real time and replay an exact log.

class RobotIO:
    def read(self) -> SensorFrame: ...
    def write(self, command: MotorCommand) -> None: ...
    def now(self) -> float: ...

def control_tick(io, controller):
    sample = io.read()
    command = controller.update(sample, io.now())
    io.write(command)

Choose a simulator that fits the job

No simulator is best for every question. Start from the behaviour you need to test. That might be a first 3D robot, ROS integration, a flight stack, fast contact dynamics, camera data, embedded firmware or radio signal processing.

Use supported combinations of operating system, middleware and simulator. A newer package is not useful if the flight stack or teaching computers do not support it. Record the versions in the project so another person can reproduce the run.

Build and test a mobile robot

Begin with a body, two driven wheels, a caster, wheel joints and measured mass properties. Add encoders and one distance sensor. Put walls and one movable obstacle in the world. Only then connect the controller through the interface from Step 10.

Test a straight drive, a turn in place and a stop before planning a full route. These small tests isolate wheel radius, track width, motor direction and friction. If all of them change at once, a wrong path does not tell you which model is wrong.

for case in room_cases:
    world.reset(case.seed)
    robot.set_pose(case.start)
    result = run_controller(case.goal, timeout_s=40)
    assert result.clearance_m >= case.minimum_clearance_m
    assert result.reached_goal

Fly a mission before building the drone

A flight simulator can run the real autopilot program as software-in-the-loop. The physics model supplies IMU, GPS, barometer and other sensor data. The autopilot sends motor commands back. A ground station can connect through the same MAVLink messages used for a real vehicle.

Start with arm, takeoff, hover, land and loss-of-link tests. Next add waypoints, wind and obstacles. Keep the fast attitude controller in the flight stack. A planning or vision model should request bounded positions, velocities or trajectories rather than raw motor values.

Turn requirements into repeatable scenarios

A demonstration answers “can it work once?” A scenario test asks a harder one. Does a stated requirement hold across starts, obstacles, weather, sensor conditions and random seeds? Each scenario needs initial conditions, events and an oracle that decides pass or fail.

Write the operational design domain, or ODD, as ranges the runner can sample. For an indoor rover that may include floor friction, aisle width, lighting, people speed and network delay. Keep a small fixed regression set and a larger sampled set.

scenario = {
    "start": [1.0, 1.0, 0.0],
    "floor_mu": 0.42,
    "sensor_delay_ms": 120,
    "obstacle_event_s": 4.5,
    "seed": 7319,
}
result = run(scenario)
check(result.reached_goal and result.min_clearance_m >= 0.35)

Inject faults and check the safe response

A fault is a broken or degraded part. A hazard is the harmful situation it might cause. Losing a range sensor is a fault. Driving into a person is a hazard. Fault tests should check the detection, the fallback and the final safe state.

Inject faults at the same interface where they appear on hardware. Freeze a sensor value, delay packets, drop messages, reduce motor authority or corrupt a timestamp. Do not change five things at once until each single fault has a known signature.

Fit the model to measurements

A simulator starts with estimates. Improve them with small physical experiments. Weigh the robot and measure wheel diameter under load. Time a motor step response, coast to a stop, and log sensor delay. This process is called system identification.

Fit parameters on one set of runs and check them on different runs. If the same log is used for both, a complicated model can copy its noise. Plot the residual, which is measured value minus simulated value, and look for a pattern the model still misses.

Randomise the parts that vary

One calibrated model represents one machine on one day. Domain randomisation samples plausible mass, friction, delay, lighting, wind and sensor error on each run. A controller that succeeds across that range is less likely to depend on one exact simulator setting.

Wider is not always better. Impossible combinations waste training and can teach timid behaviour. Use measured ranges, preserve correlations, and keep a held-out set of real runs. Randomisation is a way to cover uncertainty, not a substitute for measurement.

Use synthetic sensor data carefully

A simulator can render camera, depth, segmentation and lidar data with exact labels. This is useful for rare events and viewpoints that are expensive to label by hand. It is also easy to train on clues that exist only in the renderer.

Vary geometry, materials, lighting, weather, motion blur, exposure and occlusion within measured ranges. Keep a real validation set from the target camera. Report results by condition so a good daytime score cannot hide poor performance in glare or low light.

Train learned policies without hiding mistakes

Reinforcement learning learns actions from rewards. Imitation learning copies demonstrations. Diffusion policies predict action sequences, and vision-language-action models connect images and instructions to actions. All can be trained or evaluated in simulation, but each can exploit an accidental shortcut.

Give the policy only observations available on the real machine. Keep exact simulator state for the critic, scorer or teacher if the method needs it, but do not leak it into the deployed actor. Evaluate with unseen worlds, seeds and physical logs. Put a deterministic safety layer around every output.

Move from SIL to HIL to guarded field tests

Simulation reduces risk but does not certify the physical machine. Use an evidence ladder. Start with unit and model checks, then run production software in SIL. Test timing and drivers on hardware or HIL. After restrained bench tests, enter a small guarded operating domain.

Write release gates before running the tests. A gate has a measured condition and a required result: minimum clearance, maximum stopping distance, deadline misses, fallback latency, battery reserve and allowed interventions. A failed gate sends the project back to the earliest layer that can explain it.

A practical project record

• Model files, coordinate-frame and unit conventions, and every calibrated parameter.
• Controller, estimator and safety-monitor versions with their interface contracts.
• Fixed regression scenarios, sampled ODD ranges, seeds and result summaries.
• Fault cases, fallback traces and the reason each release gate exists.
• SIL, HIL, bench and field logs linked to the exact configuration that produced them.

Continue with a build

Use this workflow in a project rather than jumping from a lesson widget to an unrestricted machine. The Robotics course supplies the rover motion model. Drones supplies the fast flight-control loops. Autonomous Systems supplies mapping, planning, learned action models and runtime safeguards.