What Sits Between the Model and the Motor

Most robotics conversations focus on AI. But the software stack connecting models to physical hardware plays a critical role in whether robots perform reliably in the real world.

Most of the conversation in robotics centres on AI. Far less attention goes to the software that carries a model’s output through to the hardware, reliably and on time.

That layer is where much of the day-to-day engineering effort in robotics is spent.

Where the Complexity Sits

A robot’s software is a stack. Firmware and drivers interface with the electronics. An operating system manages limited compute. Middleware moves data between processes, and application software sits on top.

Each layer can work well on its own. Issues tend to appear where the layers meet.

A perception pipeline may copy every camera frame back to CPU memory before passing it on, adding latency. A control loop may miss its timing because another process shares the same core. A sensor driver may behave differently after a hardware revision.

These issues rarely show up in a model benchmark, but they have a direct effect on whether a system performs reliably outside the lab.

How Platform Companies Are Approaching It

Several major companies are building tools aimed specifically at this layer.

Intrinsic’s platform architecture is built around IntrinsicOS, a Linux-based operating system that runs Kubernetes containerised workloads and uses the same software stack in simulation and on real hardware. Its real-time control framework is designed to support different robots, sensors and grippers. The emphasis is on consistency between development and production.

NVIDIA Isaac ROS works closer to the data path. Its NITROS transport layer uses ROS 2 type adaptation and type negotiation so that data processed on a GPU can pass between nodes as a handle, rather than being copied back to CPU memory at each step. NVIDIA now states that NITROS is available natively in ROS 2 Lyrical through an official CUDA backend plugin.

The two approaches differ, but both focus on the same question: how to make the components of a robotic system work together efficiently and predictably.

What This Means for Engineers and Hiring Teams

The engineers who do this work often move between levels of abstraction. On a given day, that might mean reviewing system architecture in the morning and working through a kernel trace or a datasheet in the afternoon.

For engineers, this experience is often undersold on a CV. Phrases such as “supported integration” or “worked on platform software” rarely capture the work. Specific examples carry more weight: a fault traced across several layers, a product supported through a hardware revision, or a measurable improvement in latency or memory use.

For hiring teams, the same points are useful in assessment. Questions that tend to reveal depth include:

• Can the candidate walk through a fault they traced across more than one layer of the stack?
• Have they worked on a product through a hardware change or revision?
• Do they understand the latency, memory and compute cost of their code on the target device?

AI will continue to expand what robots can do. The software stack beneath it determines how reliably they do it.

For those working in robotics software, which part of the stack has proved the hardest to get right?

Connect with Akkar

If you’re building or scaling a robotics software team, Akkar can help you connect with specialist engineers across embedded software, systems integration and robotics platforms. Get in touch to discuss your hiring requirements.

Bella Smith - bella@akkar.com