Software Stack

Software Architecture

Every software component runs open-source code with clear responsibilities. The stack is designed for remote management, over-the-air updates, and consistent behavior across 1,000+ vehicles.

Flight Controller: Pixhawk

PX4 v1.14 LTS

The flight controller runs PX4 Autopilot v1.14 LTS:

Why LTS:

• Stability — Production-tested codebase, minimal churn
• Security — Critical vulnerabilities patched without feature changes
• Predictability — Known behavior across entire fleet
• Support — Commercial support available from Dronecode ecosystem

Key Modules:

• EKF2 — Extended Kalman Filter for state estimation
• Position Controller — Multicopter position and velocity control
• Navigator — Mission execution, RTL, geofence
• Commander — State machine, failsafe handling
• MAVLink — Telemetry and command protocol

Sensor Companion: Raspberry Pi

Ubuntu Server 22.04 LTS

The Raspberry Pi runs Ubuntu Server 22.04:

Why Ubuntu Server (not Raspberry Pi OS):

• Consistency — Same OS on Pi and Jetson
• Packaging — Standard apt repositories, snaps available
• LTS Support — Security updates for 5 years
• Tooling — Familiar administration for ops teams

Core Services

mavlink-router is critical—it forwards MAVLink traffic from the Pixhawk’s serial port to the Jetson over UDP, enabling the Vehicle Gateway to process telemetry.

AI Companion: Jetson

JetPack 6.x

The Jetson runs NVIDIA JetPack 6.x:

Why JetPack 6:

• Latest Orin support — Full hardware acceleration on Orin family
• Ubuntu 22.04 base — Matches Pi for consistent operations
• Container support — NVIDIA Container Runtime for isolated workloads
• OTA updates — NVIDIA tools for fleet-wide firmware updates

CUDA + TensorRT

AI inference runs through the TensorRT runtime:

• Model optimization — INT8/FP16 quantization for edge deployment
• Batch inference — Process multiple frames efficiently
• Low latency — Direct GPU memory access

Typical workloads:

• Object detection (YOLO, SSD)
• Semantic segmentation
• Optical flow
• Depth estimation

ROS 2 Humble

ROS 2 Humble Hawksbill provides the robotics middleware:

Why ROS 2 Humble:

• LTS release — 5-year support matches Ubuntu/JetPack
• Real-time capable — Deterministic execution paths available
• Sensor integration — Extensive driver packages
• Simulation — Gazebo integration for testing

Key Packages:

Vehicle Gateway

Go Implementation

The Vehicle Gateway is a custom Go service running on each Jetson:

Why Go:

• Single binary — No runtime dependencies, simple deployment
• Performance — Low latency, efficient memory usage
• Concurrency — Goroutines for parallel MAVLink/NATS handling
• NATS ecosystem — First-class nats.go client library

Responsibilities:

1. MAVLink Ingest — Receive and parse MAVLink messages from mavlink-router
2. State Downsampling — Reduce telemetry rate for WAN transmission
3. Event Extraction — Generate events from state transitions
4. Command Execution — Receive NATS commands, validate, send to FCU
5. Shadow Reconciliation — Sync desired/reported state with fleet backend

Gateway Details →

Control Plane

NATS + JetStream

Fleet coordination runs on NATS with JetStream persistence:

Why NATS:

• Performance — Millions of messages per second per node
• Simplicity — Single binary, minimal configuration
• Persistence — JetStream for durable streams and KV
• Topology — Leaf nodes, clusters, superclusters for any scale

Fleet Topology:

┌─────────────────────────────────────────────────────┐
│                   Global Hub (optional)             │
│                   NATS Supercluster                 │
└─────────────────┬───────────────────┬───────────────┘
                  │                   │
      ┌───────────▼───────┐ ┌─────────▼───────────┐
      │   Regional Hub A  │ │   Regional Hub B    │
      │   3-node cluster  │ │   3-node cluster    │
      └─────────┬─────────┘ └─────────┬───────────┘
                │                     │
    ┌───────────┼───────────┐         │
    │           │           │         │
┌───▼───┐ ┌─────▼───┐ ┌─────▼───┐ ┌───▼───┐
│ Leaf  │ │  Leaf   │ │  Leaf   │ │ Leaf  │
│ VID-1 │ │ VID-2   │ │ VID-3   │ │VID-N  │
└───────┘ └─────────┘ └─────────┘ └───────┘

Each vehicle runs a leaf node that connects to its regional hub. The leaf node handles local pub/sub and store-and-forward when disconnected.

NATS Topology Details →

Software Update Strategy

Fleet-Wide OTA

Principles:

• Staged rollout — Update subset, verify, expand
• Rollback capability — Previous version always available
• Health checks — Automated verification post-update
• Minimal downtime — Updates during maintenance windows

Summary

Next

NATS Topology →