ArduPilot / ardupilot

ArduPlane, ArduCopter, ArduRover, ArduSub source
http://ardupilot.org/
GNU General Public License v3.0
10.8k stars 17.26k forks source link

Copter: terrain following improvements #14204

Open rmackay9 opened 4 years ago

rmackay9 commented 4 years ago

This is a top-level issue to capture a list of all the ways that terrain following could be improved in autonomous (Auto, Guided) and non-autonomous modes (like Loiter):

Resolved issues:

AlexDutilh commented 4 years ago

Hello,

We are interested in surface tracking in AUTO mode uses rangefinder, in version 3.6 rangefinder filters are available.

Are there any advancements for re-implemented in the following versions (4.0)

thank you

chris89116 commented 4 years ago

Would it be possible initially to only activate the RNGfnd_Gain in Auto mode in order to have this option quickly? Thank you

MikeCharikov commented 3 years ago

@rmackay9

BTW it would be great to have RANGEFINDER_WPNAV_FILT_HZ not hardcoded but to have it as ardupilot parameter. It is not critical but may be good feature for users.

Here is the case:

We meet some problems with current "settings" when fly close-to-the-ground missions because rangefinder data goes to WPNAV with relatively large lag (because of filter). (BTW in logs the unfiltered data is saved so i spent some time to understand the reason of problem :) )

Our common case is to fly to survey area at 5-10-20 meters above the ground and then make descend to 1 meter above the ground (in global terrain frame). When drone descends with standard 1.5 m\s - there could be the problems. If we "set" RANGEFINDER_WPNAV_FILT_HZ to 0.8 - results are much better.

Here is SITL example of two equal lights with different RANGEFINDER_WPNAV_FILT_HZ

image

Of cause we can handle it by setting descend speed to some small value, but i think adding RANGEFINDER_WPNAV_FILT_HZ as a parameter will make overall rangefinder process more clear for interested users.

Best regards, Mike