io.github.furkanisikay/ardupilot-mcp

Run the full deterministic diagnostic suite over an ArduPilot .bin log (or a ground station's .tlog). A .tlog is the telemetry the ground station received: a few Hz, the primary sensor and EKF core only, and gaps where the radio link dropped. Checks that would read a link dropout as a vehicle fault (log integrity, timing) are skipped on it; prefer the onboard .bin when the user has it. Returns severity-ranked findings (each with concrete evidence AND official ArduPilot doc links), per-check results, a plain-language summary, and `guidance`. Read the cited references for the log's firmware version, call `vehicle_profile` for the airframe's physical configuration, and fold in any real-world details the user gives — then explain and cite sources. Every finding is grounded in the log; do not invent causes beyond them.

What changed between two logs of the same vehicle ("it flew fine last week")? Lists configuration parameters that differ (separately from values the autopilot learns/counts itself), parameters present in only one log, the firmware change, and flight metrics side by side (vibration, hover throttle, battery/board voltage minimums). Differences only — it does not judge which side is right. By convention A is the earlier/good flight and B the later/bad one.

A Markdown reply to paste into a discuss.ardupilot.org thread: vehicle and firmware, what went wrong first (onset and impact), the findings with their corroborating log records, and a small text plot of the data behind each one. It contains no GPS positions and is returned as text (nothing is written to disk). Review it with the user and add what they saw before they post it.

Parameter values recorded in the log's PARM dump. ``name_glob`` is a case-insensitive glob, e.g. 'INS_HNTCH_*'. Includes `total` (full param count), `metadata_url` (version-specific definitions to interpret values), and a `note` if the snapshot looks incomplete (truncated log) — in which case ask the user for their exported .param file and read it with `load_param_file`. `documented` gives each returned param's documented range, units, listed values and bitmask bits for the log's firmware (bundled, offline); a value outside the documented range or list is not necessarily wrong (some defaults, e.g. 0 = disabled, lie outside). `undocumented` names params that release does not document.

What went wrong first, and what followed: the onset (first anomaly while armed), the impact (crash check, crash disarm, or the log ending while armed), and every firmware verdict, error, failsafe mode change and finding in time order, each tagged before_onset / onset / after_onset / impact / after_impact. Use it to answer "what failed first, and is the rest just the crash?". Time order only — never causation.

List the registered diagnostic checks (the extensible catalogue).

Decoded ERR/MODE/EV/MSG timeline. ``kinds`` filters families (ERR, MODE, EV, MSG); times are seconds.

Load a user-exported ArduPilot parameter file (.param / .params). The authoritative *complete* configuration — use it when the log's PARM snapshot is truncated/incomplete, or to compare the flown config (get_params) against the user's current/intended config. ``name_glob`` filters. ``firmware`` (e.g. 'ArduCopter V4.6.3', from the log's log_summary) attaches the documented metadata and lists names that release does not document (typos, script or other-firmware params).

Cheap orientation: vehicle, firmware, duration, message counts, flight modes, max altitude, integrity.

Numeric time series for a message type and fields, for drilling into a finding. Multi-instance messages (VIBE/IMU per IMU, GPS per receiver, MAG per compass, BAT per battery, XKF* per EKF core) are returned one instance at a time: pass ``instance`` (default: the first one; see ``available_instances``). Values are aligned with ``times_s`` by index. Downsamples (decimates) to at most ``max_points`` points.

Advisory tuning recommendations (harmonic notch from the batch sampler, a fast IMU, the in-flight FFT or ESC RPM; PID; autotune). Recommendation ONLY — never applied.

Physical / architecture profile of the aircraft inferred from the log. Frame class & type, motor count, battery cells/capacity, and — the key physical insight — the hover throttle and resulting power margin / thrust-to-weight. Use this to reason about the craft physically and to combine with real-world details the user gives (weight, prop diameter, motor KV, wind).