Choosing onboard compute for a robot dog: Jetson Orin NX and alternatives
Updated 2026-11-01 · YUANZHI ROBOTICS engineering team
The onboard computer is where a robot dog payload either works or does not: it runs localization, reads every sensor, runs the detection models, records, and talks to the operator. It is also the component that decides a large part of the power and heat budget. This guide explains when the robot's own computer is enough, how the NVIDIA Jetson Orin family compares for payload work, when a Rockchip or x86 part is the better choice, and the carrier, cooling and software details that matter in practice.
Start with what the robot already has
Every current robot dog has a computer inside, and the first question is whether it can host the payload software.
- Unitree Go2 EDU: a Jetson Orin NX (or Orin Nano on some configurations) is available to the user alongside Unitree's own processes. It is adequate for a Mid-360 LiDAR, one camera and a SLAM stack, and tight for anything more. The robot's internal power and cooling were designed for Unitree's load, not for a payload running the GPU at full tilt in summer.
- Unitree B2, DEEP Robotics X30 and similar: a more capable internal computer, still shared with the manufacturer's stack and, on some models, with restricted access.
- Boston Dynamics Spot: the payload computer is a separate purchase (Spot CORE I/O, Jetson based) and the model of a separate payload computer is built into the platform.
Our rule: a mapping or research payload with a LiDAR and a camera can run on the robot's computer. An inspection payload with a gimbal, thermal camera, gas block and detection models gets its own computer in the payload, for three reasons: the robot's controller is never starved of CPU, the payload runs when the robot is off or docked, and the payload moves to a different robot without porting.
The Jetson Orin family for payload work
NVIDIA's Jetson Orin modules are the default for robot payloads because they combine an ARM CPU, a GPU that runs the perception models, hardware video encoders and the interfaces a sensor set needs, in a module the size of a credit card or a little larger. The three members that matter:
- Jetson Orin Nano 8 GB: up to 67 TOPS, 7 to 25 W configurable, 6-core CPU, 8 GB memory. Runs LiDAR SLAM and one camera pipeline with a light detection model. Right for Go2-class payloads and for mapping kits. Memory is the limit: SLAM, a camera pipeline and a model do not fit comfortably in 8 GB.
- Jetson Orin NX 16 GB: up to 157 TOPS, 10 to 40 W configurable, 8-core CPU, 16 GB memory, same form factor as the Nano. Runs SLAM, two camera streams (visible and thermal), gauge reading and an object or defect detection model at the same time, within 15 to 25 W in practice. This is what we fit in most inspection payloads on B2, X30 and UGV platforms.
- Jetson AGX Orin 32 or 64 GB: up to 275 TOPS, 15 to 60 W, 12-core CPU, PCIe and 10 Gb Ethernet. Needed when the payload runs several networks on high-resolution video, dense 3D reconstruction, or two or more LiDARs. It is larger (about 100 by 87 mm), heavier with its cooling, and its power draw means a bigger payload battery.
Within the family the deciding factor is almost always memory and the number of simultaneous pipelines, not peak TOPS. An inspection payload is a set of medium-sized tasks running at once; the NX's 16 GB and extra CPU cores are what make that comfortable.
Alternatives to Jetson
- Rockchip RK3588: an 8-core ARM SoC with a 6 TOPS NPU, 8 K video decode and 8 K encode, available on industrial modules at a fraction of a Jetson's cost. It runs LiDAR SLAM, video encoding for the operator and light inference (gauge reading, person detection) well; it does not run large vision models at useful frame rates. We use it where NVIDIA parts cannot be shipped to the destination, where the payload is mostly a camera and communications unit, and where cost is the first constraint. The inspection software is ported to it, with the heavy models moved to the operator's server.
- x86 modules and mini PCs (Intel Core or AMD Ryzen embedded): 30 to 65 W, heavier cooling, no useful GPU without a discrete card. Chosen only when the customer's software is x86-only, needs a specific PCIe device, or must run a Windows application. On a quadruped the power and mass are a real penalty.
- Qualcomm and other ARM SoCs: capable parts, but the robotics software ecosystem (ROS 2 packages, SLAM, camera and LiDAR drivers, model deployment) is far thinner than on Jetson, which costs integration time. We use them only when a customer specifies them.
Carrier board, storage and interfaces
The Jetson module alone does nothing; it sits on a carrier board that provides the connectors, and the carrier is where payload integration succeeds or fails. The developer kit carrier is fine on a bench and wrong in a payload: it is large, has consumer connectors, and is not rated for vibration or temperature. Industrial carriers (from several vendors, in sizes down to the module's own footprint) provide locking connectors, a wide-range DC input (typically 9 to 36 V, which allows direct supply from a 12 or 24 V payload rail), an M.2 slot for an NVMe SSD, and the interfaces a sensor set needs.
Count the interfaces before choosing a carrier: Gigabit Ethernet for the LiDAR and often the gimbal, a second Ethernet or a managed switch for the robot and a 5G module, USB 3 for depth and visible cameras, a serial port or two for the GNSS receiver and gas block, CAN where the gimbal or lighting uses it, and a GPIO for the pan-tilt trigger or strobe. A small managed Ethernet switch inside the payload is the usual answer when the count exceeds the carrier.
Storage is an industrial NVMe SSD of 512 GB to 1 TB; a round records tens of gigabytes of video and images, and the drive must take vibration and wide temperatures.
Power and cooling
Budget the module's configured maximum, not its typical draw: an Orin NX set to 25 W will reach it when SLAM, two camera pipelines and a model run together at an inspection point. Add the carrier, SSD, fan and any USB-powered sensors, and the compute section of an inspection payload comes to 25 to 35 W peak. Supply it from a dedicated DC-DC converter on the payload's distribution board with its own fuse, so that a motor or lighting transient on the shared rail cannot reset the computer mid-round.
Heat is the problem that shows up in the field. A sealed payload shell in the sun has no airflow; the module is bolted through a thermal pad to the aluminium shell, and the shell has fins or a large shaded flat area. A vented payload uses a filtered fan. The software reads the module's temperature sensors and reduces the model frame rate or warns the operator before the module throttles itself; a thermal shutdown in a tunnel or on a substation round is the failure to design against.
Software on the module
Our payloads run Ubuntu with NVIDIA's JetPack, ROS 2, the drivers for the LiDAR, cameras, gimbal, GNSS and gas block, a LiDAR-inertial SLAM stack, the inspection application (route, points, thresholds, recording) and the detection models exported to TensorRT. The operator reaches it through a browser on the robot's own Wi-Fi or over 5G; everything runs on the robot and an on-site server with no cloud dependency. The same software image runs on the Orin Nano and NX, and a reduced build runs on the RK3588 with the heavy models moved to the server.
Our recommendation by payload
- Mapping or research kit on a Go2 EDU (LiDAR, depth camera): the robot's own computer, or an Orin Nano if the kit must be independent of the robot.
- Inspection payload on a B2, X30 or inspection UGV (gimbal, thermal, acoustic, gas, LiDAR, 5G): Orin NX 16 GB on an industrial carrier, own battery.
- Heavy perception (several networks on 4 K video, dense reconstruction, two LiDARs): AGX Orin 32 or 64 GB, with the larger battery and cooling that implies.
- Export-restricted destination or camera-and-communications payload: RK3588 industrial module.
If you are deciding what computer to put on a robot dog, send us the sensor list and what the software has to do on board; we will tell you which module we would fit and what it would draw.
FAQ
Can I run my payload software on the robot's own computer?
Partly. A Unitree Go2 EDU has a Jetson Orin NX that is shared with Unitree's own stack, and some vendors expose only part of it; a B2 or X30 has a more capable internal computer but still shared. For a LiDAR and a camera with a light SLAM stack the internal computer is often enough. For a full inspection payload we add a separate computer in the payload so that the robot's own controller is never starved and the payload can be moved to another robot.
Orin Nano, Orin NX or AGX Orin?
Orin Nano 8 GB (up to 67 TOPS, 7 to 25 W) for LiDAR SLAM and one camera; Orin NX 16 GB (up to 157 TOPS, 10 to 40 W) for SLAM plus two camera streams and a detection model, which is the usual inspection payload; AGX Orin 32 or 64 GB (up to 275 TOPS, 15 to 60 W) for several networks on high-resolution video, dense 3D reconstruction or multiple LiDARs. Memory, not TOPS, is what usually decides: SLAM and two camera pipelines want more than 8 GB.
Why not just use a small x86 computer?
An x86 mini PC or module draws 30 to 65 W, weighs more with its cooling, and has no GPU worth using for perception unless you add one. It is the right choice only when the customer's existing software is x86-only or needs specific PCIe hardware. For everything else an ARM module with an integrated GPU does the same work at a third of the power.
What about export restrictions on Jetson modules?
Jetson Orin modules are standard commercial parts and ship to most countries without licensing. For a few destinations under export control our payloads are built with a Rockchip RK3588 module instead, which handles video encoding, light inference and SLAM at lower cost, with the inspection software ported to it.
How much power does the compute draw?
An Orin NX on an industrial carrier runs at 15 W typical for an inspection stack and up to 25 W at full load; an Orin Nano at 7 to 15 W; an AGX Orin at 30 to 60 W. Add the carrier board, storage and fan, and budget the peak figure plus 30 percent in the payload's power design.