BAGEL BY EXTELLIGENCE · TASK GUIDE

Investigate PX4 flight-log anomalies

Bagel investigates PX4 .ulg flight logs by checking recorded power, IMU, GPS, timing and status data. Start with the bundled command-line demo, then use an MCP client to inspect schemas and query the time window behind a finding.

Run the bundled PX4 report

With Docker installed and running, this command downloads the PX4 image if needed and runs its bundled sample.ulg:

terminal · no MCP client or model needed

docker run -it --rm ghcr.io/extelligence-ai/bagel/px4:latest demo

The headless demo uses Bagel's source, schema and query primitives directly. It does not invoke an LLM or MCP transport. The image download needs network access; the demo checks themselves make no network calls.

Example output documented in the repository

For the bundled sample, the README reports minimum battery voltage of 21.07 V and a largest single-sample drop of 2.37 V near 4.8 seconds after the log starts. The GPS check is skipped because no GPS topic is present.

These are the repository's documented sample results, not a new run or a general flight-health benchmark. Read the original demo output.

To run the same checks on your file, replace the host path below with your log directory:

terminal · your own log

docker run -it --rm \
  -v /absolute/path/to/logs:/home/ubuntu/data:ro \
  ghcr.io/extelligence-ai/bagel/px4:latest demo /home/ubuntu/data/flight.ulg

latest changes as images are released. Record the image digest or pin a released version when sharing a reproduction. A download or container startup can take longer than the checks themselves.

Investigate the window behind a finding

For interactive questions, install an MCP-enabled client and start the PX4 service from the Bagel checkout. Configure its data volume before starting when using your own log.

terminal · first terminal

git clone https://github.com/Extelligence-ai/bagel.git
cd bagel
mkdir -p ~/.bagel/artifacts ~/.bagel/capabilities
docker compose run --service-ports px4

Wait for Uvicorn on port 8000. In a second terminal:

terminal · second terminal

claude mcp add --transport sse bagel http://localhost:8000/sse
claude

If port 8000 is busy, use MCP_SERVER_PORT=8100 docker compose run --service-ports px4 and port 8100 in the client URL. See client setup for other clients.

prompt · bundled flight log

Investigate ./data/sample/px4/sample.ulg with Bagel.
Describe the source and inspect the battery and IMU topic schemas first.
Find the largest single-sample voltage drop and report its time relative
to log start. Query the surrounding window for IMU changes, message gaps,
and recorded errors. Show every executed SQL query and explain missing
checks. Distinguish observed changes from possible causes.

To use your own log, replace the path with its mounted container path, such as /home/ubuntu/data/flight.ulg. State a known event time if available so Bagel can narrow the investigation.

Check the schema and the calculation

Call describe_data_source first, then describe_topic for relevant topics. PX4 topic names include an instance suffix, such as battery_status_0; read the actual topic list rather than assuming instance zero exists.

If the inspected battery topic contains voltage_v and the default timestamp_seconds column, the following is a query pattern for query_messages:

SQL pattern · topic battery_status_0

WITH samples AS (
  SELECT timestamp_seconds AS t,
         "battery_status_0"['voltage_v'] AS voltage_v
  FROM "battery_status_0"
), changes AS (
  SELECT t, voltage_v,
         LAG(voltage_v) OVER (ORDER BY t) - voltage_v AS drop_v
  FROM samples
)
SELECT t, voltage_v, drop_v
FROM changes
WHERE drop_v > 0
ORDER BY drop_v DESC, t
LIMIT 1

A single-sample drop is a change between consecutive readings. It does not establish a sustained brownout or a battery failure. Include enough context to inspect the voltage before and after the change, sampling gaps, and relevant status messages.

Power: confirm voltage units and inspect minimum, end value and largest drop.
IMU: inspect axis fields, units and sample counts; compare window variation with the same log's baseline.
GPS: query the recorded fix-quality fields if a GPS topic exists; otherwise mark the check skipped.
Timing and status: compare inter-message gaps with a topic's typical interval and inspect read_loggings output around the event.

PX4 timestamps are converted from microseconds into source seconds by Bagel. A reported offset such as “4.8 seconds after start” must be added to the source start before use in start_seconds or end_seconds. Keep the absolute source timestamps in the saved query results.

What the log can and cannot establish

Missing sensors, sparse logging, dropouts, firmware differences and corrupted files limit the answer. The headless demo uses fixed check rules and topic/field matching; an unsupported check is skipped. Its flags are starting points for inspection, not a diagnosis of flight safety or a proven cause.

Interactive PX4 schema inspection may fetch message descriptions from the PX4 repository. For offline inspection, pass args={"download_description": false} to each applicable MCP call; field descriptions and units then need another verified source. The headless demo already disables those downloads.

This guide covers PX4 ULog analysis. The incident example writes a reduced MCAP; it does not establish a PX4 ULog reduction writer. See the measured MCAP example for that separate workflow, or share a reproducible report from your own investigation.

Implementation references: headless demo and check rules, interactive health capability, and PX4 topic and schema handling.