Inav not using rangefinder for distance estimation.

[Tiim12312]

Current Behavior

I am using a n MATEK Optic Flow / Lidar CX-OF + VL53L0X sensor with Inav 6.1. I have configured everything correctly for using Althold with this sensor. The Althold feature worked correctly. No events happened to quad. Now when entering althold it only uses the barometer for altitude estimation. I can open the sensor tab and see the sonar sensor changing appropriately when i manually move the quad up and down. When I arm I get no warnings. I reduced the weighting of the barometer to 0 and confirmed it thinks its getting no data from the lidar unit and even though it enters althold with no errors does not maintain any hold. How can the sensor produce completely normal looking values in the sensors tab but then not be used for altitude estimation during flight?

Steps to Reproduce

Expected behavior

I expect if the sensors tab shows completely normal sonar data for it to be able to use the sonar data for altitude estimation.

---

version

INAV/MAMBAH743_2022B 6.1.1 Jun 13 2023 / 11:20:13 (42ced253)

GCC-10.2.1 20201103 (release)

[sensei-hacker]

The rangefinder measures the shape of the ground, and is used for Surface mode.

Use Surface mode if you want to follow the shape of the ground, diving into ditches and going up over hills. That uses the rangefinder.

The red line in the image is maintaining barometer / gps altitude (MSL). The yellow line is maintaining rangefinder distance to the ground (AGL), which is surface mode.

[Tiim12312]

I understand what the different modes and modifiers are. Nav althold and surface modifier WERE working properly for many flights. My problem is that suddenly the range finder altitude is not being used in the althold altitude estimation even though it is showing in the sensors tab as normal and all configuring stayed the same and I'm at a loss on how to troubleshoot this given I get no errors and the data seems fine based on the sensor tab.

[sensei-hacker]

suddenly the range finder altitude is not being used in the althold altitude estimation

Are you in SURFACE MODE alt hold?

If so, check the setting for maximum rangefinder distance.

[Tiim12312]

Are you referring to this parameter?

nav_max_terrain_follow_alt

is this in mm or cm?

[Tiim12312]

I am in Nav ALTHOLD and SURFACE modifier. I first arm the quad and then switch to these modes. Is there any sort of debugging or logging i can do to see why it doesn't use the rangefinder?

[breadoven]

Check the log file for: flightModeFlags - should say ALTHOLD and SURFACE navTgtPos[2] - should be the same as the value of nav_max_terrain_follow_alt(which is in cm) navPos[2]- should be reading the distance from the ground as measured by rangefinder navTgtVel[2] - should increase as navPos[2] diverges from target set by navTgtPos[2] navFlags- check it shows ALT_TRUSTED

[Tiim12312]

Thank you for the info. The flight mode flags are correct. The rangefinder seems to be reading correctly until it gets out of its max range which is 2m. At a certain point in the flight it just throttles straight upwards and once the drone goes above 2m it the AGL trusted flag goes away. Attached is the blackbox log. The sequence that I'm doing is this, Arming the quad, while still on the ground switching to nav althold and surface. Then ramping throttle up to mid throttle and staying there. This exact sequence worked flawlessly for months of testing. I'd think that if I had a bad sensor it wouldn't read properly ever. blackbox_log_2024-01-26_165114.TXT

[Tiim12312]

In analyzing the log more it seems that my rx refresh rate drops very low right before the incident(I am controlling this via SBUS from another microcontroller) and then for some reason the quad goes above the 2 m range of my rangefinder and loses that measurement. Then it reacts by going full throttle upwards, presumably to some predefined safe altitude somewhere. This does not seem like safe behavior at all. My failsafe behavior is set to land at 1100us throttle and its definitely not doing that. In either case, losing RX signal or losing rangefinder signal the behavior should not be to full throttle up like this. Any ideas on what target its trying to reach?

[breadoven]

The problem is the estimated vertical velocity is screwed up. On arming it goes -ve, probably because of ground effect from the prop wash, then ends up with a negative offset after AltHold/Surface is selected even thought the estimated vertical position is static or increasing. Other than this the control demand seems to be working correctly up to the point the rangefinder drops out ... target velocity is +ve when below the target altitude and -ve when the target altitude is exceeded. But it can't control properly because the estimated vertical velocity is wrong, i.e. it thinks it's descending when it isn't in fact. It skyrockets because the estimated vertical velocity becomes even more negative than the -ve target velocity demand causing the motors to rev up to try and reduce the excessive (false) descent rate.

Not sure what the issue is although poor vertical velocity estimations are often vibration related (doesn't seem to be the case here until it skyrockets). I also noticed your PID settings for Baro/Sonar/Altitude in the Log header file look odd, much higher than expected. A Diff file would be useful to understand what settings you've changed. And it appears you aren't using a GPS ?

[Tiim12312]

Thank you for looking at the log file! Yes I am not using GPS as this is indoors. Attached is the output from diff all. My PID settings are copied directly from the matek 3901 rangefinder docs I'm using although I'm sure they were made on a much earlier version of Inav. Should I be switching to althold once in flight? Are there settings for resetting this vertical velocity offset? diffall.txt

[Tiim12312]

Would turning air mode and lowering my arming throttle help in this situation as well?

[Tiim12312]

Is there any way to prevent the instant throttling up when the AGL Trusted flag goes away in the case of the rangefinder going out of its effective range? I'd rather it initiate failsafe procedures then full throttle obviously.

[breadoven]

Is there any way to prevent the instant throttling up when the AGL Trusted flag goes away in the case of the rangefinder going out of its effective range? I'd rather it initiate failsafe procedures then full throttle obviously.

It throttles up because the estimated vertical velocity is wrong. It's actually setting a target vertical velocity of -0.5m/s, i.e. descend, but the estimated vertical velocity is -6 m/s so it throttles up to try and reduce the velocity to the target which actually caused it to climb. It's never going to work properly until the issue with the false estimated vertical velocity is resolved.