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

What 538 positions and 1 millisecond taught us about on-robot AI

An overnight simulation run: a cloud model labels, a small model learns, and answers come back about 3,000 times faster. What it proved, and what not.

Engineering notes · AI ·

A patrol robot that checks a roller door has to decide whether the door is closed. Today, in MoLogica’s simulation work, that decision comes from a large cloud model looking at the image and returning a verdict with a reason. It works well. It also takes about 3 seconds and needs a network connection.

On a remote perimeter or in a basement with no signal, a robot that needs the cloud to see is a robot that stops. So the question we set out to test was simple: can the cloud model teach a small model good enough to run on the robot itself?

The overnight run

The test ran in simulation over one night. The robot was given a job and left alone:

  1. Drive to a series of positions around the simulated depot.
  2. At each one, capture images of the objects that matter on an inspection route.
  3. Send the images to a large cloud model to judge and label.
  4. Train a small image classifier on those labels.

The robot drove itself to 538 positions over four hours with zero navigation failures. It collected the images, the cloud model labelled them, and a compact classifier (ResNet-18, a well-known small image model) was trained on the result. It reached 95% validation accuracy.

Then we timed it.

Cloud model Small trained model
Time per answer About 3 seconds About 1 millisecond on a GPU
Network needed Yes No
Role Teacher and judge Answers on the robot

About 1 millisecond against about 3 seconds is roughly 3,000 times faster. On a CPU the same small model answered in about 15 ms, still far quicker than a round trip to the cloud.

Why the speed matters

A millisecond answer means a robot can check more often at each stop without seconds of waiting every time. Over a night of patrolling, those seconds add up.

The network matters more than the speed. The design rule for every MoLogica robot is that it keeps working when the tier above it goes offline. The robot keeps itself safe with no network at all, and the site is designed to run for days without the cloud. An inspection model that lives on the robot fits that rule. One that lives in the cloud does not.

There are two more reasons to move answers onto the robot:

  • Privacy. Some sites will not let footage leave the premises. A local model keeps the image where it was taken.
  • Cost. Every answer the robot gives itself is a cloud call nobody pays for.

Teacher and student

The large cloud model (Claude, in current testing) is good at judging an image and explaining its verdict, for example “slats all the way down to the ground, no gap” for a closed roller door. It is too slow and too dependent on a connection to sit on the robot.

The small model is fast and local but knows nothing until it is taught. The cloud model’s judgements become its training data. Once trained, the small model handles the routine checks on the robot, and the cloud stays on as teacher and judge for hard cases and new objects.

Choosing the teacher matters. MoLogica tests models against each other and assigns each job to the one that does it best. In testing, a smaller cloud model misjudged a plainly closed door, and the larger one got it right every time. So the larger model judges inspections, and a faster, lighter one (Claude Haiku) plans missions. A student is only as good as the labels it learns from.

What the run proved, and what it did not

This is the part worth reading twice.

The overnight run proved the pipeline. A robot can drive itself to hundreds of positions without help, collect images, get them labelled by a large model, and train a small model that answers in about a millisecond. Every step worked end to end with no human in the loop.

It did not prove a production inspection model. The images were simulated. A classifier trained on rendered images of a simulated depot has learned about rendered images. It has not seen real dust, glare, rain on a lens, a padlock half in shadow, or the way near-infrared light falls on a fence at 3 a.m. Night and thermal imagery in particular simulate poorly.

So the 95% figure describes a pipeline test, not accuracy on a real site. The real version trains on the robot’s own camera, in real buildings, on the objects at that site. That work is on the roadmap behind the first physical robot, which is on the bench now.

Where the data goes next

The overnight run sits inside a larger learning loop that MoLogica has designed but not yet closed:

  1. Run patrols and record every episode.
  2. Capture every human correction, by joystick or in plain language (“go back, get closer, show me that lock”).
  3. Label the experience, with a large cloud model as judge.
  4. Retrain.
  5. Test the new model on a fixed course.
  6. Ship it only if it beats the current model. Otherwise reject it and keep the one that works.

Human corrections are the most valuable data in that loop, because they mark exactly the moments where the robot fell short. Everything is recorded in LeRobot format, an open robot dataset standard, so current open robot AI models can train on it without conversion. In simulation, a single patrol produced 1,477 frames of position, commands and camera images.

Why not trial and error

Learning purely by trial and error, through reinforcement learning, needs a very large number of attempts, roughly 700 robot-days for a single task. That is impractical for a patrol robot and unnecessary for this job. MoLogica’s robots learn from labelled experience and human corrections, while the hard physical skills (driving, braking, obstacle avoidance) come from proven controllers.

The approach draws on current research into robot self-improvement, including Chelsea Finn’s work at Stanford: use human interventions to avoid wasted attempts, and score whether a task is going well. We credit that as inspiration. There is no affiliation.

The lesson

The overnight run taught us that the hard part is not making a small model fast. That part took one night. The hard part is giving it the right data: real images, from real cameras, labelled by a judge that has been tested against alternatives, and corrected by people who know the site.

Where this stands

The training pipeline is proven in simulation: 538 positions, four hours, zero navigation failures, 95% validation accuracy on simulated images, and about 1 ms per answer on a GPU. Model selection between cloud models is proven in simulation. The full learning loop is designed. Training on real cameras and replacing cloud calls with on-robot models is planned.

Book a demo to see the pipeline and the inspection verdicts it produces.

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.