When you fly a mission which does not have a RTL or land item and the UAV gets to the last waypoint, it will stay in auto mode. When at the end of a mission in auto mode, selecting a previous waypoint via the SET_CURRENT MAVLink message does not automatically make the drone go to that waypoint. But it does if the mission is paused (by setting flight mode to “Brake”) and resumed. This is in contrast to the normal behavior of sending SET_CURRENT while the UAV is not at the last item of the mission. In this case, the UAV will immediately go to that waypoint without any further intervention.
I was going to open up an issue on the ardupilot repository, but I am not entirely sure if this is intended behavior of the firmware. I have verified it also happens on master branch.
I think this is intended behavior. The mission state is “complete,” and the vehicle moves on to the state dictated (loiter until mode change for Copter).
Could you point me to where MIS_DONE_BHV is? I don’t see it in the param list for 4.6. Possibly a different param name? I do see MIS_RESTART and MIS_OPTIONS which might fix the problem I am running into.
I will say that, intended or not, the behavior of the vehicle not responding to SET_CURRENT when on the last waypoint causes user confusion because the vehicle is still in AUTO mode. And PX4 does the opposite where it allows this behavior.
If you plot a mission without any return or landing sequence, I would expect the vehicle to always be able to go to a previous point in the mission as long as it’s still in AUTO mode. From a GCS end, it’s difficult to differentiate when the vehicle is actively running the mission and when it isn’t if the vehicle stays in AUTO at the end.
”I think this is intended behavior. The mission state is “complete,” and the vehicle moves on to the state dictated (loiter until mode change for Copter).”
That’s the thing, the vehicle doesn’t change modes automatically. It stays in AUTO
Correct. It’s waiting for user intervention, per the documentation, and a GCS message alerts the user that the mission is complete.
I’m not suggesting that your expectation is unreasonable, but failing to meet it is not a bug, it is intentional design. Changing it is not a UI level change, but rather a firmware level change. PRs certainly welcome, and I think a change to meet your expectation would be welcome, but I also think you’d have to be the one to spearhead that effort.
The behavior you desire is also achievable now without any changes by placing a LOITER_UNLIMITED command as the last mission item.
The way the documentation reads, the design philosophy appears to be for missions to have a distinct, intentional completion state. As such, if you do not wish to culminate in RTL or LAND, it might be arguable that your mission should culminate in LOITER_UNLIMITED in order to retain an active mission state that would be responsive to subsequent mission commands from the user.
In other words, that’s the potential argument against making a firmware change to meet your expectation.
Appreciate the insight, and that makes sense to me. I’m going to look into the mission completion GCS message you mentioned because it sounds like a workaround to the issue I’m running to either way.
Looks like it behaves as I would expect if you send MAV_CMD_DO_SET_MISSION_CURRENT with “Reset Mission” set to true. When creating this post yesterday, I was referencing the old deprecated message without realizing a newer one existed. I would say this issue is resolved