# Update: Moving the Safety-Bounded PX4 AI Assistant to QGroundControl Analyze View **URL:** \ **Category:** QGroundControl\ **Created:** [September 12, 2026, 2:06am UTC](https://discuss.px4.io/t/update-moving-the-safety-bounded-px4-ai-assistant-to-qgroundcontrol-analyze-view/49488 "2026-09-12T02:06:07Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![gfLv\_amov](https://discuss.px4.io/user_avatar/discuss.px4.io/gflv_amov/32/21809_2.png) [@gfLv\_amov](https://discuss.px4.io/u/gfLv_amov)\ **Post date:** [September 12, 2026, 2:06am UTC](https://discuss.px4.io/t/update-moving-the-safety-bounded-px4-ai-assistant-to-qgroundcontrol-analyze-view/49488/1 "2026-09-12T02:06:07Z")
> **Experimental / Unofficial / PX4 only:** This update describes work on a development branch. It is not an upstream QGroundControl feature or a flight-safety authority. This is a detailed follow-up to [Building a Safety-Bounded AI Flight Diagnostic Assistant in QGroundControl](https://discuss.px4.io/t/building-a-safety-bounded-ai-flight-diagnostic-assistant-in-qgroundcontrol/49228). The original post remains available as a record of the MAVLink Console prototype. ## Why the direction changed A QGroundControl maintainer commented that the concept looked interesting, but that it did not belong inside MAVLink Console. The important point was architectural: MAVLink Console is PX4-only, while a QGroundControl feature should have a clearer product boundary. The suggested direction was a dedicated Analyze page. The current branch now implements that direction: - The assistant is a dedicated **AI Flight Diagnostics (PX4)** page under Analyze Tools. - MAVLink Console is again a standalone Console tool. - Common conversation and context handling are separated from firmware-specific diagnostics. - Phase one deliberately registers only a PX4 provider; it does not claim ArduPilot support. ## New Analyze experience ![AI Flight Diagnostics Analyze page](https://discuss.px4.io/uploads/default/original/3X/0/6/067abc2c3de177c5b3f5d2f9155b7da0663ed131.png) The new page presents the connected firmware, armed/flight state, link state, and available diagnostic data. It contains the conversation, question input, Ask, Cancel, Clear, Settings, and a local approval card for gated MAVLink data requests. PX4 Console text is now optional evidence, not an implicit data source. A collapsed attachment area accepts text only when the user deliberately pastes it. The page explains that the attachment will be sent to the selected AI service, sends only the final 12,000 characters, and clears the attachment when the session is cleared or the active Vehicle changes. The request boundary is explicit for each connection state: | State | Can ask? | Local Vehicle tools | | --- | --- | --- | | Supported PX4 Vehicle connected | Yes, when an AI service is configured | Available under the local safety policy | | Non-PX4 Vehicle connected | No; rejected before any AI request | Disabled | | No Vehicle, no attachment | No | Disabled | | No Vehicle, explicit attachment | Yes, for attachment-only analysis | Disabled | ## Refactored architecture and context contract ![Updated QGroundControl AI diagnostic data flow](https://discuss.px4.io/uploads/default/original/3X/5/f/5fbc7aab1c9cb07526ecd39920bb864d58106aa7.png) The original Console-oriented controller has been split into four responsibilities: - **AIDiagnosticController** coordinates the QML conversation, request lifecycle, cancellation, approval, service selection, and local tool execution. - **AIDiagnosticContextBuilder** creates a versioned QGroundControl snapshot containing core Vehicle state, sensor summaries, health and arming checks, link state, FactGroups, batteries, provider evidence, and the explicit Console attachment. - **AIDiagnosticProvider** defines the firmware-diagnostic extension boundary. - **PX4DiagnosticProvider** implements PX4 eligibility, external-vision evidence, parameter and Console policies, question routing, the MAVLink data-message whitelist, and PX4-specific prompt semantics. The context contract starts at `schemaVersion: 1`. Missing evidence is represented as unavailable or unknown instead of being turned into a guessed fault. Future context changes can therefore be reviewed as changes to an explicit interface rather than as untracked prompt text. ## Two AI service paths and the data boundary ![AI Assistant settings](https://discuss.px4.io/uploads/default/original/3X/8/d/8d83522d748626de79bb54616d3552936e2e13e1.png) The two service paths remain intentionally different: 1. **OpenAI-compatible Chat Completions:** QGroundControl sends the versioned context and a fixed structured-tool registry. A model may propose a tool call, but QGroundControl validates the tool name, arguments, bound Vehicle, state, whitelist, and call limits locally. 2. **ChatGPT through the local Codex App Server:** QGroundControl sends the supplied context and receives answer text. This path is started read-only and does not expose QGroundControl local tools or approval actions. Depending on availability, the versioned context may contain Vehicle identity and firmware, armed and flight state, mode and readiness, position, sensor and battery summaries, health/arming checks, link counters, FactGroups, relevant loaded PX4 parameters, provider-generated evidence, limited conversation history, and Console text explicitly attached by the user. This does not remove the remote service’s own data-handling terms. Users should still remove secrets, identifiers, internal addresses, and unrelated Console output before sending a request. ## Safety boundary retained and tightened ![PX4 provider and local safety checks](https://discuss.px4.io/uploads/default/original/3X/f/0/f0ec8833144e11f13db9455472f1bb80655dae36.png) The assistant cannot arm, disarm, move, take off, land, change modes, write or reset parameters, calibrate, reboot, run actuator tests, edit missions, or execute arbitrary shell or MAVLink commands. The OpenAI-compatible path exposes only a fixed diagnostic registry: - Current QGroundControl state, FactGroups, health, link status, and loaded-parameter reads are in-memory and read-only. - Restricted PX4 Console diagnostics use a command whitelist and a per-question call limit. - `MAV_CMD_REQUEST_MESSAGE` and temporary `MAV_CMD_SET_MESSAGE_INTERVAL` are limited to whitelisted telemetry messages and always require explicit user approval. Vehicle-side Console and MAVLink requests are rejected when the PX4 Vehicle is armed, flying, or communication is lost. Each request is bound to the Vehicle that was active when it started. Switching, disconnecting, or destroying that Vehicle cancels the request and clears pending approval, preventing a delayed result or approval from being applied to another Vehicle. ## Settings compatibility The settings interface is now named `AIAssistantSettings`, and QML uses `aiAssistantSettings`. A temporary `aiConsoleSettings` alias remains for compatibility. The underlying QSettings group is still `AIConsole`, preserving the endpoint, model, API key, ChatGPT model selection, and legacy fields from the earlier prototype. ## Source and build availability - Source branch: [ai/mavlink-console-assistant-v5.0.8](https://github.com/amovlgf/qgroundcontrol/tree/ai/mavlink-console-assistant-v5.0.8) - Analyze-view feature commit: [`823585e0e02aca598f7f8c35bbb9a6161aeab766`](https://github.com/amovlgf/qgroundcontrol/commit/823585e0e02aca598f7f8c35bbb9a6161aeab766) - Current branch HEAD: [`5f869595db94f35c0a30bfdd5a1cb211a91e4fcd`](https://github.com/amovlgf/qgroundcontrol/commit/5f869595db94f35c0a30bfdd5a1cb211a91e4fcd), a later Linux launcher input-method fix that does not change the AI diagnostic architecture. There is currently **no prebuilt experimental package containing the Analyze-view implementation**. The existing [`v5.0.8.1-ai.1`](https://github.com/amovlgf/qgroundcontrol/releases/tag/v5.0.8.1-ai.1) package was built from [`e561057133ffeb9d735710758c11fb6320ffbe09`](https://github.com/amovlgf/qgroundcontrol/commit/e561057133ffeb9d735710758c11fb6320ffbe09) and contains the older MAVLink Console prototype. It should not be used to evaluate the new Analyze page. ## Verification status The Analyze-view change adds automated coverage for: - The dedicated Analyze page, AI settings page, and standalone MAVLink Console page - Versioned attachment-only context - Legacy settings storage and the compatibility alias - PX4 versus non-PX4 provider eligibility - Parameter-name, Console-command, and MAVLink-message whitelists - External-vision routing and confirmed, invalid, unavailable, and unknown evidence semantics - Vehicle switching and stale asynchronous-event isolation - Codex App Server client protocol behavior The bilingual VitePress documentation build has been rerun successfully for this update. PX4 SITL is the intended manual acceptance environment for status, parameters, external vision, approval, cancellation, Vehicle switching, armed/flying state, communication loss, and attachment-only analysis. A compatible application runtime still needs to rerun the focused unit tests, Debug build, and the full SITL matrix before a new binary is offered. This update therefore describes the implemented coverage without claiming a newly verified release. ## Scope and questions for the community ArduPilot is intentionally outside phase one. The provider boundary leaves room for a separately designed implementation, but adding a firmware label without equivalent evidence semantics, safety checks, ownership, and tests would not be meaningful support. The feedback that would be most useful now is: 1. Does the dedicated Analyze-page layout provide the right balance between conversation and structured Vehicle health? 2. Is the boundary between common QGroundControl context and PX4-specific provider evidence clear enough? 3. Is a versioned context contract a useful basis for reviewing what data can be sent to an AI service? 4. Are the explicit attachment and data-boundary notices sufficient, or should a request preview and redaction step come first? 5. Which additional PX4 diagnostic scenario has evidence semantics clear enough to implement and test next? Feedback on the Analyze workflow, provider abstraction, data contract, privacy boundary, and local safety policy would be very helpful. ---
**Author:** ![yigitcan-ozturk](https://discuss.px4.io/user_avatar/discuss.px4.io/yigitcan-ozturk/32/22039_2.png) [@yigitcan-ozturk](https://discuss.px4.io/u/yigitcan-ozturk)\ **Post date:** [October 5, 2026, 2:07am UTC](https://discuss.px4.io/t/update-moving-the-safety-bounded-px4-ai-assistant-to-qgroundcontrol-analyze-view/49488/2 "2026-10-05T02:07:19Z")
This is moving in a strong direction, especially the explicit distinction between **unknown** , **unavailable** , **invalid** , and confirmed evidence. For the next PX4 diagnostic scenario, I would suggest one where the assistant has to reconstruct a **time-ordered failure chain** , rather than classify a single current-state fault. A useful first case could be: **estimator degradation → control response → mode/failsafe transition** The important part would be to preserve the evidence timeline explicitly: `observation timestamp → estimator innovation/state change → control response → mode/failsafe event` and require the assistant to distinguish: - earliest observable divergence - downstream symptoms - confirmed evidence - missing/unavailable evidence - inferred hypothesis I would also consider adding an `evidence_provenance` field to the versioned context contract so each diagnostic fact can carry its source, timestamp, freshness/age, and confidence/availability state. That would make it easier to review not only _what_ was sent to the AI service, but also _why that evidence should be trusted_. A PX4 SITL acceptance test could then inject a controlled sensor or estimator fault and verify that the assistant identifies the correct first relevant divergence rather than only the final failsafe. If useful, I’d be happy to sketch a small validation matrix for that scenario. ---
**Author:** ![gfLv\_amov](https://discuss.px4.io/user_avatar/discuss.px4.io/gflv_amov/32/21809_2.png) [@gfLv\_amov](https://discuss.px4.io/u/gfLv_amov)\ **Post date:** [October 9, 2026, 2:36am UTC](https://discuss.px4.io/t/update-moving-the-safety-bounded-px4-ai-assistant-to-qgroundcontrol-analyze-view/49488/3 "2026-10-09T02:36:05Z")
Thanks @yigitcan-ozturk — reconstructing a time-ordered failure chain would be a useful next diagnostic scenario. I especially appreciate the emphasis on separating the earliest observable divergence from downstream symptoms. The context described in this update is primarily snapshot-based. Supporting this scenario would require timestamped evidence history and explicit handling of gaps and stale data. I would also want the assistant to distinguish the first observable anomaly from a confirmed root cause, and keep causal hypotheses clearly labeled. The `evidence_provenance` suggestion fits well with the versioned context contract. I’d explore recording the source, observation timestamp and time basis, freshness, and availability/validity state for each diagnostic fact. That should also help avoid mixing observation time with the time QGC received the data. For an initial SITL case, I’d start with a controlled sensor fault and compare the assistant’s reconstruction against the recorded evidence. The acceptance criteria could cover: - Identifying the earliest relevant divergence supported by the available evidence. - Tracing the subsequent estimator, control, and mode/failsafe events where those are observed. - Explicitly reporting missing evidence and uncertainty when the chain cannot be established. Fault injection would belong to the test setup, with the assistant retaining its existing diagnostic-only boundary. I’d appreciate your sketch of a small validation matrix. A suggested initial fault, the minimum evidence needed, and the expected behavior when some evidence is unavailable would help define a manageable first case. ---
**Author:** ![yigitcan-ozturk](https://discuss.px4.io/user_avatar/discuss.px4.io/yigitcan-ozturk/32/22039_2.png) [@yigitcan-ozturk](https://discuss.px4.io/u/yigitcan-ozturk)\ **Post date:** [October 9, 2026, 4:43am UTC](https://discuss.px4.io/t/update-moving-the-safety-bounded-px4-ai-assistant-to-qgroundcontrol-analyze-view/49488/4 "2026-10-09T04:43:26Z")
Hi Tom, Thanks for the thoughtful response. I agree that a controlled sensor fault is a good starting point, and that the assistant should remain strictly diagnostic-only. Here is a proposed small validation matrix for the first SITL iteration: | Case | Scenario | Minimum evidence | Expected assistant behavior | | --- | --- | --- | --- | | V01 | Controlled sensor fault | Timestamped sensor observations, estimator outputs, vehicle status and relevant events | Identify the earliest evidence-supported divergence and reconstruct subsequent observed events | | V02 | Stale or delayed observations | Source timestamps, QGC reception timestamps, freshness and validity metadata | Distinguish observation time from reception time and flag stale evidence | | V03 | Missing evidence interval | Available ULog records, sequence continuity and explicit data gaps | Report the missing interval and avoid reconstructing unsupported transitions | | V04 | Ambiguous causality | Sensor, estimator and control-state history | Separate observed anomalies from causal hypotheses without asserting an unverified root cause | **Suggested initial test: V01** Inject a controlled sensor fault in PX4 SITL and preserve the corresponding ULog as the reference evidence. The assistant should: 1. Identify the earliest relevant divergence supported by the recorded observations. 2. Reconstruct subsequent estimator, control, and mode/failsafe events only where the evidence supports them. 3. Preserve event ordering using the appropriate timestamp domains. 4. Explicitly identify missing evidence, stale observations and causal uncertainty. 5. Avoid presenting the first observable anomaly as a confirmed root cause. For `evidence_provenance`, I suggest a minimal per-fact contract containing: - Source identifier and evidence reference - Observation timestamp and time basis - Reception timestamp, where available - Freshness or age - Availability and validity state - Associated uncertainty or evidence limitation One important acceptance criterion is that the assistant must not invent intermediate events when the evidence history contains gaps. For evaluation, we could compare the assistant’s output with an independently reconstructed reference timeline from the SITL logs, checking event ordering, first-divergence identification, evidence references, and uncertainty handling. This would provide a reproducible first case without expanding the assistant beyond its existing safety boundary. Happy to help refine the initial case and its acceptance criteria. Best regards, Yiğitcan Öztürk PAMILANGA LIMITED ---
**Author:** ![gfLv\_amov](https://discuss.px4.io/user_avatar/discuss.px4.io/gflv_amov/32/21809_2.png) [@gfLv\_amov](https://discuss.px4.io/u/gfLv_amov)\ **Post date:** [October 16, 2026, 8:15am UTC](https://discuss.px4.io/t/update-moving-the-safety-bounded-px4-ai-assistant-to-qgroundcontrol-analyze-view/49488/5 "2026-10-16T08:15:19Z")
Hi Yiğitcan, Thanks for putting together this matrix. V01 looks like a manageable starting point, and the distinction between the earliest observable anomaly and a confirmed root cause is especially important. For the first iteration, I’d use the recorded SITL evidence to establish a reference timeline independently of the assistant’s output, then evaluate event ordering, first-divergence identification, evidence references, and uncertainty handling. The fault-injection time should be recorded separately from the first observable divergence. The minimal `evidence_provenance` fields you suggested also make sense. Moving beyond the snapshot-based context described in this update will require explicit timestamp domains and evidence history. Where timing cannot be reliably aligned or observations are missing, the assistant should preserve that uncertainty and leave unsupported parts of the chain unresolved. Could you suggest a specific sensor fault for V01, along with the minimum logged signals needed to observe its effects? It would also help to identify which downstream estimator, control, or mode changes we should expect under the chosen SITL configuration. Once that baseline is reproducible, V02–V04 would provide focused extensions for testing delayed data, missing intervals, and ambiguous causality. Fault injection would remain part of the test setup, with the assistant retaining its diagnostic-only role. Thanks again for helping turn this into a concrete validation case. ---
**Author:** ![yigitcan-ozturk](https://discuss.px4.io/user_avatar/discuss.px4.io/yigitcan-ozturk/32/22039_2.png) [@yigitcan-ozturk](https://discuss.px4.io/u/yigitcan-ozturk)\ **Post date:** [October 16, 2026, 9:04am UTC](https://discuss.px4.io/t/update-moving-the-safety-bounded-px4-ai-assistant-to-qgroundcontrol-analyze-view/49488/6 "2026-10-16T09:04:49Z")
Hi Tom, Thanks for the detailed response. I agree that V01 should establish an independent reference timeline before evaluating the assistant’s interpretation. For the first reproducible case, I suggest a controlled GPS data-loss scenario in PX4 SITL. **V01 — Single-GPS measurement stream interruption** **Test configuration** Use a fixed PX4 SITL version and vehicle configuration with one GPS source, EKF2 providing the position estimate, and no alternative horizontal position source. Start from a stable, healthy GPS state with valid local position estimation. **Fault injection** At a recorded time `t_inject`, stop the GPS measurement stream without deliberately changing the vehicle mode or estimator configuration. Keep the exact injection method and PX4 parameters in the test record. **Minimum evidence** I would capture: - `sensor_gps`: measurement timestamps, update continuity and available quality indicators. - `vehicle_local_position`: position validity, timestamps and estimator output. - Estimator status information: available fusion, innovation and fault indicators for the selected PX4 version. - `vehicle_status`: navigation-state transitions. - `failsafe_flags` and `vehicle_control_mode`, where available, to distinguish estimator effects from control and failsafe responses. The exact message fields should be confirmed against the PX4 version used for the test. **Reference timeline** Build the expected event timeline from the recorded SITL data independently of the AI assistant: 1. `t_inject` — the fault is introduced. 2. `t_last_gps` — last valid GPS measurement. 3. `t_divergence` — first independently observable anomaly. 4. `t_estimator` — first relevant estimator validity or fusion-state change, if observed. 5. `t_mode` — first control-mode, navigation-state or failsafe change, if observed. These timestamps should not be assumed to coincide. **Expected downstream behaviour** The immediate observable effect should be the absence of new GPS measurements. Any subsequent estimator validity change, position discontinuity, control-mode transition or failsafe response must be determined from the actual configuration and log evidence, not assumed in advance. If no downstream mode change occurs within the observation window, that should be recorded as a valid observation rather than treated as a missing result. **Assistant evaluation** The assistant should identify the first supported anomaly, reconstruct the event order, cite the relevant logged evidence and distinguish observations from possible causes. It should not infer an exact fault-injection time from incomplete telemetry or claim a confirmed root cause solely because GPS updates stopped. If timestamps cannot be aligned or required observations are absent, the corresponding parts of the causal chain should remain unresolved. I would keep V01 strictly diagnostic-only and use the resulting independently reviewed timeline as the baseline for V02–V04. Once you confirm the PX4 version, SITL vehicle model and GPS fault-injection mechanism, we can freeze the signal list and expected observable transitions for this case. Best regards, Yiğitcan Öztürk PAMILANGA LTD