Codecov Report

❌ Patch coverage is 0% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 32.42%. Comparing base (f29efd3) to head (f2f0630).
⚠️ Report is 188 commits behind head on master.

❌ Your patch check has failed because the patch coverage (0.00%) is below the target coverage (30.00%). You can increase the patch coverage or adjust the target coverage.

@@            Coverage Diff             @@
##           master   #14345      +/-   ##
==========================================
+ Coverage   25.47%   32.42%   +6.95%     
==========================================
  Files         769      781      +12     
  Lines       65912    67227    +1315     
  Branches    30495    31147     +652     
==========================================
+ Hits        16788    21796    +5008     
+ Misses      37285    30732    -6553     
- Partials    11839    14699    +2860     

Build Results

Platform Status

All builds passed.

Pre-commit

Pre-commit hooks: 0 passed, 0 failed, 0 skipped.

Test Results

linux-coverage-integration: 35 passed, 0 skipped
linux-coverage-unit: 111 passed, 0 skipped
Total: 146 passed, 0 skipped

Code Coverage

Coverage: 68.9%

No baseline available for comparison

Artifact Sizes

_{Updated: 2026-07-24 21:37:19 UTC • Commit: f2f0630 • Triggered by: Android}

I don't see how this works. You set the current sequence number to 1. But what if that is pointing to a takeoff item? To me this just requires manual control from the user. Manually pick the right point they want to restart from by clicking on the item. And start the mission. All this special stuff just seems doomed to failure.

I don't see how this works. You set the current sequence number to 1. But what if that is pointing to a takeoff item? To me this just requires manual control from the user. Manually pick the right point they want to restart from by clicking on the item. And start the mission. All this special stuff just seems doomed to failure.

Good point. My current implementation is too error prone. I'll look into making it more similar to how the "set current waypoint" is done

@DonLakeFlyer I updated the implementation so that the "Restart Mission" is a checkbox option with "Set Current Waypoint" which only shows if the vehicle firmware supports MAV_CMD_DO_SET_MISSION_CURRENT.

I also updated the PR description above

Also confirmed the "Restart Mission" checkbox doesn't show on PX4 which does not support it. 👍

I continue to not be thrilled with all of this. It all seems like an error prone hack which should be handled by the firmware side. Why isn't this a fix in the firmware so you can move the last waypoint? Isn't this working around a vehicle side problem?

I continue to not be thrilled with all of this. It all seems like an error prone hack which should be handled by the firmware side. Why isn't this a fix in the firmware so you can move the last waypoint? Isn't this working around a vehicle side problem?

I initially thought this was a vehicle-side issue as well, which is why my first implementation attempted to work around it. However, I did more research, and now I don't see it as a hack or workaround for a vehicle-side bug. My understanding is that this is the intended use case of MAV_CMD_DO_SET_MISSION_CURRENT.

ArduPilot sets the mission state to MISSION_STATE_COMPLETE if you have reached the last waypoint. ArduPilot supports the newer MAV_CMD_DO_SET_MISSION_CURRENT command which explicitly has a "Reset Mission" flag which is intended to be set to true if you wish to go to a previous waypoint but the mission state is complete. PX4 does not currently support MAV_CMD_DO_SET_MISSION_CURRENT and uses MISSION_SET_CURRENT instead which does not have a "Reset Mission" flag and is less explicit about mission resetting. From the QGC perspective, the checkbox is simply exposing an existing capability provided by the firmware and MAVLink protocol rather than implementing custom restart behavior.

That said, I am open to other ideas and hearing your thoughts on it. We don't have to expose a checkbox in the UI for this.

Ok, I understand now. I'll think some more about this when I get back in town. I'll be gone till start of July.

@jnomikos Did you test multi-rotor and fixed wing? ardupilot FW differs in a bunch of it's mission code

Also note that even when restart mission is false ardupilot will reset jumps counters if the mission is complete when you set the new waypoint

After staring at this I'm still not super thrilled with the extra UI complexity but there doesn't seem to be any other decent solution. Thanks for this @jnomikos. If you've also tested with FW then I'll merge.

After staring at this I'm still not super thrilled with the extra UI complexity but there doesn't seem to be any other decent solution. Thanks for this @jnomikos. If you've also tested with FW then I'll merge.

I have not tested with fixed wing yet. I'll do that

After staring at this I'm still not super thrilled with the extra UI complexity but there doesn't seem to be any other decent solution. Thanks for this @jnomikos. If you've also tested with FW then I'll merge.

I'm on the same page, and I agree it makes the UI needlessly complex. The only other solution I can think of is automatically setting "restart mission" when changing current waypoint when you particularly have reached the last waypoint of a mission. But, the drawback of that is it makes the behavior of "set current waypoint" more implicit. I mentioned that idea in the original PR here: #13934 (comment).

But, now that you mention that the jump counters are always reset if you are on the last waypoint (I was not aware of that), I think the implicit solution may be more favorable, as it would not affect the user interface at all.

@rubenp02 do you have any insights?

I think the implicit solution may be more favorable

I tried coding that. And ran into the fact that it means that whenever you change the waypoint the mission automatically restarts. Which isn't always expected. I tried a pile of different options and what you have was the worst of multiple evils.

I think the implicit solution may be more favorable

I tried coding that. And ran into the fact that it means that whenever you change the waypoint the mission automatically restarts. Which isn't always expected. I tried a pile of different options and what you have was the worst of multiple evils.

Oh yeah good point, I forgot about that

Sorry, I may be a bit out of the loop on this. What would be wrong about a simple "Restart Mission" guided action? Given that this isn't strictly related to changing target waypoint. Yes, it's sometimes handy when doing that, but it can always also be done quite quickly right afterwards with an action, no? And if conditional mission logic is a concern, you can perhaps achieve what you want by doing the reset before changing the target waypoint, instead.

To me at least, this is enough of an advanced feature that I don't think it warrants any additional UI complexity or compromises in UX: It can afford to be slightly less automatic as long as the functionality itself is accessible.

Again, sorry if I'm missing anything obvious, please fill me in if that's the case.

@jnomikos Did you test multi-rotor and fixed wing? ardupilot FW differs in a bunch of it's mission code

@DonLakeFlyer You're right that fixed wing behaves differently. When texting with fixed wing SITL, the vehicle automatically goes into RTL mode and circles around the home position if you plot a mission without a landing sequence. When in this RTL mode, setting current waypoint with the "restart mission" checkbox does not make the vehicle automatically start flying the mission again. Instead you have to pause the mission first and then continue mission.

So, in short, with this current solution, due to differences in behavior on fixed wing, the end result is still pretty confusing. I am considering if there are any UI state updates to the guided actions controller we could make that would solve the issue on the fixed wing side without regressing copter.

Sorry, I may be a bit out of the loop on this. What would be wrong about a simple "Restart Mission" guided action? Given that this isn't strictly related to changing target waypoint. Yes, it's sometimes handy when doing that, but it can always also be done quite quickly right afterwards with an action, no? And if conditional mission logic is a concern, you can perhaps achieve what you want by doing the reset before changing the target waypoint, instead.

To me at least, this is enough of an advanced feature that I don't think it warrants any additional UI complexity or compromises in UX: It can afford to be slightly less automatic as long as the functionality itself is accessible.

Again, sorry if I'm missing anything obvious, please fill me in if that's the case.

It was an option that was considered, and the initial direction I took this PR before modifying it. Originally, my implementation was a "Restart Mission" guided action. However, we ended up going the direction of manually choosing the point to restart to. One of the main reasons, if I recall correctly, was because the first waypoint of a mission is not always at the same index, depending on firmware.

#14345 (comment)

Honestly, I wish I could just go in and change the MAVLink spec on this. 😢

This is all getting ridiculously complicated.

My opinion:

• Whatever this ends as I don't see it going into 5.1. It's too late for such insanity.
• I'm unconvinced there is a reasonable way to fix this problem without either firmware side changes and/or spec changes

* I'm unconvinced there is a reasonable way to fix this problem without either firmware side changes and/or spec changes

At this point, I agree with you and I think closing this PR is probably the best move.

I am a bit uncertain on next steps. The problem is that ArduPilot already shipped firmware using the new message with this behavior. I am thinking of adding in issue in MAVLink about this, and discussing ways we can improve it in the future.