Remove multicopter autonomous flight offtrack logic#26047
Remove multicopter autonomous flight offtrack logic#26047
Conversation
It was added at a time where the triplet target was directly fed as position setpoint to the controller. Since the smoothing improvements to FlightTaskAuto(SmoothVel) and removing the previous "aggressive" FlightTaskAuto variant there should be no need anymore for this logic. It can sometimes lead to unexpected sideffects. E.g. the vehicle would suddenly change direction when exceeding some arbitrary threshold.
a79b651 to
97eb75f
Compare
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: -656 byte (-0.03 %)]px4_fmu-v6x [Total VM Diff: -656 byte (-0.03 %)]Updated: 2026-01-30T14:22:56 |
|
I am in favor of this! |
Was previously set to the current setpoint. However, when we are re-entering a mission, we have a valid previous setpoint.
…ission Rejoin logic should be consistent with what was previously done in offtrack
|
Thanks a lot @mahima-yoga !! 🎉
That's exactly what I thought. As long as Navigator provides the waypoints and we can't request them (more simple mission interface) it should populate the previous waypoint when continuing the mission. But I wasn't sure how easy that is. Your described examples look perfect. Things I'd like to find out in review:
|
It cannot be stored in |
…ring a mission" This reverts commit e051d83.
This additional logic handles edge cases where we are either behind the previous_setpoint, or ahead of the current_setpoint.
|
I have two questions to this after looking into it for this issue: From my side looking into obstacle avoidance, I find it undesirable to go directly back to the closest point, like shown in the comment from @mahima-yoga. |
It was reverted because this commit introduces a much smaller change that achieves the same result |



Solved Problem
Since the beginning of FlightTaskAuto covering the navigator triplet interface for most autonomous multicopter flight there's the "offtrack" logic which made sure nothing too bad happens if the vehicle is too far away from the line between two waypoints or overshoots the goal waypoint.
See e.g. 6e62beb
This logic duplicates much of the position/velocity smoothing trajectory planner, which is a coarse path following logic. Now the offtrack logic can lead to unexpected behavior and regularly problems which are hard to debug. Last issue with hacky workaround for reference: #25725
Solution
Remove the offtrack logic and test that the corner cases still work fine because the trajectory generation does better path tracking than the offtrack logic.
Changelog Entry
Test coverage
Testing the corner cases in SITL SIH:
The vehicle slows down when it gets far from the line but no sudden jerky unexpected movements anymore.

The vehicle does not come back to the line but rather directly heads to the next waypoint. Remains to be fixed.
