Hi all,
I had just a Crash of a Hexa (luckily for me into a soft field, so no major damage). I took of to check a few things and flew into the field gaining some Altitude as the terrain slowly rises. Soon I noticed that the Copter went much to high and reached 50m Altitude (the reason for this was not known to me, first I thought RTL Fired). So I tried to get it back to me and get to a lower altitude, but descent was terribly slow which amazed me. Suddenly it began to descend faster, so I started rising thrust again, but to no use even at full thrust it was still descending and this was accelerating. Too late I realized this and tried to switch to stabilized in order to control Thrust more directly. It already hit the ground.
Looking at the Log File I noticed that somehow the LIDAR got stuck at 40cm Altitude. Despite Baro and GPS Data being correct and showing the Right Altitudes and also those have been shown as Altitude in the OSD apparently EKF trusted the LIDAR more than the other two. Occasionally there have been Height Check Bits but only during times where there is no use.
Here is the Log: https://logs.px4.io/plot_app?log=2c1b4721-503e-49a0-adcd-6a683289622f
I have seen that I have a Vibration Problem (which is new to this frame) and I’ll exchange the mRo X2.1 with a Pixhawk v5 soon - hopefully this will reduce vibrations.
1 Like
Hi,
Do you use a Garmin lidar lite? In that case it is a classic failure of the sensor, the EKF even has some protection implemented to reduce the problem.
Either the driver has to be reworked (might help according to Garmin) or you can add logic to handle the failure case for your application.
Hi @CarlOlsson,
no this is a Lightware SF20 Lidar and I have never had any failure to date. Anyhow, I wonder why EKF sticks to the LIDAR when GPS and Baro both deviate from it. I know that it will try to follow terrain, but this would need some movement in X/Y. When the Vehicle does not move in X/Y for ex from 1:50 - 2:00 the Vehicle stood still (Pos Lock) while the Baro and GPS both rose 20 - 25m and LIDAR was at 0.4m. Then finally the Baro Reset Message was seen and the Lidar got the Check Bit.
There is a Parameter EKF2_TERR_GRAD which is set to 0.5m/m. I interpret this that LIDAR is respected if the Gradient of the Terrain is <= 0.5m change per 1m horizontal movement. So why is the Lidar respected here when there is no horizontal movement?
no this is a Lightware SF20 Lidar and I have never had any failure to date.
Ah okey, then I guess the failure can be due to something else
Anyhow, I wonder why EKF sticks to the LIDAR when GPS and Baro both deviate from it.
I haven’t used the range aid and terrain following feature but as far as I know there is no (except for the logic linked above) range sensor failure detection implemented. So the EKF uses the barometer for altitude but fuses the range sensor to estimate the terrain altitude. You can see in the log that the estimated altitude changes but the estimated distance to ground does not. (The GPS altitude is not fused at all since you use the baro as primary height source)
There is a Parameter EKF2_TERR_GRAD which is set to 0.5m/m. I interpret this that LIDAR is respected if the Gradient of the Terrain is <= 0.5m change per 1m horizontal movement. So why is the Lidar respected here when there is no horizontal movement?
No, this parameter sets the growth of the state variance with horizontal velocity. So increasing it will make the EKF trust the range sensor more if the vehicle is moving
As for EKF2_TERR_GRAD I thought that it will limit the Altitude Change if Lidar Measurements exceed this Gradient - for instance if the flight is over a House so that the Roof will not be taken into account for the Terrain Alt and the Drone would assume a constant Altitude also once the House is overflown. So it would follow a Hillslope with constant Alt over Ground, while skipping a Tree.
