search

iNavFlight / inav

INAV: Navigation-enabled flight control software
https://inavflight.github.io
GNU General Public License v3.0
3.14k stars 1.47k forks source link

Failsafe RTH sometimes doesn't work. #4327

Closed tiriad closed 5 years ago

tiriad commented 5 years ago

Current Behavior

After continuing to test version 2.1 RC2 continued to experience problems in the RTH, the steps to follow to reproduce the error are, armed and flight start in ANGLE, ACRO (manual mode), run the FS-RTH and fail. As seen in the video the arrow pointing home is always pointing in the right direction. Subsequently active the POSHOLD works correctly and to start FS-RTH works perfectly, attached DVR video. I think its correction is important before the final version before goes out if there really is a bug.

<img src="http://img.youtube.com/vi/kEFMnTI74Zs/0.jpg" alt="FS" width="240" height="180" border="10" /> https://youtu.be/kEFMnTI74Zs

DIFF https://pastebin.com/Tdp2ZsqX

https://youtu.be/glNb3gESNPY

------

Another day another flight

https://youtu.be/_LV5jqjGSzI

LOG: https://1drv.ms/t/s!ApZg0bgutSkzglD4iJ5DL1KGcofK

giacomo892 commented 5 years ago

Do you have a blackbox log?

tiriad commented 5 years ago

Do you have a blackbox log?

Not this time, the next time I'm gonna try to get a blackbox in flight another day.

krzysztofmatula commented 5 years ago

You are engaging FS with a switch, right? Long time ago I remember it didn't work for me either, however when engaged by switching off the transmitter it worked as it should. Since then I simply no longer have FS on a switch and I test it by switching off the transmitter. Did you use the switch-FS on previous versions?

tiriad commented 5 years ago

You are engaging FS with a switch, right? Long time ago I remember it didn't work for me either, however when engaged by switching off the transmitter it worked as it should. Since then I simply no longer have FS on a switch and I test it by switching off the transmitter. Did you use the switch-FS on previous versions?

Yes, I have it placed in a stick and I use the failsafe as RTH, since version 2.0 I had it like this and it has always worked for me. FS fails both ways from stick or no radio signal. https://youtu.be/glNb3gESNPY

tiriad commented 5 years ago

I was able to try something else and I think it only happens in acro mode, in angle it doesn't happen and only with acro an the FailSafe mode, however if I activate the RTH mode from a stick it works correctly. Could it be that it doesn´t force to use the angle mode when you activate the failsafe rth?. Seeing the data in the blackbox log when I activate the FailSafe and it fails me the phase 3 appears, failsafe phase landed, and when I quit it, failsafe phase idle, it could be a failure on the phases of the failsafe probably that are not the ones that correspond

giacomo892 commented 5 years ago

If you have the log. Please post it @tirad

tiriad commented 5 years ago

If you have the log. Please post it @tirad

@giacomo892

Here's to see if we can get something clear

LOG: https://1drv.ms/t/s!ApZg0bgutSkzglD4iJ5DL1KGcofK

https://youtu.be/_LV5jqjGSzI

From second 17 to 50 the failsafe fails

stronnag commented 5 years ago

Here's the various state transitions from the log:

 inav_modes.rb /t/inav-contrib/logfs.TXT 
logfs.TXT: INAV 2.1.0 (7bdd5967e) OMNIBUSF4V3
Iteration   Time(s) Elapsed(s)  State
        0     26.4  (   0.0)    nav_state_undefined (0)
    14304     33.7  (   7.4)    nav_state_poshold_3d_in_progress (7)
    14528     33.9  (   7.5)    nav_state_idle (1)
    30179     41.9  (  15.6)    F/S=RETURN_TO_HOME (1500,1501,1500,1371);(1,1)
    30179     41.9  (  15.6)    nav_state_rth_head_home (10)
    70228     62.7  (  36.3)    nav_state_emergency_landing_in_progress (23)
    72130     63.6  (  37.3)    F/S=IDLE (1500,1568,1500,1372);(1,1)
    72130     63.6  (  37.3)    nav_state_idle (1)
    78900     67.1  (  40.8)    F/S=RETURN_TO_HOME (1500,1500,1497,1434);(1,1)
    78900     67.1  (  40.8)    nav_state_rth_head_home (10)
    93996     74.9  (  48.6)    F/S=IDLE (1500,1567,1500,1435);(1,1)
    93996     74.9  (  48.6)    nav_state_idle (1)
    97888     77.0  (  50.6)    nav_state_rth_head_home (10)
   124000     90.5  (  64.1)    nav_state_idle (1)
   157472    107.7  (  81.4)    F/S=RETURN_TO_HOME (1500,1501,1500,1402);(1,1)
   157472    107.7  (  81.4)    nav_state_rth_head_home (10)
   195687    127.5  ( 101.2)    F/S=IDLE (1500,1552,1500,1401);(1,1)
   195687    127.5  ( 101.2)    nav_state_idle (1)
   238409    149.6  ( 123.2)    F/S=RETURN_TO_HOME (1500,1501,1499,1431);(1,1)
   238409    149.6  ( 123.2)    nav_state_rth_head_home (10)
   256489    158.9  ( 132.5)    F/S=IDLE (1499,1567,1500,1430);(1,1)
   256489    158.9  ( 132.5)    nav_state_idle (1)
   274464    168.2  ( 141.8)    nav_state_rth_head_home (10)
   291904    177.2  ( 150.8)    nav_state_idle (1)
   315183    189.2  ( 162.8)    F/S=RETURN_TO_HOME (1499,1500,1500,1407);(1,1)
   315183    189.2  ( 162.8)    nav_state_rth_head_home (10)
   352433    208.5  ( 182.1)    F/S=IDLE (1500,1551,1500,1406);(1,1)
   352433    208.5  ( 182.1)    nav_state_idle (1)
   484340    276.5  ( 250.2)    end of log
Disarmed by: SWITCH

And, for what it's worth, is a graphical reconstruction, https://youtu.be/CW4pCPLEYks . The mwp compass anomaly checker is conservative and naïve; however, were it my machine, I'd want to understand why it is kicking in (maybe the machine is being flown sideways?).

digitalentity commented 5 years ago

This looks like a classic compass issue. Before engaging in long-range flights where you might need RTH, make sure POSHOLD is reliably working with quad facing all directions.

A simplest flight test is to enable POSHOLD and slowly (over a timespan of a minute) do a 360 yaw. Quad should maintain it's position steadily regardless of heading. If it's not - it's a compass issue - either calibration or interference.

tiriad commented 5 years ago

Sorry to disagree, poshold works, return to home works, failsafe makes mistakes, take a look at the videos carefully, the response that gives me interference is the easiest way to explain it, when I active failsafe it turns to my but the quad is static, another thing that happens is that if I activate any assisted mode, subsequently the failsafe works relatively well

digitalentity commented 5 years ago

@tiriad I found some weird data in the log, but it's not detailed enough. I've located the most likely place where error manifests and built a 2.1.0-RC2 + some verbose debug so we can collect more information.

inav_2.1.0_OMNIBUSF4V3.hex.zip

Please flash it, set set debug_mode = GENERIC and try catching the bug in the logs again. This time we'll collect much more information from the velocity controller which I believe is misbehaving. TIA

digitalentity commented 5 years ago

I have a solid theory on what was happening:

Sequence of events:

  1. Pilot takes off
  2. At +7 seconds pilot briefly activates POSHOLD
  3. Speed at that point is ~3m/s
  4. Braking mode controller happily armes NAV_CRUISE_BRAKING_BOOST state
  5. We DONT SEE THAT in BB log because: a) BB[stateFlags] field is 8 bit while NAV_CRUISE_BRAKING_BOOST is bit 13 (https://github.com/iNavFlight/inav/issues/4333) b) BB[flightModeFlags] is 32 bit, but BOXBRAKING is bit 36 (not so trivial to fix)
  6. Pilot disengages POSHOLD
  7. Pilot activates RTH via FAILSAFE. Speed at that point is about 10m/s AWAY FROM HOME
  8. We are now in FLIGHT_MODE(FAILSAFE_MODE), so braking controller doesn't get called and never gets the chance to reset NAV_CRUISE_BRAKING_BOOST (https://github.com/iNavFlight/inav/blob/development/src/main/navigation/navigation.c#L2729-L2731)
  9. Speed is large and boost code in VelXY controller happily boosts our response
  10. While we decelerate and approach zero speed we hit a bug in braking code in VelXY controller: a) If speed is <= braking_boost_speed_threshold, boostFactor is ZERO (https://github.com/iNavFlight/inav/blob/development/src/main/navigation/navigation_multicopter.c#L422-L432) b) Our roll/pitch response is dampend as we decelerate towards braking_boost_speed_threshold c) The whole thing balances out at a steady rate of 2.4m/s away from home (with wind)
  11. RTH failsafe triggers via 50m safety threshold and enters emergency landing
  12. Pilot aborts
  13. Same repeats for second attempt of RTH via FAILSAFE
  14. Now pilot engages RTH manually
  15. We are no longer in FLIGHT_MODE(FAILSAFE_MODE) when we enter navigation controller a) Braking mode controller finally is called and gets a chance to disengage NAV_CRUISE_BRAKING_BOOST
  16. We are no longer affected by a bug in VelXY boost controller and RTH executes normally.
tiriad commented 5 years ago

@digitalentity the explanation makes all the sense and I was able to check it and is especially dangerous when you are in mc braking mode and there is failsafe. I collected new data, first of all I flash the verbose debug version , and I have captured the bug in two cases, one when there is a flyaway in failsafe, related with this case #4228: https://1drv.ms/t/s!ApZg0bgutSkzglKm2tDn35Xq8-II At seconds 70, 173, 290

Another when in failsafe the quad stands still: https://1drv.ms/t/s!ApZg0bgutSkzglHqw8Q4iDCtdUQQ At seconds 28, 155, 185, 229

Next time I'll try the version with fixed code

tiriad commented 5 years ago

I have tested the new version with the fixed code and I have not found any bad behavior in poshold mode combined with mc braking mode and failsafe so we can consider this problem fixed. Congratulations for the quick localization of the bug and its correction, good work