I Told a Simulated Robot to Stop. It Kept Moving Another Half Meter.

priestly — Wed, 11 Nov 2026 00:46:29 +0000

I Told a Simulated Robot to Stop. It Kept Moving Another Half Meter.

What 60 Gazebo scenario observations taught me about stop commands, motion evidence, and the limits of sensor agreement.

ROS 2 · Gazebo Sim · Python · Robotics Reliability

I sent a stop command to a simulated robot. The command was published successfully—but it went to the wrong topic.

The robot continued moving.

Across 20 repetitions of this deliberately injected fault, the robot traveled an average of 0.5225 meters after the faulty stop command.

This wasn't a malfunction I discovered by accident. I created the failure deliberately to investigate a straightforward robotics question:

How do we know a robot actually stopped, rather than simply knowing that software sent a stop command?

That question led me to build Stop Evidence Monitor (SEM), an open-source ROS 2 research prototype that evaluates whether a stop request has supporting command and motion evidence.

View the source code on GitHub

1. The problem: A stop command is not a stopped robot

Autonomous robots rely on several software components communicating with one another.

A navigation system may generate velocity commands, which travel through ROS 2 topics and eventually reach a controller.

But what happens when something breaks along that path?

Consider a simple case: a navigation component publishes a zero-velocity command, but the message is sent to a topic the robot's drivetrain does not consume.

The command publication succeeds. Meanwhile, the real velocity-command topic continues receiving forward commands.

A naive check that treats successful publication as proof of stopping would miss the problem.

This is an illustrative command-only baseline, not a separately benchmarked safety controller.

I wanted to explore whether observing the commands actually reaching the motion topic, alongside evidence of physical movement, could provide a more informative result.

2. Reproducing the failure in Gazebo

I used Gazebo's differential-drive reference robot, vehicle_blue.

For the experiment, I constructed a controlled world containing a fixed wall and a front-facing LiDAR sensor.

The robot received forward commands on its normal motion topic:

/model/vehicle_blue/cmd_vel

Then I deliberately published the stop command to an unconnected topic:

/model/vehicle_blue/unconnected_stop

The forward-command source continued running.

As expected, the robot did not stop merely because a zero-velocity command had been published somewhere in the system.

This gave me a reproducible failure scenario against which to test the monitoring logic.

[Insert the Gazebo + terminal demonstration video here]

Video caption: A separately recorded demonstration of the injected wrong-topic fault. SEM reports STOP_FAILED. The video run measured 0.50772 m of continued motion; the 20-run benchmark mean reported below is 0.5225 m.

3. Building the Stop Evidence Monitor

SEM is an observation layer, not a replacement navigation controller.

It assesses three pieces of information:

The stop request: When did the system request a stop?

Downstream commands: What velocity commands are actually visible on the drivetrain's command topic?

Motion evidence: Does an independently observed measurement support standstill or continued motion?

For the live Gazebo experiment, I used changes in LiDAR distance to a static wall to estimate longitudinal movement.

This avoided relying on wheel odometry as the primary motion measurement in that experiment.

The monitor produces three key outcomes:

Verdict	Meaning
`STOP_EVIDENCED`	Available measurements support standstill under defined assumptions
`STOP_FAILED`	Observed commands or motion violate the expected stop behavior
`UNVERIFIABLE`	The evidence is insufficient to support a stop conclusion

The rule I wanted to preserve was simple:

Missing evidence must never be interpreted as proof that a robot stopped.

The experiment also used Gazebo's model pose as an evaluation reference. That ground-truth pose was not supplied to SEM's decision-making logic.

4. Testing the approach: 20 complete simulation trials

My initial experiment demonstrated the expected behavior once. But a single successful run provides very limited evidence about repeatability.

I therefore repeated the experiment 20 times, restarting the Gazebo simulation world before each complete trial.

Every trial contained three scenarios:

Normal stop: The robot received valid zero-velocity commands and was expected to stop.
Misrouted stop: The stop command was deliberately sent to the wrong topic while forward commands continued.
Missing LiDAR: Motion observations were deliberately withheld from the monitor.

That produced 20 complete trials and 60 scenario observations.

Results

Scenario	Expected SEM result	Observed
Normal stop	`STOP_EVIDENCED`	20/20
Misrouted stop	`STOP_FAILED`	20/20
Missing LiDAR	`UNVERIFIABLE`	20/20

All 20 complete trials produced the expected classifications.

In the misrouted-stop scenario, the measured movement after the faulty command was:

Measurement	Result
Mean displacement	0.5225 m
Sample standard deviation	0.0024 m
Minimum displacement	0.5173 m
Maximum displacement	0.5281 m
Observed false stop confirmations in this scenario	0/20

The small standard deviation is important to interpret correctly.

All 20 repetitions used the same robot model, world layout, command settings, and monitor thresholds. The tests did not deliberately introduce randomized environments or different motion profiles.

These results demonstrate repeatability in a controlled, nearly deterministic simulation—not robustness to real-world variation.

The original single-run M4 experiment recorded 0.5046 m. The implementation's source hash matches the later repeatability campaign, but the recorded data does not establish the precise cause of the displacement difference. Execution and observation timing are plausible contributors.

The repeated-run statistics above are therefore the primary quantitative results of this article.

The experiment also did not measure detection latency or demonstrate any hardware safety guarantees.

The complete results are available in the 20-run evidence directory.

5. The most important limitation: What happens when two sensors lie?

The repeated Gazebo tests produced the expected outcomes.

However, the more important challenge emerged during adversarial software testing.

Imagine a robot that is still moving, but its sensors report otherwise.

The LiDAR returns constant distance measurements with plausible increasing timestamps. Wheel odometry also reports zero velocity. The downstream command appears to be zero.

SEM can interpret those consistent observations as standstill evidence, even though the robot is assumed to be moving.

In a synthetic test, this produced STOP_EVIDENCED under the false stationary measurements.

Two sensors agreeing does not necessarily mean both sensors are telling the truth.

This is a fundamental limitation of interpreting sensor agreement as physical truth.

The failure was demonstrated with synthetic evidence; the test did not involve a second live robot-motion experiment.

I documented this behavior as an unresolved limitation rather than hiding it behind the successful test counts.

Read the known-failure issue on GitHub.

6. What do 41 passing tests actually mean?

The software test suite completed 41 tests:

40 expected-behavior tests examine the monitor's responses to scenarios such as normal stopping, movement after a stop request, stale measurements, missing evidence, contradictory inputs, and timing conditions.

1 known-failure characterization test deliberately reproduces the correlated-sensor false-confirmation vulnerability.

All 41 tests passed.

But the interpretation matters.

A passing test that successfully reproduces a known failure is evidence that the failure was demonstrated—not that the underlying problem was fixed.

Similarly, the 20 repeated Gazebo trials do not tell us how often SEM would make an incorrect decision on an unfamiliar physical robot.

7. How does this relate to existing robotics safety systems?

Robotic systems already use command timeouts, watchdogs, controller monitoring, and hardware safety functions.

For example, ROS 2 Control's diff_drive_controller provides command-timeout behavior and supports hardware-based odometry feedback.

These mechanisms are important, and SEM does not replace them.

My experiment explores a narrower question:

Can an additional ROS 2 observation layer distinguish selected failed-stop conditions from situations where the available evidence supports standstill?

This prototype does not establish novelty over industrial safe-standstill monitoring or certified safety controllers.

It is also not a collision-prevention system.

SEM cannot guarantee physical standstill, detect every correlated fault, or assess every direction of movement. Its demonstrated LiDAR estimator was specifically designed for longitudinal motion toward a static wall.

No physical robot experiments or safety certification were performed.

8. What I learned

This project started with a small question about a stop command.

It became an exercise in understanding what software can actually conclude from the evidence it receives.

The controlled experiments showed that SEM could detect a deliberately misrouted stop, support a normal-stop conclusion, and report uncertainty when LiDAR evidence was unavailable.

The adversarial testing exposed something equally valuable: a system can be completely consistent internally and still reach the wrong conclusion when its evidence sources are misleading.

That is why I think robotics reliability needs careful attention not only to sensor measurements, but also to their assumptions, freshness, dependencies, and observability.

SEM v0.1.0-sim is a simulation-validated research prototype, not a certified safety system or a general solution to robot stop verification.

I've made the source code, experiments, and known limitations available for others to inspect, reproduce, and challenge.

I'd especially welcome feedback from robotics engineers working with ROS 2, mobile robot controllers, state estimation, and runtime monitoring.

Project resources

GitHub: https://github.com/priestly-ops/stop-evidence-monitor

Research pre-release: https://github.com/priestly-ops/stop-evidence-monitor/releases/tag/v0.1.0-sim

20-run experimental evidence: https://github.com/priestly-ops/stop-evidence-monitor/tree/main/evidence/m4_repeat20

Known failure: https://github.com/priestly-ops/stop-evidence-monitor/issues/1

Related ROS 2 Control documentation: https://control.ros.org/master/doc/ros2_controllers/diff_drive_controller/doc/userdoc.html

This article reports controlled simulation experiments and synthetic software tests. It makes no claim of hardware safety certification or reliability in arbitrary environments.

DEV Community: priestly

I Told a Simulated Robot to Stop. It Kept Moving Another Half Meter.

I Told a Simulated Robot to Stop. It Kept Moving Another Half Meter.

1. The problem: A stop command is not a stopped robot

2. Reproducing the failure in Gazebo

3. Building the Stop Evidence Monitor

4. Testing the approach: 20 complete simulation trials

Results

5. The most important limitation: What happens when two sensors lie?

6. What do 41 passing tests actually mean?

7. How does this relate to existing robotics safety systems?

8. What I learned

Project resources