Third-Party Dependencies

A fresh git clone of this repo does not build. The kernel sources, the rootfs, the cross-toolchain, and all four vendor driver trees are external (some public, some NDA-gated) and every one of them is gitignored. This page is the full inventory: every third-party input, where it comes from, what account it needs, where it lands on disk, which build phase consumes it, and the traps we hit getting each one in.

versions.env is the single source of truth for every pin and URL it carries. If this page and versions.env ever disagree, versions.env wins, and check_version_consistency.sh should have caught it. A few tags live as defaults inside their install scripts instead (the zed-ros2-wrapper tag, the OpenCV build version, the zed-sdk samples tag); those are linked per row below and the lint gate does not cover them.

What a fresh clone is missing (all gitignored):

axelera-driver/  voyager-sdk/  zedx-driver/  zed-sdk/   # the four vendor trees
*.tbz2                                                   # three NVIDIA tarballs
zedx-daemon-cache/                                       # optional prebuilt daemons
latest_jetson/                                           # generated by make extract
.config                                                  # run make defconfig

Staging layout and path overrides: Quickstart Step 3. How each tree is wired in-tree: Drivers. This page is acquisition: get the bits, put them where the build looks, know the traps before they cost you a build.

The whole list, one table

Ordered by when you need it. “Auto” means a script fetches it. You stage nothing.

Component Version Where from Where it goes Needed for
L4T BSP tarball R36.4.3 (TARBALL_L4T) Jetson Linux Archive, NVIDIA account repo root Phase 1 extract, mandatory
Sample rootfs tarball R36.4.3 (TARBALL_ROOTFS) same archive repo root Phase 1, mandatory
public_sources tarball R36.4.3 (TARBALL_PUBLIC_SOURCES) same archive, sources/ repo root Phase 1/2, mandatory
Bootlin toolchain aarch64--glibc--stable-2022.08-1 NVIDIA CDN r36_release_v3.0/, no login /opt inside the Docker image Phase 2, auto via make docker-build
Docker + ubuntu:22.04 jetson-av-builder tag Docker Hub host Docker Phase 2, make docker-build
Host apt packages n/a Ubuntu archives x86_64 host Phases 1-4, make doctor checks
axelera-driver/ portal drop Axelera customer portal, account $REPO_ROOT/axelera-driver/ Phase 1/2, Metis baseline
voyager-sdk/ 1.6 / 1.6.1 Axelera customer portal, account, same package $REPO_ROOT/voyager-sdk/ Phase 3 bake + on-device runtime
zedx-driver/ R36.4 drop Stereolabs support, NDA $REPO_ROOT/zedx-driver/ Phase 1/2/3, camera profile
zed-sdk/ installer ZED SDK 5.3.x .run stereolabs.com/developers/release, public $REPO_ROOT/zed-sdk/ Phase 3 bake → first boot
zedx-daemon-cache/ n/a, optional your own previously provisioned unit $REPO_ROOT/zedx-daemon-cache/ skips on-device daemon build
PyTorch + torchvision 2.8.0 / 0.23.0 pypi.jetson-ai-lab.io/jp6/cu126 /opt/av-env on device first boot, auto
Axelera wheels 1.6 line (axelera-rt, axelera-devkit) software.axelera.ai Artifactory /opt/av-env first boot, auto
Generic PyPI numpy<2.0.0 + friends pypi.org /opt/av-env first boot + phase installers, auto
JetPack userspace CUDA 12.6, cuDNN 9, TensorRT, VPI 3 repo.download.nvidia.com apt (preconfigured) device post-flash apt install nvidia-jetpack
ROS 2 Humble repo Humble (jammy) packages.ros.org device Phase 5, auto
Isaac ROS repo 3.2 (release-3 channel) isaac.download.nvidia.com device Phase 5, auto
Axelera model artifacts yolov5s-v7-coco default; yolov8s-coco, yolov8l-coco also deployed compiled by deploy.py on device /opt/jetson-av/models/ mission inference + samples, auto
ZED AI models 15 models for SDK 5.3 Stereolabs servers, auto on first use /usr/local/zed/resources/ optional neural depth / OD
mavlink-router unpinned apt, else GitHub source build device Phase 7, auto
RockBLOCK 9704 SDK rockblock9704 pip pypi.org device Phase 7 Iridium relay, manual: the installer checks for it but does not install it
GeographicLib datasets per Humble MAVROS install script device Phase 5 MAVROS, auto
zed-ros2-wrapper tag v5.3.1 github.com/stereolabs /opt/zed_ros_ws on device Phase 5 camera node
OpenCV + contrib source 4.10.0, CUDA_ARCH_BIN=8.7 github.com/opencv /usr/local + /opt/opencv-cache Phase 5 step 1
zed-sdk samples repo tag 5.3.0 github.com/stereolabs/zed-sdk ~/zed-sdk on device optional dev
VS Code / Chromium unpinned Microsoft .deb / snap store device GUI optional

Group 1, Before the host build

Everything in this group must exist before make extract (kernel inputs) or make bake (rootfs payloads). make doctor checks all of it with exact remediation messages. Run it before you waste 90 minutes on a doomed build.

NVIDIA L4T tarballs, three of them

The BSP (bootloader, flash tools, apply_binaries.sh), the Ubuntu 22.04 sample rootfs, and the kernel/OOT-module sources. Pinned in versions.env as TARBALL_L4T, TARBALL_ROOTFS, TARBALL_PUBLIC_SOURCES.

# from https://developer.nvidia.com/embedded/jetson-linux-archive → JetPack 6.2 / L4T R36.4.3
wget https://developer.nvidia.com/downloads/embedded/l4t/r36_release_v4.3/release/Jetson_Linux_r36.4.3_aarch64.tbz2                          # BSP, ~700 MB
wget https://developer.nvidia.com/downloads/embedded/l4t/r36_release_v4.3/release/Tegra_Linux_Sample-Root-Filesystem_r36.4.3_aarch64.tbz2    # rootfs, ~1.8 GB
wget https://developer.nvidia.com/downloads/embedded/l4t/r36_release_v4.3/sources/public_sources.tbz2                                        # sources, ~226 MB
# expected: three .tbz2 files at the repo root, next to the Makefile
  • Account: NVIDIA Developer account + L4T EULA acceptance on the download portal. The CDN URLs themselves answer to plain wget once you know them. The archive page is where you accept the license and find the links.
  • Placement: repo root (default TARBALL_DIR=$REPO_ROOT); override with TARBALL_DIR=/path or per-file TARBALL_L4T_PATH etc. Filenames match case-insensitively: NVIDIA ships R36.4.3, the repo pins r36.4.3, no renaming of a 700 MB file required.
  • Consumed by: 00_doctor.sh (--only sources), 01_extract_and_patch.sh, 02_build_kernel.sh.
  • Exact pin, do not substitute. Not 6.0, not 6.1, and not the newer 6.2.2 / L4T R36.5 either: Isaac ROS 3.2 is only validated against R36.4.3 / JetPack 6.2. Full rationale in Compatibility.
  • Rootfs extraction needs sudo (ownership preservation); 01_extract aborts with the exact manual command if sudo -n fails.
  • public_sources.tbz2 carries NVIDIA’s generic_rt_build.sh, which Phase 1 runs to enable PREEMPT_RT. Building it inside Docker needs IGNORE_PREEMPT_RT_PRESENCE=1. 02_build_kernel.sh sets it, nothing for you to do.

Bootlin cross-toolchain (automatic, but know the URL quirk)

aarch64--glibc--stable-2022.08-1 (BOOTLIN_TOOLCHAIN), fetched by the Dockerfile during the one-time make docker-build and installed at /opt inside the jetson-av-builder image. No manual step, no login, but the image build needs network once.

The CDN path is a landmine: the toolchain lives at the release-independent r36_release_v3.0/toolchain/ mirror. The “obvious” r36_release_v4.3/toolchain/ path 404s, and so does the v5.0 URL circulating in older guides (verified June 2026). That is why versions.env pins L4T_CDN_RELEASE and L4T_TOOLCHAIN_CDN separately: the release directory is not derivable from the L4T number. check_version_consistency.sh whitelists the exception. See Compatibility §NVIDIA CDN layout.

One more reason the toolchain is locked: with CONFIG_MODVERSIONS=y the toolchain fingerprint feeds symbol CRCs. Never build a .ko outside the project Docker image: it will silently stop matching. Toolchain change = full Phase 2 rebuild. See Vermagic.

Docker + ubuntu:22.04 (the build container) 

make docker-build   # one-time, ~5 min; auto-detects docker vs sudo docker; DOCKER=podman to override

Base image ubuntu:22.04 from Docker Hub; the container apt list lives in the Dockerfile. One non-obvious entry: fakeroot + debhelper are required for make bindeb-pkg. Without them the Image and modules still build, but the linux-headers .deb fails, and every DKMS installer on the target (ZED SDK, Voyager) breaks later.

Host packages

x86_64 Ubuntu 20.04/22.04 host, 8 GB RAM floor (16 recommended), 40 GB disk floor (100 recommended). The apt install command is in Quickstart Step 1; 00_doctor.sh checks the full REQUIRED_PKGS list. Add pip install kconfiglib (or apt python3-kconfiglib) for make menuconfig/make defconfig. Passwordless sudo recommended: rootfs extraction and module install prompt otherwise.

The four vendor trees

Pre-compiled .ko modules will not load on this build’s PREEMPT_RT kernel. CONFIG_PREEMPT_RT=y changes the vermagic token and LOCALVERSION=-tegra stamps the release, so every prebuilt module from NVIDIA apt, Stereolabs .debs, or Axelera dies with Invalid module format and no further diagnostic. Source is mandatory for the kernel-side trees. That is the entire reason the Stereolabs ZED X tree requires an NDA. See Vermagic.

All four directories are gitignored. The build proceeds without absent ones (features skipped per config, see Build), and make doctor reports each tree PASS/WARN/FAIL.

axelera-driver/: Metis PCIe kernel driver source (account)

  • Get it: Axelera customer portal, account required (no NDA). No public URL exists.
  • Placement: $REPO_ROOT/axelera-driver/ (EXTERNAL_AXELERA_DRIVER). Must contain Makefile, the driver sources, and udev/72-axelera.rules. Needed before make extract: doctor hard-FAILs without it unless CONFIG_AXELERA_METIS=n.
  • Consumed by: plugins/axelera/plugin.sh (source injection, in-tree promotion to drivers/misc/axelera/, udev staging), 02_build_kernel.sh.
  • Gotchas:
    • The in-tree promotion shim is layout-only: its custom modules: target is never invoked by Kbuild, so Phase 2 also builds metis.ko as an external module (M=) against the just-built kernel: same tree, same toolchain, same Module.symvers, exact vermagic by construction. Don’t “simplify” this away. Kernel patches §6.
    • The plugin sed-forces LINK_WAIT_MAX_RETRIES=200 in pcie-designware.h (pinned as PCIE_LINK_WAIT_MAX_RETRIES): with NVIDIA’s stock 10 retries the Metis is invisible to lspci on cold boot. Kernel patches §1.

voyager-sdk/: Axelera Voyager SDK checkout + axl-jetson.patch (account)

  • Get it: same Axelera portal package, account required, no NDA. Verified live at 1.6.1 (2026-06-11).
  • Placement: $REPO_ROOT/voyager-sdk/ (EXTERNAL_VOYAGER_SDK). Needed before make bake: Phase 3 stages the whole tree into the rootfs at /home/j/voyager-sdk. Expected inside: axl-jetson.patch (PCIe link-retry patch; missing is only a WARN, the plugin falls back to sed-only), the axelera.app framework, deploy.py/inference.py, sample media, and optionally a wheels/ wheelhouse for offline first boot (baked to /opt/av-wheels).
  • Consumed by: plugins/axelera/plugin.sh, 03_bake_rootfs.sh, install_mission_inference.sh, install_zed_ros2_wrapper.sh.
  • Gotchas:
    • Voyager 1.6 dropped install.sh --driver. Runtime and tooling come from pip wheels now (see Group 2); do not run the legacy installer.
    • axelera.app lives in this checkout, not in the wheels. Getting the app framework running needs requirements.application.txt installed into /opt/av-env MINUS opencv-python (shadows the CUDA cv2) and pyopencl (no OpenCL on Jetson); make operators needs ninja-build opencl-headers ocl-icd-opencl-dev libsimde-dev. AV stack.
    • AXELERA_GST_EXPLICIT_PARSE is stale: a 2026-06-11 grep over the full 1.6.1 checkout and installed wheels found zero references. The real Jetson decode workaround for file/RTSP sources is GST_PLUGIN_FEATURE_RANK=nvv4l2decoder:NONE. Field confirm results §3.3.
    • Re-bake nesting: a naive cp -r of this tree into the rootfs nests voyager-sdk/voyager-sdk on the second bake. The plugin removes the prior copy first (Troubleshooting B-6).

zedx-driver/: Stereolabs ZED X / ZED Link kernel driver source (NDA)

  • Get it: Stereolabs business/NDA relationship via support.stereolabs.com. No public repo for the ZED X kernel driver exists. The public .debs ship .kos built against the stock L4T kernel, which will never load here (vermagic, see above).
  • Placement: $REPO_ROOT/zedx-driver/ (EXTERNAL_ZEDX_DRIVER). Needed before make extract for the camera profile; skip with CONFIG_CAMERA_NONE=y. Expected layout: src/kernel/stereolabs, src/hardware/stereolabs (overlay DTS + Utils/), nvidia_kernel/kernel_patches/R36.4/, ISP/*.isp, Daemon/, nvidia_364_fix/R36.4.3/libnvisppg.so.
  • Consumed by: plugins/zedx/plugin.sh, 02_build_kernel.sh, install_zedx_daemons.sh.
  • Gotchas (this tree is the trap-densest input in the project; integration detail in Drivers §1):
    • MAX9296, not MAX96712. The wrong deserializer compiles cleanly, loads cleanly, streams 30 fps with zero dmesg errors, and silently corrupts frames (garbage depth, drifting SLAM). Enforced in both the defconfig and a -D compiler-flag sed; the Makefile flag overrides Kconfig if they disagree. Drivers §1.2.
    • The vendor 0006 compilation-makefile patch is mangled by patch -p2 (/dev/null source becomes a file literally named null), so the plugin awk-materializes the Makefiles instead. Troubleshooting B-5.
    • The overlay DTS #includes Utils/ relative to nv-public. Ship the tree complete or the DTBO cpp pass dies with a bare “No such file”. Kernel patches §8.
    • SDK ≥5.x cannot open a ZED X without pieces from this tree, not the SDK installer: bmi088.ko/bmi_spsc.ko, the three vendor daemons, and the patched libnvisppg.so (stock R36.4.x renders the image soft; installed via dpkg-divert). All automated by install_zedx_daemons.sh. Troubleshooting H-5/H-6.

zed-sdk/: ZED SDK .run installer (public)

  • Get it: public download, stereolabs.com/developers/release, the Tegra / L4T 36.4 installer matching JetPack 6.2 (ZED SDK 5.3.x for CUDA 12.6; present on the reference build: ZED_SDK_Tegra_L4T36.4_v5.3.1.zstd.run). SDK EULA applies, no NDA.
  • Placement: $REPO_ROOT/zed-sdk/ZED_SDK_Tegra_*.run (EXTERNAL_ZED_SDK, glob ZED_SDK_INSTALLER_GLOB). Needed before make bake, but optional: first boot skips the SDK install if absent, and you can drop it on-device at /opt/zed-sdk later.
  • Consumed by: plugins/zedx/plugin.sh pre_bake → install_zed_sdk.sh at first boot.
  • Version gate: the SDK requires CUDA 12.6 exactly, what L4T R36.4.3 ships. A mismatched SDK segfaults on import. Install-time gotchas (silent flags, the zed group, the pyzed numpy bump) live in Group 2 below, where they actually bite.

zedx-daemon-cache/: optional prebuilt daemons

Copy /usr/sbin/{ZEDX_Driver,ZEDX_Daemon,IMU_Daemon} from a previously provisioned unit into $REPO_ROOT/zedx-daemon-cache/ before make bake and install_zedx_daemons.sh skips the on-device cmake/Qt5 daemon build entirely. Without the cache, first boot apt-installs qtbase5-dev + cmake and builds on device. The binaries are Stereolabs vendor code. Treat them as NDA-tree derivatives.

Group 2, Fetched on device at first boot

Nothing here is staged by you. jetson_first_boot.sh and the phase installers fetch it all, which means the device needs internet at first boot, or you pre-stage the voyager-sdk/wheels/ wheelhouse (baked to /opt/av-wheels, installed with pip --no-index --find-links). The first-boot service re-runs every boot until provisioning completes. make doctor --only network checks index reachability from the host before you flash.

PyTorch + torchvision (Jetson AI Lab wheel index)

torch==2.8.0 + torchvision==0.23.0 (PYTORCH_VERSION/TORCHVISION_VERSION) from https://pypi.jetson-ai-lab.io/jp6/cu126 (PYTORCH_INDEX_URL) into /opt/av-env. No account. Three live-observed traps, all from Troubleshooting P-2:

  • The old pypi.jetson-ai-lab.dev host is dead at the DNS level (verified 2026-06-10). .io is the only host; there is no fallback.
  • The index prunes old wheels: the pinned version must still exist there (2026-06-10: oldest served is 2.8.0). If your pin vanishes, update versions.env, not the script.
  • Pin torch, torchvision, and numpy in the same pip command, and never install torch from generic PyPI: the unconstrained resolver pulls torchvision 0.26 + numpy 2.x, or “upgrades” to a CPU-only torch (torch.cuda.is_available() → False, observed live).

Axelera PyPI (axelera-rt, axelera-devkit)

Voyager 1.6 runtime + devkit wheels from https://software.axelera.ai/artifactory/api/pypi/axelera-pypi/simple (VOYAGER_PYPI_URL), installed unauthenticated by first boot. The axruntime pkgconfig/libs for the C++ example come from this install too.

  • The /api/pypi/.../simple suffix is required: the bare Artifactory URL is not a pip index.
  • Re-state torch==2.8.0 inside this pip call or the resolver swaps in PyPI’s CPU-only torch 2.10 (observed live).
  • Hard requirement numpy<2.0.0: the axelera wheels reject numpy 2.x.

Generic PyPI + the numpy<2.0.0 invariant

numpy<2.0.0 (NUMPY_CONSTRAINT), scipy, pillow (first boot), requests (via install_zed_sdk.sh), and pymavlink (install_av_stack.sh pips it into /opt/av-env; the Phase 7 relay itself runs on system Python with apt’s python3-pymavlink): plain pypi.org, no pins beyond numpy. rockblock9704 is the one manual pip here: the Phase 7 installer checks for it but does not install it (see Phase 7 telemetry bits below). numpy<2.0.0 is a stack-wide invariant: Voyager and the CUDA cv2 are both built against 1.x headers, and at least two installers (pyzed, unpinned torchvision) keep trying to drag 2.x in. Multiple scripts re-assert the constraint after other installers bump it. Troubleshooting P-6.

ZED SDK install + pyzed (first boot)

install_zed_sdk.sh runs the staged .run with the verified silent flags: silent runtime_only skip_python skip_cuda skip_tools skip_od_module skip_hub nvpmodel=0. A skip_drivers flag does not exist (an earlier revision used it). runtime_only is what stops the installer rebuilding sl_zedx.ko: this build already owns a vermagic-aligned one.

  • The installer creates /usr/local/zed as 770 root:zed. A user outside the zed group gets ImportError: libsl_zed.so from pyzed. usermod -aG zed, or sg zed -c for the current session.
  • get_python_api.py needs requests and downloads the pyzed wheel from Stereolabs servers (network required at first boot).
  • pyzed declares an unbounded numpy dep and installs with --ignore-installed, silently bumping the venv to numpy 2.x. The script re-asserts numpy<2.0.0 immediately after. Troubleshooting P-6.

JetPack userspace (apt, post-flash)

The NVIDIA sample rootfs ships without JetPack userspace: no CUDA toolkit, cuDNN, TensorRT, VPI, or NVIDIA GL. nvcc missing on a fresh flash is expected, not a build failure: sudo apt install nvidia-jetpack (~3.8 GB) from the preconfigured repo.download.nvidia.com repo. Troubleshooting P-3.

  • Safe alongside the kernel: first boot apt-mark holds + Pin-Priority -1-pins nvidia-l4t-kernel*/-bootloader/-init/-xusb-firmware so OTA can’t clobber the custom RT kernel.
  • PATH quirk: nvcc lives at /usr/local/cuda/bin, trtexec at /usr/src/tensorrt/bin, neither on PATH by default.
  • Never apt-install Ubuntu universe’s nvidia-cuda-toolkit (CUDA 11.5): it conflicts with JetPack’s CUDA 12.6 and rolls back the whole apt transaction (observed live, Troubleshooting P-4).

ROS 2 Humble + Isaac ROS apt repos (Phase 5)

install_av_stack.sh configures both automatically: packages.ros.org/ros2/ubuntu (key from the rosdistro GitHub) and isaac.download.nvidia.com/isaac-ros/release-3 (key repos.key), with a git clone + colcon source-build fallback into /opt/isaac_ros_ws if the apt fast path fails. No accounts.

  • The apt package is ros-humble-isaac-ros-detectnet. An isaac-ros-object-detection meta-package does not exist in the 3.x repo, and one unknown name fails the entire apt transaction (observed live).
  • Isaac ROS 3.2 is the reason the whole stack pins R36.4.3/JP6.2; 4.x moved to JetPack 7 / Jazzy. Compatibility.
  • /opt/ros/humble/setup.bash references unset variables: scripts must drop set -u around sourcing (Troubleshooting P-5).
  • MAVROS extra: GeographicLib datasets via ros2 run mavros install_geographiclib_datasets.sh (best-effort, automatic).

Model downloads (Axelera artifacts + ZED AI models)

Axelera: install_mission_inference.sh runs deploy.py <network> --aipu-cores 4 if no artifact exists (~17 min first compile, then cached) and stages to /opt/jetson-av/models/<network>/. Default yolov5s-v7-coco; verified live at 49.2 FPS end-to-end (2026-06-11). yolov8s-coco deploys the same way (batch-4); yolov8l-coco is large enough that the compiler fits only one copy, so it deploys single-core batch-1. The samples auto-resolve the 4/, 2/, or 1/ core artifact dir (Samples); measured per-model throughput is in Benchmarks. Artifacts are relocatable directories: pre-deploy on one machine and ship the directory to the fleet. Core-count trap: create_inference_stream defaults aipu_cores=1, inference.py defaults to 4, and each core count is a different artifact. Mismatch triggers a full recompile.

ZED: the SDK downloads + TensorRT-optimizes each AI model on first use (~8-15 min/model on Orin NX, 15 models for SDK 5.3) into /usr/local/zed/resources/. Optional for the basic pipeline. Quirk seen live: a download can report FAILURE yet leave a valid file. A second --optimize pass picks it up. Drivers §2.5.

Phase 7 telemetry bits

  • mavlink-router: apt if available, else automatic git clone + meson/ninja build by install_telemetry_failover.sh. Build failure degrades to a socat fallback, not fatal.
  • RockBLOCK 9704 SDK: pip install rockblock9704, manual, the one exception to “nothing here is staged by you”. install_telemetry_failover.sh detects the SDK at relay startup and degrades cleanly (sdk_missing black-box event, systemd restart back-off) if it is absent, but does not install it; run the pip install yourself into system Python (the relay runs under python3, not /opt/av-env). Iridium IMT/JSPR, IRIDIUM_MODEL=9704 in versions.env. Software is free; actual transmission needs a Rock7/Ground Control account + Iridium airtime (a hardware-side requirement, not a software gate).

On-device apt utility packages

First boot and the phase installers apt-install their own prerequisites (python3-pip, rt-tests, qtbase5-dev, btrfs-progs, the OpenCV -dev list, …) from ports.ubuntu.com + the L4T repo. Two notes: the bake masks packagekit.service because packagekitd races first boot for the apt lock (killed provisioning on a live boot), and scripts use DPkg::Lock::Timeout=600.

Group 3, Optional and dev extras

zed-ros2-wrapper (Phase 5 camera node)

git clone --depth 1 -b v5.3.1 https://github.com/stereolabs/zed-ros2-wrapper.git, done automatically by install_zed_ros2_wrapper.sh into /opt/zed_ros_ws. The tag pairs with ZED SDK 5.3.1 on Humble (ZED_WRAPPER_TAG); master needs SDK ≥ 5.2.

  • Topic rename trap (wrapper ≥ 5.1): /zed/zed_node/rgb/color/rect/image, not rgb/image_rect_color. Topics are lazy (published only while subscribed), left/right are OFF by default (cuVSLAM needs publish_left_right:=true). Consumers wired to pre-5.1 names wait forever with zero errors. Troubleshooting H-8.
  • zed-config.cmake needs CUDA_TOOLKIT_ROOT_DIR, supplied by nvidia-jetpack-dev; CUDA must be on PATH for colcon. zed_msgs comes from apt (renamed from zed_interfaces in 4.2.x).

OpenCV 4.10.0 CUDA build (Phase 5 step 1)

apt python3-opencv ships without CUDA/cuDNN/GStreamer: cv2.cuda.* fails and DNN silently runs on CPU, a 10-30x slowdown. build_opencv_cuda.sh clones opencv + opencv_contrib at the version tag and builds with CUDA_ARCH_BIN=8.7 (sm_87, Orin), ~45-60 min once, then cached as a .deb in /opt/opencv-cache so units 2-N install in seconds. Full recipe and traps in CUDA libraries; the two that bite during acquisition: deps are nvidia-cuda-dev + libcudnn9-dev-cuda-12 (never universe’s nvidia-cuda-toolkit, see Group 2), and the script refuses to configure if venv numpy ≥ 2 (the bindings compile against numpy headers, Troubleshooting P-6).

OpenGL / CUDA verification packages

verify_opengl_cuda.sh runs a 14-check gauntlet (EGL vendor, glxinfo renderer, nvcc, sm_87 probe, trtexec, VPI, cuDNN, cv2 CUDA). The one to memorize: glxinfo reporting llvmpipe means nvidia-l4t-3d-core is missing and you’re on Mesa software rendering. The healthy string is NVIDIA Tegra Orin (nvgpu). CUDA libraries.

stereolabs/zed-sdk samples repo

The .run installer ships no samples since 4.x. git clone https://github.com/stereolabs/zed-sdk (tag 5.3.0, ~/zed-sdk on the verified unit): 40 samples + 12 tutorials, and the zed_ai_models helper for pre-building the AI models. GL viewer samples need freeglut3-dev (the image ships only the runtime). Drivers §2.5.

Chromium (snap) and VS Code

  • Chromium: snap install chromium after first boot. Snaps work on this image because the kernel ships AppArmor in CONFIG_LSM (omitting it silently dropped CONFIG_SECURITY_APPARMOR and broke every snap) and fix_snapd_jetson.sh repairs the snapd stack at first boot. First snap install needs internet once for seeding (snap wait system seed.loaded, the classic “snap install hangs” on Jetson).
  • VS Code: the snap store has no arm64 build. Install Microsoft’s official arm64 .deb instead (VS Code 1.124 verified live on the device, 2026-06-10).

Fresh clone, staged inputs, ready to go? One command settles it:

make doctor
# expected: PASS for tarballs, vendor trees, host packages, Docker, network

Fix all FAILs before continuing.