I have problems using Lidar on my copter. This is SF 11/C from Lightware. I already wrote here about the issue I had during auto-mission flight when I crashed the vehicle but unfortunately that topic remained unanswered. Yesterday I was able to reproduce the issue in safe environment. So I have both TERRAIN_ENABLE=1 and TERRAIN_FOLLOW=1 and I made a test using RTL using my copter. I had the theory that the problem occurs when Lidar misses the ground and I was able to prove it during my test flight. Normally the Lidar range is 120 m but to perform a test I suppressed the sensor by obscuring its lenses with transparent sticky tape so its effective range reduced to about 40 meters. I climbed the copter to 40 meters up in Position Hold mode and hit RTL. And the issue occurred right away: instead of returning home the vehicle started to climb and at the same time I noticed the reported altitude on my OSD dropped to zero and at some point became negative! This is recorded in the attached log. At some point I arrested the climb (it seemingly was going to climb indefinitely) and landed it manually in Stabilized mode (vehicle didn’t stop to climb in Position Hold mode) to analyse the log. I attached the picture with this exact moment: in this snippet red is Lidar altitude - it goes to 130 meters which is above RNGFND_MAX_CM=12000 and means that Lidar is nonfunctional. As described in http://ardupilot.org/copter/docs/terrain-following.html in this case the autopilot should switch to Baro altimeter and consider Home Altitude as a reference point instead of terrain elevation but that was not what I see in the log. Instead there is a strange altitude source (accelerometers?) - green line showing kinda weird data around a zero at some point dropping way below zero. Blue line is barometric altitude. Could anyone explain me the data and what can I do to instruct the autopilot to use barometer in this case or at least GPS altitude?
I haven’t looked at the log, but from your post it looks like you reduced your rangefinder range on purpose but left your configuration like before… If you configured ArduPilot with a maximum range of 120m but you physically reduced the maximum to 40m, what did you expect?
I did respect it won’t climb indefinitely but at least returned back using baro altimeter when lost Lidar signal as it described in http://ardupilot.org/copter/docs/terrain-following.html .Otherwise it seems barely useful when vehicle is always in danger of uncontrollable climb any time it lost rangefinder in flight.
Let me explain what is the purpose of all of this. Documentation on Lidar SF 11/C says that its range is 120 m over a solid ground but it reduces to only 40 m over water. Previously I had a failed experiment when I’ve flown a vehicle over a pond in auto-mission when it lost control and crashed from altitude due to uncontrollable ascend when RTL was engaged. So I decider to reproduce the issue in safe environment by purposely reducing Lidar range to figure out the limits of the safe use of the copter in real flight. The results are in my post.
We have parameters for a reason - it is clear from your image that the Lidar continues to send data above the 40m so there’s no way for ArduPilot to know if that data is valid or not unless you properly configure the maximum range parameter.
I’m not saying there is no bug or possible improvement, but developers already have limited time, wasting it looking at something that is improperly configured is not worth it, in my opinion.
Lidar sends 130 m when it is out of range. That exactly what happens, regardless of the actual range, whether it 120 m or just 40.As 130 m > than RNGFND_MAX_CM=12000, it is expected that Ardupilot switches to other altitude source when it reads 130m. We can assume that any data which is less than 130m is valid, and 130 is a 'magic number indicating out of range state. About ‘improperly configured’ - as I said that happened in real flight over water - there is no guarantee that the actual range of any rangefinder will be exactly the same as it stated in specs. It depends on very many circumstances and if the copter will behave unpredictably every time it loses the signal, it would be too dangerous to use this feature at all. I;m trying to figure out the culprit. Maybe there is a safe configuration which I don’t know about.
As far as I know that only applies to the SF11 so it can’t be used in a driver that applies to other products.
Ok, I looked at your log and from a controller perspective it looks good: when rangefinder reports bad data a terrain failsafe event is fired and the RTL is re-started without using rangefinder data. What doesn’t look good is the height estimate provided by the EKF. I can’t say why, so I’ve asked @priseborough to take a look.
As far as I know that only applies to the SF11 so it can’t be used in a driver that applies to other products.
Right, but as far as I know, any range finder when looses ground reports either its maximum (or beyond) range or zero. SF11, though, can be configured to hold its last valid value but this is specifics, I guess. So, as far as I know its implemented in the controller via RNGFND_MAX_CM and RNGFND_MIN_CM so the controller knows when rangefinder is not usable either way.
What doesn’t look good is the height estimate provided by the EKF
Yeah, exactly! That’s what I suspect is a culprit as well.
You cave set RNGFND_MIN_CM to 5cm and the range finder is returning a value of 20cm when out of range, hence data is eventually accepted as valid by the algorithms. Set RNGFND_MIN_CM to a value greater than the out of range value.
