The board arrived, we plugged in HDMI, and the Ubuntu desktop came up. We typed pip install torch ultralytics into a terminal and the install finished without a hitch. Then we called torch.cuda.is_available() and got False. We were running inference on the CPU of a 157 TOPS module.

Just about everyone who touches a Jetson for the first time lives through that scene. Here is the problem: a Jetson is not a "small ARM-based Linux computer." It is its own platform, with its own kernel, its own CUDA packaging scheme, and its own PyTorch builds. Half the habits that work on an x86 desktop quietly give you the wrong answer here — nothing errors out, it just runs slow.

This post walks the Jetson Orin NX 16GB — the companion computer on our SUAS 2026 aircraft — from the box to its first YOLO inference. We are not trying to restate NVIDIA's documentation; we want to record where each decision actually gets made and where the time gets lost. Version numbers are current as of July 2026; the JetPack line moves fast, so check the download page one more time before you start.

Where the Orin NX sits in the lineup

On the Jetson side, the module (the compute board) and the carrier board are two separate things. The Orin NX is a module; it drops into the carrier from the Orin Nano developer kit just as happily as into a third-party carrier.

We picked the Orin NX 16GB for the memory, not the TOPS. The same board carries the YOLO11m TensorRT engine, the RTSP decoder, the FastMosaic mapping process, and the ROS2 nodes all at the same time. On an 8 GB module that stack falls into swap and latency stops being predictable.

What exactly does JetPack bundle?

JetPack is the Jetson's operating system + driver + acceleration library bundle. There are three things inside it: Jetson Linux (L4T, i.e. Linux for Tegra — the kernel, bootloader, and BSP), the CUDA stack, and the AI libraries sitting on top of it.

The most critical point: you do not choose your CUDA, cuDNN, and TensorRT versions — JetPack chooses them. Upgrading one library on its own usually breaks the stack.

JetPack 7.2 shipped on June 1, 2026 and brought the Orin family onto the JetPack 7 line. So as of 2026 there are two live options for the Orin NX:

• JetPack 6.x — a mature ecosystem. Third-party carrier board BSPs, prebuilt wheels, and forum fixes were all written for this line. If you are a few months out from the competition and do not want to take on risk, stay here.

• JetPack 7.2 — Ubuntu 24.04, CUDA 13, a newer kernel. Makes sense if you are starting from scratch and your carrier board vendor explicitly says it is supported.

Do not push a working stack across a major version right before a competition. Every JetPack major transition means re-validating everything from your torch wheels to your camera driver.

Storage: NVMe or SD card?

There is no eMMC on the Orin NX module. The bootloader and hardware configuration live in a small QSPI flash on the module itself; the root filesystem gets written to an external drive.

The M.2 slot is PCIe; SATA M.2 drives will not work. If you are recording 1080p RTSP plus per-frame image logs in flight, size the drive from flight time × bitrate instead of saying "128 GB is probably enough."

Flashing with SDK Manager

SDK Manager is NVIDIA's flashing tool, and it runs on a host computer. It does not run on Windows.

Host requirements: Ubuntu x64 22.04 or 20.04, and free disk space. NVIDIA asks for roughly 27 GB free on the host side and 16 GB on the target side for a full deployment; in practice, set aside 60 GB. USB passthrough in a virtual machine has a habit of causing trouble — use bare metal or a second disk if you can.

The flow:

1. Install SDK Manager on the host and sign in with your NVIDIA account.

2. Put the Jetson into force recovery mode. On a developer kit that means jumpering the FC_REC pin to GND and resetting the board (on the Orin Nano devkit carrier: with pins 9–10 on the button header jumpered, briefly short 7–8). Third-party carriers use a different pinout, so check your own manual.

3. Connect it to the host over USB-C and verify:

lsusb | grep -i nvidia
# e.g. Bus 001 Device 012: ID 0955:7323 NVIDIA Corp. APX

lsusb | grep -i nvidia
# e.g. Bus 001 Device 012: ID 0955:7323 NVIDIA Corp. APX

1. In SDK Manager, select the Orin NX module as the target hardware, then select the JetPack version.

2. Check NVMe as the storage device. Skipping this step means extra work later to move onto the drive.

3. When the flash finishes, the board reboots and shows Ubuntu's first-run screen (OEM config): language, user, time zone. At that point SDK Manager asks for the username/password you just created and installs the remaining SDK components over the network.

Do not swap the USB cable or let the host go to sleep during a flash. A flash interrupted halfway through means putting the board back into recovery mode.

First boot: the verification checklist

Once the board comes up, first confirm what actually got installed:

# JetPack / L4T version
cat /etc/nv_tegra_release
sudo apt-cache show nvidia-jetpack | grep -m1 Version

# CUDA compiler
nvcc --version    # if missing: export PATH=/usr/local/cuda/bin:$PATH

# Fill in the missing SDK components
sudo apt update && sudo

# JetPack / L4T version
cat /etc/nv_tegra_release
sudo apt-cache show nvidia-jetpack | grep -m1 Version

# CUDA compiler
nvcc --version    # if missing: export PATH=/usr/local/cuda/bin:$PATH

# Fill in the missing SDK components
sudo apt update && sudo

The output of nvidia-smi does not behave on a Jetson the way it does on desktop GPUs; use jtop, covered below, for GPU status.

Power modes and jetson_clocks

A Jetson does not arrive in its highest performance mode. The nvpmodel tool caps CPU/GPU frequencies and the number of active cores against a power budget, and the setting persists across a power cycle.

sudo nvpmodel -q            # show the current mode
sudo nvpmodel -m 0          # MAXN / MAXN SUPER (unrestricted)
sudo jetson_clocks          # pin the clocks to their ceiling (resets on reboot)
sudo jetson_clocks --show

sudo nvpmodel -q            # show the current mode
sudo nvpmodel -m 0          # MAXN / MAXN SUPER (unrestricted)
sudo jetson_clocks          # pin the clocks to their ceiling (resets on reboot)
sudo jetson_clocks --show

The Orin NX has 10W, 15W, 20W, and 40W reference modes plus the unrestricted MAXN SUPER mode. The Super mode that arrived with JetPack 6.2 lifts INT8 dense performance on the Orin NX 16GB from 50 TOPS to 78 TOPS (35 → 58 TOPS on the 8GB part).

The difference between the two matters: nvpmodel sets the budget, while jetson_clocks turns off dynamic frequency scaling within that budget and holds the clocks at the ceiling. jetson_clocks reduces latency variance (jitter) but drives the fan and the temperature up. MAXN SUPER may mean "unrestricted," but the module still throttles once it exceeds TDP — meaning that picking the top mode with inadequate cooling can end up slower than staying in a middle one.

Measure this inside the airframe, not on the bench. A closed drone body has no airflow; in our flight profile, what decided whether we hit our target of 15–20 FPS on 640-pixel full-frame inference was not the model, it was thermal stability.

Monitoring with jtop

jetson-stats is a monitoring package written specifically for the Jetson (7.2.0 as of July 2026). GPU utilization, power mode, temperatures, the fan, and the engines (NVENC/NVDEC/DLA) all appear on a single screen.

sudo pip3 install -U jetson-stats
jtop            # if it does not run right after install, log out and back in

sudo pip3 install -U jetson-stats
jtop            # if it does not run right after install, log out and back in

Memory: zram, swap, and headless

JetPack sets up zram (compressed in-RAM swap) by default. If a large model export — building a TensorRT engine in particular — strains memory, a real swap file on the NVMe is the safer option:

sudo systemctl disable nvzramconfig
sudo fallocate -l 16G /ssd/16GB.swap
sudo mkswap /ssd/16GB.swap
sudo swapon /ssd/16GB.swap
echo '/ssd/16GB.swap none swap sw 0 0' | sudo tee -a

sudo systemctl disable nvzramconfig
sudo fallocate -l 16G /ssd/16GB.swap
sudo mkswap /ssd/16GB.swap
sudo swapon /ssd/16GB.swap
echo '/ssd/16GB.swap none swap sw 0 0' | sudo tee -a

The flight configuration has no need for a desktop. Shutting down the GUI wins back roughly 800 MB of RAM:

sudo systemctl set-default multi-user.target   # persistent headless
sudo init 3                                     # this session only

sudo systemctl set-default multi-user.target   # persistent headless
sudo init 3                                     # this session only

Traps people fall into

1. pip install torch — the most expensive mistake. The torch and torchvision packages on PyPI are not compatible with the Jetson's ARM64 + CUDA stack. The install looks like it succeeded, import torch works, but torch.cuda.is_available() returns False. The Ultralytics documentation warns about this explicitly. The right move is to install the prebuilt wheel that corresponds to your JetPack version:

# JetPack 6.x (Python 3.10) — confirm the versions/URLs against the Ultralytics docs

# JetPack 6.x (Python 3.10) — confirm the versions/URLs against the Ultralytics docs

On JetPack 7.2 the path is different: you use the official index for CUDA 13 (pip install torch torchvision --index-url https://download.pytorch.org/whl/cu130). So there is no single line to memorize as "the command on Jetson" — the JetPack version determines the command.

2. Never getting into the wheel business at all. The most durable route is Docker. Ultralytics publishes a ready-made image per JetPack release:

sudo docker run -it --ipc=host --runtime

sudo docker run -it --ipc=host --runtime

Without --runtime=nvidia the container will not see the GPU.

3. Flying straight off PyTorch. Converting a .pt weight into a TensorRT engine buys real speedup on the Jetson. The first build takes minutes, so do it beforehand rather than in the field — and run the engine on whichever board you built it on, because engines are not portable.

yolo export model=best.pt format=engine quantize=16 imgsz=640

yolo export model=best.pt format=engine quantize=16 imgsz=640

4. Clobbering NumPy and the system Python. On a Jetson, some NVIDIA packages depend on the system Python. Instead of messing with the global environment via sudo pip install, use a virtual environment; the bulk of version conflicts are born right here.

5. Making the call on the bench. Power mode, fan curve, and FPS measurements all have to be repeated with the airframe closed up, at real operating temperature.

Practical summary

• Choose the JetPack version first, then install everything around it. The CUDA/cuDNN/TensorRT versions are not yours — they belong to JetPack. Do not jump a major version close to the competition.

• Select NVMe at flash time. There is no eMMC on the Orin NX; moving onto the drive afterward means extra work.

• Make nvpmodel -m 0 + jetson_clocks a standard pre-flight step, but validate the mode against in-airframe temperatures — throttling can give you a worse result than a lower mode.

• Do not run pip install torch. Use the wheel that matches your JetPack, or the official Docker image; the first thing you do is verify with torch.cuda.is_available().

• Script the setup. You will end up flashing the board a second time; keeping the steps in a setup.sh turns that day from hours into minutes.