Closed ThomasRigi closed 2 years ago
@sfuhrer @RomanBapst we could track it down with git bisect to this commit https://github.com/PX4/PX4-Autopilot/commit/c13726af66e73d5664d158e8824ff8287e4f1b70 coming from https://github.com/PX4/PX4-Autopilot/pull/18834
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
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)
Corresponding Log: https://logs.px4.io/plot_app?log=a7e3fe44-4ff9-4c60-932e-ace69d2d4891
Proposed the fix in https://github.com/PX4/PX4-Autopilot/pull/20488 , @ThomasRigi your bisect was very useful. Could you check if that fixes the loiter issue and you don't get any new regressions?
Yes, it fixes the issue. Testing the same as before I didn't see any bad behaviour.
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:
make px4_sitl gazebo_standard_vtol
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: