CPU, GPU and where each earns its keep on a robot

Robot software is a mix of two very different kinds of work. Some of it is step-by-step logic: decide where to go next, check whether a command is safe, work out which waypoint comes after this one. Some of it is the same simple maths repeated across millions of numbers at once: recognise what is in an image, run an AI model, draw a simulated camera view.

Those two kinds of work suit two kinds of processor. Getting the split right decides how fast a robot reacts, how much it can see and how much of its thinking it can do without a network.

CPU versus GPU in one paragraph

A CPU has a few powerful cores that do one complex thing after another very quickly. It is best for logic, coordination and anything that branches. A GPU has thousands of small cores that do the same simple maths on huge amounts of data at once. It is best for images, AI models and rendering. On a robot, the GPU looks and recognises, and the CPU decides and coordinates.

Where MoLogica uses each

Job	Best on	Why
Physics simulation (Gazebo)	CPU, specifically fast single cores	Physics steps happen one after another, so clock speed matters more than core count
Rendering simulated cameras	GPU	Drawing images is parallel work
Image recognition and inspection models	GPU	The same maths on millions of pixels
Training AI models	GPU	Training repeats the same maths across thousands of images
Navigation, mission logic, safety supervisor	CPU	Branching, step-by-step decisions
Large language models	GPU, with lots of memory	The model must fit in GPU memory to run fast

Physics is a CPU problem

Simulation surprises people. A simulated depot looks like a graphics job, but a bigger graphics card only helps half of it.

A physics simulator advances the world in small steps, one after another. Each step depends on the one before: where the wheels were, what they touched, how the robot moved. That chain cannot be split across thousands of cores. What speeds it up is a fast single core. A bigger GPU barely changes how quickly the physics runs.

Rendering the simulated cameras is different. Drawing an image is parallel work, so that part goes to the GPU. A good simulation machine needs both: fast CPU cores for physics and a capable GPU for cameras and training.

Inspection is a GPU problem

An inspection model takes an image and returns a verdict: door closed, padlock on, rack intact. Under the hood, that is the same arithmetic applied across every pixel. GPUs are built for exactly that.

MoLogica measured it. The compact inspection model trained in the overnight simulation run (a ResNet-18 image classifier) answered in about 1 ms on a GPU and about 15 ms on a CPU. Both are far quicker than a cloud AI call, which took about 3 seconds. The GPU figure is roughly 3,000 times faster than the cloud and does not need a network.

On a patrol robot, that gap leaves more time at each stop for checks and more headroom for everything else the robot is doing.

Safety is a CPU problem

The safety supervisor, navigation and mission logic are branching, step-by-step decisions. Is this command from an operator or from the AI? Is it on the whitelist? Have commands stopped arriving? Each answer depends on the last. That is CPU work, and it is also the work that has to be most predictable. The watchdog that stopped the robot in 0.94 s in testing is this kind of logic.

It also fits MoLogica’s first safety rule: no AI is ever in the real-time control loop.

The NVIDIA family, and why one stack matters

MoLogica builds on NVIDIA hardware at every tier, chosen so that software moves between them without conversion.

Jetson Orin, on the robot. A small computer with an ARM CPU and an NVIDIA GPU sharing one pool of memory. The entry board, the Orin Nano with 8 GB, runs perception, mapping, navigation and a small language model. Larger boards (Orin NX with 16 GB, AGX Orin and Thor) bring larger on-robot AI and, later, robot arms.

DGX Spark, at the site. A compact AI server with 128 GB of memory, designed to run larger models locally and coordinate the fleet without the cloud.

RTX workstation, in development. MoLogica’s simulation and training machine is an x86 PC with an NVIDIA RTX 5080 (Blackwell generation, 16 GB). It runs the simulated world and trains models, and the real robot plugs into it over Ethernet for hardware-in-the-loop testing.

All three run the same NVIDIA software stack, CUDA and TensorRT. A model trained or tuned at the site moves to the robot as it is.

ARM versus x86

Robots and the site AI server use ARM chips, which are power-efficient. The workstation is x86, the desktop standard. Code that works on one does not automatically behave the same on the other.

So MoLogica builds and simulates on x86 but tests everything that will run on a robot on the real ARM Jetson, connected to the simulator, before it goes near real hardware. That is the point of hardware-in-the-loop testing: the robot’s real computer drives a virtual robot, and any ARM-specific problem shows up on the bench instead of on a floor.

Language models on the robot

Large language models are the most memory-hungry job on the list. They need to fit in GPU memory to run fast, which is why the larger local models are designed to sit on the 128 GB site server.

Smaller models are closer to fitting on the robot. As a public reference point, an open model (Gemma 4 E2B) has been shown running on a Jetson Orin Nano at about 15 tokens per second, fast enough to take spoken or written instructions on the robot with no cloud. On-robot language models are on the MoLogica roadmap. They are not built yet.

The principle

Put each job where it runs best, and keep one toolchain across all of it: Ubuntu 24.04, ROS 2 Jazzy and NVIDIA’s stack from simulator to robot. Physics on fast CPU cores. Images and models on the GPU. Safety and decisions on the CPU, close to the wheels. Nothing that works in testing should need rewriting for a real robot.

Where this stands

The 1 ms GPU and 15 ms CPU inspection timings come from a model trained in simulation, on simulated images, and are proven in simulation. The DGX Spark site server is designed. Hardware-in-the-loop testing on the real Jetson and on-robot language models are planned. The first physical robot, a Hiwonder JetAuto with a Jetson Orin Nano, is on the bench.

Book a demo to see how the stack runs from simulator to robot.