I’d like to try to sum up some points regarding this that keep coming up again and again. It would be great, if @rmackay9, @DonLakeFlyer, @Mohit_Morar and some one else would confirm, amend or correct that. Then I’ll make updates in this post
Missunderstandings:
Terrain follow has nothing to do with a rangefinder as primary source of height control. The EKF is not involved in a rangefinder’s use here. So leave all EKF parameters unchanged. Especially do not touch the often mentioned parameters like EK?_ALT_SOURCE or EK?_RNG_USE_HGT and so on.
Terrain following behaves differently when in AltHold-/Loiter modes or in Auto mode. In Auto mode, the WPNAV_RFND_USE parameter in conjunction with the TERRAIN frame setting of the waypoints (i.e. in Mission Planners planning tool) decides.
Take care of setting the rangefinder’s parameters correct, especially RNGFNDx_MIN_CM, RNGFNDx_MAX_CM and so on.
Rangefinder terrain following has nothing to do with the use of terrain data. So the TERRAIN_ENABLE parameter is irrelevant.
Rangefinder corrections are not used during Auto RTL (?).
The RNGFND_GAIN parameter is not used in Auto mode, and it seems generally somehow difficult to say what exactly this parameter does?
Issues and Whishes:
First of all, and most annoying: The terrain following with ragefinders is very choppy. Especially, for example, when a turning point of a survey grid is accidently over trees, the movement of the vehicle is very … difficult. It would be perfect, if the rangefinder’s measurements would be averaged during an travel dinstance of, maybe 1-2m?
Maybe the RNGFNDx_WSP_MAVG parameter is the the right approach, can anyone explain this parameter in detail?
qGroundControl does not support the TERRAIN frame setting in any missions except single waypoints. That makes it nearly unusable for rangefinder terrain following survey missions. I do not know, how complictated it would be to allow the terrain frame in surveys to.
I.e. my SF/11 from Lightware jumps to max height, when the measurement goes wrong. This can often be seen i.e. when flying over solar panels during inspections. In this case, the copter does a immediate failsafe RTL (with the a litte bit irritating “No Terrain Data”-FS). It would be nice, if this behavior would be configurable. “Use last Baro alt and throw a message, but proceed” or something like that. This error could be cleared if subsequent measures are valid again.
Hi Stefan
Good post and I also have a SF11 and I would also like to able even out the choppy height control in an auto mission. Sorry I haven’t been able to find any more information than you but it would be great if the Experts could?
Peter
But I do not know, for example, how often does the rangefinder reading happen? Would it be possible (only in Auto mode, to avoid unwanted side effects with prec land and so on) to use a a distance rather than a time bases avaeraging?
Have you tested differnt settings for RNGFND1_WSP_MAVG: Moving Average Range or RNGFND1_WSP_MEDF: Moving Median Filter?
Or better still does anyone have any more information on these parameters?
From your research it looks there was a ‘RANGEFINDER_GLITCH’ filter in the code that averages rangefinder altitude differences??? Looks like it has been deleted???
@findagar You might want to track https://github.com/mavlink/qgroundcontrol/issues/8839 if you want to follow along as to when QGC will support terrain frame in complex items (Survey, Corridor Scan, etc.). I started working on it today.
I would like to test but when I use the daily version of Qgroundcontrol on Android it crashes after a few seconds, it is not stable while the standard version it no problem
Land alt relative, as I’m quite sure that at the moment the RTL command doesn’t make use of the rangefinder’s terrain following; maybe I’m wrong here, or I do have a configuration problem. Or maybe, this is not intended or does not work as intended here
Here you can see very well, where the failsafe happens and what probably causes the missreadings from the SF11. The flight path at this moment was exactly above the solar panels, inclined to the south.
Maybe, someone from Lightware (@Mohit_Morar ?) can give us some insights.
I do not know, if a radar based Rangefinder would perform better in this situations.
It would be perfect, if the terrain failsafe would be configurable: not always do a “hard FS”, but ignore rangefinder and proceed with rel. alt.
Another abnormality during this flight was the short “low distance” spike here:
I’m very exausted for the first time with ardupilot. I use it for 7 years.
This week we fly 850ha (350 fields) of corn my team and me, this year crash 10 drones, yes TEN!
The ground following is not like last seasons years before.
I this not clear when the drone use terrain data or mesure from lidar, some time I send the mission (txt file generated by Mission Planner) with Mission Planner is working sometime and sometime not, same with QGC.
I try TERRAIN_ENABLE to 0 or 1 it’s not clear who it works.
I try lidar-lite v2 and v3 in i2c and in pwm and tf02 pro.
We always have this fuking FS terrain data who put the drone in RTL and up in the sky or in the power line or come back through a tree or a pylon…
The worst is sometimes the drone is just falling (fast descent) in the field on his way for the next point.
It’s random!
I also tried to preload terrain data on sd card, try to change OA_ params and use the 4.0.4rc2
I have a lot of data I’m ready to pay/donate for that but next week from 30 june we have a second fly to do 10 days to find a solution. I have logs (many logs).
Please @rmackay9 take time to read this post we can have a chat by pm about time for making that working well and an amount.
I just want than nobody have the same week than me I want to find a solution quickly. I can take time to clarify the documentation, I’m just not a dev.
