Skip to content
Autonomous patrol and inspection robots · Johannesburg, South Africa
Menu

How we test: the proof gate

One script, the full scenario, end to end. How the proof gate works, what passed in a simulated depot, and why it ran on two robot bodies.

Engineering notes · Method ·

Robotics demos are easy to stage. Drive a robot down one corridor, film the run that worked, and leave out the runs that did not. We wanted a test that could not be staged, so we built one and called it the proof gate.

A proof gate is a pass or fail test that has to be met before work moves to the next stage. It runs the full scenario end to end, in one script, with no human stepping in. Either every part works together or the gate fails.

What the gate runs

The scenario is the whole job a patrol robot does, compressed into one run:

  1. Plan from plain English. A person gives the instruction in ordinary language. Claude plans it as a sequence of robot actions.
  2. Patrol a randomised route. The robot drives a route drawn at random, so the run cannot depend on a rehearsed path.
  3. Inspect at every stop. At each checkpoint it stops, faces the object and returns a PASS or FAIL verdict with an image and a reason.
  4. Dock itself. It finds its charger using a visual marker and docks.
  5. Undock and go again. It leaves the dock and runs a second lap on a fresh route.

Every step has to succeed. A missed leg, a failed dock or a wrong verdict fails the gate.

The results

The gate ran in MoLogica’s simulated warehouse depot, 31 by 16 m. It passed four times in a row, each time on a different random seed.

Measure Result
Patrol legs completed 32 of 32
Self-docks on the charger 8 of 8
Inspection verdicts correct 16 of 16
Consecutive passes on different seeds 4

Different seeds matter. Each seed produces a different randomised route, so four passes on four seeds show the stack handles routes it was not tuned for. A single pass on a single seed would prove much less.

Two robot bodies, no rewrite

The same software then passed the same gate on a second robot body.

The first was a standard research robot. The second was a stand-in shaped like MoLogica’s first real robot, with omnidirectional wheels and sensors at different heights. Wheels that move sideways and cameras mounted lower or higher change a lot about how a robot moves and what it sees. The software passed without a rewrite.

That is early evidence for one of MoLogica’s central design claims: the brain is hardware-agnostic, so it can move to a better or cheaper body when one ships. Two bodies is not a large sample. It is two more than a claim with no test behind it.

What came before the gate

The proof gate sits on top of smaller tests that each had to pass first:

  • Mapping and navigation. The robot built its own map of the depot autonomously and navigated to goals within 2 to 4 cm, re-planning around an obstacle dropped into its path.
  • Plain-language control. “Go to the loading dock, face the roller door and take a picture” was planned as three tool calls and executed within 2 to 3 cm, three runs out of three.
  • Endurance. A five-lap patrol completed 20 of 20 legs and 5 of 5 self-docks in 15 minutes, with no retries.
  • Safety. The watchdog stopped the robot in 0.94 s when commands stopped arriving, and the AI whitelist refused “open the roller door and chase the intruder” before the robot moved.

Each of those is a component. The gate is the first test where they all have to work together.

Why simulation first

Iterating in simulation is fast and free. Iterating on a real robot is slow and puts the hardware at risk. A bug that drives a simulated robot into a simulated wall costs a restart. The same bug on a real robot costs a repair.

The method has three steps:

  1. Build and prove the whole stack in a simulated site.
  2. Plug the real robot’s computer into that same simulated world. This is hardware-in-the-loop testing: the real Jetson computer drives a virtual robot, so real hardware is tested without risk.
  3. Run it on real floors.

The simulator is Gazebo, the robot software is ROS 2 Jazzy with Nav2 for navigation and SLAM Toolbox for mapping, and docking uses Nav2’s open-source docking server. The toolchain is the same from simulator to robot, so nothing that passes in simulation has to be rewritten for real hardware.

What simulation cannot tell us

A simulated depot is a controlled place, and we try to be clear about what it leaves out.

  • Moving traffic has to be modelled deliberately. Forklifts and people do not appear in a simulation unless someone puts them there.
  • Night and thermal imagery simulate poorly. Near-infrared light, glare and heat signatures are hard to render convincingly, so night-first perception has to be validated on real hardware at pilot sites.
  • Simulated images are not real images. Inspection verdicts in the gate were made on rendered scenes. Real cameras in real buildings come next.

These limits are why the gate is a stage, not a finish line.

The next gate

The roadmap repeats the same test on progressively more real hardware:

  1. The simulation and training workstation becomes the home for the simulated world and model training.
  2. The first real robot, a Hiwonder JetAuto with a Jetson Orin Nano, is flashed to the same toolchain and plugged into the simulated world.
  3. A digital twin of a real office is built, then the same proof gate runs on real floors: plain-language patrol, inspection checks with timestamped images, self-docking.
  4. A three-robot fleet follows, then a legged robot on the same software, then pilot sites.

Each step has to pass its gate before the next one starts.

Twins as test courses

The gate also points at how a pilot will work. Before any hardware is bought, MoLogica can build a simulated copy of a site from floor plans and rack layouts and show the fleet patrolling it. Once a pilot is running, that twin becomes the fixed test course every new AI model must pass before it ships to the fleet. A model that does worse than the current one on the course is rejected.

Where this stands

The proof gate is proven in simulation: four consecutive passes on different random seeds, 32 of 32 patrol legs, 8 of 8 docks and 16 of 16 correct verdicts, on two robot bodies with no rewrite. Hardware-in-the-loop testing and the gate on real floors are planned next. The first physical robot is on the bench.

Book a demo to watch the proof gate run.

Ready to see robots patrolling your site?

Before any hardware is bought, we can build a simulated copy of your site and show the fleet patrolling it at night while you configure the checks in plain language.