Robot Computer Guide: Choosing Onboard Compute for AMRs, Humanoids and Cobots

A robot computer is the onboard computer that turns a robot’s sensor data into decisions: it runs perception, localization, planning and, increasingly, large AI models, and it hands motion commands to the controllers that drive the motors. In an autonomous mobile robot, a humanoid, a cobot cell or a mobile manipulator, it is the part of the machine that decides what happens next, while separate real-time and safety controllers make sure it happens safely.

Choosing it has become harder as robots have moved from scripted motion to physical AI. A warehouse robot that once followed reflectors now fuses cameras and lidar, and a humanoid robot may run a vision language action model on board. The compute choice now ranges from a 7 W Jetson Orin Nano to a Jetson Thor module rated at up to 2,070 FP4 TFLOPS, and the I/O, power and safety questions around it matter as much as the processor.

This guide is the reference view. It walks through the robot software stack and where each layer runs, the sensor and control interfaces, how Jetson Orin, Jetson Thor and IGX differ, the split between AI, real-time and safety controllers, power and ruggedness on a battery-powered machine, the software, and how to size the computer by robot class. For the controller that drives an arm’s joints, see our explainer on the robot controller; for the difference between guided and autonomous vehicles, start with AGV vs AMR.

The rates below are typical orders of magnitude rather than fixed figures, but they show why one computer rarely does everything. The robot computer is built for throughput; the layers at the bottom of the table need guaranteed timing instead.

Read down the table and the split becomes clear. Everything above motion control is a throughput problem that suits a GPU-heavy computer. Everything below it is a timing problem that suits a microcontroller, a drive or a certified safety device. The boundary between the two is where most integration work happens, and where most robot designs differ.

Where foundation models fit

Robots are starting to run models that map camera images and a spoken or written instruction straight to actions. A vision language action model usually runs at a few actions per second and hands its output to a faster controller that smooths and executes it. These models are trained in simulation and from demonstrations, using imitation learning and reinforcement learning, then run on the robot. Training happens in the data centre; the robot computer only runs inference, but it needs the memory to hold the model and the bandwidth to feed it.

On most robot projects the interfaces narrow the shortlist before processing power does. The table lists the common links, what they carry and what to check on the computer. Treat the rates as typical values; the camera, lidar or drive datasheet has the final word.

Cameras: GMSL2, MIPI CSI-2 or Ethernet

GMSL2 is the usual choice on mobile robots because it carries video, control and power over one locking coax cable several meters long, and the serializer sits at the camera. MIPI CSI-2 is the camera interface on the Jetson module itself, so it suits cameras mounted close to the computer, and GMSL2 deserialisers convert to it on the carrier board. Ethernet cameras, including GigE Vision cameras, suit fixed cells and longer runs, and PoE powers them from the same cable. Our guide to GMSL technology goes further on links and serialisers.

A worked camera bandwidth example

Say a mobile manipulator carries eight 1920 × 1080 cameras at 30 frames per second in a 16-bit YUV format. Each camera produces about 62 million pixels a second, or roughly 1 Gbps, so the eight together need about 8 Gbps into the computer before any processing. That fits comfortably on eight GMSL2 links, but it is a real load on memory bandwidth once each frame is copied, resized and fed to several networks. Raw or compressed formats change the figure a lot, so work it out for your own cameras.

Lidar, IMU and time synchronization

Sensor fusion only works when every reading carries an accurate timestamp. Most 3D lidar connects over Ethernet and takes its time from PTP or a GPS-style PPS pulse, and an IMU needs timestamping close to the sensor. Ports with hardware timestamping let the computer act as the time master for the whole robot. Our guides to IEEE 1588 PTP and sensor fusion cover the detail.

Drives and actuators: CAN FD and EtherCAT

Wheel drives, battery management systems and many robot joints talk CAN bus or its faster successor CAN FD, which carries up to 64 bytes per frame. On Linux the ports appear through SocketCAN, and isolated ports protect the computer from ground differences between the battery and the drive electronics. Arms and humanoids with many joints more often use EtherCAT, which needs a master with tight, repeatable timing; that usually means a dedicated core with a real-time kernel or a separate motion controller.

Most robot computers sold today are built on an NVIDIA Jetson module, because it combines an Arm CPU, a GPU, AI accelerators, camera interfaces and a mature robotics software stack in one low-power part. The table summarizes NVIDIA’s published module figures. Orin figures are sparse INT8 TOPS and Thor figures are sparse FP4 TFLOPS, so the two columns are not directly comparable: NVIDIA rates the Thor series at up to 7.5 times the AI compute of AGX Orin.

For most AMRs, cobot cells and inspection robots, Jetson Orin is still the sensible starting point: it is mature, widely supported by camera and carrier board makers, and an Orin NX or AGX Orin covers several cameras, lidar and the usual perception networks. Jetson Thor earns its place when the robot runs large transformer models, many high-resolution cameras or several workloads at once, and its 25GbE networking and 128 GB of memory matter as much as the headline figure. Our white paper on Jetson Thor vs AGX Orin covers the step in detail, Jetson T5000 vs T4000 compares the two Thor modules, and our guide to choosing a Jetson module sizes the whole range.

IGX and functional safety

IGX is NVIDIA’s industrial and medical edge AI range. IGX Orin pairs an AGX Orin-class processor with a separate safety microcontroller, and IGX Thor uses a functional safety island on the Thor processor, which NVIDIA describes as designed to meet ISO 26262 and IEC 61508. IGX boards add ConnectX networking, discrete GPU options, a board management controller and, for IGX Orin, support until 2033. NVIDIA positions the IGX Thor Developer Kit Mini as its development kit for robotic safety.

That makes IGX the better fit when the robot computer itself has to take part in the safety architecture, or when a long, fixed support window matters more than size and power. It does not make a robot safe on its own: the certified safety functions, the drives and the risk assessment still carry the safety case. Many IGX systems are mains-powered boards with large discrete GPUs, which suits fixed cells, surgical robots and carts better than battery-powered mobile robots.

x86 with a discrete GPU

Some AMR builders prefer an Intel or AMD computer with an NVIDIA RTX graphics card, usually because their software stack is built for x86, they need Windows, or they want to swap GPUs over the product’s life. It typically costs more power and space than a Jetson for the same AI throughput, but it is a valid choice, and several AMR computers combine a Core processor, a GPU slot, GMSL2 inputs and CAN in one chassis.

If the robot computer froze for half a second, would anyone or anything get hurt? If the answer is yes, the function at risk belongs on a controller that is designed and certified for it, not on the AI computer.

Jetson Linux is a general-purpose operating system. JetPack offers a real-time kernel option that tightens latency for motion control, but GPU workloads, memory pressure and software updates can still delay a thread. The usual answer is a layered design in which the robot computer decides, a real-time controller executes, and a safety controller can stop everything regardless of what the robot computer is doing.

The standards depend on the robot. Industrial arms and cobots are covered by ISO 10218, with collaborative operation guidance that is set out in our explainer on cobot safety standards. Driverless industrial trucks, including most AMRs, fall under ISO 3691-4, and functional safety design usually follows ISO 13849-1 or IEC 61508. Standards for legged and humanoid robots are still being developed. We are hardware specialists, not safety assessors: choosing computers and controllers with the right features supports a safety case, but the risk assessment and certification belong to the robot builder and their notified body.

Our case study on Jetson computers for safe human-robot collaboration shows the AI computer adding person detection alongside, not instead of, the certified safety system.

Power from the traction battery

On a mobile robot the computer shares the battery with the drives, so every watt it uses shortens the shift. Module power ranges on their own understate the load: cameras powered over coax or PoE, lidar, wireless modules and the carrier board all add to it.

Say a mobile robot carries a 2 kWh battery and the computer, with its cameras, averages 60 W. Over an 8-hour shift the computer alone uses 480 Wh, about a quarter of the pack. Dropping the average to 30 W with a smaller module or a lower power mode saves more than an hour of drive time. Measure your own duty cycle, because perception load and power modes change the average a lot.

DC input, ignition and hold-up

Look for a wide DC input that covers the battery’s full charge range plus transients, such as 9–36 V, 9–50 V or 19–36 V depending on the pack. Ignition control lets the computer start and shut down cleanly with the robot’s key switch or power relay, and a supercapacitor UPS can hold it up long enough to close files when the battery is swapped. NVMe drives with power loss protection protect maps and logs against sudden loss of power.

Cooling in a closed body

Robot bodies are often sealed, so the computer has to reject heat into a small enclosure. A Jetson module running at 60 W or more usually needs a heatsink coupled to the chassis or a fan, and a computer rated for 60 °C with airflow can throttle in a warm body without it. Our Jetson thermal design guide and our explainer on thermal throttling cover the design rules.

Shock, vibration and ingress

Floor joints, dock plates and outdoor terrain put steady vibration and repeated shocks through the robot. Locking connectors such as M12 and FAKRA, soldered or screwed-down memory and storage, and a chassis tested against MIL-STD-810H or a similar vibration profile all help. Outdoor and washdown robots need sealing, and an IP67 enclosure removes the need for a separate box around the computer.

The software stack often decides the hardware family. On Jetson, JetPack bundles Jetson Linux, CUDA, TensorRT and the camera and multimedia libraries; Jetson Thor uses JetPack 7, and our white paper on JetPack 7.2 and Yocto on Jetson Orin covers production images. Most robot builders run ROS 2 on top, with NVIDIA Isaac ROS packages that move perception, stereo depth and visual odometry onto the GPU. Our guide to the ZED ROS 2 wrapper on Jetson is a worked example of a stereo camera in ROS 2.

For high-bandwidth sensors, NVIDIA Holoscan and the Holoscan Sensor Bridge stream camera and sensor data over Ethernet straight into GPU memory, which suits robots with many cameras on Jetson Thor or IGX. Models are usually optimized with TensorRT before deployment, and many teams run vision language models and VLA policies in containers so they can be updated independently of the operating system.

Plan the fleet side early. Remote updates, logging and health monitoring matter more on a hundred robots than on one, and our explainer on AMR fleet management covers the software around the robot. Check the support window too: our answer on how long NVIDIA Jetson is supported sets out module lifecycles, which matter for a robot that will be built for five years or more.

The right computer depends on how many sensors the robot carries, which models it runs and where it works. The table gives typical starting points by robot class with an example from our range for each; the final choice depends on your sensor list, software and power budget.

What else to check

Count the camera links before the TOPS: a robot with eight GMSL2 cameras needs eight deserialiser channels on the carrier board or a frame grabber, and the module’s camera interfaces set a ceiling. Check CAN FD port count and isolation against the drives and battery system, Ethernet ports against lidar and uplinks, and the DC input against the battery’s full voltage range. Our explainers on what TOPS means and Jetson Super mode help translate the headline figures, and our article on the Vecow EAC-7000 Jetson Thor robot computer looks at one Thor-based design in detail.

Our wider ranges of NVIDIA Jetson computers and edge AI computers cover more module, port and enclosure combinations, and our autonomous and unmanned systems page shows where they are used. We configure every robot computer with JetPack or the operating system you need, camera drivers, storage, wireless modules and antennas, then test it before it ships.