From my tests the rangefinder is not supported by Arduplane 3.8.4 in Auto mode and I doubt that even in Land mode despite “engage” messages in the log file the Lidar is really used
Well it is a BIG limit of Arduplane , if you need to fly close to the ground you cannot rely on Baro or Gps height.
About Lidar used during Land mode, I have some doubts since it seems that EK2_RNG_USE_SPEED1 , will prevent the use of Lidar when airplane speed is above 6 m/s.
The more simple is to use a companion computer (rpi) and develop tools to correct navigation or send trigger like RTL when ground (from lidar) is too close from UAV.
Terrain following is working well in US due to high level data (30m resolution) but all around the world it’s not that kind of detail and we have only tiles at 90meters resolution. You could estimate detail or accuracy by dividing by 3. 30m resolution are available all around the world, but not in Mission Planner. It needs to be downloaded apart and integrated as third party terrain.
Well it is really hard to do at low altitude. You should think about the risk. Plane cannot stop and change altitude the way a quad can. Or fly as slow. You would need all kinds of forward sensors for it to be even remotely safe.
Even in the wilderness a simple tree would cause a crash. Not to talk of gutter and ridges.
I am of course not refering to the RTL rafety feature/use as kikislar is inferring, but rather wanting to fly at 2m AGL as luca would like.
A simple gust at such altitude could mess up your program for good.
Of course 2 meters is a quite extreme low altitude , but since Lidars nowadays have a very good performance and an affordable cost why do not implement Lidar as primary height source while in auto mode ?
It would permit a very precise altitude flight in the range of the Lidar , so from 1 to 100 meters .
About precision terrain following , I think that a mission at constant higher altitude could map the terrain heights underneath and then update the terrain course used by the autopilot.
Final step th emission at low altitude with precision terrain following .
Good point. Usually those range values can be overridden. I’ll have to try it sometime. I’m just wondering if it only works in auto mode with “relative” or “terrain” waypoints. I also wonder how it would be handled by FBWB parameters. Considering it’s feeding into the EKF as an altitude reference, I wonder if it would send EKF off of its rocker on slopes. Maybe it just disregards other altitude sources. I don’t know, but it would be great to test.
I think I’ve seen that speed parameter brought up in discussion elsewhere - probably in regards to landing faster than 6m/s. I’ll have to find it.
Optical flow navigation reference for “Setting 1” make me think that as EK2_RNG_USE_SPD , those parameters and the controller strategy comes directly from Arducopter.
Lidar range is limited, so if you have a SF11/C plan a fly @250m AGL and above a hill lidar module find that there is 30meters between aircraft and ground, this parameter will do nothing.
If you fly higher than your lidar module is able to measure, these parameters could not be use.
Idea is to increase mission safety (particularly in uneven terrain) by keeping a more even height between the drone and the ground. It’s needed on mountain.