Skip to content

MAVLink: allow mission upload and clear in flight when WP mode is inactive - #1

Open
raphaelhunziker1202-stack wants to merge 1 commit into
masterfrom
mavlink-inflight-mission-upload
Open

MAVLink: allow mission upload and clear in flight when WP mode is inactive#1
raphaelhunziker1202-stack wants to merge 1 commit into
masterfrom
mavlink-inflight-mission-upload

Conversation

@raphaelhunziker1202-stack

Copy link
Copy Markdown
Owner

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.

@github-actions

github-actions Bot commented Sep 1, 2026

Copy link
Copy Markdown

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

  • maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.

  • maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.


This is an automated suggestion to help route contributions to the appropriate branch.

@github-actions

github-actions Bot commented Sep 1, 2026

Copy link
Copy Markdown

RAM / Flash usage vs. base branch — commit 0de5a51

No size baseline is available yet for this PR's base commit (no per-commit baseline has been published for it). This comment will show deltas once one exists — rebasing the PR refreshes its base commit.

Target Flash Δ RAM Δ
MATEKF405 625159 B (no baseline) 133256 B (no baseline)
MATEKF722 468515 B (no baseline) 123312 B (no baseline)
MATEKF765 646131 B (no baseline) 138768 B (no baseline)
MATEKH743 664395 B (no baseline) 139776 B (no baseline)

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.
@raphaelhunziker1202-stack
raphaelhunziker1202-stack force-pushed the mavlink-inflight-mission-upload branch from 747b6eb to 0de5a51 Compare September 1, 2026 18:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant