Two recent, separate proposals in Betaflight and INAV make this failure mode unusually concrete. Both introduce optional lockstep behavior, but for different external simulator protocols. Neither proposal should be confused with a feature already present in a stable firmware release.
The problem is elapsed time, not just delayed packets
A real aircraft does not stop moving because the computer running its controller is busy. A simulation can. Physics may pause during debugging, slow under CPU contention or advance in discrete steps according to an external engine. If the firmware uses the host computer's monotonic clock while the simulator advances on its own clock, the two systems disagree about how much physical time passed.
That disagreement reaches ordinary controller calculations. A task designed to execute at 100 Hz assumes a nominal 10 ms interval. When its wall-clock scheduler runs several times for one stale simulated sensor sample, it can integrate or react to motion that the model never generated. Conversely, after physics catches up, a large state discontinuity can enter the controller as if the aircraft had abruptly moved.
The Betaflight proposal describes a test on version 2025.12.5 in which ALTITUDE and ALTHOLD tasks nominally scheduled at 100 Hz actually ran at 12 to 64 Hz under load. Its author reports altitude-hold oscillation and an eventual simulated ground contact. These are the proposer's observations, not independently reproduced benchmark results or evidence that a normal aircraft would exhibit the same failure. The useful question is whether the simulated time and scheduler time were coherent. Source: Betaflight pull request #15841.
INAV's separate report identifies a related symptom in a RealFlight/FlightAxis setup: the external physics backend stalled for up to 0.8 seconds while firmware continued on the host clock, after which the simulated vehicle exited NAV POSHOLD. Again, that is a maintainer-submitted reproduction on a particular setup, not a broad reliability statistic. Source: INAV pull request #12154.
What lockstep changes
The proposed solutions assign simulation time to the controller's clock rather than asking the physics engine to keep up with the host. Betaflight's optional --lockstep mode would make micros() and millis() follow incoming flight-dynamics-model (FDM) timestamps once packets begin arriving. After processing tasks due at that timestamp, the firmware sends the corresponding motor response. It also tags that response with the timestamp, making each actuator command attributable to a specific physics step. Repeated packets get the prior response rather than moving simulated time forward twice.
INAV's proposed --lockstep mode uses the physics time in FlightAxis responses for micros(). Its scheduler works through tasks due at each step before the next exchange. The proposal applies to the RealFlight interface, starts on the host clock during boot and switches after the main loop can consume simulator time. It is off by default. These details matter because changing timer semantics can affect more than the navigation algorithm. Sources: Betaflight proposal, INAV proposal.
Neither patch claims that ordinary flight firmware should use a simulated clock on real hardware. The feature's point is to make SITL a faithful numerical experiment when the simulation runs slower or faster than wall time.
An existing reference: PX4's simulator synchronization
PX4 documents an established lockstep arrangement with Gazebo and jMAVSim. In its classic arrangement, the simulator sends timestamped sensor data; PX4 performs estimation and control; the simulator waits for actuator output before calculating the next physics step. The flight controller and simulator therefore progress together rather than racing independently. PX4's current Gazebo documentation also describes updating PX4 time every simulation step and allowing the simulation-speed factor to differ from real time. Sources: PX4 Gazebo documentation, PX4 lockstep sequence.
That architecture demonstrates a general principle, not code compatibility across projects. PX4, Betaflight and INAV differ in their event loops, simulators and sensor plumbing. An implementation that pauses a physics step until actuator output arrives must still handle startup, timeouts and missing data deliberately. A blocked handshake is more deterministic than uncontrolled drift, but it is not automatically a safe or recoverable simulation failure.
ArduPilot's external JSON SITL interface shows another integration surface. Its documented protocol receives a physics timestamp, inertial readings, position and velocity from an external backend, and sends actuator outputs over UDP. That contract is relevant when checking which component owns simulated time. It does not establish that ArduPilot's scheduler behavior is identical to either of the new proposals.
What the reported tests prove, and what they do not
Both proposals include deliberately stalled external physics backends. The Betaflight author describes 1 ms physics steps with periodic 0.8-second pauses and reports that 5,134 out of 5,134 advancing packets received a reply in one lockstep run. The INAV author describes a comparable 1 ms stepping experiment: about 3.6 seconds of physics progressed during a 15-second wall-clock observation, while firmware uptime in lockstep tracked roughly four seconds rather than sixteen. Betaflight test report; INAV test report.
Those demonstrations support the narrower claim that the proposed clock paths followed the supplied test timestamps. They do not establish flight-control stability over every workload, nor do they validate sensor physics, actuator saturation, network packet loss, simulator collision dynamics or a real vehicle's failsafe logic. The experiments also differ enough that their uptime figures should not be presented as a direct performance comparison.
A good lockstep test must be able to fail. If the external simulator stops delivering steps entirely, the harness should expose the stall and its timeout policy instead of silently pretending the aircraft continues flying. Separate tests are needed for duplicate packets, out-of-order timestamps, abrupt resets and very small or very large time increments.
A practical validation sequence
A useful SITL regression test can be short, provided its clocks are explicit:
- Record wall-clock time, physics time, firmware-reported uptime, task rates and the timestamps attached to sensor and actuator packets.
- Run a steady baseline with a known physics step, then introduce a repeatable host stall while holding the simulated vehicle's physical state constant.
- Confirm that physics time does not advance during the stall and that each resumed step receives the expected actuator output.
- Replay a duplicate sensor packet and verify that it cannot advance simulated time a second time.
- Inject a missing or out-of-order packet and observe whether the simulator halts, rejects it or follows a documented recovery path.
- Compare navigation behavior and internal task scheduling with and without lockstep, while keeping the simulated airframe, gains and sensor noise model identical.
This is a proposed test design, not a claim that these tests have been run across the three firmware projects. Log fields and harness commands will vary by backend. Most importantly, a nominally smooth position trace is insufficient evidence: the timestamps must agree before controller quality can be judged.
The boundary between simulation evidence and flight evidence
Lockstep can remove an artificial source of instability and make a paused debugger useful for tracing control decisions. It can also expose hidden assumptions inside code that was written against a fixed-rate loop. A controller that divides by elapsed time, integrates error or triggers a failsafe must use the right notion of elapsed time for the environment under test.
There is a limit. In a real aircraft, processor overload, stale sensors and missed control deadlines remain physical hazards. A simulation that freezes its entire clock through a stall may give a cleaner numerical comparison while concealing the wall-clock consequences of CPU starvation. Keep separate tests for scheduling deadlines and real-time overload. Lockstep answers whether the control system behaves coherently as physics advances; real-time and hardware-in-the-loop tests answer whether it can keep up with a flying vehicle.
The two proposals are therefore most valuable as a reminder about test validity. Before blaming an altitude or position controller for an odd SITL trace, verify that the aircraft and its software agree on what one millisecond means.