Jetson Orin Nano on a UGV: Power Budget, Thermals and What Runs in Real Time

TL;DR: The NVIDIA Jetson Orin Nano 8GB supports official 7 W and 15 W module power profiles; the newer Super mode raises the module power profile to 25 W and peak AI performance to up to 67 TOPS. On a small UGV like the Leo Rover, this compute node can fit within a typical battery budget only if you plan cooling, payload power and duty cycles carefully. Illustrative measurements in a compact IP54-class enclosure at ambient temperatures around 25 to 30 °C show that passive cooling can bring the SoC close to its thermal limits under sustained load, while an added fan and a conductive heat path to the enclosure can keep temperatures substantially lower. You can expect roughly 30 to 60 FPS for YOLOv8n object detection and around 10 to 15 Hz for RTAB-Map RGB-D SLAM running in parallel, depending on resolution, optimization, sensors, cooling and the selected power profile. This article breaks down the jetson orin nano robot power consumption, thermal behavior, and what workloads can run in real time on a mobile platform.

Why does jetson orin nano robot power consumption matter on a UGV?

A mobile robot has three energy consumers competing for the same battery: drivetrain, sensors, and compute. On a compact 4WD platform like the Leo Rover, the total onboard energy budget is limited by the battery pack. Leo Rover configurations commonly use a 6S Li-Ion pack rated at 22.2 V and 10 Ah, or about 222 Wh nominal; available options and usable energy depend on the specific rover configuration, battery-management limits and operating conditions. Every watt spent on compute reduces mission time or the power margin available for motors and sensors.

The Jetson Orin Nano 8GB delivers up to 40 TOPS of AI performance in its original configuration and up to 67 TOPS with the Super mode update, which is enough for parallel perception pipelines. But that performance is not free. Understanding the jetson orin nano robot power consumption across its modes lets you match the compute load to the mission profile, whether that is a short indoor mapping run or a multi-hour outdoor inspection.

Power modes and measured draw

NVIDIA exposes power modes through nvpmodel. On the Orin Nano 8GB developer kit, the standard module power profiles include:

• 7W mode: Limits the module power budget to 7 W. CPU core availability and clock limits depend on the installed JetPack and board configuration. Input-side system draw can be lower at idle and can exceed 7 W once carrier-board losses and connected peripherals are included.
• 15W mode: Limits the module power budget to 15 W. In a typical developer-kit setup, total input-side draw commonly reaches roughly 13 to 16 W under sustained compute load before cameras and other USB peripherals are added.
• MAXN SUPER (25W): Available on supported Orin Nano 8GB systems with the JetPack 6.1 Super update or later. This profile enables CPU clocks up to 1.7 GHz and GPU clocks up to 1020 MHz, with a 25 W module power profile. Actual input-side power can be higher after carrier-board and peripheral consumption are included.

Power-mode limits apply to the module rather than to the complete rover payload. Add the consumption of the carrier board, storage, network interfaces and sensors. A USB camera may add around 1 to 3 W depending on its operating mode; an Intel RealSense D435i typically draws around 1.5 to 2 W, while an RPLIDAR A2 is specified for up to approximately 2.5 W.

Before switching modes, inspect the profiles available on your installed BSP, because mode indices can differ between JetPack releases and board configurations:

sudo nvpmodel -q --verbose # list available power profiles and IDs
sudo nvpmodel -m <ID> # select the required profile
sudo jetson_clocks # lock clocks to the maximum allowed by that profile

To monitor power and thermals live, use tegrastats or the jtop tool from the jetson-stats package:

sudo pip3 install -U jetson-stats
sudo systemctl restart jtop.service
jtop

What fits in a rover power budget and what does not?

Assume a Leo Rover-class UGV with a 22.2 V, 10 Ah battery pack, or about 222 Wh nominal. Drivetrain draw varies heavily with terrain, payload, speed, slope and wheel slip, while base electronics and the primary microcontroller add their own continuous load. Rather than treating the remaining wattage as a fixed payload allowance, calculate mission duration from measured total system power and retain sufficient current margin for drivetrain peaks.

The table below summarizes what can realistically fit within that envelope during continuous operation.

Payload feasibility table

• Fits comfortably (7W mode + one camera, approximately 10 W total payload): Teleoperation with H.264 encoded video, ArUco marker detection at 30 FPS, basic 2D SLAM with a LiDAR (Cartographer, gmapping), waypoint navigation with Nav2.
• Fits with margin (15W mode + RGB-D camera, approximately 18 W total payload): YOLOv8n object detection at 30 to 45 FPS, RTAB-Map RGB-D SLAM at 10 to 15 Hz, ORB-SLAM3 monocular at 20 to 25 Hz, Nav2 with local costmap fusion.
• Tight fit, expect reduced mission time (MAXN SUPER + depth + LiDAR, approximately 28 W total payload): YOLOv8s at 30 FPS plus RTAB-Map in parallel, semantic segmentation with lightweight models, dual-camera perception stacks.
• Not a predictable real-time fit on this platform: Large transformer-based models such as full SAM or BEVFormer, dense high-resolution stereo combined with heavy detection, and large language-model inference. Some of these workloads may run with quantization or reduced inputs, but require workload-specific benchmarking and cooling validation.

The takeaway: matching workload to power mode is a design decision, not a runtime one. Profile your pipeline on the bench, then pick the lowest mode that meets your latency targets.

How do thermals behave inside a sealed enclosure?

Field robotics rarely allow open-air cooling. An IP54-rated enclosure is protected against dust ingress and water splashes, but it still restricts airflow and can trap heat. In illustrative testing with a Jetson Orin Nano 8GB mounted inside a compact polycarbonate housing of about 2 liters internal volume at 25 °C ambient, the following behavior was observed:

• Passive cooling (stock heatsink, no fan) in 15W mode: SoC temperature rose from approximately 45 °C at idle to 78 to 85 °C under sustained YOLOv8n load within 8 to 12 minutes. Thermal throttling thresholds depend on the JetPack release, sensor and thermal policy, so verify them on the deployed system rather than relying on one fixed temperature.
• Active cooling (5 V PWM fan, 40 mm, inside the enclosure) in 15W mode: SoC stabilized at approximately 58 to 65 °C under the same load. A recirculating fan improves heat transfer from the heatsink to the enclosure air, but it does not by itself reject heat outside the enclosure; a conductive path to the enclosure wall remains important.
• Active cooling in MAXN SUPER (25W): SoC reached approximately 72 to 78 °C under sustained load in this setup. Without a fan or another effective heat-rejection path, sustained 25 W operation can lead to thermal throttling, especially in a compact enclosure.

At 35 °C ambient, temperatures will generally rise substantially, although the increase is specific to the enclosure, heat path, airflow and workload. Passive cooling in MAXN SUPER is usually impractical in that range. If your deployment includes hot climates, active cooling and a conductive thermal path to the outside of the enclosure are strongly recommended. An aluminum plate coupling the heatsink to the enclosure wall can improve heat rejection without compromising the IP rating when designed correctly.

Reproducible thermal test

To reproduce these numbers on your own hardware, run a sustained inference load and log tegrastats output:

tegrastats --interval 1000 --logfile thermal_log.txt &
# Run your inference pipeline for 20 minutes
python3 detect.py --source 0 --weights yolov8n.pt --imgsz 640

Then plot the available temperature fields, such as CPU@, GPU@, SOC0@ or Tdiode@, against time. The exact field names vary by JetPack release. This gives you a thermal curve specific to your enclosure and mounting.

What runs in real time on a Leo Rover with Orin Nano?

Real time on a UGV usually means keeping perception, planning, and control loops predictable at their required rates. Perception at 10 Hz is enough for many navigation tasks, control loops commonly need 50 to 100 Hz on the microcontroller side, and detection can run at whatever the camera provides if throughput allows.

Representative pipelines under ROS 2 Humble with the Jetson Orin Nano 8GB in 15W mode can achieve the following results when engines are optimized, sensors are configured appropriately and the system is adequately cooled:

• YOLOv8n (640×640) with TensorRT FP16: 55 to 65 FPS standalone, 40 to 50 FPS when running alongside Nav2 and a camera driver.
• YOLOv8s (640×640) with TensorRT FP16: 28 to 35 FPS standalone, 22 to 28 FPS in a full stack.
• RTAB-Map RGB-D SLAM with RealSense D435i at 640×480: 12 to 15 Hz mapping update, with loop closure operating in real time in favorable scenes.
• Nav2 with local and global costmaps: Control loop at 20 Hz and planner at 1 Hz are generally achievable, but jitter must be measured on the complete robot stack rather than assumed absent.
• YOLOv8n + RTAB-Map in parallel: Detection can drop to 30 to 38 FPS while SLAM holds 10 to 12 Hz. Total input-side compute-and-sensor draw depends on the carrier, sensors, clocks and cooling, and must be measured on the target platform.

These numbers assume TensorRT-optimized engines built on the target device with matching JetPack and CUDA versions. Raw PyTorch models usually deliver lower throughput and can consume more energy per inference than optimized TensorRT FP16 engines, but the magnitude of the difference depends on the model and implementation.

Practical ROS 2 integration

A minimal ROS 2 launch pattern for perception on the Orin Nano can use the image_transport compressed pipeline to reduce network bandwidth where appropriate. Compression and decompression also consume CPU resources, so compare it with raw transport on the actual publisher and subscriber hardware. CPU affinity can be used to reserve selected cores for inference-related processes:

taskset -c 2,3,4,5 ros2 run your_detector detector_node --ros-args -p model_path:=/opt/models/yolov8n.engine

For Leo Rover users, integrating the Orin Nano as a secondary compute node over Ethernet keeps the base microcontroller free for real-time motor control. The rover’s ROS 2 stack exposes odometry, IMU, and command topics, so the Jetson can publish perception outputs and, when it is responsible for navigation, publish /cmd_vel commands. You can find integration details on the Leo Rover product page and application examples on the research applications page.

Passive or active cooling in the field?

The choice is not universal. Passive cooling is silent, has no moving parts to fail, and works well for low-duty missions. Active cooling adds a failure point but expands the operating envelope substantially.

Choose passive when: mission duration is short (under 20 minutes of sustained load), ambient stays below 25 °C, you operate in 7W or low-duty 15W mode, and the enclosure has an effective metal-to-metal heat path to the outside.

Choose active when: you run MAXN SUPER or sustained 15W load, ambient can exceed 30 °C, the enclosure is small or airflow-restricted, or mission duration exceeds 30 minutes of continuous inference. For field robotics in variable conditions, a temperature-triggered fan offers a reasonable compromise, but its trigger point should be validated against the thermal policy and sensor readings of the deployed system.

FAQ

What is the actual power draw of a Jetson Orin Nano on a rover?

The 7 W, 15 W and 25 W settings are module power profiles, not a complete rover-payload measurement. In a typical setup, add the carrier board, storage, network interfaces, cooling and sensors. Plan for roughly 15 to 25 W for a typical perception payload, then verify the figure with an input-side power measurement on the completed robot.

Can the Orin Nano run YOLO and SLAM at the same time?

Yes. In 15W mode with TensorRT FP16, YOLOv8n and RTAB-Map RGB-D SLAM can run in parallel at approximately 30 to 38 FPS and 10 to 12 Hz respectively in a well-optimized setup. Higher-parameter models such as YOLOv8s reduce those numbers but can remain usable.

Does the Orin Nano need active cooling on a mobile robot?

It depends on power mode, ambient temperature, enclosure design and workload. Passive cooling can suffice in 7W mode and in intermittent 15W workloads at low ambient temperatures. Sustained MAXN SUPER operation, hot-climate deployments or compact enclosures generally require a fan and an effective heat path to the outside to avoid thermal throttling.

How long will a Leo Rover run with a Jetson Orin Nano payload?

Runtime must be calculated from the actual battery configuration and measured total system power. A 22.2 V, 10 Ah pack stores about 222 Wh nominal: at a measured continuous system draw of 40 to 50 W, the ideal calculation is about 4.4 to 5.5 hours before accounting for battery-management limits, conversion losses, terrain and drivetrain peaks. Sustained MAXN SUPER operation increases total draw and correspondingly reduces runtime.

What JetPack version should you use for real-time robotics?

Use JetPack 6.1 or later if you need the Orin Nano Super mode update, while confirming compatibility with your carrier board and application stack. JetPack 6 is based on Ubuntu 22.04 and aligns directly with ROS 2 Humble. ROS 2 Jazzy targets Ubuntu 24.04 for its standard binary packages, so it is not a like-for-like default match for JetPack 6.

Is TensorRT conversion mandatory for good performance?

Not mandatory, but strongly advised for supported models. Raw PyTorch or generic ONNX Runtime inference often delivers lower throughput and worse energy efficiency than TensorRT FP16 engines built on the target device. Benchmark the exact model, precision and input resolution before making a power-budget decision.

Can you use the Orin Nano for outdoor SLAM without GPS?

Yes. Visual-inertial and LiDAR-inertial SLAM stacks such as RTAB-Map, ORB-SLAM3 and, with an appropriate LiDAR configuration, LIO-SAM can run on the Orin Nano. Real-time performance depends on sensor rate, point-cloud density, mapping settings and the rest of the robot workload. Fusing wheel odometry from the rover base improves robustness on rough terrain.

Ready to build your perception stack?

If you want a validated hardware baseline for Jetson-based perception on a UGV, Fictionlab offers a Vision Pack configuration built around the Leo Rover with integrated compute and sensor mounting. Explore the options in the Fictionlab shop to find a starting point that matches your power and thermal targets.