Choosing an Edge AI Module for a Robot: Jetson Orin, Jetson Thor and IGX Thor Against Seven Criteria

The onboard computer is one of the hardest parts of a robot to change once chosen, because the carrier board, power supply, cooling and camera wiring are all designed around it. Yet module comparisons often come down to one large number, TOPS or TFLOPS. This article takes the official specifications for NVIDIA Jetson Orin, Jetson Thor and IGX Thor and sets out seven criteria to check beyond headline performance, including the ones you can settle with a quick calculation.

Whether a model fits in memory, and the bandwidth-bound ceiling on inference speed, are covered in sizing memory and bandwidth for on-device VLA models. Here the focus is the step after that calculation: choosing the module.

Official specifications of the candidates

Sources: NVIDIA Jetson Orin, NVIDIA Jetson Thor. The Jetson Orin page’s table has some misaligned columns, so confirm values against each module’s datasheet before locking a design. The Jetson Thor page footnotes that its peak figure was measured at 130 W.

IGX Thor, the industrial variant, is covered under the functional-safety criterion below rather than in this table.

Criterion 1: match the precision behind the number

Performance is the first thing anyone looks at, but Orin is quoted in sparse INT8 TOPS and Thor in sparse FP4 TFLOPS. Because the same hardware produces very different numbers at different precisions, dividing one by the other to claim “N times faster” is meaningless.

What matters is the precision at which you will deploy your model. If you have no plan to quantize to FP4, treat the FP4 figure as background and compare on benchmarks or your own measurements at the precision you will actually use.

Criterion 2: look at capacity and bandwidth separately

On the Jetson Thor specification, T4000 and T5000 share 273 GB/s of bandwidth and differ only in capacity, 64 GB versus 128 GB. If your model already fits in 64 GB, moving to T5000 may not change bandwidth-bound inference speed much. Moving from Orin NX 16GB to AGX Orin 64GB, by contrast, doubles bandwidth from 102.4 GB/s to 204.8 GB/s according to the Jetson Orin specification, so capacity and speed change together.

Criterion 3: turn power and heat into a battery calculation

On a battery-powered robot, a module’s power range translates directly into runtime. With module power $P$ and shift length $t$, the energy spent on compute alone is:

Running a T5000 at its 130 W maximum from the Jetson Thor specification for four hours takes 520 Wh; a T4000 at its 70 W maximum takes 280 Wh, and an AGX Orin at 60 W takes 240 Wh. Setting these next to the robot’s battery capacity shows immediately how much runtime compute costs. Real draw depends on power mode and load and can sit below the maximum, so substitute values measured in your operating mode.

Nearly all of that power becomes heat, so the same figure drives thermal design. For a humanoid with the computer sealed inside its torso, confirm with thermal testing whether the maximum power mode can be sustained.

Criterion 4: derive the latency budget from the control rate

The latency the module must meet comes from the robot’s control rate. If commands must go out at rate $f$, each cycle has $1/f$ to work with: 5 ms at 200 Hz, about 33 ms for a 30 Hz camera.

As shown in how Figure’s Helix evolved, large models often run at a slow rate while a small policy runs fast. Module choice then becomes two questions: does the fastest layer fit in its latency budget, and can the slow and fast layers run on one chip at the same time? The Jetson Thor page lists Multi-Instance GPU support (10 TPCs on T5000, 6 on T4000), which makes it possible to consider partitioning GPU resources by layer.

Criterion 5: count sensor and network I/O first

Humanoids often carry head, wrist and palm cameras plus lidar, an IMU and tactile sensors, so input ports can run out before compute does. The Jetson Thor page lists the number of 25GbE ports (four on T5000, three on T4000) and describes multi-camera connections over MIPI CSI-2 and Holoscan Sensor Bridge. List your cameras and interface types (MIPI, GMSL, Ethernet) first, then check how many the carrier board actually exposes, not just the module.

Criterion 6: decide early whether you need functional safety

Certifying a robot that works alongside people brings functional safety into scope. The NVIDIA technical blog describes IGX Thor this way:

• It complies with ISO 26262 and IEC 61508 and targets ASIL D/SC3 and ASIL/SIL 2; the wording does not claim certification.
• An independent safety processor, the Functional Safety Island, separates safety and non-safety domains in hardware.
• IGX T5000 is said to deliver the same performance as Jetson T5000 with full DRAM ECC enabled.

If your product needs functional safety, separate what the module supports from what the whole system must be certified for, and talk to your certification body early.

Criterion 7: software stack and supply life

The same blog says the IGX platform is supported for up to 10 years in hardware and offers an LTS branch with version-locked frameworks maintained for 10 years. Production robots may need the same board for years, so checking this during the developer-kit phase avoids a redesign later. How the robot-side stack (Isaac, GR00T, Holoscan) relates to the training and simulation computers is covered in NVIDIA’s three-computer architecture.

Running the candidates through the same numbers

Criteria 3 and 4 can be compared across candidates with a few lines of code. The power values below are the maxima from the Jetson Thor and Jetson Orin pages; battery capacity, shift length and inference times are illustrative assumptions to replace with your own measurements.

# Compare compute energy and control-loop slack across candidate modules.
modules = {            # maximum power (W) from official pages
    "Orin NX 16GB": 40,
    "AGX Orin 64GB": 60,
    "Jetson T4000": 70,
    "Jetson T5000": 130,
}
battery_wh = 2000      # assumption: robot battery capacity
shift_h = 4            # assumption: shift length
control_hz = 200       # rate of the fastest control layer
infer_ms = {"Orin NX 16GB": 6.0, "AGX Orin 64GB": 3.5,   # assumption: measured policy latency
            "Jetson T4000": 2.0, "Jetson T5000": 1.5}

budget_ms = 1000 / control_hz
for name, watt in modules.items():
    e = watt * shift_h
    share = e / battery_wh
    slack = budget_ms - infer_ms[name]
    print(f"{name:14s} compute {e:5.0f} Wh ({share:4.0%} of battery) | cycle {budget_ms:.1f} ms, slack {slack:+.1f} ms")

A negative slack means the policy cannot run at that rate on that module. The options are then to change the module, shrink the policy or lower the control rate.

The seven criteria in one table

If you have not yet chosen the model to deploy, check per-model VRAM needs in comparing open-source robot policy models and then come back to this table.