Working Hover Mode - quick and dirty

[omwdunkley]

Hey guys,

some of you might have seen my post here: http://forum.bitcraze.se/viewtopic.php? ... t=10#p2405

A while back I was experimenting with using the barometer to implement a hover mode. It worked relatively well in stable pressure conditions. I never released the code because I wanted to clean it up and do it properly (EKF, etc). However Ive not got around to doing that yet so I decided to expose the code. Yes its messy, yes lots is redundant, yes lots is suboptimal, but yes it works too:). I not going to continue to develope this fork (maybe some minor bug fixes and gui updates), but someone might find it useful.

How to use:

• Set up your hover button from the GUI. By default for PS3_Mode_1 its the L1 button of the PS3 controller.
• When you press this button, it sets the target altitude as the current altitude.
• Hold the button to remain in hover mode.
• While in hover mode, the throttle can be used to change the target altitude. Eg holding throttle up for a second raises it about a meter.
• Release the button to return to manual mode.
• Next time you enter hover mode, the target altitude is reset to the current altitude again.
• A good tip: Let go of the throttle immediately after entering hover mode. Its very easy to forget that one is holding it up and the flie will continue to rise.

Some details:
The ms5611 driver has been partly rewritten to enable pressure measurements at 50-100hz.

I wrote the code a while ago, but if I remember correctly it sort of works as follows:

All pressure readings are converted to an altitude above sea level.
When entering hover mode, we set the target altitude.

We can then define a PID controller that should take the flie from its current altitude to the target altitude. The P part is just the difference, eg 1 meter too high.
For the D term we use the vertical speed...here the code is ugly. First one needs to compute the vertical acceleration, then subtract gravity. This vertical acceleration is then integrated to get a speed estimate. To stop it accumulating error forever, it converges to the speed estimate from the barometer. This is also computed in a non mathematical way: some factor * (super_smoothed_altitude-smoothed_altitude).
The I term is just the integrated error - and is very very very important as it makes up for the voltage drop. The P and D term are reset every time hover mode is entered, and the I term is only reset when you start charging the flie. The default I value right now is set up to be a pretty good value for a stock flie at 80% battery. The default values takes around 1-2 to converge on a flie with a depleted battery during which time the flie might oscillate within a meter range or so.

Note that hover mode only works well in pressure stable environments. Trying to hover with people opening/closing windows/doors or during a thunderstorm does not work very well!

Here are videos of it working:
http://www.youtube.com/watch?v=aRsvPyRQaFA - static
http://www.youtube.com/watch?v=0oYzMVUKZKI - moving

Here is the firmware:
https://bitbucket.org/omwdunkley/crazyflie-firmware
Here is the client:
https://bitbucket.org/omwdunkley/crazyflie-pc-client

Good luck

EDIT: corrected the link

[tobias]

Thanks again for contributing! We have said we will try to get the hover mode in the main branch during the fall and this will be a great base!

[omwdunkley]

It just occurred to me that I have no idea what happens if it disconnects while in hover mode. It probably behaves as usual but dont quote me on that Ill test it this weekend.

[internguy]

Hello omwdunkley! i downloaded your client and firmware and got them to work for hover mode. Thanks for that! what i would like to ask is that when i log "baro.asl" on the client side, i am assuming i am recieveing above sea level in meters right? my reading is about 112 meters but i know i am about 40 meters. I checked the firmware side and formula is correct. is there some kind of correction factor iget 90 meters difference? thanks in advance

[omwdunkley]

hey man!

Glad to hear it worked on your side too

The 40 vs 112 meters could be a number of things. First and most importantly, the weather outside If you are in a high or low pressure weather condition that could effect it. I also do not compensate for pressure, so this would add to an offset. The pressure the flie measures varies too much (board heating up, airflow, etc).

How well does hover work? Any feedback? You're the first other person to mention using it and Im just interested

Cheers!

[internguy]

hey man!

Glad to hear it worked on your side too

The 40 vs 112 meters could be a number of things. First and most importantly, the weather outside If you are in a high or low pressure weather condition that could effect it. I also do not compensate for pressure, so this would add to an offset. The pressure the flie measures varies too much (board heating up, airflow, etc).

How well does hover work? Any feedback? You're the first other person to mention using it and Im just interested

Cheers!

thanks for the fast reply! may i ask, for example in your case, does baro.asl match your actual above sea level altitude? can you confirm if you have time please.
i am flying indoors without problem (thank you (^_^)v but when i got outside (the weather is really stagnant steady, no wind etc) is not good performance (still good enough) i think it is because of the sun changing the reading of temp drastically. i also noteced temp changes drastically even if you change thrust it may also be because of the humidity in here (so much humidty in Tokyo X_X)

i am now crawling thru your source code and will try to improve it ( and comment it) if i can.
However,if i undertand your code correctly, since hovering subtracts two altitudes, even if there was an offset since it is substracted it should give correct diffrence?

[omwdunkley]

thanks for the fast reply! may i ask, for example in your case, does baro.asl match your actual above sea level altitude? can you confirm if you have time please.
i am flying indoors without problem (thank you (^_^)v but when i got outside (the weather is really stagnant steady, no wind etc) is not good performance (still good enough) i think it is because of the sun changing the reading of temp drastically. i also noteced temp changes drastically even if you change thrust it may also be because of the humidity in here (so much humidty in Tokyo X_X)
i am now crawling thru your source code and will try to improve it ( and comment it) if i can.
However,if i undertand your code correctly, since hovering subtracts two altitudes, even if there was an offset since it is substracted it should give correct diffrence?

I made some measurements indoors (air conditioning etc) and measure 540m. The building is at 480, + 2ish meters for being on the top floor = 40 meters off.

Yes you are right, the offset is irrelevant as long as long as it does not change too fast.

Cheers!

[pablo_paul]

Hi thought I'd post also. Finally got round to building this today and am happy with the results it make the flie far easier to control in situations when you want finer control of its movements. I have noticed a couple of things which I'm sure are just development things to be sorted. When the fly transitions from forward flight in hover mode it drops noticeably during the transition. During static hover it will drift up and down but due to slow speed is easily controllable. The only major issue I did have is with the UI it didn't like the hover button mapping first time with the UI locking and the flie dropping to the ground I remapped the trim to some of the other buttons and left the hover mod on L1 If I the. tried to trim with the newly mapped buttons the UI would crash. Unfortunately the flie stayed at the set throttle and crashed with the motors running into a wall luckily no damage! I will post up the error message when I get the chance.

Great work this for me is the biggest feature missing from the CF

[omwdunkley]

hey Paul! Thanks so much for your feedback

When the fly transitions from forward flight in hover mode it drops noticeably during the transition. During static hover it will drift up and down but due to slow speed is easily controllable.

Im sure this could be fixed. Taking the orientation into account and boosting thrust accordingly. Just would take time to find good values..someone else want to do this?
How bad were the oscillations (magnitude/frequency?) This could possible be improved with better parameters. But to be honest the pressure sensor is accurate but not perfect and I am not sure how perfect we could get everything to work.

The only major issue I did have is with the UI it didn't like the hover button mapping first time with the UI locking and the flie dropping to the ground I remapped the trim to some of the other buttons and left the hover mod on L1 If I the. tried to trim with the newly mapped buttons the UI would crash.

Can you give me the exact steps to reproduce this problem? Ive had no such problems so far. Which controller and configuration are you using?

Unfortunately the flie stayed at the set throttle and crashed with the motors running into a wall luckily no damage!
I will post up the error message when I get the chance.

Hmm. So it disconnected and the flie didnt stop or the UI "freeze" (and might still be sending commands to the flie)?
Ill try to see if I can disconnect the flie in mid flight and see what happens.

Great work this for me is the biggest feature missing from the CF

Thanks much for your feedback!! I appreciate it
Cheers,
-Oll

[pablo_paul]

it seems a repeatable issue. See the terminal output. I have remapped the trims to the square/tiangle buttons etc when you hit any of them to trim the UI will crash. See terminal output below but the flie will keep flying not sure why if it had really lost connection i thought it would just drop from the sky. I'm using a cheap clone ps3 controller.

Code: Select all

--> True 32767
--> True 32767
--> True 32767
--> True 32767
--> True 32767
--> True 32767
--> True 32767
--> True 32767
INFO:cflib.crazyflie:Callback->Disconnected from [radio://0/10/250K]
INFO:cflib.crazyflie:Callback->Connectionl ost to [radio://0/10/250K]: Too many packets lost
WARNING:cflib.crazyflie:Got link error callback [RadioDriver: Could not send packet to copter] in state [0]
WARNING:cfclient.utils.input:Exception while reading inputdevice: Traceback (most recent call last):
  File "/home/bitcraze/projects/hover-client/lib/cfclient/utils/input.py", line 242, in readInput
    self.rp_trim_updated.call(self._trim_roll, self._trim_pitch)
  File "/home/bitcraze/projects/hover-client/lib/cflib/utils/callbacks.py", line 56, in call
    cb(*args)
TypeError: native Qt signal is not callable

INFO:cflib.crazyflie:Closing link
INFO:cflib.crazyflie:Callback->Disconnected from [radio://0/10/250K]

Last time it happened i was in hover mode and didn't notice and couldn't figure out why the flie was not responding to commands, i had to go and catch it