I am trying to bring it into the separate topic as cannot find anything that actually describes correct process of setting up this feature.
It was initially started in the thread reference below, pls look at my last post in there, i also copy it here.
The intent here is to execute what was stated in wiki as ‘default’ already supported behavior where in ‘AltHold’ or similar mode vehicle is expected to read alt value from the lidar in the defined working lidar range, and if out of that range - use baro.
In my understanding it was supposed to allow you fly indoors and outdoors. In reality it does not seem to be happening and i am trying to understand what else was presumed to be setup correctly for the lidar integration to work as expected, what EKF settings are needed for this and what not else was ‘skipped’ in the wiki, if anything, about it.
Ideally the expected behavior outdoors in the Loiter and PosHold should be exactly same - use baro/gps when out of lidar range, when closer to ground - switch to lidar accurate reading of the surface - should help much if one flies close to the roof, etc, to avoid crash. Not sure what of that actually exists or not.
I also feel it is not alt reading that is needed but collision avoidance in loiter, but would love to hear how it is actually supposed to be setup.
RIght now i have 1 lidar that is pointing down, plan to add one more pointing forward, still on 3.5.5 version of code as drone refuses to fly on 3.6 at all still, with severe osculations, i still need to figure out why. So i would love to figure out if all this can be done in 3.5.5 or 3.6 is the only version where all this may work.
A switch to the optical flow as i see it is not automatic by the way of what is presumed between the lines of descriptions on the EK2_ALT_SOURCE and EK2_GPS_TYPE parameters.
For the first one it says pretty definitively - “Setting 0 will use the baro altitude at all times”.
And indeed it is what i see as indoors baro goes crazy and hits basement`s ceiling. it does not even look at the lidar. Then they continue: “Setting 1 uses the range finder and is only available in combination with optical flow navigation (EK2_GPS_TYPE = 3).”
That, again, presumes that optical flow navigation is not dynamic. I will try next to set EKF2 into EK2_ALT_SOURCE=1 and EK2_GPS_TYPE = 3 and setting EK3_ALT_SOURCE=0 and EK3_GPS_TYPE = 0 but not sure it was supposed to be like that.
Next complication is the AHRS_EKF_TYPE parameter that has to point to the exact EKF model and i do not see any confirmation anywhere that it may ‘switch’ between EKFs or care if one EKF is on lidar for alt and other is on baro.
Donno, all this is as clear as mud and i have no time at all to open up code and read all this stuff that is in there to decipher what is it expected to happen in what undocumented combination of parameters… It is too bad wiki is not updated to actually say HOW to use all those features they listed in there. it simply presumes it is expected to work, and may be it is indeed true, i just cannot figure it out, yet.
I saw some threads asking about same thing and there were responses of the RTFM type pointing to other threads that have 0 usable information. Very odd.