Self stabilizing using the 3-axis accelerometer?

[cabbage]

Hi, I just got my Crazyflie yesterday and its been a blast to fly around and tweak with!

I am curious what the current plans/realizations are regarding using the accelerometer for some basic centering, while hovering or climbing, and the flie isn't receiving pitch-roll commands? In other words using the accelerometer data to help it hold its relative position. Is the 3-axis accelerometer capable of detecting well enough if it's drifting to the left, gets bumped, breeze, etc to allow using that data to try and re-center the flie again to its starting position? Any user given directions with the controller could then also be allowed for, and not compensated against after.
I don't see this mentioned on the wiki wishlist, is it not a possibility given the sensors capabilities or would this be a good place to contribute? The closest things I saw on the wishlist are using openCV to externally manage this on a bigger scale and altitude and heading control. While I can see how the currently unsupported altimeter and magnetometer would offer more precision options for auto stabilizing and programmed flight, once they are working, could the accelerometer not pull off a basic version of the functionality now? This would only be for correcting small drifts in direction.

Thanks! Let me know if this is way off, already being made, etc You are all doing amazing work so far, I love the open nature of this project!

[mrb0y]

I had a very similar thought my self but wanted to examine the stabilization code more closely before I went any further. Please document your progress if you make any! Does any one know the ETA on the 10DOF sensors? Is there any code (drivers / interface) out yet?

[marcus]

Hi,

With the accelerometer/gyro we think that it's not possible to get a position hold. The regulation should keep the platform level (if you set roll/pitch to 0/0) but turbulence, vibrations etc will cause this to be slightly off. If the platform is drifting slowly to the sides there's no way to detect this, the only thing we can detect is the orientation of the platform. The accelerometer should in theory show something when you start accelerating in one direction but the output is so low it would never be detected. The same goes for the thrust. In theory we should be able to detect if we are accelerating up/down or not at all. But we believe that the output will be too low here as well. For the yaw we are dependent on only the gyro which will show rotation but no absolute position (we integrate to get this in the firmware). Even though the gyro we have is good, a MEMS gyro will drift over time and this cannot be detected. With this being said there's always room for improvement when it comes to sensor filtering/regulation that might improve the performance.

But this is our theory on things, you are more than welcome to prove us wrong. In the next version of the client we will improve the plotting and logging functionality so you will be able to see output from sensors/regulation better.

Hopefully the pressure sensor will help with the thrust regulation and the magnetometer will help with the yaw drift but like we've said before, we haven't had time to test this. The basic drivers are implemented but the reading of the sensors is not integrated into the regulation. The ETA of this is unknown, it depends a bit on what's happening in the project and if anyone else is contributing to the code. Currently we are putting all our efforts into support, documentation and bug-fixing. Once there's some progress made on this we will let everyone know.

/Marcus

[phiamo]

have a look into the hover branches of my forks:
https://bitbucket.org/phiamo/crazyflie- ... abilizer.c
and
https://bitbucket.org/phiamo/crazyflie- ... 9ad9eb39fc
config was the o-button on ps 3 controller turn mode on or off and the thrust on left thumbstick is then used to indicate higher or lower ....

at least the ms5611 is readable now and then i think its due to i2c latency that i need to check for > 0.0f but the rate it gives new results seems to be ok enough ... just need to fiddle with the speedup ratio
i think the more distance between desired height and current should influence how much more thrust is given ....

[cabbage]

Excellent, I will definitely give those stability changes a try phiamo. I think we could also do a lot with the yaw still, the sensors are able to give very good readings on it and yet the flie still is in the habit of losing its orientation due to wind, bumping, etc. Given the current sensor data any changes in yaw that are not sent from the controller should be able to auto-correct quickly.

It's also hard to not change the yaw when applying trust with the current control layout, since it's on the same thumb stick. I am going to try remapping yaw change to the left and right triggers, I'll let you know. Hopefully that takes care of the sensitivity on the right thumb stick when applying thrust.

[marcus]

have a look into the hover branches of my forks:
https://bitbucket.org/phiamo/crazyflie- ... abilizer.c
and
https://bitbucket.org/phiamo/crazyflie- ... 9ad9eb39fc
config was the o-button on ps 3 controller turn mode on or off and the thrust on left thumbstick is then used to indicate higher or lower ....

at least the ms5611 is readable now and then i think its due to i2c latency that i need to check for > 0.0f but the rate it gives new results seems to be ok enough ... just need to fiddle with the speedup ratio
i think the more distance between desired height and current should influence how much more thrust is given ....

Nice work!! How is the performance when you hover? I still haven't had time to test it but I will.

/Marcus

[willminers]

I'm not sure how relevant this is to the crazyflie, but I've used something like this before to good effect with 6-dof sensors: http://marks-space.com/2013/04/18/succe ... pberry-pi/

I will be experimenting with this as soon as I get my copter!

[pnewb]

It's also hard to not change the yaw when applying trust with the current control layout, since it's on the same thumb stick. I am going to try remapping yaw change to the left and right triggers, I'll let you know. Hopefully that takes care of the sensitivity on the right thumb stick when applying thrust.

I had the exact same thought. My housemate generously agreed to write in support for this...but it turns out there already IS support, just no UI element to activate it. So here's a diff of the file in conf/input that activates the analog shoulder buttons:

Code: Select all

 diff PS3_Mode_1.json PS3_Mode_3.json 
5c5
<       "name": "PS3_Mode_1", 
---
>       "name": "PS3_Mode_3", 
19c19
<           "id": 2
---
>           "ids": [12, 13]
69,75d68
<         }, 
<         {
<           "scale": 1.0, 
<           "type": "Input.BUTTON", 
<           "id": 12, 
<           "key": "exit", 
<           "name": "exitapp"
80c73

[marcus]

My housemate generously agreed to write in support for this...but it turns out there already IS support, just no UI element to activate it. So here's a diff of the file in conf/input that activates the analog shoulder buttons

Yes, thanks to Philipp there's support for this and this task had been added to fix the UI configuration.

[pablo_paul]

phiamo, I have cloned your repo's from the links you gave. Flashed the CF and started the UI but the mapping doesn't seem to work on the O-button to get the stabalization working. Do I have to edit the mapping manually or have you hard coded it?