Smart robot, smarter site: why warehouse robots don't work on mines

Most fleet robots are built for one kind of building. A purpose-built fulfilment centre has flat floors, a complete map, strong Wi-Fi in every aisle and a fleet server that tells each robot where to go next. In that environment, a robot can be a thin client: a set of wheels and sensors that follows instructions from the network and does very little thinking of its own.

A mine perimeter is the opposite. So is a solar farm, a substation, a basement car park or the stairwell core of an office tower. These places have long distances, rough ground, changing layouts, poor or absent GPS and networks that drop without warning. A thin client in those conditions stops thinking the moment the link goes.

The thin-client model

A thin-client robot depends on three things the building provides:

• A perfect map. The robot knows where it is because the floor is flat, fixed and fully mapped.
• A perfect network. Decisions come from a central server, step by step, over Wi-Fi.
• A predictable environment. Aisles do not move, ground does not change, and the robot rarely meets something it has not seen.

Take away any one of those and the robot loses its footing. Take away the network and it has nobody telling it what to do.

That design is sensible for its job. It keeps each robot simple and pushes the intelligence into the building. It does not travel well to sites where the building cannot carry that weight.

The MoLogica model: three tiers

MoLogica splits the thinking across three tiers, and each tier keeps working if the one above it goes offline.

Tier	Hardware	Job	Reaction time	Needs the internet
Robot	NVIDIA Jetson Orin, on board	Stay safe, move, see, run the current step	Milliseconds	No, never
Site	Operations server plus an NVIDIA DGX Spark AI server	Control room, fleet coordination, video, mission planning, larger local AI models, local learning	Seconds	No, designed to run offline for days
Cloud	Claude plus GPU compute on demand	Teach, judge, retrain, share learning across sites	Minutes to hours	Optional

The short version: the robot thinks, the site decides, and the cloud teaches.

The robot thinks

Perception, mapping, navigation, the safety supervisor and the inspection model all run on the Jetson on board. The robot builds its own map, works out where it is on that map and drives to its goal. In MoLogica’s simulated depot it built its map autonomously, reached goals within 2 to 4 cm and re-planned around an obstacle dropped into its path.

Most importantly, the robot keeps itself safe with no network at all. The safety supervisor and the watchdog run on the robot. If commands stop arriving, it stops within about a second (0.94 s in testing). An operator can still drive it. Nothing about stopping depends on a connection.

The site decides

A mine or a large depot needs coordination: which robot covers which section, who goes to an alert, what the control room sees. That work runs on servers at the site, on the site’s own network. The design pairs an always-on operations server with an NVIDIA DGX Spark, a compact AI server with 128 GB of memory, so larger AI models can run locally.

Because the site runs on the same NVIDIA software stack as the robots (CUDA and TensorRT), a model trained or tuned at the site moves to the robot without conversion. If the internet goes down for a day or three, patrols, inspections and alerts keep running from the site.

The cloud teaches

The cloud is optional and does slower work: labelling images, judging hard inspection cases, retraining models and sharing what one site learns with others. Minutes to hours is fine for that. None of it is in the path of anything that moves.

Why this suits mines

Take a mine perimeter as the design case. Kilometres of fence. Rough ground in sections. GPS that is good on open ground and poor near structures. A network that is patchy at the far end of the property. Night as the main operating time.

A robot built for that has to:

• Find its way without a building to lean on. On-board mapping indoors, precise RTK GPS outdoors (designed).
• Keep patrolling when the link drops. The current step runs on the robot and the mission runs from the site, not the cloud.
• See for itself at night. Near-infrared cameras with illuminators, and thermal imaging as an upgrade that can detect a person beyond 200 m (designed).
• Raise an alert that still reaches someone. Alerts go to a control room at the site, on the site network.

The same logic applies to multi-storey buildings. Concrete cores and basements are GPS-poor and often badly connected. A robot on each floor that carries its own perception, backed by a site server that runs the building, does not need the cloud to do its rounds.

Hardware-agnostic by the same design

Putting the brain on a standard computer on every robot has a second benefit. The software does not care much which body it sits in.

MoLogica’s end-to-end proof gate passed on two different robot bodies in simulation: a standard research robot and a stand-in shaped like MoLogica’s first real robot, with omnidirectional wheels and different sensor heights. No rewrite. That is early evidence that the brain can move to a cheaper or better body when one ships. A rover for a mine fence and a small robot for a data hall can run the same software image.

What we give up

Smart robots ask more of each body. Each one needs a capable on-board computer and a full sensor kit, where a thin client could get by with less. We think that is the right trade for the places MoLogica is built for. A thin client that stops when the Wi-Fi drops is not much use on a fence line, and pushing perception onto the robot also gives faster answers and keeps footage on site.

It also means thin-client fleets remain a good fit for the buildings they were designed for. The argument here is about fit, not about one design being better everywhere.

Where this stands

The robot tier and a stand-in site tier are proven in simulation, including on-board mapping, navigation and the safety supervisor, on two robot bodies with no rewrite. The site AI server, RTK GPS, thermal imaging and industrial bodies for perimeters are designed and not yet tested on real hardware. The first physical robot is on the bench, and pilots start in logistics before mine perimeters.

Book a demo to see the three tiers working together in simulation.