Inav: Altitude Runaway in NAV WP Mode

[MartianLocust]

Hello All! Been having some strange behavior on 5"quad in NAV WP mode regarding altitude flyaway.

Current Behavior
Created Survey Pattern in http://www.iforce2d.net/surveyplanner/ and uploaded to FC via Mission Control and sanity checked WP altitudes (100m = 10000cm).

FLIGHT SEQUENCE: ARM, takeoff, into NAV POS HOLD then NAV WP. Upon selection of NAV WP mode high rate of climb noted as expected, but didn't stop climbing at target altitude. It kept climbing. It rather caught me off guard as I had misread the OSD altitude.

Selected RTH and with the slow descent rates I had selected ran out of battery before controlled landing.

Blackbox log...
https://www.dropbox.com/s/a2uzpsagiy8ffin/LOG00002.TXT?dl=0

OBSERVATIONS:

navTgtPos[2] remains constant in NAV WP mode at "5.73m" irrespective of BARO and navPos[2] reading accurately and considerably higher.

navTgtVel[2] also remains constant in NAV WP mode at a very leisurely "0.43m/s" although the actual rate of climb was "11.83m/s" (navVel[2]).

Expected behavior

I'd expected a climb to 100m and Survey execution in NAV WP

Any ideas from you lovely people?

---

INAV/MATEKF405 2.5.1 Jun 16 2020 / 12:41:44 (098a574b3)
GCC-9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label BUG to this issue, with a confidence of 0.84. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[stronnag]

There is no WP mission loaded into volatile RAM; the BBL shows:

H waypoints:0,0

It seems like the craft is drifting and climbing at constant rate until PH then RTH is engaged. After the RTH, the craft reverts to PosHold before being put back into RTH/Land.

$ inav_modes.rb ~/dl/LOG00002.TXT 
2.5.1 using states for 2.5.0
LOG00002.TXT: INAV 2.5.1 (098a574b3) MATEKF405
Iteration   Time(s) Elapsed(s)  State
        0    250.8  (   0.0)    nav_state_undefined (0)
     7840    254.8  (   4.0)    nav_state_poshold_3d_in_progress (7)
    55936    279.4  (  28.7)    nav_state_idle (1)
   199200    352.6  ( 101.9)    nav_state_poshold_3d_in_progress (7)
   210240    358.3  ( 107.5)    nav_state_rth_head_home (10)
   342503    426.1  ( 175.4)    nav_state_rth_hover_prior_to_landing (11)
   345443    427.6  ( 176.9)    nav_state_rth_landing (12)
   414784    463.2  ( 212.4)    nav_state_poshold_3d_in_progress (7)
   486912    500.2  ( 249.4)    nav_state_rth_landing (12)
  1047088    787.4  ( 536.7)    end of log

[digitalentity]

No mission loaded in the run-time flight plan. Maybe we should fallback to RTH or PR if WP is activated without a mission?

[stronnag]

I agree that the behaviour is non-intuitive. Falling back to RTH would be consistent with current WP list initialisation and the traditional advice for clearing out a WP list.

[MartianLocust]

Awesome work @stronnag !

Going into the FC now I can load the Mission from EEPROM...

This is the Mission I just retrieved off the FC.. https://www.dropbox.com/s/9716jg9qiu2ftg3/WP%20retrieve%20from%20FC.mission?dl=0

So what did I get wrong to not get the WPs to load?

Many most awesome thanks!!!!

[stronnag]

In order to execute the WP must be in RAM (not EEPROM). You can either use a software (Configurator, mwp, DroneHelper, ezgui etc.) or a stick command (prior to arming). If you have a buzzer, it will beep twice when the mission is loaded from EEPROM to RAM. See https://github.com/iNavFlight/inav/blob/master/docs/Controls.md

[MartianLocust]

AH! Always learning. Thanks you @stronnag !

Here is an NDVI image from the appogee....

Cheers!

[stronnag]

This is the Mission I just retrieved off the FC.. https://www.dropbox.com/s/9716jg9qiu2ftg3/WP%20retrieve%20from%20FC.mission?dl=0

So what did I get wrong to not get the WPs to load?

Many most awesome thanks!!!!

Having the mission file is always helpful in triaging WP questions, you can now see the craft is just drifting (until RTH, which is well behaved).

[MartianLocust]

Case closed! Thanks @stronnag @digitalentity .

[digitalentity]

@MartianLocust @stronnag PTAL at #5997