Corrrect SmartRTL internal error by preserving home srtl point

[peterbarker]

This test is expected to fail.

It's based on another PR which adds a simple, working, test for SmartRTL.

[peterbarker]

The actual test guts failing is this:

            self.change_mode('AUTO')
            self.wait_ready_to_arm()
            self.change_mode('ALT_HOLD')
            self.change_mode('SMART_RTL')
            self.change_mode('ALT_HOLD')
            self.change_mode('SMART_RTL')

[peterbarker]

The proposed fix now included here stops us from removing the home point from the list of points in the return path.

Since that home position is explicitly written to using set_home, it doesn't make sense to remove it from the path as it will never get reset.

[rmackay9]

we probably need a comment here saying why this shouldn't happen.

[peterbarker]

I've added comments in this case and the similar case below it.

[rmackay9]

I thought we always used a WITH_SEMAPHORE macro instead of writing the take and give directly.

[peterbarker]

In this case we're not taking this semaphore in a blocking fashion - we're using take_nonblocking. As we're in the main thread and the path-tidying thread can take the path sempahore for prolonged periods of time so we don't want to block.

Doing it this way does mean we have to be extra-special-careful to release the semaphore, of course.

Note that this is pre-existing. I've just moved the "take" of the semaphore to be out around all of the work the main thread is doing to ensure consistency of the path count with the pop/peek operations.

[peterbarker]

Closes #17416

[rmackay9]

@peterbarker could you rebase this? It will probably resolve this issue #17416

[peterbarker]

@peterbarker could you rebase this? It will probably resolve this issue #17416

I've pushed up a rebased version; for the most part I continuously rebase all my PRs.

I haven't looked at this branch in years, so it does need some study before merge. OTOH, the SmartRTL stuff hasn't been touch in that long either!

[rmackay9]

yeah, we should try and get this in..

[rmackay9]

@peterbarker,

It looks like there's a valid failure in the autotest to do with python cleanliness and an unused variable.

[rmackay9]

@peterbarker maybe you could rebase this again? We seem to have a new PR #28284 trying to resolve issue #22780 so maybe we should try and get this one in instead

[harsh839]

this is possibly triggering a bug in the state management of SmartRTL’s home or waypoint preservation system
we have to ensure that when the mode switches out of SMART_RTL (to something like ALT_HOLD), the system still preserves the SmartRTL's home point and waypoints in memory.