Q_planes and LIDAR

Okay, parameter documentation has me confused about when I can expect the LIDAR to be used, if at all.

I want Lidar to be used in 1) landing, and 2) MC mode to compensate for baro and GPS drift, but I’m not sure what params to set to make that happen.

RNGFND_LANDING =1 ---- I suppose this only works for plane landings not Quadplane VTOL_Land commands (or Q_Land mode) can anyone clarify?

EK2_ALT_SOURCE=1 ----- seems to require optical flow (which I don’t have, or want) to incorporate LIDAR?

And

EK2_USE_HGT ---- seem to require EK2_ALT_SOURCE=1?

If this is true, what is it this way? I can’t think of any reason to require optical flow to use LIDAR. This seems like an easy fix for a big problem. From a VTOL plane perspective LIDAR data on landing seems pretty important considering how we affect pressure on landing (like a quad).

@WickedShell we talked on this at Interdrone, your insight here would be appreciated.

Lidar for landing makes sense, however using lidar as your primary height source is a bad idea. I’ve been a part of a couple of discussions about this in the past, but it mostly boils down to being for a very limited set of use cases. EK2_ALT_SOURCE 2 will use the GPS for height, and is a good way to compensate for baro drift.

RNGFND_LANDING does get used in quadplane landing code, it’s primarily only used for dictating what altitude to switch to the slower descent rate.

I can’t speak to EK2_USE_HGT at all, I’ve only ever changed my altitude source.

Copy, is there some reason that these altitude sources are not all blended together to ID things like baro error?

It seems that lidar data, if available, should be worked into qplane landing better, specifically as it relates to the z-pos controller, maybe only in that final landing phase. I know we discussed how dumb vtol plane landings look right now.

Does anyone know for sure how the EK2_USE_HGT works? on copter side they seem to think it works (uses LIDAR for alt below the defined height) even if EK2_Alt_Source=0 despite having the same wording in their documentation (which says it only works if ek2_alt_source=1).

Small test this morning with ek2_rng_use_hgt = 20 (20% of 50m = 10m) and ek2_alt_source = 0 (baro) with Q_loiter hover well below 10m (~3m) resulted in building, long wave altitude oscillations that required me to need to recover in q_stab. reverted the parameter, and it q-loitered like a dream…

displayed alt did not appear to match lidar at all, but ti was difficult (watching the GCS and the AC) to see if the baro was really bouncing that bad due to induced px changes.

is there a data flash log metric that tells what altitude the aircraft thinks its at after the ek2 filter?

more to follow

looks like nkf5.hagl is the altitude seen by the aircraft.

@jace26 to quote Paul from when he presented some refinements to this feature (Source):

The patches in this PR relate to use of the range sensor as the primary height reference which is a bad idea if the ground is not level and the vehicle is moving quickly.

So for any outdoor quadplanes you can easily encounter issues with this. (Particularly if you imagine the effect of rangefinder as a height reference and then flying over a tree line for example). GPS altitude tends to work very well on planes, (particularly if you have SBAS, but even on normal fixed wing flying in Australia without any SBAS corrections on L1 only I’ve been happy)

Sure, using lidar as a primary alt reference in forward flight seems a little more tricky, for a quad it seems somewhat reasonable below certain speeds, and in the end, if you go over a treeline and intend to keep an obstacle height, then it seems relevant at any speed. So long as I set the parameters to limit its use (speed and alt) then I think it’ll do what I really need which is landing help.

I just don’t know if it’ll work without optical flow enabled? maybe I’ll try to SITL it.

There is a significant difference between terrain following, and using the range finder to feed your position estimator. In this case the height change is a variance induced on the estimator and causes it to have a significantly less stable position estimate. If you want to maintain height over an obstacle then you want that as a control mode input, rather then a position estimator input. Copter supports that form of terrain following, but Plane does not.

yeah, it makes sense that the position estimator feed should be based on a fixed altitude reference like sea-level or home alt. and it makes sense that copter modes in particular should have a need for an AGL reference as well. All I’m saying is that since a qplane acts sometimes like a copter, it should have the ability to use agl data at certain points, like landing an maneuvering in copter mode, if the operator desires it. And it seems like it might be setup that way, I just haven’t figured it out yet.

That is currently not supported on quadplane. (I agree it would be nice, but it’s not a supported feature at the moment, and while I’d like it, it’s not one I can commit to at the moment).

We might be interested in doing it on our end. I’m not the coder here, but i’m trying to convince my guys to do it. If I succeed then expect to hear from them on collaboration. We may also be interested in contributing to the flash log documentation I asked @MagicRuB about at interdrone.