NVIDIA Jetson for Drones: Choosing an AI Companion Computer

A Jetson drone computer, or UAV companion computer, is an NVIDIA Jetson module on a light carrier board that flies alongside a UAV’s flight controller as its AI companion computer, turning camera and sensor data into navigation, obstacle avoidance and target detection. The flight controller keeps the aircraft stable and flying; the Jetson decides where it should go and what it is looking at.

Our explainer on the drone companion computer covers the idea itself. This guide is the engineering view: which NVIDIA Jetson Orin or Thor module suits which aircraft, the size, weight and power budget, how the Jetson links to the flight controller, the camera and sensor inputs, power, vibration and heat on an airframe, and the drone computers in our range.

The short answer for most projects is a Jetson Orin NX, which balances AI performance, weight and power for multi-camera vision on small and medium UAVs. The Orin Nano suits lighter workloads where every gram counts, and AGX Orin and Thor belong on large aircraft with heavy sensor payloads.

The module sets the AI ceiling, the memory and the power draw. The table lists each current module with NVIDIA’s published figures and the drone role it usually fits; system weights are for complete computers in our range, not bare modules.

Without Super mode, the Orin Nano 8GB is rated at 40 TOPS and the Orin NX 16GB at 100 TOPS. Our Jetson Super mode explainer covers what the higher modes change and what they cost in heat and battery. Drone computer makers often quote the original figures for their systems, so check which mode a datasheet assumes.

Three things set the choice. The AI workload, meaning how many cameras and how heavy the models, sets the minimum performance. The weight budget matters because every gram on the computer is a gram off payload or flight time. And the power drawn from the battery reduces endurance. The Orin NX balances all three for most UAV work; the Orin Nano wins where the workload is light and weight is critical.

Large fixed-wing and VTOL aircraft carrying radar, several high-resolution cameras or a gimballed EO/IR payload can justify an AGX Orin, which quadruples the memory of the Orin NX 16GB and adds 10GbE. For the heaviest sensor fusion and on-board language models, Jetson Thor is NVIDIA’s newest step, though its power draw limits it to large platforms. Our guide to choosing a Jetson module compares the whole range. All current Orin modules run the same JetPack software, so a project can move up or down without rewriting the application.

On a drone, every gram and every watt is taken from flight time and payload. This is the SWaP constraint, size, weight and power, often extended to SWaP-C to include cost, and it is what separates a drone computer from an ordinary edge computer. Our explainer on SWaP-C covers the term; the table shows how the systems in our range trade weight for protection.

A worked example

Take an illustrative 6 kg hexacopter that hovers at about 900 W. Hover power rises roughly in proportion to all-up weight, so a 350 g companion computer adds about 50 W of lift power, and the computer itself draws perhaps 20–25 W in a mid power mode. Together that is around 8 percent of the hover budget, or several minutes from a 30-minute flight. Moving to a 2 kg sealed computer would cost far more, which is why sealed mission computers belong on large aircraft and ground vehicles.

The same arithmetic favours the lowest power mode that meets the workload. Running an Orin NX at 25 W rather than 40 W saves 15 W directly and reduces the heat the airframe has to shed, at the cost of some peak throughput.

The Jetson and the flight controller talk over a serial UART, Ethernet or CAN link, usually speaking MAVLink. The Jetson sends velocity commands, waypoints or a position estimate from visual odometry; the flight controller flies the aircraft and returns telemetry. Our explainer on how a Jetson connects to a flight controller walks through the wiring; this is the summary.

What is MAVLink?

MAVLink is a lightweight message protocol for drones. Each message, such as a heartbeat, an attitude report or a position target, is a small packet with a message ID, so it runs well over a slow serial line. ArduPilot and PX4 both speak it, so the same Jetson software can talk to either autopilot. MAVLink 2 supports message signing to authenticate traffic, but not encryption.

MAVSDK, MAVROS and ROS 2

On the Jetson side, developers reach MAVLink through MAVSDK, pymavlink or MAVROS, and a router such as mavlink-router can share one flight-controller link between several programs and a ground station. Teams working in ROS 2 increasingly use DDS instead: PX4 exposes its internal topics through the uXRCE-DDS bridge, and recent ArduPilot releases add DDS support, so vehicle state arrives as ordinary ROS 2 topics. Both can run side by side, DDS for the autonomy stack and MAVLink for the ground station.

Where the drone also uses CAN for GNSS or ESCs, the Jetson can join the bus through its own controller using SocketCAN on Linux. The drone computers in our range expose these links for exactly this job: the FLYC-300 provides UART, CAN 2.0 and Ethernet, and the IBOX-604-G2 adds CAN FD, RS-232/422/485 and a 3.3 V UART. Never wire an RS-232 port straight to a 3.3 V UART; the voltage levels differ.

Autonomy is only as good as what the drone can sense. The camera and sensor path decides latency, cable weight and how well the system survives vibration.

Both drone computers in our range carry two GMSL2 camera inputs for long-cable, high-resolution, hardware-synchronised cameras, including stereo cameras such as the Stereolabs ZED X for depth and obstacle avoidance. The FLYC-300 takes two 1920 × 1080 cameras at 60 FPS or two 2880 × 1860 cameras at 30 FPS on its FAKRA Z inputs. Our explainers on lidar and EO/IR cameras cover the other common payloads.

That mix covers the usual UAV workloads: mapping and survey, infrastructure and environmental monitoring, search and rescue, and detect-and-track. GNSS modules and 4G or 5G connectivity fit over M.2 for positioning and a real-time downlink, and RTK GPS adds centimetre-level positioning for survey work.

A drone computer runs straight from the flight battery, sits on a vibrating frame and has to shed heat without a heavy heatsink. Each of those shapes the system.

Battery input

Lithium polymer and lithium-ion packs are described by their cell count in series. The input range has to cover the pack from full charge down to its cut-off, plus transients from the motors.

Vibration and shock

Both drone computers are tested to MIL-STD-810H for shock and vibration, and the IBOX-604-G2 also to IEC 60068-2-64. On the airframe, soft mounts or isolators keep motor vibration away from the board, locking connectors stop links dropping out, and conformal coating protects boards from condensation and spray where the payload bay is open.

Heat

Fanless drone computers rely on conduction or airflow, and their ratings say so. Neousys rates the FLYC-300 from −25 °C to 40 °C free-standing, to 60 °C with its heat spreader secured to an aluminum surface, and to 70 °C on that mount with 4S to 6S packs; Sintrones rates the IBOX-604-G2 16GB model to 50 °C with 0.6 m/s of airflow. Plan the mount and the airflow with the airframe, and treat the payload bay, not the outside air, as the ambient. Our Jetson thermal design guide covers sizing the thermal path for a given power mode.

Not every drone needs a Jetson. The companion computer should match the job, and lighter options exist for lighter work.

A Raspberry Pi is a good companion for telemetry, logging and simple vision. Real-time AI on several cameras usually needs a GPU module such as Jetson Orin, which carries the CUDA and TensorRT stack used on the ground. Our explainer on AI accelerators covers the add-on route, and what NVIDIA Jetson is explains the platform.

Our three Orin drone computers overlap, so the choice comes down to the detail of the payload and the airframe. The table uses the manufacturers’ published specifications.

The FLYC-300 leans into small UAV use with its 297 g board-level build and a heat spreader for airframe mounting. The IBOX-604-G2 adds an on-board accelerometer, CAN FD and a Taiwan country of origin that helps where TAA compliance matters. The MILBOX‑ORNX is the sealed option for larger UAVs, aircraft payloads and ground vehicles, where its weight is acceptable. For an airborne ISR example, our Airbus ISR drone case study shows a rugged AGX Orin in an airborne video role, and our explainer on ISR covers the term.

Most drone AI falls into a handful of jobs, and each sets a different camera and compute load. The table maps common UAV applications to the payload and module that usually fit.

Detect-and-track work leans on object tracking as much as detection, and navigation without GNSS combines camera and IMU data through sensor fusion. For farming payloads, our explainer on precision agriculture covers the wider context.

Our news pieces on the Neousys FLYC-300 drone mission computer, the Sintrones IBOX-604-G2 drone computer and the Forecr MILBOX‑ORNX rugged drone computer go into each system in more detail.

Software on the companion computer

A typical Jetson drone stack runs JetPack and Jetson Linux at the base, camera drivers for the GMSL2 or CSI cameras, a perception layer built with TensorRT-optimised models, and an autonomy layer, often on ROS 2, that turns detections and depth into commands. Stereo cameras usually bring their own SDK for depth and visual odometry, and a MAVLink router or DDS bridge carries the results to the flight controller. Keeping that stack in a locked, tested image is what makes a fleet of drones behave the same way every flight.