What Foxborne does
Foxborne rebuilds a field robotics incident from the logs your vehicles already keep. It puts every source on one clock with a stated error and hands off a report where each line cites its original file.
On this page12
Foxborne is incident reconstruction software for drones and ground robots that run PX4 with a Linux companion computer. It answers the first question of any failure review: what failed first, and how sure the evidence lets you be.
It runs inside your network, reads the files your vehicles and ground stations already write and has no way to command a vehicle. Foxborne is a diagnostic aid for engineering review, not a flight safety system.
From log files to a report you can check#
An incident moves through four steps, from the first file to the hand-off. Each step leaves a record that a reviewer can check later.
Import#
Drop in a .ulg flight log, a journalctl export and collector samples, or point Foxborne at the bucket where they already land. Foxborne hashes each original with SHA-256 the moment it arrives and stores it unmodified. See Evidence integrity.
Align#
GPS time anchors the flight log and chrony vouches for the companion clock, so every source lands on UTC with a stated error bound. A source with no anchor stays visibly separate, and Foxborne makes no before or after claim against it. See Clocks, anchors and error bounds.
Reconstruct#
Deterministic rules catch the memory climb, the service exit and the telemetry gap. Each finding names the rule ID, version and threshold that fired and the events it read, so a rerun next month gives the same answer. See Rules and findings.
Hand off#
The engineer writes the conclusion, and Foxborne exports the report as a case file on marked pages. It carries exact excerpts, the SHA-256 of every source file, the limits of the evidence and the open questions, under your marking. See Reports and case files.
What it reads#
Foxborne reads six kinds of evidence. The console recognizes the first four from each file's contents, not its name, and refuses anything else with a reason.
| Format | Extension | What it holds |
|---|---|---|
| PX4 ULog | .ulg | Completed flight logs: vehicle status, position, battery, GPS, telemetry, logged messages and dropouts. |
| journalctl JSON | .json | systemd journal exports from the companion computer, with realtime and monotonic timestamps and the boot ID. |
| Collector JSONL | .jsonl | Process samples from the Foxborne collector: CPU, resident memory and restart count, with clock status on every sample. |
| Receiver JSONL | .jsonl | Ground station receive records: which MAVLink message arrived, from which system and when it arrived. |
| IRIG 106 Chapter 10 | .ch10 | Flight test recordings: time packets, PCM, MIL-STD-1553 and ARINC 429 channels, decoded with the recording's own TMATS setup record. |
| Range records | .csv, .json | Radar TSPI, telemetry receiver and flight termination console logs on range time, mapped once per range. |
File import also takes ArduPilot DataFlash logs, MAVLink telemetry logs, MCAP and ROS 2 bags and CAN logs. Supported file formats describes each format and how Foxborne recognizes it.
Where it reads from#
Files arrive through the storage and services you already run. Each connection is read-only, and a manual upload is hashed in the browser before it leaves your machine.
| Connection | How Foxborne reads it |
|---|---|
| Amazon S3 | Including AWS GovCloud, through a read-only IAM role. |
| S3-compatible storage | MinIO, Ceph or any S3 API inside your network. |
| Azure Blob Storage | Including Azure Government, through a managed identity. |
| Google Cloud Storage | Through a service account with the viewer role. |
| SFTP | Ground stations and log servers, polled on a schedule. |
| SMB or NFS | Network shares mounted read-only on the worker. |
| Companion collector | A read-only service on each companion computer. |
| MAVLink receiver | Records every receipt on the ground with its own clock. |
| Ingest API | Test rigs and pipelines push signed bundles. |
| Manual upload | Files dropped into the console, hashed in the browser first. |
The collector is optional: Foxborne works from imported files alone. See How data gets into Foxborne.
Read-only by design#
Foxborne observes and reports. Its architecture rules out the actions a review tool should never be able to take:
- No command channel. The collector never sends MAVLink to the flight controller. Foxborne cannot fly, command or reconfigure a vehicle.
- No open port on the vehicle. Collectors connect outbound over mutual TLS and spool on board while the link is down.
- Engineers conclude. Rules report what they observed. The engineer writes the conclusion, and the report keeps the two apart.
- No invented confidence scores. A figure like 91% needs a calibrated model and labeled incidents. Reviewers get the evidence itself, which is what they sign off on.
- Write-once originals. Files are hashed on arrival and never rewritten. Reviewers annotate beside the evidence, never on top of it.
- Nothing sent to us. A self-hosted deployment has no telemetry, no crash reporting and no license call home.
Where it runs#
Foxborne is software you run in your own environment, inside your own authorization boundary. There is no remote access path for Foxborne staff: when you want help, you share an export or a screen under your own process.
| Mode | What it means |
|---|---|
| Your cloud account | Deploys into your AWS, AWS GovCloud or Azure Government account. Originals stay in your buckets, encrypted with your keys. |
| Your data center | Runs on your own Kubernetes or a pair of Linux hosts, next to the log servers you already have. |
| Air-gapped | No network path out at all. Updates arrive as signed bundles that your administrator carries in and verifies. |
Deployment options compares the three.
The example dataset#
These docs use the console's example dataset throughout. All of it is invented: its incidents, runs, vehicles, files, sites and people come from no real program and no real flight.
| Incident | What happened | What it shows |
|---|---|---|
| INC-0142 | Telemetry gap after perception.service was killed. UAS-04, run R-0931. | Four sources on one aligned timeline, and a stall and a kill 39 ms apart whose order is unknown. |
| INC-0143 | UGV-02 held mid-lane after its radio dropped off USB. Run R-0934. | A radio that keeps no log, and the PX4 data link timer behind the hold. |
| INC-0139 | Obstacle data stopped mid-mission and the vehicle held. UAS-07, run R-0922. | A companion clock that was never synchronized, and how to align it by hand. |
Five lighter incidents fill out the list: INC-0141, INC-0137, INC-0135, INC-0133 and INC-0130. Figures built from these values carry an Example data label, and your own deployment shows your own data.
Where to start#
| Reader | Then read |
|---|---|
| Investigators | Work an incident, Read the timeline, Write and review a report |
| Reviewers | Reports and case files, Alignment and event order, Verify a report against the originals |
| Platform and security teams | Architecture and network paths, Security model, Audit log |
| Admins | Invite, change and remove access, Connect a storage source, Thresholds, scopes and overrides |
Next#
- Quickstart: reconstruct your first incident walks the example dataset from import to case file.
- A tour of the console shows where every screen lives.