Plan: add an ALL mission type to edit mission, fence and rally items … by Autonomost · Pull Request #3780 · ArduPilot/MissionPlanner

Autonomost · 2026-09-17T03:04:25Z

…together

The mission type dropdown on the Plan screen gains an ALL entry. In that mode the single command grid holds mission, fence and rally items at once; a row's type follows its command (RALLY_POINT, FENCE_* or anything else), so no extra columns are needed. The map draws all three sets in one overlay with type-aware midline handles, and the fence polygon tools work in this mode.

Read and Write open a small picker (Mission / Fence / Rally, all ticked by default) so one click transfers everything or any subset. Reading a subset keeps the grid rows of the types that were not fetched. Uploads go in mission, fence, rally order; a type the vehicle rejects (for example fence items on old firmware) is reported without aborting the rest.

The MAVFTP download path now updates the cache matching the item type instead of always writing the mission cache.

…together The mission type dropdown on the Plan screen gains an ALL entry. In that mode the single command grid holds mission, fence and rally items at once; a row's type follows its command (RALLY_POINT, FENCE_* or anything else), so no extra columns are needed. The map draws all three sets in one overlay with type-aware midline handles, and the fence polygon tools work in this mode. Read and Write open a small picker (Mission / Fence / Rally, all ticked by default) so one click transfers everything or any subset. Reading a subset keeps the grid rows of the types that were not fetched. Uploads go in mission, fence, rally order; a type the vehicle rejects (for example fence items on old firmware) is reported without aborting the rest. The MAVFTP download path now updates the cache matching the item type instead of always writing the mission cache.

Copilot

🟡 Changes recommended

Unresolved critical and moderate issues affect mixed-item handling and transfers.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds an ALL mission type combining mission, fence, and rally items in Flight Planner.

Changes:

Adds unified editing and type-aware map rendering.
Adds selective Mission/Fence/Rally read and write support.
Updates MAVFTP caching by item type.

File summaries

File	Summary
`GCSViews/FlightPlanner.cs`	Implements ALL-mode planning, transfers, rendering, and cache updates.
`Controls/MissionTypePicker.cs`	Adds the Mission/Fence/Rally selection dialog.

Review details

Suppressed comments (3)

GCSViews/FlightPlanner.cs:722

After a subset is selected here, the existing confirmation below still says the read will clear all existing points, while getWPs(sender, types) deliberately preserves rows whose types were not fetched. The prompt is false for the new partial-read flow and can make users cancel a safe refresh; make it conditional on all types being selected or change its wording.

                    types = MissionTypePicker.Show(this, "Read");
                    if (types == null || types.Count == 0)
                        return;

GCSViews/FlightPlanner.cs:8006

This infers the midline type from the physical row immediately before pnt2, but ALL-mode mission midlines are built after fence/rally points are filtered out. A mission edge can therefore span fence rows; dragging it sees a fence vertex at pnt2 - 2 and inserts/recalculates a fence command instead of a mission waypoint. Determine the type from the midline's tagged endpoints or attach the type when creating the marker.

                            if (midtype == MAVLink.MAV_MISSION_TYPE.ALL)
                                midtype = IsFencePolygonVertexRow(pnt2 - 2)
                                    ? MAVLink.MAV_MISSION_TYPE.FENCE
                                    : MAVLink.MAV_MISSION_TYPE.MISSION;

GCSViews/FlightPlanner.cs:850

The picker is shown only after the preflight loop above validates every grid row. In ALL mode, choosing only one type still fails on an invalid number or zero-altitude warning in an unselected fence/rally row, so the new subset write cannot ignore that type. Select the types before validation or limit validation to rows whose command type is selected.

                types = MissionTypePicker.Show(this, "Write", counts);

Files reviewed: 2/2 changed files
Comments generated: 5
Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

- Classify FENCE_HOME_CIRCLE_INCLUSION (legacy home centred fence) as a fence item so it is not uploaded as a mission command. - Reading a subset of types now says it replaces only those types instead of claiming all points will be cleared. - Ask which types to write before checking the grid, and only apply the altitude checks to rows of a type that is being sent. - Distance, gradient and bearing are computed from a mission-only list in ALL mode, so mission legs no longer span fence or rally rows and those rows are left alone. - Dragging a mission midline takes its type from the row it starts at rather than the physical row before its end, which could be a fence vertex in ALL mode. - Insert the home sentinel when the downloaded mission is empty, not only when the mission was not refreshed, so the first fence or rally row is not stripped as home. - When several types are written, a type the vehicle rejects is logged and the remaining types are still sent; the failures are reported together at the end. A single type fails as before. - MissionTypePicker takes its captions from Strings.resx so the dialog is translated like the rest of the planner.

Autonomost

Made the changes as requested.

Autonomost · 2026-09-29T03:39:01Z

@meee1 this should be good to go now

Copilot

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

Review effort: Lite
Findings: 6 · 1

Open (7)

SelectedMissionType only checks SelectedValue, but ComboBox data-binding can yield enums via… · New
These new/modified user-facing strings are hardcoded (prompt) and the partial read/write failures… · New
In ALL mode, UNKNOWN rows are treated as sending unconditionally, which can cause validation… · New
In ALL mode, UNKNOWN rows are treated as sending unconditionally, which can cause validation… · New
These new/modified user-facing strings are hardcoded (prompt) and the partial read/write failures… · New
These new/modified user-facing strings are hardcoded (prompt) and the partial read/write failures… · New
using System.Drawing; is unused in this file. Removing it avoids unnecessary dependencies and… · New

Resolved since last review (5)

ALL-mode processToScreen always removes the first item as the mission home. If a successful…
Every UploadMissionItems exception escapes the outer try, so a rejected or unsupported type…
In ALL mode wpOverlay.pointlist contains mission, fence, and rally points, but…
FENCE_HOME_CIRCLE_INCLUSION (MAV_CMD 5005) is also a fence mission item, but this classifier…
This new WinForms dialog hardcodes all user-visible text (Read, Write, Cancel, Mission,…

Files not reviewed (1)

ExtLibs/Strings/Strings.Designer.cs: Generated file

Brings the 32-bit system id work (e6454cc, 0077a89, 1517bce) so the branch merges cleanly again. Stops short of ae8c290, whose regenerated Mavlink.cs does not compile. Conflict: upstream dropped the (byte) cast on sysidcurrent in the item upload code, which this branch had moved into UploadMissionItems; the cast is dropped there instead.

- The confirmation prompt, the ALL mode hint and the two "some items could not be read / sent" messages come from Strings.resx like the picker's text, and the per-type failures use the picker's localized type names. - Before a write, a row's item type comes from MissionTypeOfRow, which reads an UNKNOWN row's command id from the Command cell's Tag the way the upload does. An UNKNOWN row of a type the user did not select is no longer validated (it used to count as being sent, so its zero altitude check could block a fence-only or rally-only write). - MissionTypePicker drops an unused using.

Found by a review pass over the whole PR before pushing: - Switching the dropdown to ALL with no mission cached deleted the first fence or rally row, because processToScreen strips row 0 as home. GetAllCachedItems now puts a placeholder in front in that case, the same one getWPs uses; it sits at 0, 0 so the "Reset Home" prompt cannot fire on it. - Dropping the first mission midline (home to waypoint 1) inserted a fence vertex whenever the row above the first waypoint was a fence vertex. The midline marker now carries the type of leg it was drawn on (writeKML: mission, addFenceMidlines: fence) and the drop uses that; the row inference and IsFencePolygonVertexRow are gone. - The Write picker ticks only the types that have rows, so a mission-only plan no longer sends an empty fence and rally, which cleared them on the vehicle. - Automatic reads (after a guided upload, on connect, from a plugin) fetch the mission only, as before ALL existed: no picker, and no fence or rally download that fails on older firmware. A full ALL read no longer parses the grid first, so a half edited cell cannot stop it; a partial read still keeps the rows of the types it does not fetch. - Home is read back once after a write instead of once per type, and the terrain prefetch covers home and the mission legs that were sent instead of every grid row. A MAVFTP upload now updates the vehicle side cache like the item by item path does, so switching the dropdown afterwards shows what was sent. - The pointlist the KML server and the 3D view read holds the mission legs only. - "Some items could not be read / sent" is shown as the message itself rather than as an unexpected error with a stack trace, and saveWPs releases giveComport in a finally. - Progress text uses the localized type names on read and write, MAVFTP's -1 progress passes through unscaled, the write validation reuses the parsed grid instead of re-reading the Command cells, the remaining raw dropdown casts use SelectedMissionType, ReCalcFence uses IsFencePolygonVertex, and the Strings.Designer comment for AllModeHint has the full text.

Autonomost · 2026-10-04T02:03:10Z

Three commits since the last review:

18bb4bc merges master up to 1517bce so the branch is mergeable again. It stops short of ae8c290, whose regenerated Mavlink.cs does not compile (every workflow on master and on every PR has been red since 2026-09-30 for that reason). The one conflict was upstream dropping the (byte) cast on sysidcurrent in the item upload code, which this branch had moved into UploadMissionItems; the cast is dropped there.
cfa1c2c answers the review: the new user-facing strings live in Strings.resx, an UNKNOWN row no longer counts as sent whatever its type (before a write it is classified by the command id in its Tag, the way the upload treats it), and the unused using is gone. The SelectedValue finding is answered on its thread: the combo is data-bound with no ValueMember, so SelectedValue is the enum item itself.
39ee73f is a second look at the whole feature before pushing, listed in its commit message. The two user-visible bugs: switching the dropdown to ALL with no mission cached deleted the first fence or rally row (processToScreen strips row 0 as home), and dropping the first mission midline after fence rows inserted a fence vertex instead of a waypoint. Also from that pass: the Write picker now ticks only the types that have rows, so a mission-only plan no longer clears the fence and rally on the vehicle; automatic reads (guided upload, connect, plugins) fetch the mission only and show no picker; home is read back once per write instead of once per type; and partial results are shown as a message rather than as an unexpected error. It also simplifies the UNKNOWN fix from cfa1c2c: the write checks take the type of each row from the parsed grid that the upload itself uses.

Built on Windows (MissionPlanner.csproj, Release). The MissionTypeOf classification is covered by unit tests in our fork, which pass.

@mission

A read or write of several item types carried on after any failure. That suits a vehicle that refuses a type, such as fence items it does not support, but not one that stopped answering: every remaining type waited out the same timeouts, and a write could start the next transfer while the vehicle was still inside the one that timed out. The mission protocol throws TimeoutException when its retries run out and a plain exception for a refusal, so a timeout now ends the read or write, and the message names the types that were skipped. A refusal still moves on to the next type. With MAVFTP on, a write went through MAVFtp.UploadFile, which ignores the results of its create and write steps. A vehicle that did not answer therefore looked like a finished upload: the write reported success and never fell back to sending the items one by one. The upload now runs those steps itself and falls back when they get no reply, so a silent vehicle ends in a timeout and one without MAVFTP still receives the items. A session reset with no answer already means no MAVFTP, so the file steps, which wait about 30 s each, are skipped then. A read already fell back when the open got no reply, by way of a null reference; that case is now handled explicitly. The three @mission paths are in one helper used by both directions, and the partial result message is built in one place.

Autonomost · 2026-10-04T02:50:15Z

One more commit, 05dc47f, from a last look at how ALL mode behaves when the vehicle stops answering:

A read or write of several types now stops at the first timeout instead of going on to the next type. The mission protocol throws TimeoutException when its retries run out and a plain exception when the vehicle refuses, so a refusal (fence items the vehicle does not support, for example) still moves on to the next type. The message lists the types that were skipped.
With MAVFTP enabled, MAVFtp.UploadFile ignores the results of its steps, so a vehicle that did not answer looked like a finished upload: the write reported success and never fell back to the item by item upload. That was already the case on master before this PR, but a write here can cover three types. The upload now runs those steps itself and falls back when they get no reply. A session reset with no answer already counts as no MAVFTP, which skips the two file steps that wait about 30 s each.

Built on Windows (MissionPlanner.csproj, Release). In our fork a test runs the upload against a simulated vehicle that keeps sending heartbeats but answers nothing: it now ends in a timeout after about 8 s instead of reporting success. Not yet tried on a real vehicle.

Switching the mission type dropdown loaded the new type from the vehicle's copy and threw the grid away, so rally points dropped in RALLY mode were gone after a look at the mission, and rows edited in ALL mode were lost on the way to any single type. The grid's rows are now kept per type when the dropdown leaves a type (all three types apart when it leaves ALL), and a type that has been shown comes back as it was, sent to the vehicle or not. A type never shown still comes from the vehicle's copy, and a read or a file load replaces what is shown as before. ALL joins the kept or cached parts in its usual order, with the home placeholder in front when there is no mission.

The dropdown's first event fires while the page is being built, and it kept the empty grid as an empty mission list, which came back as a lone home placeholder. processToScreen with a non-empty list calls Invoke, which throws before the page has a handle; the ComboBox data binding swallowed the exception, so the placeholder row stayed in the grid and quickadd was left set. Kept rows that are empty now stay empty (nothing to strip, so no placeholder), and ALL with nothing to show is empty too, which is the path the page took before rows were kept.

Autonomost · 2026-10-05T01:36:05Z

Two more commits: switching the dropdown no longer throws the grid away.

2775233 Rally points dropped in RALLY mode were gone after a look at the mission, and rows edited in ALL mode were lost on the way to a single type, because each switch reloaded the new type from the vehicle's copy. The grid's rows are now kept per type when the dropdown leaves a type (the three types apart when it leaves ALL) and come back as they were when the type is chosen again, sent to the vehicle or not. A type never shown still comes from the vehicle's copy, and a read or a file load replaces what is shown as before. ALL joins the kept or cached parts in its usual order, with the home placeholder in front when there is no mission.
cc75ba2 An empty kept list shows an empty grid. The first commit let the dropdown's constructor-time event bring an empty mission back as a lone placeholder row, and processToScreen with a non-empty list calls Invoke before the page has a handle; the ComboBox data binding swallowed the exception, which left the placeholder row in the grid and quickadd set. The fork's unit tests caught it (a FlightPlanner built in a test had an extra row); the empty list now takes the path it always took.

The keep/show helpers behind the dropdown handler are covered by unit tests in my fork: rows kept per type, the home placeholder in front of kept mission rows and none when they are empty, the ALL split and join, a type never shown coming from the vehicle's copy, and a new page starting with an empty grid.

@meee1 could you take another look?

Autonomost · 2026-10-18T20:30:33Z

@meee1 any chance you can merge this in?

meee1 requested a lite review from Copilot September 17, 2026 03:35

Copilot started reviewing on behalf of meee1 September 17, 2026 03:35

View session

Copilot AI reviewed Sep 17, 2026

View reviewed changes

Comment thread GCSViews/FlightPlanner.cs Outdated

Comment thread GCSViews/FlightPlanner.cs

Comment thread GCSViews/FlightPlanner.cs

Comment thread GCSViews/FlightPlanner.cs Outdated

Comment thread Controls/MissionTypePicker.cs Outdated

Autonomost commented Sep 17, 2026

View reviewed changes

meee1 requested a lite review from Copilot September 30, 2026 21:16

Copilot AI reviewed Sep 30, 2026

View reviewed changes

Copilot started reviewing on behalf of meee1 September 30, 2026 21:39

View session

Autonomost added 3 commits October 3, 2026 21:00

This was referenced Oct 4, 2026

Plan/Data/SITL: enter and show home, POIs and SITL start in GEO, UTM … #3781

Open

Plan: elevation graph over the bottom of the map #3813

Open

Autonomost added 2 commits October 4, 2026 21:18

Autonomost added 2 commits October 4, 2026 21:42

Merge branch 'master' into feature/plan-all-mission-type

8a39adb

Merge branch 'master' into feature/plan-all-mission-type

2115410

Conversation

Autonomost commented Sep 17, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Suppressed comments (3)

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Autonomost left a comment

Choose a reason for hiding this comment

Uh oh!

Autonomost commented Sep 29, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Copilot review overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Autonomost commented Oct 4, 2026

Uh oh!

Autonomost commented Oct 4, 2026

Uh oh!

Autonomost commented Oct 5, 2026

Uh oh!

Autonomost commented Oct 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants