Plane: option to allow plane to crosstrack on all mission items

[timtuxworth]

When a mission is interrupted, by default in Plane it will never crosstrack (i.e. get right back on the defined mission path) when the mission is resumed.

I am working on object avoidance script that diverts the plane from the mission based on rangefinder readings of real obstacles, while running long missions on fixed wing planes with magnetic sensors attached. For those sensors, being "on track" is essential to getting correct data for the client, so getting back on track after the obstacle is mission critical.

The code to do this is already in ArduPilot, there is an existing plane.auto_state.next_wp_crosstrack boolean value, but it is only ever set to true when first starting the mission and not set on resume. This PR adds MIS_OPTION bit that sets the next_wp_crosstrack value to true for every new waypoint, which does a much better job of following the required path.

Tested in SITL.

[timtuxworth]

Could you take a look please @IamPete1 @peterbarker ? Just some feedback on the basic concept to start.

[IamPete1]

I don't think this really does what you want. It does not cross track between the legs of the of the mission when its interrupted. It crosstracks between the location where auto was re-entered and the next mission item.

For example with out:

With:

So I don't really see how this helps with following the mission, you still have to line it up manually and make sure you re-enter at the correct point. If your having to do that anyway all you need to do is yaw to face the next waypoint and both methods are the same

If I manualy wait for the vehicle to line up before entering auto I get this:

Without:

With:

[timtuxworth]

Here's my before/after - pretty clearly showing the behavior the partner wants to see.
MIS_OPTIONS = 0

MIS_OPTIONS = 8

[timtuxworth]

Here's an example where the mission was interrupted by my obstacle avoidance Lua script on it's way to WP 18 with a 15 km/hr crosswind.
MIS_OPTIONS = 0

MIS_OPTIONS = 8

It's better @IamPete1, but I guess I must admit, it's not as good as I was hoping for.

[IamPete1]

I think if you were to track the mission items in your script you would be able to do a significantly better job. If you get on the mission line, and point towards the next point then you don't need this change. It might be that we need some new bindings to make that easier, but that is better than adding options that don't really solve the problem.

[timtuxworth]

I think if you were to track the mission items in your script you would be able to do a significantly better job. If you get on the mission line, and point towards the next point then you don't need this change. It might be that we need some new bindings to make that easier, but that is better than adding options that don't really solve the problem.

I'm pretty sure that's what I'm doing. Note that the crosstrack code here

ardupilot/ArduPlane/navigation.cpp

Line 323 in 0e7a5ef

auto_state.crosstrack &&

will not crosstrack if you are closer than WP_LOITER_RAD * 3, so that might be why your test case doesn't seem to work. [My Lua script is setting the loiter radius to a very small value].

[tridge]

this won't work for cases where we reset prev_WP_loc, for example, Mode::entry() always resets that variable, so changing to GUIDED then back to AUTO won't get what I think you're after.
maybe a vehicle:set_crosstrack_startloc(loc) binding to allow the set of the prev_WP_loc from a script
and maybe a get_crosstrack_startloc(), would return nil if not crosstracking

[timtuxworth]

You suggested in the dev call yesterday @tridge something like this PR shouldn't be necessary unless there was an existing bug in cross tracking. After the call, I re-ran my tests multiple times and I'm thinking there might be a bug, because this code for "always crosstrack" as a mission option definitely shows different (and better) cross tracking behavior than the existing code. I have a 15km/h crosswind for this test.

Here's a log with 2 flights of the same mission. The first is my PR, the second is existing behavior (MIS_OPTIONS = 0) - it's chalk and cheese!
https://www.dropbox.com/scl/fi/0dl1fqbbvg2m7zt0ygx6e/00000020.BIN?rlkey=68t5gxocawin089jqr1tkyorq&dl=0

With MIS_OPTIONS = 0 (basically existing behavior)

With MIS_OPTIONS = 8 (forcing cross track on every waypoint):

[IamPete1]

I think this would be better to be re-oppend in a new PR. The existing discussion and testing is no longer relevant.

[timtuxworth]

I think this would be better to be re-oppend in a new PR. The existing discussion and testing is no longer relevant.

I'm not totally convinced, my testing still shows a problem, but I've made it draft for now.

[IamPete1]

I'm not totally convinced, my testing still shows a problem, but I've made it draft for now.

What I mean is the title of the PR is "Plane: option to allow plane to crosstrack on all mission items", the discussion and testing were all of that proposed mission option. However, if you look at the changed files they add scripting bindings for setting cross track start points. If you push the original mission option change back then feel free to leave it open. But as it stands the discussion and files changed are two completely different things, so its just confusing.

[timtuxworth]

Got it - at very least I'll split them.

[timtuxworth]

I think this would be better to be re-oppend in a new PR. The existing discussion and testing is no longer relevant.

Here it is: #27759