Plane: support DO_RETURN_PATH_START mission item and command

[IamPete1]

Adds support for the DO_RETURN_PATH_START mission item to plane. Alternate to #28571

DO_RETURN_PATH_START is marks that the vehicle can rejoin the mission at any point after that waypoint and before a landing or a DO_LAND_START. The mission will be re-joined on the leg which is closest to the vehicles current location.

I had wanted to get rid of RTL_AUTOLAND and have a AUTO RTL mode as we do in copter. But I have not got to that yet.

[Hwurzburg]

can you explain how this differs from do_land_start? if it is used anywhere in the mission an RTL will just jump to the closest mission leg and continue? a bit confused

[IamPete1]

@Hwurzburg I did a demo for copter, at that time the waypoint was going to be called DO_LAND_REJOIN in the end we changed it to DO_RETURN_PATH_START, but the behavior is the same.

https://youtu.be/SoHXRTD0vEs?si=clwC3TLAVPJrNjNF

[peterbarker]

Adds support for the DO_RETURN_PATH_START mission item to plane. Alternate to #28571

Doesn't currently replace the functionality in that PR - doesn't force loops to be considered "done".

[tridge]

did anyone measure the CPU cost for max mission size when this went into copter?
we also have larger missions now, as can be on microsd

[tridge]

I'm a little worried about CPU usage - could we watchdog from calling this with a complex mission? might be worth measuring the CPU cost on a F4 per WP and think about max WP count

[tridge]

is this a separate bug fix? or related somehow?

[IamPete1]

Related in that the same pattern is in the new case. If the mode change failed then mission was left with force resume true. This means the next time you enter auto you will resume the mission and not restart ignoring MIS_RESTART 1 if it is set.

edit: I'm sure you spotted it but we set set_force_resume(true) before we try and change mode up on line 113

[IamPete1]

did anyone measure the CPU cost for max mission size when this went into copter? we also have larger missions now, as can be on microsd

I would note that this had been supported for longer than missions on SD card. No CPU measurement were done at the time.

First it scans the mission for DO_RETURN_PATH_START way points. That is a full scan. For each DO_RETURN_PATH_START it scans up to the next 254 way points doing the distance to leg calculation. So I guess a worst case mission is 253 waypoints. Then a DO_RETURN_PATH_START followed by a jump to the start of the mission. Mission item reads would be something like: (n - 253) * 0.5 * 254. So 4367 waypoints would be 522478 waypoint reads.

edit: DO_RETURN_PATH_START can actually have a location, so the worst case mission would actually be one full of DO_RETURN_PATH_START items. (n-254)* 253 + 252 + 251 + 250..... = 1072467

If we decide its a issue it would be quite easy to just consider the first 10 or 20 DO_RETURN_PATH_START that would then be 20 * 254 reads (5080).

[IamPete1]

@tridge I have done some testing. You totally can get it to watchdog if you fill your mission full of DO_RETURN_PATH_START way points. The threshold seems for happiness seems to be about 50 points, watchdogs at 500 or so. 50 consecutive points is 1275 waypoint lookups. The first rejoin searches the 49 remaining points, the next one 48 points ect ect.

Currently the limit is a search of 254 points per DO_RETURN_PATH_START. So 5 points to get us up to the max of 1275 points. I think were probably better to limit to a cumulative way-point lookup of 1000, so you could have DO_RETURN_PATH_START with a path of 1000 or 10 each with a path of 100.

Note that although we don't get a watchdog, we also get long loops on 4367 DO_LAND_START points.

[IamPete1]

I have added that 1000 point limit in #28608