Hardware checks
Embedded Files
Before flying, run the hardware checks to confirm every subsystem on the drone is working. The HW Check tab has six individual checks plus a drone-config editor and a reference builder. None of them require flight — most are read-only probes that take a few seconds.
When to run them?
Run the checks at the start of every flight session, after any hardware change, after rebuilding the drone-side software, or whenever something feels wrong. They take less than a minute total to complete and surface most field-relevant issues immediately.
Open the HW Check tab
With the drone connected, click the HW Check sub-tab in the Single Shell. The page lists all six checks, each as its own card with a Run and Details button.
The Six Checks
IMU
Polls the BNO08x IMU over I²C for a non-zero quaternion. The first read after power-on is always zeros until the BNO08x's SHTP rotation report arrives, so the check waits up to 3 seconds for real data. Pass means orientation is being reported. Fail typically means the IMU isn't wired correctly or the I²C bus is misconfigured.
Needs idle 12 s timeout.
GPS
Probes the GPS receiver's serial port at three baud rates (9600, 38400, 115200) looking for NMEA sentences. Pass means the receiver is wired and emitting data. Fail usually means a wrong cable, no power to the receiver, or the receiver hasn't acquired any satellites yet (give it a few minutes outdoors before retrying).
Needs idle 18 s timeout.
Camera exposure
Captures one frame from the camera and labels it normal, under, or overexposed. Run with the camera pointed at flight-representative ground from 3–5 m (i.e. holding the drone at flying height). If the result is under or overexposed, adjust the camera or environment before flight — the detector tolerates some exposure variance but not extremes.
Needs idle 30 s timeout.
MAVLink
Verifies the flight controller's heartbeat reaches the Jetson. The check waits up to 3 seconds for the FC to send a heartbeat packet over the serial connection. Pass means the FC is alive and talking to the companion computer. Fail usually means the cable is loose, the FC is in a non-standard mode, or the baud rate is wrong.
Needs idle 10 s timeout.
GPU
Reads tegrastats / nvidia-smi for the Jetson's current memory and thermal state. Reports both so you can fly without out-of-memory crashes or thermal throttling mid-flight. Pass means there's enough memory headroom and the GPU isn't already throttling.
Idle not required 4 s timeout.
Disk
Checks free space on /, /home, and the pfa-edge directory. Confirms there's room to save flight logs and detection images. Pass means every relevant volume has enough headroom (typically >1 GB).
Idle not required 3 s timeout.
Run a check
Click Run on any card. The card's status pill flips to running while the check executes; when it finishes, the pill turns pass or fail. A short summary line appears underneath.
For the failure case, click Details to open a modal with the full stdout, stderr, and exit code. Most field issues are obvious from the stderr (missing device, permission denied, etc.).
Drone Configuration
Below the check cards is a collapsible Drone Configuration section. It loads the drone's data-collect-run.toml file over SSH, lets you edit values via typed inputs, and pushes the changes back with an atomic SFTP rename.
The card stays collapsed by default — most operators dial this in once and leave it. Click the header to expand. Three section groups inside:
[run] — sensor rate, magnetic declination, field of view, base directory, reference path, detector weights, VPS mode, and other mission-level scalars.
[camera] — capture pipeline parameters (intrinsics, distortion coefficients).
[vo] — visual odometry scale and tuning.
Build a reference
Inside the [run] section, immediately under the Reference Path input, is a Reference (.pt) sub-section with a drone-side build badge. This is how you build a new .pt reference file on the drone using a cached tile region.
A reference is a serialized data file the on-drone VPS subsystem uses to localize the drone against satellite imagery. It's specific to a region and zoom level. You build one per operating area, then point the drone at it via the Reference Path field.
The backend pre-validates the API key with a single call to Google before queuing the build. If the key is invalid you'll see the rejection within a second or two — much better than finding out minutes into the drone-side fetch.
Watch the progress
A progress card appears with:
The current status pill: pending → running → done (or error).
A stage label (e.g. fetch (47/225)).
A progress bar split 80% fetch / 20% prepare.
The drone-side log tail (expandable) showing each line of output as it arrives.
A typical 6-tile build finishes in 30–60 seconds. Larger regions take proportionally longer.
Use the new reference
When the build finishes, the card shows the result path. Click Use this path to populate the Reference Path input with the new file. You still need to click Save & push on the Drone Configuration header to commit the change — the build doesn't auto-update the config.
Switching between existing references
Above the build section is a list of .pt files already on the drone. Click any of them to populate the Reference Path input with that file's path. Same as above — Save & push to commit.
What "all checks pass" looks like
When IMU, GPS, MAVLink, Camera Exposure, GPU, and Disk all show pass and the Drone Configuration reflects your intended values, the drone is ready to fly. Move to the Fly tab.
Report abuse