Motors stopped in NAV ALTHOLD + SURFACE mode

[Torchi]

The quad fell from the sky, two times.

Fw Version: INAV/MATEKF722SE 7.1.2

Quad FW:

• Matek System Optical Flow Lidar Sensor 3901-L0X Module
• Baro_hardware DPS310

Quad has flown (well) for months. I decided lately to add a 3901-L0X Module. I flew few times with this Lidar but altitude was unstable. I saw that altitude reading being reliable only below 1 meter (even if sporadically glitching, I suppose Lidar sometimes failing to get an altitude reading). Then I modified the configuration. Starting from flying config. A (diff attached) I did the following modifications to config. B (diff attached):

• enable Lidar on uart4 configuring MSP for it
• enable rangefinder e opflow on MSP
• set inav_max_surface_altitude to 100
• set nav_max_terrain_follow_alt to 80
• add NAV ALTHOLD + SURFACE modes to already existing POS_HOLD

Then I flew. First flight was ok but when manually landing in HOLD mode, once reached about 30 meters, the motors stopped and quad fell. It seems the quad presumed to have touched ground already.

So I just disabled the rangefinder and opflow (config. C, leaving uart4 configuration unmodified, diff attached).

I flew a second time. It was ok up to when I was manually landing in HOLD mode. There was no way to rise: even pushing to maximum the throttle stick, the quad slowly descended and (softly) landed.

After that, I flew a third time. Again it flew but when I was landing in HOLD mode, at about 6 meters, motors stopped. I am not sure but I think, also this time, the quad believed to have already touched ground. All three logs are attached.

INAV_7.1.2_cli_CHIMERA7_20250408_080327.txt INAV_7.1.2_cli_CHIMERA7_20250411_182823.txt INAV_7.1.2_cli_CHIMERA7_20250423_205856.txt

LOG00001.TXT LOG00002.TXT LOG00003.TXT

[breadoven]

Problem here is Surface (AGL) Altitude is never trusted other than briefly at the start of Log 1. If you're in Poshold with Terrain enabled and AGL Alt is not trusted then vertical velocity demand is simply set to a fixed value of -0.5 m/s regardless of Throttle stick position. The Throttle stick becomes locked out of altitude control. Things were made worse by the fact the Vel Z estimation was also drifting causing the erratic altitude control, i.e. it thought it was descending at 0.5m/s when in fact looking at the Baro it was probably closer to an average of 0.1m/s but sometimes drifting up as well as down.

Then finally it disarmed in flight because it thought it had landed when the Throttle was reduced to minimum which is used as a trigger to detect landing when flying in Poshold mode (there are other factors used which were also met at the point it disarmed).

I assume there's nothing to indicate Terrain isn't actually working when it's selected ? Perhaps something needs adding if that's the case. Might also make sense to prevent landing detection when Terrain is malfunctioning to prevent the issue with the Throttle stick being low.

[Torchi]

I understand from your explanation that it was the enabling of SURFACE followed by the un-trusted altitude estimation, that caused what appeared a very slow descent / float in mid air. After that, not knowing that the throttle stick was being ignored and trying to down the model, I lowered the throttle so much that the model concluded it was already grounded.

Knowing that, now I would just exit HOLD and issue ANGLE...

I have a question: on the basis that, SURFACE when Lidar gives no trustable altitude, leads to such situations, I would avoid using SURFACE, but is there any other possible way of using Lidar to hover close to the ground?

[Jetrell]

@Torchi Have a read through this wiki. Specifically from Flight modes: and below... It might help provide you some additional information.

You'll want to set nav_max_surface_altitude a good 20cm below the maximum reliable range the sensor can achieve, which is what you want to set nav_max_terrain_follow_alt to... Regardless of what the manufacturer says the sensors max range should be.

[sensei-hacker]

Note the environment where you're flying makes a significant difference in range. The manufacturer "up to range" is typically measured indoors, with the sensor pointed at a whiteboard, in a room that isn't very brightly lit.

Indoors, the ambient lighting may be about 150 lux. So the light from the sensor is competing with 150 lux. Outdoors, the sunshine is about about 50,000 lux. That makes it much harder for the sensor to see the light from the LED! Same as you can see the spot from a flashlight much easier at night than during the day.

Sunshine can vary from 1,000 when it's overcast to 100,000 at noon with no clouds, so the range will vary based on the time of day and weather. The sun is actually 100X as bright on some days than others. (Our eyes have expo).

Also, dark surfaces such as grass will give a much lower range than lighter surfaces such as concrete or light sand.

[Torchi]

Thank you all for your comments and especially thank you @jetrell for linking the wiki, it does help. May I ask why the wiki and generally documents online show about optical flow tarature the same pic, why I have another one (attached) similar but not same? I tried to make it equal but cannot. (Is the difference relevant ?)

[Jetrell]

I tried to make it equal but cannot. (Is the difference relevant ?)

@Torchi They should be similar because they're come from the same general source.. As long as the spikes are relatively mirror image, it should be okay. 0 shows the estimated optical flow rate on the x axis. While 2 shows the estimated flow coordinates on the x axis before radians to degrees conversion. And the same applies to the y axis for 1 and 3.

Differences in these logging feilds can vary due to..

• Tilting the copter on its axis too quickly, or causing too much motion across the surface of the terrain in the process.
• Poor opt flow clarity. Check the lens on the sensor is clean.
• Acc calibration on the y axis could be better.
• Or possible GNSS position validity check effecting the estimation in a bad way, if it had a weak Sat fix at the time.