Files
gps-denied-onboard/_docs/02_document/deployment/containerization.md
T

2.0 KiB

Containerization

Strategy

The production runtime targets Jetson hardware and may not be fully containerized for all camera/GPU paths. The test and development stack uses containers where practical, with local hardware execution required for release gates.

Runtime Units

Unit Containerized? Notes
GPS-denied service Optional on Jetson Must access camera, CUDA/TensorRT/ONNX, MAVLink, local cache, FDR storage
Replay consumer Yes Deterministic black-box test harness
Satellite cache stub Yes Local fixture volume for COG/manifest/descriptors
ArduPilot Plane SITL Yes or local process Used for MAVLink and failsafe validation
QGC observer/log parser Yes Parses MAVLink status/tlogs

Docker Compose Profiles

Profile Purpose Services
replay CI/PR deterministic fixture tests gps-denied-service, replay-consumer, satellite-cache-stub
sitl ArduPilot Plane integration tests gps-denied-service, ardupilot-plane-sitl, qgc-observer
jetson-local Documentation-only profile for local hardware run Host runtime with local scripts/tasks created later

Image Requirements

  • Base images must match JetPack/CUDA compatibility for GPU tests.
  • Replay-only images may use standard Ubuntu/Python/C++ build images.
  • No production image should contain secrets, mission signing keys, or provider credentials.
  • Dataset downloads are not baked into images; they are mounted as versioned fixtures.

Volumes

Volume Purpose
/data/input Test images and public dataset slices
/cache/satellite Offline cache fixture
/fdr Runtime FDR output
/test-results CSV/Markdown reports

Open Tasks For Decomposition

  • Create Dockerfiles for replay-compatible service and consumer harness.
  • Define Jetson local setup scripts for GPU/camera/MAVLink access.
  • Create compose profiles for replay and SITL.
  • Add license-aware public dataset fixture downloader.