M7-T2: NVIDIA Jetson platforms

Learning objectives

After this lesson, you should be able to:

• Describe Jetson power modes and clock management, and how to query and set them.
• Monitor utilisation, frequency, temperature and power with tegrastats and related tools.
• Explain thermal throttling and its effect on latency in flight.
• Convert vendor figures to measured budgets for your pipeline.

Conceptual explanation

Implementation-specific Jetson module families, JetPack releases, power-mode tables, tool options and supported frameworks change with each generation. This lesson names the mechanisms and tools but quotes no performance, power or price figures: read the module’s datasheet and developer guide for the exact model and JetPack version, and measure your workload.

A Jetson module is a system-on-module that combines ARM CPU cores, an NVIDIA GPU, (on some modules) dedicated deep-learning and vision accelerators, memory shared between CPU and GPU, and video and camera interfaces. The software stack (JetPack) provides Linux, CUDA, TensorRT, multimedia libraries and the tools below.

• Power modes (nvpmodel): predefined configurations that set the number of active CPU cores, maximum clocks and a power budget. A lower mode saves power and reduces peak performance.
• Clocks (jetson_clocks): can pin clocks to their maximum for the selected mode, removing frequency-scaling variability (and increasing heat).
• Monitoring: tegrastats prints CPU load per core, GPU load, memory, temperatures and (on supported boards) power rails; the on-board sensors and power-monitor ICs differ between modules.
• Throttling: when temperature or power limits are reached, the system lowers clocks to stay inside them. Throughput and latency then change over a flight.

Engineering intuition

A Jetson in a lab with a large heatsink and a fan is a different machine from the same module in a closed 3D-printed enclosure on a hot day at altitude with little airflow. Compute budgets quoted at room temperature on a dev kit overstate what you get at the end of a 25-minute flight. Treat thermal state as part of the performance specification.

Shared memory is both a strength and a trap: CPU and GPU use the same physical memory, so copies are cheap compared with a discrete GPU, but memory bandwidth is shared too. A perception node that saturates memory bandwidth slows the CPU-side estimator that is waiting for data. The cure is measurement of the whole pipeline together, not each node alone.

Mathematical formulation

Sustained performance follows a thermal balance. With power dissipation $P$, ambient temperature $T_{a}$, and a thermal resistance $R_{\theta }$ from junction to ambient (heatsink, airflow, enclosure), the steady-state junction temperature is

With a thermal capacitance $C_{\theta }$ the module heats exponentially with time constant $\tau =R_{\theta }\,C_{\theta }$, so a short burst can exceed $P_{\text{max},\,\text{sustained}}$ until the temperature reaches the limit: $T(t)=T_{a}+R_{\theta }P(1-e^{-t/\tau })+(T_{0}-T_{a})e^{-t/\tau }$. The time to throttle is $t_{\text{th}}=\tau \,\ln ((R_{\theta }P-(T_{0}-T_{a}))/(R_{\theta }P-(T_{\text{limit}}-T_{a})))$. This is a first-order model with illustrative coefficients; measure the real $R_{\theta }$ and $\tau$ for your enclosure.

$R_{\theta }$

thermal resistance junction-to-ambient (°C/W) of your installation.

$\tau$

thermal time constant (s).

$T_{\text{limit}}$

throttle threshold of the module (from the datasheet).

Architecture and data flow

Camera (MIPI CSI or USB) → ISP and capture → memory (shared) → CUDA/TensorRT inference or VIO front end on the GPU → CPU back end and ROS 2 nodes → MAVLink/DDS to the flight controller. Monitoring: tegrastats and power rail sensors → logger on the companion → flight log alongside timestamps, so that throttling events can be correlated with latency spikes.

Real-world UAV applications

• Running TensorRT detection or segmentation onboard.
• VIO and lidar odometry on the companion.
• Choosing a power mode for flight versus ground testing.
• Thermal qualification of the enclosure in a heat chamber or a hot-day test.

Implementation example

This runs as shown. A first-order thermal model of a Jetson-class module (illustrative coefficients, not vendor figures) to compute sustained power and time-to-throttle for a mission, plus a parser for tegrastats-style lines so you can analyse your own recordings (the format below is a simplified, made-up example; check the real output of your JetPack version and adapt the regular expressions).

import numpy as np, re

R_th, C_th = 2.5, 40.0                    # ILLUSTRATIVE: degC/W and J/degC for an enclosed module; measure your own
T_limit, T_a, T0 = 85.0, 35.0, 45.0
tau = R_th * C_th
def time_to_throttle(P):
    if R_th * P + T_a <= T_limit: return None                     # sustained: never reaches the limit
    return tau * np.log((R_th * P - (T0 - T_a)) / (R_th * P - (T_limit - T_a)))
P_sus = (T_limit - T_a) / R_th
print(f"sustained power limit {P_sus:.1f} W; time to throttle at 25 W: {time_to_throttle(25.0):.0f} s, at 15 W: {time_to_throttle(15.0)}")
assert abs(P_sus - 20.0) < 1e-9 and time_to_throttle(15.0) is None and 100 < time_to_throttle(25.0) < 400

# parsing a tegrastats-like log (SIMPLIFIED EXAMPLE FORMAT; adapt to your JetPack version)
log = ["RAM 3100/7800MB CPU [45%@1500,52%@1500,40%@1500,38%@1500] GPU 62%@900 temp_gpu@58C temp_cpu@55C",
       "RAM 3120/7800MB CPU [60%@1500,58%@1500,55%@1500,49%@1500] GPU 91%@900 temp_gpu@64C temp_cpu@61C",
       "RAM 3130/7800MB CPU [61%@1100,59%@1100,53%@1100,50%@1100] GPU 93%@620 temp_gpu@83C temp_cpu@70C"]
def parse(line):
    gpu = re.search(r'GPU (\d+)%@(\d+)', line); t = re.search(r'temp_gpu@(\d+)C', line)
    return int(gpu.group(1)), int(gpu.group(2)), int(t.group(1))
rows = [parse(l) for l in log]; f0 = rows[0][1]
print([f"util {u}% freq {f} MHz temp {t} C" for u, f, t in rows])
assert rows[-1][1] < f0 and rows[-1][2] > rows[0][2]             # frequency fell while temperature rose: a throttling signature

The real commands to start from (check them against the documentation for your JetPack version):

sudo nvpmodel -q                  # query the current power mode
sudo nvpmodel -m <mode-id>        # set a power mode (ids are listed in the module's documentation)
sudo jetson_clocks --show         # show clock settings
sudo tegrastats --interval 1000   # CPU, GPU, memory, temperature (and power on supported boards) each second

Common engineering mistakes

Failure modes

Debugging approach

1. Log tegrastats continuously and plot frequency, temperature and utilisation against the pipeline’s latency.
2. Repeat the test with fixed clocks to remove frequency scaling.
3. Run the pipeline in the enclosure, not on the bench.
4. Record the JetPack version, power mode and module for every test.

Practical exercises

1. Run your perception pipeline for 30 minutes in the enclosure and plot temperature, frequency and frame time.
2. Measure $R_{\theta }$ by running a constant load until the temperature settles and dividing $(T_{j}-T_{a})$ by the power.
3. Compare latency percentiles (p50, p99) in two power modes.
4. Write the thermal requirement for your enclosure with a margin and a test to verify it.

Interview questions

Write an answer in your own words, then reveal the model answer. Nothing is sent anywhere.

References and further reading

Primary papers, official documentation and standards. Each claim above that is specific to a tool or version points here.

• NVIDIA: Jetson developer kits and modules (datasheets and developer guides)
• NVIDIA: Jetson Linux documentation archive (power management, tegrastats)
• NVIDIA TensorRT

What’s next