MAVLink: allow mission upload and clear in flight when WP mode is inactive - #1
MAVLink: allow mission upload and clear in flight when WP mode is inactive#1raphaelhunziker1202-stack wants to merge 1 commit into
Conversation
Branch Targeting SuggestionYou've targeted the
If This is an automated suggestion to help route contributions to the appropriate branch. |
|
RAM / Flash usage vs. base branch — commit
See RAM/flash optimization guide for techniques to reduce usage. |
… not being executed Aligns the MAVLink mission path with the MSP policy introduced in iNavFlight#10273, where setWaypoint() accepts mission uploads while armed as long as the WP mission is not actively being flown. The MAVLink handlers still carried the blanket ARMING_FLAG(ARMED) rejection from 2017 (1076fc1), so the two transports enforced different rules in front of the same shared sink. Changes: - New mavlinkMissionEditBlocked() gate used by MISSION_ITEM, MISSION_COUNT and MISSION_CLEAR_ALL: edits are refused while armed AND (WP mode active OR the mission's own RTH leg running OR the on-the-fly mission planner active). The RTH-leg term protects the land/loiter decision at home, which reads the live list; the planner term prevents two writers on the same list. The ARMED term keeps the disarmed path unchanged. setWaypoint() enforces the WP-mode rule too but returns void, so the handler-level check turns a silent drop into a proper MAV_MISSION_ERROR NACK. - While armed, MISSION_ITEMs are only accepted inside a transfer opened by MISSION_COUNT (incomingMissionWpSequence < incomingMissionWpCount); without this a single stray or duplicated item could rewrite the mission in flight. Refusals drop the half-open transaction so a stray item cannot resume it later. The Mission Planner guided-waypoint carve-out (current == 2, iNavFlight#11061) is preserved unchanged. - MISSION_COUNT with count == 0 now clears the mission and replies MISSION_ACK(ACCEPTED) per the mission protocol instead of requesting a nonexistent item; the oversized-count reply is NO_SPACE in both armed and disarmed state (previously ERROR while armed). - navigation.c: setWaypoint()'s post-upload clamp of activeWaypointIndex uses >= instead of > (the index is 0-based, so index == waypointCount is already out of range); new public isWpMissionPlannerActive() accessor. Known limitation, unchanged from the MSP path: the 9.x upload writes items one at a time into the live list, so a transfer aborted mid-way leaves an invalid partial mission until a new upload completes - the same semantics a Configurator upload over a radio link has today. The maintenance-10.x mission stack stages uploads and commits atomically; this change deliberately ports only the policy to 9.x.
747b6eb to
0de5a51
Compare
Fork-internal PR to run CI (SITL builds + unit tests + all-target compile check) for the in-flight MAVLink mission upload patch before submitting upstream. See commit message for details.