Working Hover Mode - quick and dirty

[The_Digital_1]

Hey omwdunkley,
I have been playing with your hover mode for a little while now with the PC client and I love it! It makes flying the Crazyflie a lot more fun! As you can focus on pitch and roll and NOT constantly be adjusting for it falling out of the sky... The other thing I have found makes for great fun with the crazyflie is using the NVIDIA Shield with the Android client running on it. Joysticks are so smooth! Anyways what I was wondering was if you could help me get hover mode working with the Android client. Right now as far as I can see there is not TOC implementation in the Android client so it would be a bit of work to add it. However is there just a hacky way we can send the right value to the right param id?

Thanks!

[omwdunkley]

Hey!

Yes there is a hacky way

So usually one sends the flie rollGoal, pitchGoal, yawVelocityGoal, rawThrust commands, a (float, float, float, uint16) tuple.

In hover mode I extended that with a doHover, so the tuple becomes (float, float, float, uint16, bool).
The bool flag activates the hover mode if it is set to True.
In hover mode the uint16 changes meaning. Usually it it proportional to thrust and ranges from 0 to 65535. During hover mode the firmware treats this number differently: A value of 32767 means do not change the target altitude, 0 means decrease the target altitude fast, 65535 means increase the target altitude fast.

Relevant code:
crazyflie-client/lib/cfclient/utils/input.py:

Code: Select all

...
if hover:
    thrust = int(round(deadband(thrust,0.2)*32767 + 32767)) #Convert thrust (float from -1 to +1) to uint16, centered at 32767
...
self.input_updated.call(trimmed_roll, trimmed_pitch, yaw, thrust, hover) #Send the command

which in turn calls

crazyflie-client/lib/cflib/crazyflie/commander.py:

Code: Select all

def send_setpoint(self, roll, pitch, yaw, thrust, hover):
      ...
      pk = CRTPPacket()
      pk.port = CRTPPort.COMMANDER
      pk.data = struct.pack('<fffH?', roll, -pitch, yaw, thrust, hover)
      self._cf.send_packet(pk)

Notices the appened '?' for transmitting the boolean hover.


So in short:
Send it an additional boolean, and send thrust as 32767. If you want to change the altitude while flying, map your joystick input to decrease or increase 32767.

Hope thats clear!

[derf]

Hey omwdunkley,

Thanks for the insight on how the hover mode can be activated.
I'll try to implement it in the Android client soon. I just haven't got around to flash the hover firmware yet.

Hopefully I can check the Crazyflie's firmware version from the client to see if it's compatible with the hover mode.

Regards,

Fred

[The_Digital_1]

Great Thanks! That sounds pretty straight forward. I'll give it a try.

[derf]

Hey omwdunkley,

After updating the firmware and the PC client, I tried to include your "hacky way" to activate the hover mode into the Android client, but I'm probably missing something obvious.

I'm adding an extra byte with "1" as true and "0" as false to the byte array that gets send.
I also changed the joystick mapping according to your instructions, but hover mode is not activated.

It works fine with the PC client, though.

Any ideas what could be missing?

Regards,

Fred

[tobias]

Hi Fred,

What code are you using. We did a little change to the code in the main branch too not break compatibility with the older versions so the hover mode is activated with a parameter instead. Can that be the issue?

[derf]

Hi Tobias,

I'm using the Crazyflie firmware "Crazyflie_2013.11-beta1.bin".
I saw that in the PC client the hover mode is enabled with a parameter, but I thought that omwdunkley's "hacky way" (sending an extra boolean in the CommanderPacket) would still work.
Was the "hacky way" removed for compatibility reasons?

Eventually I'll have to implement sending of parameters etc in the Android client anyways...but if the quick and dirty way still works, I'd like to try that first.

Regards,

Fred

[tobias]

Yes we removed it for compatibility reasons. If you use omwdunkleys FW it should work though.

The parameters and logging not ideal for embedded devices. The good thing with it though is that it wont suffer from incompatibility in the same way.

[tlankford01]

Greetings,

I am new to the forum and waiting for my crazyflie to come in. I have just purchased it yesterday. I am curious why no one is working around the accelerometers. The pressure sensor makes sense when you are going to work outside or have tens of meters to climb indoors where a significant pressure change can be observed. I have worked in the past integrating this on my larger uav's but in conjunction with gps and mems data. Also in the "old days" we used analog infrared horizon sensors to help us with this attitude/ altitude stabilization.

The problem that I am seeing is that we lack spacial awareness. barometric pressure readings should help us, but is not providing the precision that we require. I see two solutions that I would like to work on when I receive my machine. The first solution disregards spatial awareness sensors. I want to take a moment to qualify that I have no idea what I am talking about. I am taking a stab at this in order to provide alternative ways to think about this problem. What if we write a code that only centers around the accelerometers. if the value of any three axis move from zero acceleration, then the motors counter act that motion by increasing or decreasing speed. I could be mistaken but lacking spatial data we are left with inertial integers.

The second solution that I propose is a small sonar ranging chip on the bottom of the crazyflie. This would provide the spatial data that is otherwise lacking. A quick look at spark fun and I found a 4.3 gram sonar sensor that is accurate within an inch form 0-255 inches. This should be more than adequate for a machine that is built primarily for indoor use and development. Thank you for allowing me to be part of the community and I hope that this adds to the solution.

[tobias]

Great to have you on board tlankford01!

The problem with the accelerometer is that it is very noisy (due to vibrations) and it is hard to use the data without filtering it hard. It might be more useful then we think though. Maybe putting another accelerometer on the board which is heavily filtered by foam or similar could be a solution.