inav
inav copied to clipboard
iNavFlight
INAV 7.1.1 Does Not Appear to Use Altitude Date Matek F405 Wing FC
Current Behavior
Altitude data doesn't appear to be processed for use in Inav 7.1.1 with Matek F405 Wing FC (only FC I've tested 7.1.1 on)
Plane flew previously with INav 7.1.0 firmware with no issues using 7.1.0 Configurator. I upgraded to INav 7.1.1 fw and all bench checks appeared to be good with blue Baro icon showing in the Configurator.
On the first Autolaunch flight after fw upgrade I set the Exit flight mode to Loiter. At launch the plane reacted as expected. When the launch terminated the plane banked to the right and I assumed it had entered Loiter mode. I notice the plane was decending and applied some up elevator and it appeared to regain altitude and maintained the bank. As I went to put on my goggles I caught the plane in a decending bank and crashing into the ground.
Review of the DVR showed the Altitude and Numeric Vario data stayed at 0 and never changed. The exit flight mode was Acro, not Loiter as set. I'm assuming Loiter didn't engage because the FC was not seeing/processing any altitude data.
Post crash bench testing shows the Baro works in the Configurator Sensors tab, but the altitude data in the OSD does not display in INav 7.1.1. I reloaded Inav 7.1.0 and the OSD altitude data displays movement when it lift/lower the FC. I reloaded 7.1.1 and no OSD altitude data displaying again.
DVR video of actual flight: https://youtu.be/DWU58eC5qEA?si=Hc-1-e6UTw3cwaJm
Steps to Reproduce
- Full erase and flash INav 7.1.1
- Set up FC from scratch
- Check Baro data in Sensors for Operation
- Enable Altitude and Numeric Vario in OSD then check for altitude readings in OSD readings (not there in my case)
Expected behavior
Expect to see OSD altitude data change with FC vertical position movement and Altitude required flight modes to activate (in OSD readings)
Suggested solution(s)
Inav 7.1.1 for (at least) Matek F405 Wing FC does not properly apply or display baro altitude data.
Additional context
version
INAV/MATEKF405SE 7.1.1 May 6 2024 / 12:09:25 (dd91a871)
GCC-10.3.1 20210824 (release)
Part of the issue here will likely be resolved by entering the following in the CLI:
set use_gps_no_baro = OFF save
That will allow it to use baro altitude.
Also, does the plane have a working GPS?
Yes, I had a working GPS on the event flight. My understanding is the use_gps_no_baro = on was to allow GPS altitude data when there is no baro or the baro fails/dies. This is how it works in previous versions of INav and it is ON by default. Turning it off sounds like INav 7.1.1. should not be considered STABLE as the default settings disable the flight modes that require altitude data...like Loiter, Altitude Hold, Waypoints, and most importantly RTH.
I did retry 7.1.1. with the use_gps... turned off and it did indeed correct the issue. Unfortunately it cost me a perfectly good plane to find it out.
Part of the issue here will likely be resolved by entering the following in the CLI:
set use_gps_no_baro = OFF save
That will allow it to use baro altitude.
Also, does the plane have a working GPS?
So what is the story here? The documentation still says: "Defines if INAV should use only use GPS data for altitude estimation when barometer is not available. If set to ON, INAV will allow GPS assisted modes and RTH even when there is no barometer installed."
This parameter should only do something when the BARO is dead or not available. Is setting this parameter to OFF a work around (to avoid issues like @vantasstic reported), when using v7.1.1 on planes? Edit: to answer my own question, yes it is. When I set it to OFF, looking at the sensors tab for BARO the blue line starts moving again. When set to ON (default) the BARO still works but the blue line ALT is stuck at 0 all the time. (Please fix this in a v7.1.2)
A BARO should always be used if available, much more accurate vs GPS alt information.
I did notice myself flying below the deck once and didn't think too much of it. Usually it is dead on exactly at 0m when landing. Now I know why, the BARO was not taken into account. Even with good sat count, ALT is not accurate.
Thanks for reporting @vantasstic I'm sorry to read it cost you a good plane. (I know the feeling.)
My understanding is the use_gps_no_baro = on was ...
That was a lot of people's understanding. Then I read the code and saw that's not actually what it does. I then tested it and confirmed. It was then further confirmed by review by another developer. I expect the setting will be removed in the next version, because what it actually does isn't useful.
Yes, I had a working GPS on the event flight.
@vantasstic But it wasn't of any use. I assume you have Arming override bypass setup.. Which is not a problem, IF you know what the requirements of arm are. Gaining 6 Satellites is only half the story. The system also requires a specific level of precision, before a 3D fix is considered obtained.. HDOP of 2.2 - 1.8. This is why the GNSS altitude reference and home location remained incorrect after arming.
I do have an Arming override in my Programming steps, but it's based of 3D speed in flight, not when sitting on the ground. I wait until I get the minimum 6 sats and the FC allows me to arm it without any sort of override.
On Thu, May 23, 2024 at 5:18 PM Jetrell @.***> wrote:
Yes, I had a working GPS on the event flight.
@vantasstic https://github.com/vantasstic But it wasn't of any use. I assume you have Arming override bypass setup.. Which is not a problem, IF you know what the requirements of arm are. Gaining 6 Satellites is only half the story. The system also requires a specific level of precision, before a 3D fix is consider obtained.. HDOP of 2.2 - 1.8. This is why the GNSS altitude reference and home location remained incorrect after arming.
— Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/10075#issuecomment-2128265838, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBLQCISSDHTESXB7KMBSKELZD2BNRAVCNFSM6AAAAABIF6T346VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRYGI3DKOBTHA . You are receiving this because you were mentioned.Message ID: @.***>
Yes, I had a working GPS on the event flight.
@vantasstic But it wasn't of any use. I assume you have Arming override bypass setup.. Which is not a problem, IF you know what the requirements of arm are. Gaining 6 Satellites is only half the story. The system also requires a specific level of precision, before a 3D fix is considered obtained.. HDOP of 2.2 - 1.8. This is why the GNSS altitude reference and home location remained incorrect after arming.
Can you explain what the 'use_gps_no_baro=on' does then and why it defaults to ON in 7.1.1? Just helps to understand what's going on/how it works.
Can you explain what the 'use_gps_no_baro=on' does then and why it defaults to ON in 7.1.1? Just helps to understand what's going on/how it works.
You can read through the issue report and reasons behind it here . The matter has been resolved. And fix in the form or a patch release may be released in the weeks a head.
Can you explain what the 'use_gps_no_baro=on' does then and why it defaults to ON in 7.1.1? Just helps to understand what's going on/how it works.
You can read through the issue report and reasons behind it here . The matter has been resolved. And fix in the form or a patch release may be released in the weeks a head.
Good information. Thank you.
Can you explain what the 'use_gps_no_baro=on' does then and why it defaults to ON in 7.1.1? Just helps to understand what's going on/how it works.
You can read through the issue report and reasons behind it here . The matter has been resolved. And fix in the form or a patch release may be released in the weeks a head.
Awesome!
The only odd thing here is that there should have been some sort of altitude estimation working off just the GPS altitude which will have been available if there was a 3D fix. When I tested this with the bug and use_gps_no_baro set to ON the altitude remained stuck at 0 until the GPS got a lock at which point the altitude started displaying. It was erratic with a constant climb rate even though the quad was static on the ground but there was some sort of altitude available.
The only odd thing here is that there should have been some sort of altitude estimation working off just the GPS altitude which will have been available if there was a 3D fix. When I tested this with the bug and
use_gps_no_baroset to ON the altitude remained stuck at 0 until the GPS got a lock at which point the altitude started displaying. It was erratic with a constant climb rate even though the quad was static on the ground but there was some sort of altitude available.
For me it did, as you can see on the OSD screenshot I posted above. The Configurator sensors tab, looking at the BARO sensor, however clearly showed an ALT stuck at zero.
OK checking the code it appears the Arming GPS check only looks at 2D position not 3D position. So it's possible to Arm with no GPS Arm blocker but actually not have a valid altitude estimation ... which doesn't seem sensible given this stops most Nav modes from working.
Good find, that explains it!
A 2D position is ofc good enough for RTH to know where it should fly to. Changing it to a 3D position before arming will take more time. In that case the trade off is, you have to wait longer before you are able to arm the craft.
OK checking the code it appears the Arming GPS check only looks at 2D position not 3D position. So it's possible to Arm with no GPS Arm blocker but actually not have a valid altitude estimation ... which doesn't seem sensible given this stops most Nav modes from working.
Good info to know. That explains why INav allowed me to arm once I got 6 satellites locked, but didn't display any altitude data. I didn't realize this as the older versions of INav allowed the baro to work from the start. Looking in my OSD before autolaunch and I'd expect to see 0 altitude...so nothing to catch my attention to wait longer before trying to fly. Maybe a setting selection would work...something like 'allow_arm_2D_Lock = on' and when off it requires 3D lock...with a default of 3D lock???
@vantasstic Don't suppose you have a log from this flight by any chance ?
@vantasstic Don't suppose you have a log from this flight by any chance ?
No I don't. I normally don't record/use log files. I guess in this case it would of been helpful though.