We are working on a research project where a group of UAVs will plan a path overflying obstacles in order to reach certain areas. At the moment we are only flying one UAV at a time, we are using the Loco Positioning System with 8 anchors to provide global positioning for the crazyflies v2. We are also using the flow deck in combination with the LPS deck on the CF's as it provides greater stability vs relying on LPS alone.
We have discovered that if the Crazflie is fitted with a Flowdeck then the laser rangefinder is used to return Z relative to whatever is directly below. If the Flowdeck is removed then the LPS is used to estimate the absolute position of Z within the coordinate system. Thus if the Flowdeck is fitted and the Crazyflie goes over an obstacle then it shoots upwards as the relative value of Z drops by the height of the obstacle – this makes the task of flying over obstacles in a caged arena near impossible. Removing the Flowdeck makes waypoint navigation much easier but less stable especially while hovering.

Ideally we would like to use the absolute altitude derived from the LPS instead of the relative altitude taken from the laser range finder of the flow deck.
1. Is there a way to choose what altitude estimation takes precedence? (LPS vs Flowdeck)
2. Is there a way to completely disable the laser range finder (or ignore its readings) on the flow deck while maintaining the use of the flow sensor?
3. Is there a way to switch altitude estimation to absolute altitude so that the crazyflie can overfly obstacles without shooting up?

Thank you for your help,

Note: I tried to find a solution on the forums with not much success. The closest possible answer was to select the choice of barometer described in links below. This is not the solution we are after since the error from the barometer is relatively high in comparison to the estimation available from the LPS.viewtopic.php?f=16&t=2725&p=13662
andviewtopic.php?f=6&t=2592&p=13131

That will basically prevent you from queueing any Z-ranger measurements and feed them into the Kalman Filter. You can try it, I'm assuming the Kalman Filter won't break in any way by doing this (any of the CF team may correct me if I'm wrong though). I've done the same thing to prevent adding distance measurements from UWB, for example.

Would you mind to share with me how you manage to ignore Z data from UWB (I assume you did this, anyway I will be happy to learn what you did and how)? We are dealing with the same system now (UWB + Flow Deck) and I am searching for some ways to improve Z performance.

So far the solution from Carlos is the one for disabling pushing the zranger values in the EKF. Idealy we might want to add a parameter to disable zranger from being pushed in the EFK so that you could do it from the stock firmware (PR are welcome . The flow algorithms have been implemented with the assumption that you are flying over a flat floor at Z=0, doing something different will require to change the code. But hopefully once we figure out how to make it better these changes will make it in the main branch.

One thing you might want to be careful with: for the flow sensor to work properly it might be important to have a fairly good idea of the distance of the tracked area bellow the Crazyflie. The flow sensor only outputs delta X and Y in unitless ticks and the height is used to convert these ticks in velocity. If you disable the Z-ranger, the flow update function might need to be updated to use the height above object instead of the absolute height. Depending of your usecase this problem might be negligible though.

I can try to give an answer to the original questions:
1. In the EKF this will be done by setting standard deviation for each sensor input. In Z-ranger we have a very low stddev when close to the floor and we increase it when going up, this allows to have a smooth transition from zranger to the LPS. If you set a high stddev there the zranger will be less used: https://github.com/bitcraze/crazyflie-f ... ger.c#L115
2. See Carlos's answer
3. Your problem is that by default, the Zranger reading is interpreted as the true absolute altitude (because of the flat floor assumption). The EKF is setup to estimate the absolute altitude at all time. One idea I had was to use the zranger as a velocity input instead and to filter it so that peaks do not make it to the EKF. This way we could help a bit the Z estimation without being affected too much by obstacle on the floor.

Would you mind to share with me how you manage to ignore Z data from UWB (I assume you did this, anyway I will be happy to learn what you did and how)? We are dealing with the same system now (UWB + Flow Deck) and I am searching for some ways to improve Z performance.

Thanks in advance,

I may have expressed myself incorrectly. We didn't ignore the Z data from UWB, but the complete UWB distance measurements (you can do so by commenting https://github.com/bitcraze/crazyflie-f ... Tag.c#L261, in case you're using TWR. There should be a similar line for any of the TDOA algorithms). We wanted to have the LPS node recording data but not fusing information into the EKF, instead it was using position information from an external motion capture system.

By the way the current EKF is set up I don't see an easy way to just ignore the Z estimates coming from the LPS system.

I can only think of doing a multilateration based on the UWB distance measurements, which will give you a position [x,y,z] estimation and those are the "measurements" you will fuse into the EKF (instead of fusing the distance measurements). That way you can just fuse the estimated x-y position and completely ignore the Z position

Thank you Arnaud for the detailed explanation, and thank you for the work you guys are doing at Bitcraze. It seems as if the only viable option to try and avoid the sudden jump is to either change the std dev as you suggested or completely remove the flow deck. We will try to improve the LPS with more anchor nodes first and then if the performance is still unacceptable we will try modifying the firmware.

It looks like a good MSc project to be offered next year though, we'll see how the students get on.