University of Alabama in Huntsville · v0.2.0-alpha.0
A framework for uncrewed vehicles, and the electronics that support them
SAPIENCE gives a vehicle's onboard software one bus, one language, and one answer to the question every autonomy stack eventually has to answer: which program holds the controls right now?
- Version
- 0.2.0-alpha.0 — early, and moving
- Simulation
- Twenty-five vehicles on one host, against PX4 and ArduPilot
- Hardware
- TARS flew an ancestor of this stack. This release has not.
What it does
A drone carries one flight controller and several programs that all want to command it. The usual answers: write everything as one program you can never safely change, or let every program reach the flight controller and hope. SAPIENCE takes a third answer — put one daemon in charge of the door, write down who may say what, and make losing control a designed behaviour rather than an accident.
That rule carries the whole framework. Everything else — the services that fly and look, the electrical conventions a vehicle has to satisfy, the tool that stamps out a swarm — follows from having somewhere to put it.
The system at a glance
Each vehicle carries a complete copy of the stack and knows nothing about its neighbours. One command writes out a whole swarm and brings it up, each vehicle sealed off so two swarms on one machine cannot hear each other by accident. That lets twenty-five drones fly a pattern on a single laptop.
The pieces
MAVFabric
One Rust daemon owns the link to the flight controller. Every other process reaches the vehicle through it, under a manifest that says what each may send and hear. It carries the control lease, so exactly one program steers at a time.
Services
autonomy flies the plan, core owns command egress and the geofence,
world-model fuses what the sensors report, vision and lidar drive them.
Each runs as a separate process with its own component ID and its own allowlist.
Hardware
The electrical rules any vehicle in the framework has to satisfy: power domains that keep propulsion return current out of signal ground, rail conventions, carrier pinouts, and a ten-gate bring-up that ends in measurements.
skynet
One CLI builds the images, brings up simulated vehicles, flies a plan, films it, deploys to a companion computer, and reads back what happened. Simulation and hardware take the same verbs.
Three ways in
Use it. A laptop with Docker brings the whole stack up in simulation — flight dynamics, companion computer, and as many drones as the host carries. No vehicle needed.
Understand it. The design argues with itself in public: a specification, a set of decision records with the alternatives that lost, and the measurements behind every number quoted.
Build with it. Attach your own process to the bus and let the manifest say what it may do, or wire a vehicle to the framework's electrical conventions.
Where it actually stands
Read this before quoting anything from this site.
| State | What that means here | |
|---|---|---|
| Communications fabric | Implemented | The daemon, the manifest, the lease and the queues all run |
| Mission autonomy | Implemented | Flies a declarative plan against PX4 and ArduPilot |
| Multi-vehicle swarm | Measured | Twenty-five vehicles on 4 cores, with the run and its numbers published |
| Perception | Provisional | vision and lidar have component identities and manifests; a simulated peer supplies the sightings |
| Vehicle electronics | Provisional | Specified to the conductor for Hawkeye Rev A, which has not flown. TARS flew, carrying an earlier stack |
| Vehicle-to-vehicle radio | Planned | The design reserves the place and every vehicle carries the identifier. No protocol chosen, no code |
Documentation
- Get started — install, fly a mission, or wire a vehicle
- Architecture — how the pieces fit, and which exist
- Hardware — the electrical rules any airframe must satisfy
- Vehicles — the record of one machine, down to the conductor
- Evidence — which numbers came from which run, and how
- Reference — specification, decision records, commands, dependencies