px4-flight-debugger
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PYTHONPATH | No | Set to an empty string to keep a sourced ROS 2 environment from leaking its packages into the server. | |
| PX4_ULOG_DIRS | No | Lists where to look for ULog files (directories separated by ':'). Default: ~/PX4-Autopilot/build/px4_sitl_default/rootfs/log | ~/PX4-Autopilot/build/px4_sitl_default/rootfs/log |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_logsA | List flight logs newest first with their local start time, or find the one that covers a given wall-clock time. |
| log_summaryB | What happened in one flight: PX4 version, arming and why, takeoff and landing, mode changes, failsafes, estimator trouble while armed, distinct warnings and errors (console and decoded events). |
| log_messagesB | PX4 console messages and decoded events at or above a level, oldest first. |
| flight_timelineB | Everything that changed, in order: modes and arming, commands and their acks, failsafe flags set/cleared, takeoff/landing, estimator validity, warnings. |
| estimator_healthB | EKF2 view: when local position/velocity were invalid, dead reckoning, resets, which sources were fused and when (GPS, mag, baro...), faults, and innovation test ratios that exceeded 1 (measurements rejected). |
| estimate_vs_truthA | SITL only: PX4's position/yaw estimate against the simulator's ground truth, on the ground before liftoff and in the air, plus sudden jumps. Shows offsets a planner flying on the estimate would carry. |
| velocity_trackingA | How PX4 followed offboard velocity setpoints: fits a first-order lag plus dead time from trajectory_setpoint to the measured velocity (the 'reaction time' an avoidance planner has to budget for). |
| log_paramsC | Parameter values as logged at boot, and any changed during the log. |
| list_topicsB | Every logged uORB topic with sample count, rate and field count. |
| topic_dataB | Min/mean/max/first/last of a topic's fields over a time window, optionally with a downsampled table. |
| scan_logsB | One line per log: start time, duration, time armed, first failsafe, warning count and the first warning. For questions like 'which flights today lost the compass' or 'which ones failsafed'. |
| plot_seriesB | Plot logged fields against time (mode changes dashed, failsafes red) and return the PNG. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools have clearly distinct scopes: discovery (list_logs, scan_logs), single-flight narrative (log_summary, flight_timeline, log_messages), estimator analysis (estimator_health, estimate_vs_truth), and data access (list_topics, topic_data, plot_series). The main friction is between log_summary, flight_timeline, and log_messages, which all describe 'what happened in a flight' from slightly different angles, and between list_logs and scan_logs, though the descriptions do differentiate them well enough.
All names are snake_case and readable, with no mixed casing conventions. However the pattern is not uniformly verb_noun: list_logs, scan_logs, plot_series use verbs while log_summary, flight_timeline, estimator_health, topic_data are noun phrases, creating a minor stylistic inconsistency.
12 tools is well within the ideal range and each one maps to a distinct analysis need (discovery, summarization, event ordering, EKF health, truth comparison, setpoint tracking, params, topics, plotting). No tool feels redundant or padded.
The surface covers discovery, per-flight narrative, estimator diagnostics, parameters, uORB topics, and plotting, which is strong lifecycle coverage for flight log debugging. Minor gaps remain, such as raw/full-resolution topic export (topic_data only gives stats plus an optional downsampled table) and no dedicated actuator/motor or battery analysis path, though plot_series partially compensates.