Altitude Hold Solution Approach

[jackemoore]

Hi
I'd appreciate your thoughts on having two althold solutions in the crazyflie that users can select either in source code or via Flight Control in cfclient. I'll call your current implementation Thrust Solution and the second one would be an Altimeter Solution. The advantages of the Thrust Solution include reasonable hover performance and simple solution to accept flight control altitude changes. The disadvantages include decreasing battery voltage, handling of different payloads (expansion boards) and handling wind or drafty areas. Clearly, the altimeter sensor has its shortcomings, but there is a simple trick to mitigating sunlight and air currents that can interfere with the sensor. The altimeter output in meters is a bit noisy, but I think a little more filtering can clean up some of this. My brief examination of using the Altimeter Solution (feasibility implementation only) shows potential promise of reasonable hover performance. In addition, it shouldn't suffer from the problems mentioned above with the Thrust Solution.

My crazyflie 2.0 without gps weighs 24 g. Another cf2 after adding the ubx gps receiver weighs 33 g and a third is 36 g with the gt titan-2 gps. The new crazyflie-firmware-master 2016.05.19 commit with its Thrust Solution for althold doesn't perform well for the increased payload weight. It would be nice to be able to change the default thrust in function position_controller.c (.thrustBase = 36000) within cfclient Flight Control.

I'll understand if the above falls short of providing a strong enough argument for Bitcraze to consider adding an Altimeter Solution.

Best regards,
Jack

[Mitteau]

Hi Jack
It's easy to implement different thrust base values to follow modifications of payload. Just add some parameter. It will be possible to adjust it using GUI python client.
Best regards.
Jean-Claude