Glossary

Fictionlab > Glossary > NVIDIA Jetson

NVIDIA Jetson

NVIDIA Jetson – definition

NVIDIA Jetson is a family of embedded computing modules and developer kits designed for edge AI, accelerated computer vision, robotics, and autonomous machines. A Jetson module combines an ARM-based CPU, an NVIDIA GPU, memory, storage interfaces, and high-speed I/O on a compact embedded platform. It runs Linux and the NVIDIA JetPack SDK, which includes CUDA, cuDNN, TensorRT, multimedia APIs, and other accelerated libraries.

In mobile robotics, NVIDIA Jetson is commonly used as the high-level compute unit for perception, mapping, localisation, path planning, and machine-learning inference. It is not a motor controller or a safety controller. Low-level wheel control, encoder reading, and real-time actuator handling should remain on a dedicated microcontroller or rover control board.

For a UGV, Jetson can process data from LiDARs, depth cameras, RGB cameras, IMUs, GNSS receivers, and other payload sensors. It can then publish processed data into a ROS 2 graph for use by SLAM, Nav2, object detection, terrain analysis, or remote inspection software.

Jetson hardware families for robotics

Jetson modules differ in GPU capability, memory capacity, power envelope, I/O availability, and mechanical format. The correct module depends on the sensor payload, expected inference load, thermal constraints, and available battery power on the mobile platform.

Jetson family Maximum AI performance Configured power range Typical UGV role
Jetson Orin Nano Up to 67 TOPS 7 W to 25 W ROS 2 navigation, one or two cameras, lightweight detection, sensor fusion
Jetson Orin NX Up to 157 TOPS 10 W to 40 W Multi-camera perception, LiDAR processing, accelerated SLAM and neural inference
Jetson AGX Orin Up to 275 TOPS 15 W to 60 W High-throughput research payloads, multiple sensors, complex perception pipelines

The values in the table are NVIDIA maximum figures for the Jetson Orin product family. TOPS is a neural-network inference metric and does not directly describe ROS 2 node latency, CPU performance, storage bandwidth, or SLAM accuracy. Actual performance depends on model precision, TensorRT optimisation, input resolution, memory transfers, cooling, and concurrent processes.

Source: NVIDIA Jetson Orin technical specifications.

NVIDIA Jetson in ROS 2 systems

Jetson does not require a specific ROS 2 distribution. It runs a supported Ubuntu-based JetPack environment, on which ROS 2 packages can be built from source or installed when compatible binaries are available. ROS 2 Humble Hawksbill is compatible with Ubuntu 22.04 used by JetPack 6; support for other ROS 2 distributions depends on the Ubuntu and JetPack version.

A common UGV architecture separates hardware control from compute-intensive robotics software. The rover controller maintains drive functions, while Jetson executes ROS 2 nodes and communicates with the base platform through USB, Ethernet, serial interfaces, CAN, or another supported transport.

  • sensor_msgs/msg/Image for RGB, mono, infrared, or depth-camera image streams.
  • sensor_msgs/msg/PointCloud2 for 3D LiDAR and depth-derived point clouds.
  • sensor_msgs/msg/Imu for angular velocity, linear acceleration, and orientation data.
  • nav_msgs/msg/Odometry for wheel, visual, LiDAR, or fused odometry.
  • sensor_msgs/msg/NavSatFix for GNSS position data.
  • tf2 transforms for sensor frames, base_link, odom, and map.

Frame naming and coordinate conventions should follow REP 103 and REP 105. REP 103 defines standard units and coordinate conventions, while REP 105 defines commonly used mobile-platform frames, including base_link, odom, and map. These conventions are important when combining camera, LiDAR, IMU, and wheel-odometry data.

Sources: ROS REP 103, ROS REP 105, ROS 2 Humble documentation.

Jetson integration on Leo Rover and Raph Rover

Leo Rover uses Raspberry Pi as its default embedded compute unit. NVIDIA Jetson should therefore be treated as an optional external or replacement high-level computer, not as a mandatory Leo Rover component. The ROS 2 distribution supported by a Leo Rover setup depends on its installed image and software version. A Jetson-based setup requires verification of power delivery, mechanical mounting, network connectivity, cooling, and compatibility with the rover control interface.

On Leo Rover, a Jetson Orin Nano or Jetson Orin NX can be appropriate when Raspberry Pi resources are insufficient for GPU inference or multi-sensor processing. Example workloads include RealSense depth processing, LiDAR point-cloud filtering, visual odometry, YOLO-family detection models, semantic segmentation, and, on modules that include an encoder, hardware-accelerated video encoding.

Raph Rover provides a larger payload-oriented platform for heavier sensor and compute configurations. It can be a more suitable base when the system includes a Jetson carrier board, active cooling, multiple cameras, LiDAR, GNSS/RTK equipment, and a battery sized for the combined drive and compute load. This does not make Raph Rover a replacement for Leo Rover in laboratory teaching or compact research setups.

In both cases, Jetson should publish only validated ROS 2 outputs to navigation and control nodes. A perception pipeline that detects obstacles is not equivalent to a complete autonomous navigation system. Nav2 also requires a configured robot model, transforms, odometry, costmaps, planner and controller plugins, recovery behaviour, and safety validation.

Sources: Leo Rover technical documentation, Nav2 documentation.

Deployment, containers, and acceleration

Jetson deployments should be reproducible. Docker is often used to isolate ROS 2 dependencies, CUDA libraries, inference runtimes, and application packages. Containers must use an NVIDIA-compatible container runtime to access the GPU and relevant device nodes.

docker run --rm -it \
  --runtime nvidia \
  --network host \
  --ipc host \
  -e ROS_DOMAIN_ID=20 \
  ghcr.io/example/ros2-jetson:humble \
  ros2 launch ugv_bringup perception.launch.py

GPU acceleration is most useful when a node has a compatible implementation. Installing CUDA alone does not accelerate generic ROS 2 code. For example, TensorRT can optimise supported neural-network inference graphs, while CUDA-enabled OpenCV or NVIDIA Isaac ROS packages may accelerate selected vision and perception workloads.

Source: NVIDIA JetPack documentation.

Limitations and engineering trade-offs

Jetson integration adds compute capability but also increases system complexity. Power consumption, heat dissipation, boot time, storage reliability, and cable retention are relevant on outdoor UGVs. A module operating at a higher configured power mode requires an electrical and thermal design that can sustain that mode under ambient-temperature and enclosure constraints.

Jetson is also not deterministic in the same way as a real-time microcontroller. Linux scheduling, GPU kernel execution, USB latency, and memory contention can affect timing. Motor safety, emergency stop logic, and low-level velocity limits should not depend solely on a GPU perception pipeline.

See also