Describe the bug
MAV_CMD_DO_REPOSITION returns MAV_RESULT_UNSUPPORTED in commands even though it is supported. If this is read by a system then it won't be using the command.
Commander (Commander.cpp:860-883) handles it first and decides the ACK:
It checks param2 (the MAV_DO_REPOSITION_FLAGS bitmask)
If bit 0 (CHANGE_MODE flag) is not set (param2=0), Commander immediately ACKs UNSUPPORTED
If bit 0 is set, Commander switches to NAVIGATION_STATE_AUTO_LOITER and ACKs ACCEPTED
Navigator (navigator_main.cpp:344-493) also subscribes to vehicle_command and processes it independently:
When armed, it reads lat/lon/alt/speed/yaw from the command parameters and sets the reposition triplet regardless of what Commander ACKed
Line 494 even comments: // CMD_DO_REPOSITION is acknowledged by commander
The result: If you send MAV_CMD_DO_REPOSITION with param2=0 (no mode switch), you get UNSUPPORTED from Commander, but the navigator still updates the reposition setpoint if the vehicle is armed.
So the vehicle can actually move despite the UNSUPPORTED ACK.
The root cause of the bug: Commander treats "no mode change requested" as unsupported, but per the MAVLink spec param2=0 is a valid use case meaning "reposition without switching mode" (e.g., update loiter point while already in Loiter). Commander should return ACCEPTED in that case and let Navigator handle it, or at minimum return UNSUPPORTED only when the vehicle truly can't act on it.
Flight Log / Additional Information
No response
Ultimately this was the cause of needing #27543
Describe the bug
MAV_CMD_DO_REPOSITION returns MAV_RESULT_UNSUPPORTED in commands even though it is supported. If this is read by a system then it won't be using the command.
Commander (Commander.cpp:860-883) handles it first and decides the ACK:
It checks param2 (the MAV_DO_REPOSITION_FLAGS bitmask)
If bit 0 (CHANGE_MODE flag) is not set (param2=0), Commander immediately ACKs UNSUPPORTED
If bit 0 is set, Commander switches to NAVIGATION_STATE_AUTO_LOITER and ACKs ACCEPTED
Navigator (navigator_main.cpp:344-493) also subscribes to vehicle_command and processes it independently:
When armed, it reads lat/lon/alt/speed/yaw from the command parameters and sets the reposition triplet regardless of what Commander ACKed
Line 494 even comments: // CMD_DO_REPOSITION is acknowledged by commander
The result: If you send MAV_CMD_DO_REPOSITION with param2=0 (no mode switch), you get UNSUPPORTED from Commander, but the navigator still updates the reposition setpoint if the vehicle is armed.
So the vehicle can actually move despite the UNSUPPORTED ACK.
The root cause of the bug: Commander treats "no mode change requested" as unsupported, but per the MAVLink spec param2=0 is a valid use case meaning "reposition without switching mode" (e.g., update loiter point while already in Loiter). Commander should return ACCEPTED in that case and let Navigator handle it, or at minimum return UNSUPPORTED only when the vehicle truly can't act on it.
Flight Log / Additional Information
No response
Ultimately this was the cause of needing #27543