Granular control of height

[elSkov]

Hello
I have a Crazyflie with the STEM ranging bundle.
Currently I'm trying to get my CF to fly through an obstacle course, aka. my apartment, but when I fly it over an obstacle such as a table, it "panics" as it tries to get to the correct height again, so if the table height is 1m and I'm flying at 1,25m, it tries to gain the 0,75m as it detects the difference. I would like to have a bit more control as the thrust is a bit wild and it's a 50/50 chance that it crashes into something afterwards There is, of course, nothing wrong with this, but I would like to control that myself. I'm using the motion_commander.py to control my CF and I'm wondering if there is a way to use that to have a more granular control of the height?

[arnaud]

This is a quite fundamental problem, we and others have tried multiple time to solve it with "an easy fix", but it is always harder than expected. None of these fixes can be done only on the control side unfortunately, all requires some modification on the Crazyflie side.

The basic problem is that when using the flow deck, the distance to the ground is used as absolute height measurement. The distance to the ground is very important for the flow sensor to be able to compensate for change of the orientation of the platform but in theory it does not have to be used as an absolute height as well.

One of my ideas has been to use the down-facing range sensor as a vertical velocity sensor and to filter spikes that occurs when you pass a table. Unfortunately, this is not working well in real life since the sensor output is not that sharp and, at the edge of a table, slight change of attitude will make the sensor measure a lot of random height.

The best I have heard to solve this problem, was to use the up-facing sensor of the multiranger to range with the ceiling and use that as height measurement and keep the down sensor for flow compensation only. This can work great if the ceiling is flat. There was a forum thread about that but I cannot find it again, I am not sure how far in the development this has gone, but it was working quite well as far as I can remember.

So, unfortunately, if you want to stick to python, my best answer would be "avoid to fly over tables". If you want to dig a bit in the firmware, using the top sensor would be my first try since it seems that it has worked before.

[elSkov]

Hi

Hmm, it was as I feared. I think I want to stick to the Python side as this issue is a nuisance, but not a deal breaker right now. it's been a while since I dived into C, so I think I'll just end up banging on the table in frustration and not getting any work done

But thanks for the reply - now I know what to avoid instead trying to dig into the API and not finding any luck.