This report covers a command path that returns success even though the requested critical transition does not occur.
Tested environment:
ArduPilot SITL: ArduCopter, based on official Copter-4.5.7
Tested commit: 4f065e2ae9150ba8663728fb21898acb83c157ea
Parent commit / official tag: 2a3dc4b7bf2507120f7378a7b2fde73185e0c325 (Copter-4.5.7)
MAVLink: MAVLink 2, ardupilotmega dialect
A. ACK return-value completion or missing-executor failures
A1. MAV_CMD_SOLO_BTN_FLY_HOLD: success ACK is returned even when arming is rejected
Reproduction summary:
With GPS disabled, ArduCopter repeatedly reported PreArm: GPS 1: Bad fix. Sending MAV_CMD_SOLO_BTN_FLY_HOLD returned MAV_RESULT_ACCEPTED, but the following heartbeat remained unarmed and the log reported Arm: GPS 1: Bad fix.
Expected behavior: If the requested arm/takeoff/land transition is rejected, the command should report failure.
Actual behavior: The command reports success while the critical transition did not occur.
Impact:
Automation that relies on the ACK can believe the vehicle is executing a critical transition while the vehicle remains unarmed.
Suggested fixes
Propagate the result of the underlying arm, takeoff, land, or mode-transition operation back to the MAVLink command ACK.
Return a failure result when a requested critical transition is rejected by arming or EKF checks.
Add a regression test that exercises the command with failed pre-arm checks and verifies that the ACK is not MAV_RESULT_ACCEPTED.
All of the SOLO_BUTTON handling always returns MAV_RESULT_ACCEPTED, regardless of state change. If I had to guess, the rationale is that it positively acknowledges the button press, even if it had no tangible effect.
You should either create a PR against ArduCopter/GCS_MAVLink_Copter.cpp, which may have farther reaching consequences than just your application, or you should check specifically for the expected state change after issuing the message.
If you are managing state via bespoke MavLink autonomy, I’d suggest that the SOLO_BUTTON message series are a poor mechanism, and you should instead issue commands that are specific to the desired behavior.
If this is just an AI generated bug report, then I suppose it is duly noted, but I’m not sure any action is warranted.
Thanks for the explanation. I understand the rationale that MAV_RESULT_ACCEPTED may mean that the SOLO_BUTTON event was accepted, not necessarily that the requested vehicle state changed.
For context, this report was not posted directly from AI. The candidate was identified by an analysis tool used in my paper, and I manually reproduced and checked this specific behavior in SITL before posting. The text was edited for clarity by AI, but the attached result/logs are from the manual verification.
If the intended contract of SOLO_BUTTON is only “button event received”, then I agree this may be better treated as a documentation/API-semantics issue rather than a flight-control bug. In that case, the important point for integrators is that callers should not infer successful state transition from MAV_RESULT_ACCEPTED, and should verify the resulting vehicle state or use more specific MAVLink commands for the desired behavior.
I don’t understand the motive for this topic. If you aren’t even using the messages, why use a scraper to point out what amounts to non-existent issues?