Broken Loiter: loitering at wrong position, erratic loiter direction

[ThomasRigi]

Describe the bug

The drone sometimes loiters around a wrong position and doesn't respect NAV_LOITER_RAD nor the desired turning direction.

I've observed it regularly on SITL VTOLs, and I could also break it once on a SITL plane. On VTOLs it's always the first HOLD command after a transition in mission mode which fucks up. The drone either holds around Home or at next Waypoint, but not at current position as it's supposed to. Resuming mission and then triggering Hold again works fine. Even the Hold in MC mode is affected by this, if triggered after a back transition.

On a pure FW drone I don't know what it takes to break, but it's possible as well. I've had one occurrence where the drone flew to the next WP instead of Loitering at current position.

Also, if this happens, then the NAV_LOITER_RAD is ignored and the drone is just flying with max bank angle.

The bug is present in both v1.13 and current main.

To Reproduce

Steps to reproduce the behavior:

1. make px4_sitl gazebo_standard_vtol
2. Upload a mission containing a transition, e.g. the one here:
   Zurich FT loiter bug.zip
3. Launch the mission. Trigger Hold at some point after the front transition.
4. See error
5. Feel free to resume mission, trigger Hold again, and observe that it works correctly again. Then resume mission, launch a back transition via QGC interface, and Hold again -> broken again.

Expected behavior

The drone should loiter around the point where the HOLD command was sent.

Log Files and Screenshots

Log on v1.13 (roughly, our fork contains some minor changes but nothing which affects this) where the drone more or less returns home for Loiter : https://logs.px4.io/plot_app?log=f24d5c4e-b495-4d9b-93dc-b6e321beda15

Log on upstream where I consistently managed to break the logic after transitioning, even after back transitions : https://logs.px4.io/plot_app?log=4e307d13-c94a-4543-a625-3e54d88ae0b9

Log on upstream with tailsitter. Same behaviour as with standard VTOL: https://logs.px4.io/plot_app?log=f1441279-1e2f-42e1-8599-b17ff4881f19

Log on upstream on a FW plane where I managed once (on the second trigger) to break the logic, but not the first time nor any time after: https://logs.px4.io/plot_app?log=683f7ffa-58c3-4860-ae32-debca6c1433e

Log on upstream on a MC drone where I couldn't break it (not sure if nothing is broken for MC or if I just haven't found how to break it): https://logs.px4.io/plot_app?log=d2fafa11-a5fa-4bed-a6ed-108749353267

Add screenshots to help explain your problem.

I've found so far that during the Loiter which goes badly the position_controller_status/type stays at 0 instead of being the usual 2.

Drone (please complete the following information):

I haven't dared to check on a real drone yet. The following SITL models have so far found to be affected:

• gazebo_standard_vtol
• gazebo_tailsitter
• gazebo_plane

[ThomasRigi]

@sfuhrer @RomanBapst we could track it down with git bisect to this commit c13726a coming from #18834

[sfuhrer]

Thanks for the detailed report! I unfortunately couldn't reproduce it yet, do you see what I do "wrong"? (that's with current main QGC daily from October 4th, and your VTOL mission plan). I also tried it with triggering Hold right after the front transition WP or a manually triggered front transition in the Mission, so far without success.
https://user-images.githubusercontent.com/26798987/197958642-18e62679-aa15-4252-b5f9-6811ba881c75.mp4
https://review.px4.io/plot_app?log=b0fc2e70-25e9-4aeb-8b39-621f6a0eebe8

[ThomasRigi]

The difference lies in how you switch to Hold mode. Apparently it's not the same thing using the "Pause" button then slide to confirm as it is to just switch modes directly from the dropdown menu. Even though there also is a problem with using the button in my case on the second Hold: It is centered around WP 4 and not around current position. I think this is the part of the bug that I already discovered for pure FW.

When I switch to Hold directly (as I suppose would also be the case via RC or for a failsafe action), then the bug I found and described above becomes apparent (after retransitioning)

Screencast_QGC.zip

Corresponding Log: https://logs.px4.io/plot_app?log=a7e3fe44-4ff9-4c60-932e-ace69d2d4891

[sfuhrer]

Proposed the fix in #20488 , @ThomasRigi your bisect was very useful.
Could you check if that fixes the loiter issue and you don't get any new regressions?

[ThomasRigi]

Yes, it fixes the issue. Testing the same as before I didn't see any bad behaviour.