Link Search Menu Expand Document

VOXL SDK Software Safety

Table of contents

  1. Overview
  2. Flight Control Architecture
  3. Failsafe Behaviors
  4. Static Analysis and Code Quality
  5. Software Quality Assurance Testing
  6. Use of Artificial Intelligence
  7. Related Pages

Overview

This page summarizes the software safety posture of the VOXL SDK: how flight-critical software is separated from non-critical software, how the vehicle behaves under abnormal and emergency conditions, how code quality is enforced through analysis and testing, and how artificial intelligence technology is — and is not — used. It complements the Configuration Management and Software Anomaly Reporting pages, which describe how software changes are controlled and how defects are handled.

Flight Control Architecture

VOXL 2 combines the flight controller and the companion computer on a single board, but not on a single processor. The PX4 flight controller (voxl-px4) executes on a dedicated sensors DSP (the SLPI), isolated from the Linux applications processor where VOXL SDK services (cameras, computer vision, networking, autonomy features) run.

This partitioning has two safety-significant properties:

  • Companion-side failures do not stop flight control. SDK services on the applications processor can fail, restart, or be stopped without taking down the flight controller; PX4 continues to fly the vehicle.
  • Autonomy inputs are advisory. Computer-vision and offboard inputs feed the flight controller as aiding data or commands, and the flight controller falls back to its own flight modes on loss of them. Autonomous behaviors are opt-in and disabled by default; the pilot can always take manual control.

Failsafe Behaviors

Flight control behavior under abnormal, emergency, and contingency conditions is provided by the PX4 failsafe system. All failsafe parameters are fully configurable, and each drone platform ships with its own defaults appropriate to that airframe; the behaviors below describe the mechanisms.

  • RC link loss — loss of the RC control link for longer than a configurable timeout triggers a configurable failsafe action (e.g. return-to-launch, land, or hold).
  • Low battery — a staged response: a warning at a configurable remaining-capacity threshold, escalating to an automatic return-to-launch or land action at critical thresholds.
  • Position-estimate degradation — autonomous and position-controlled modes require a healthy position estimate (GPS and/or visual-inertial odometry). If the estimate degrades or is lost, the vehicle falls back to altitude-controlled flight, and ultimately to manual/stabilized flight, rather than acting on bad position data.
  • Arming checks and geofence — pre-arm checks block arming until sensors, estimators, battery, and RC are healthy; an optional geofence triggers a configurable action on breach.

Static Analysis and Code Quality

As described under Change Control, every commit to every SDK package is built by automated CI in a version-controlled build environment, and a commit that fails CI does not produce a package.

In addition, every push to a package’s development branch runs a required static analysis stage:

  • Static analysis of the source with Semgrep, using a broad ruleset (the full public registry plus secrets detection) with dataflow tracing.
  • Compiler diagnostics from the cross-compilation builds for each supported hardware target are captured and normalized alongside the static analysis results.
  • All findings are uploaded to a managed defect-tracking system (DefectDojo), where they are deduplicated per component and branch, triaged, and tracked to remediation.

The analysis stage is a required (blocking) job in the pipeline: its results are recorded for every push, giving each component a continuous, reviewable code-quality history.

Software Quality Assurance Testing

Release testing is governed by ModalAI’s internally controlled, numbered SWQA test documents, which define test procedures at three levels: PCB, sub-assembly, and integrated drone/flight test. As described in the release process, every release candidate is flashed to each supported hardware platform and taken through release regression testing and flight testing on development aircraft, with flight logs collected and reviewed for every test flight, before the release manager signs off on publication.

Use of Artificial Intelligence

  • In development — AI-assisted developer tooling may be used during software development. All resulting changes go through the same controls as any other change: merge request review, CI builds, static analysis, and release testing.
  • In operation — no AI/ML technology is used in flight-critical control paths. On-board state estimation, including visual-inertial odometry, uses classical computer-vision and filtering algorithms (deterministic feature tracking and Kalman-filter-based estimation), not machine-learned models. The VOXL SDK offers optional on-board inference through voxl-tflite-server, which runs pre-trained, frozen models for perception tasks; it performs inference only, is disabled by default, and is not part of flight control.
  • No on-board learning — deployed models are static. They do not update their weights, learn from collected data, or accept new training input during operation.