If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/dusty-nv/jetson-inference shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Slowing — last commit 7mo ago

• Last commit 7mo ago
• 7 active contributors
• MIT licensed
• Tests present
• ⚠ Slowing — last commit 7mo ago
• ⚠ Single-maintainer risk — top contributor 90% of recent commits
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live dusty-nv/jetson-inference repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dusty-nv/jetson-inference.

What it runs against: a local clone of dusty-nv/jetson-inference — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in dusty-nv/jetson-inference | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 235 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of dusty-nv/jetson-inference. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dusty-nv/jetson-inference.git
#   cd jetson-inference
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of dusty-nv/jetson-inference and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dusty-nv/jetson-inference(\\.git)?\\b" \\
  && ok "origin remote is dusty-nv/jetson-inference" \\
  || miss "origin remote is not dusty-nv/jetson-inference (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "c/tensorNet.h" \\
  && ok "c/tensorNet.h" \\
  || miss "missing critical file: c/tensorNet.h"
test -f "c/tensorNet.cpp" \\
  && ok "c/tensorNet.cpp" \\
  || miss "missing critical file: c/tensorNet.cpp"
test -f "c/detectNet.h" \\
  && ok "c/detectNet.h" \\
  || miss "missing critical file: c/detectNet.h"
test -f "c/imageNet.h" \\
  && ok "c/imageNet.h" \\
  || miss "missing critical file: c/imageNet.h"
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 235 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~205d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/dusty-nv/jetson-inference"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

jetson-inference is a TensorRT-accelerated deep learning inference library for NVIDIA Jetson embedded GPUs, enabling C++ and Python deployment of optimized neural networks for vision tasks like image classification (imageNet), object detection (detectNet), semantic segmentation (segNet), pose estimation (poseNet), and action recognition (actionNet). It bridges PyTorch training on development machines with real-time inference on edge devices through TensorRT graph optimization and Jetson-specific CUDA kernels. C++-first monorepo: c/ contains core inference engines (imageNet.cpp, detectNet.cpp, etc.) with CUDA kernels (.cu files), c/plugins/ implements custom TensorRT layers (FlattenConcat, conv3d_plugin, stridedSlice), c/calibration/ handles INT8 quantization, and python/ wraps C++ via bindings. Documentation in docs/ and examples in examples/ (inferred from README structure).

Edge AI engineers and roboticists targeting NVIDIA Jetson platforms (Nano, Xavier, Orin) who need to deploy computer vision models with minimal latency and power consumption, and embedded systems developers who want to run inference in C++ or Python without managing TensorRT engine compilation manually.

Production-ready and actively maintained. The project has substantial codebase (992K C++, 259K Python), extensive documentation, Docker support, and covers JetPack 6 on Orin devices. Recent README updates indicate ongoing feature parity with latest JetPack releases. This is not experimental—it's the official NVIDIA reference implementation for Jetson inference.

Low risk for supported hardware and JetPack versions; high risk if you're on unsupported configurations. Heavy CUDA/cuDNN version coupling (visible in calibration/ and plugin/ CUDA code) means breaking changes when NVIDIA releases JetPack versions. Single maintainer (dusty-nv) is a consideration, though NVIDIA backing reduces abandonment risk. Custom TensorRT plugins in c/plugins/ could be fragile across TensorRT versions.

Active JetPack 6 support rollout on Orin devices, LLM/Generative AI tutorial expansion on Jetson AI Lab, and ongoing WebRTC/ROS2 integration examples. CHANGELOG.md would reveal specific recent commits, but based on README, feature work is focused on latest Jetson hardware support and modern training workflows (PyTorch).

Clone and build from source: git clone https://github.com/dusty-nv/jetson-inference.git && cd jetson-inference && mkdir build && cd build && cmake .. && make -j$(nproc). Or use the Docker container: docker build -t jetson-inference . && docker run -it --gpus all jetson-inference. See docs/building-repo-2.md and docs/jetpack-setup-2.md for detailed setup.

Daily commands: After build: ./detectNet --network=ssd-mobilenet-v2 --input_blob=input_0 --output-cvg=scores --output-bbox=boxes /path/to/image.jpg (C++ CLI), or python3 detectNet.py --network=ssd-mobilenet-v2 /path/to/image.jpg (Python). Live camera: ./detectNet /dev/video0 on Jetson with USB camera. See docs/detectnet-console-2.md for full CLI options.

• c/tensorNet.h — Core base class for all DNN inference networks; all vision primitives inherit from this, making it the foundational abstraction every contributor must understand.
• c/tensorNet.cpp — TensorRT engine initialization, model loading, and inference execution logic; the primary entry point for GPU-accelerated inference on Jetson devices.
• c/detectNet.h — Object detection network interface and core API; one of the five primary vision primitives and a reference implementation for network-specific logic.
• c/imageNet.h — Image classification network interface; demonstrates the standard pattern for wrapping TensorRT models and is frequently used in examples.
• CMakeLists.txt — Build configuration for the entire project; defines dependencies, targets, and compilation flags for C++/CUDA code and TensorRT integration.
• c/modelDownloader.h — Model acquisition and caching logic; critical for understanding how pre-trained networks are fetched and managed for deployment.
• c/tensorConvert.cu — GPU kernel implementations for image format conversion and tensor preprocessing; essential for performance-critical data pipeline operations.

Add a New Vision Primitive (e.g., New Task Network)

1. Create header file inheriting from tensorNet, defining the task-specific API (c/newTaskNet.h)
2. Implement the model class with task-specific pre/post-processing methods (c/newTaskNet.cpp)
3. Add CUDA kernels for output decoding if needed (e.g., detections→boxes) (c/newTaskNet.cu)
4. Register model metadata and download URLs in modelDownloader.cpp (c/modelDownloader.cpp)
5. Update CMakeLists.txt to build the new target library (CMakeLists.txt)

Add a Custom TensorRT Plugin for Unsupported Layer

1. Create plugin header inheriting from nvinfer1::IPluginV2Ext (c/plugins/myPlugin/myPlugin.h)
2. Implement plugin logic with serialize/deserialize and forward pass (c/plugins/myPlugin/myPlugin.cpp)
3. Write CUDA kernel for the custom layer operation (c/plugins/myPlugin/myPlugin.cu)
4. Register plugin in TensorRT plugin registry and CMakeLists.txt (CMakeLists.txt)

Optimize Model with INT8 Quantization

1. Create or customize a calibration dataset class extending randInt8Calibrator (c/calibration/myDatasetCalibrator.h)
2. Implement getBatch() and getBatchSize() for your dataset (c/calibration/myDatasetCalibrator.cpp)
3. Pass calibrator instance to tensorNet during engine building with INT8 flag (c/tensorNet.cpp)
4. Benchmark inference latency/accuracy trade-off on target Jetson hardware (examples/your_benchmark_app.cpp)

Add GPU Tensor Preprocessing for New Image Format

1. Define new color conversion kernel in tensorConvert.cu (c/tensorConvert.cu)
2. Add wrapper function in tensorConvert.h exposing the kernel to C++ (c/tensorConvert.h)
3. Call the preprocessing function in your network's ProcessFrame() method (c/imageNet.cpp)

• NVIDIA TensorRT — Provides graph optimization, kernel fusion, and mixed-precision inference (FP32/FP16/INT8) specifically optimized for NVIDIA GPUs; critical for achieving real-time performance on resource-constrained Jetson devices.
• CUDA / GPU Kernels — Enables custom high-performance tensor operations (color conversion, resizing, post-processing) that would be too slow on CPU; directly leverages Jetson GPU hardware.
• C++ with Python bindings — C++ provides low-latency inference execution for real-time systems; Python bindings enable rapid prototyping and ease of use for ML practitioners.
• PyTorch (training) — Industry-standard framework for model development and transfer learning; integrates with ONNX export pipeline for TensorRT deployment.

• Monolithic tensorNet base class with task-specific subclasses (imageNet, detectNet, etc.) rather than plugin architecture

  • Why: Simplifies API consistency and ensures tight integration with TensorRT; reduces abstraction overhead critical for latency-sensitive inference.
  • Consequence: Adding new vision primitives requires creating new classes; less flexibility than a fully pluggable system, but better performance and clearer semantics.

• Custom CUDA kernels for image preprocessing and post-processing vs. relying solely on TensorRT plugins

  • Why: Allows fine-tuned optimization for Jetson-specific hardware (e.g., Tegra memory hierarchy) and supports preprocessing that doesn't fit TensorRT's plugin model.
  • Consequence: More C++/CUDA code to maintain; increases development complexity but delivers critical performance gains for real-time video inference.

• Eager model download and caching vs. lazy loading or model servers

  • Why: Simplifies deployment on edge devices where network availability is unreliable; ensures model is ready before inference begins.
  • Consequence: First-run latency includes download time (~1-5s); requires local storage for models, which may be constrained on small Jetson boards.

CUDA Compute Capability coupling: code compiled for one Jetson arch (e.g., Orin with sm_87) may not run on another (Xavier with sm_72)—rebuild required. TensorRT engine serialization: .trt files are version-specific and architecture-specific; moving engines between devices breaks silently. cuDNN/CUDA version mismatch in JetPack breaks at runtime; verify with jetson_release. Python bindings assume libjetson-inference.so is installed system-wide—LD_LIBRARY_PATH issues if building from source without make install. Camera input expects V4L2 on Linux; Windows support is Docker-only.

• TensorRT Graph Optimization — jetson-inference's core value—TensorRT fuses operations, optimizes precision (INT8/FP16), and generates Jetson-specific CUDA kernels; understanding this explains why TensorRT engines are device-specific
• INT8 Quantization & Post-Training Calibration — Jetson Nano has limited memory and compute; INT8 reduces model size 4x and speeds inference 2-4x; randInt8Calibrator.cpp implements calibration dataset collection
• CUDA Plugin Architecture — Not all layers are in TensorRT stock lib; c/plugins/ shows how to implement custom CUDA kernels (FlattenConcat, conv3d) registered as plugins for model-specific ops
• Jetson Compute Capability & Device-Specific Compilation — CUDA code is compiled for specific GPU architectures (sm_72 for Xavier, sm_87 for Orin); .trt engine files are bound to both Jetson model and TensorRT version—portability requires recompilation
• Transfer Learning with PyTorch on Edge — Hello AI World workflow: train small models on Jetson with PyTorch using collected datasets, then deploy via TensorRT; shows how to minimize cloud dependency for continuous learning
• Post-Processing Kernels for Vision Tasks — detectNet.cu implements bounding box clustering, NMS, and decoding on GPU; moving post-processing to CUDA keeps full pipeline on device without CPU->GPU round-trips
• V4L2 Camera Input & Real-Time Streaming — Examples use /dev/video0 and V4L2 API for USB camera input; understanding zero-copy buffering and frame synchronization is critical for live inference on robotics platforms

• NVIDIA/TensorRT — Underlying inference engine; jetson-inference is a Jetson-specific wrapper and plugin library on top of TensorRT
• pytorch/pytorch — Training framework paired with jetson-inference in the Hello AI World tutorial; models trained in PyTorch are converted to TensorRT for deployment
• ros-perception/vision_opencv — ROS2 integration point for real-world robotics pipelines using jetson-inference on Jetson hardware with ROS sensor nodes
• NVIDIA/jetpack-containers — Official JetPack containers that jetson-inference Dockerfile extends; provides CUDA/cuDNN/TensorRT baseline
• dusty-nv/jetson-utils — Companion utility library by same author for camera I/O, image processing, and WebRTC streaming used throughout jetson-inference examples

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for TensorRT plugin implementations in c/plugins/

The c/plugins/ directory contains critical custom TensorRT plugins (interleaving, slice, stereo operations, upsampling) but has no corresponding unit tests. These plugins are complex CUDA kernels that are easy to regress. Adding tests would catch issues early and make the codebase more maintainable for contributors extending plugin functionality.

• [ ] Create c/plugins/tests/ directory structure
• [ ] Add unit tests for c/plugins/interleaving/interleavingPlugin.cpp with various tensor shapes
• [ ] Add unit tests for c/plugins/slice/slicePlugin.cpp including edge cases
• [ ] Add unit tests for c/plugins/stereo/conv3d_plugin.cpp and transpose variants
• [ ] Add CMake targets to build and run plugin tests
• [ ] Document how to run tests in README or CONTRIBUTING.md

Add Python bindings and example for experimental stereo vision networks

The c/experimental/ folder contains stereoNet, odometryNet, and flowNet implementations with sophisticated CUDA kernels, but these lack Python bindings while other networks (imageNet, detectNet, segNet) have them. This blocks Python developers from using these advanced stereo vision features and represents missing functionality parity.

• [ ] Create python/stereoNet.py with ctypes bindings following pattern of existing c/imageNet.py
• [ ] Create python/odometryNet.py wrapper
• [ ] Create python/flowNet.py wrapper
• [ ] Add example script: examples/my-stereo-camera.py demonstrating stereo depth inference
• [ ] Add Python API documentation in docs/ directory
• [ ] Test with sample stereo dataset to verify correctness

Add GitHub Actions CI workflow for CUDA plugin compilation and regression tests

The repository contains 15+ custom CUDA plugins but lacks automated CI to catch compilation failures or performance regressions across different NVIDIA GPU architectures (Jetson Nano, Xavier, Orin). Currently, contributors can break plugin code without detection. A focused CI job would improve code quality and prevent regressions.

• [ ] Create .github/workflows/cuda-plugins-ci.yml workflow file
• [ ] Add build step that compiles all c/plugins/ targets with CMake
• [ ] Add step to run plugin unit tests (from PR #1)
• [ ] Configure matrix for multiple Jetson architectures using QEMU or Docker with nvidia/cuda images
• [ ] Add artifact upload for compiled .so libraries
• [ ] Add step to verify Python plugin bindings load correctly

• Add C++ unit tests for c/detectNet.cpp post-processing kernels using Google Test; currently only CLI integration tests exist. Start with c/detectNet.cu's clustering logic.
• Document TensorRT custom plugin lifecycle in examples/plugins/README.md with step-by-step guide to adding a new operation to c/plugins/—currently only source code exists as reference.
• Implement Python dataloader wrapper in python/ that mirrors PyTorch's Dataset/DataLoader for easy transfer learning on Jetson; currently training examples assume PyTorch on x86.

The jetson-inference codebase demonstrates moderate security posture for a deep learning inference framework. Primary concerns include: (1) incomplete Docker security assessment, (2) model download supply chain risks without apparent validation, (3) custom CUDA plugin security, and (4) use of experimental code. The C++ and CUDA implementation requires careful memory management oversight. Strengths include structured code

• Medium · Incomplete Dockerfile Security Review — Dockerfile. The Dockerfile content is truncated in the provided security context, making it impossible to fully assess Docker security configurations. Common issues in Docker configurations include missing health checks, running as root user, using 'latest' tags, and lack of multi-stage builds. Fix: Ensure the complete Dockerfile: (1) Uses specific base image versions, (2) Runs with non-root user, (3) Implements multi-stage builds, (4) Includes HEALTHCHECK directive, (5) Minimizes layer count, (6) Uses .dockerignore effectively
• Medium · Model Downloader Component — c/modelDownloader.cpp, c/modelDownloader.h. The presence of 'modelDownloader.cpp' and 'modelDownloader.h' suggests the application downloads pre-trained models from external sources. This introduces risks of supply chain attacks, man-in-the-middle attacks, or downloading malicious model files if not properly validated. Fix: Implement cryptographic signature verification for downloaded models, use HTTPS only, pin TLS certificates, maintain a whitelist of trusted model sources, implement checksum validation (SHA-256), and log all model downloads
• Medium · Custom TensorRT Plugins — c/plugins/ (multiple .cu and .cpp files). Multiple custom CUDA/TensorRT plugins are present (stereo, upsampling, interleaving, slice). Custom plugins can contain memory safety issues, buffer overflows, or GPU memory corruption vulnerabilities if not carefully implemented. Fix: Perform thorough code review of all CUDA kernel code, implement bounds checking, use static analysis tools for CUDA code, enable compiler warnings (-Wall -Wextra), conduct fuzzing tests on plugin inputs, and implement memory sanitizers
• Medium · Calibration Integer Quantization — c/calibration/randInt8Calibrator.cpp, c/calibration/randInt8Calibrator.h. The 'randInt8Calibrator' uses random data for INT8 quantization calibration. Random data may not represent real-world distributions, potentially leading to model accuracy degradation and unpredictable inference behavior that could be exploited. Fix: Use representative calibration datasets from production, implement data validation, document quantization impacts on security-critical inferences, add regression tests, and validate model behavior on edge cases
• Low · Experimental Code in Production Path — c/experimental/ (multiple files). The 'c/experimental/' directory contains unstable, potentially untested code (flowNet, odometryNet, homographyNet) that could introduce security or stability issues if inadvertently used in production. Fix: Clearly separate experimental code from stable releases, use feature flags for experimental features, maintain separate build targets, implement mandatory code review for experimental→stable promotion, and document stability status in headers
• Low · Missing Dependency Lock File Information — Dependencies/Package file. The provided dependency/package file is empty. Without a lock file (requirements.txt, package-lock.json, CMakeLists.txt version pinning), there's potential for inconsistent builds and supply chain vulnerabilities. Fix: Implement dependency version pinning in CMakeLists.txt, use a lock file for reproducible builds, regularly audit dependencies with tools like OWASP Dependency-Check, enable automated security scanning for dependencies
• Low · Dynamic Memory Management in C++ — c/ (multiple .cpp and .cu files). The codebase is primarily C++ with CUDA, which requires careful memory management. While not inherently a vulnerability, improper memory handling could lead to buffer overflows, use-after-free, or memory leaks in inference networks. Fix: Use smart pointers (std::unique_ptr, std::shared_ptr), enable AddressSanitizer (-fsanitize=address), implement static analysis (clang-tidy), conduct memory testing, review tensor allocation/deallocation patterns

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.