Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crazyflie firmware #25

Open
araujokth opened this issue Dec 18, 2015 · 1 comment
Open

Crazyflie firmware #25

araujokth opened this issue Dec 18, 2015 · 1 comment

Comments

@araujokth
Copy link

Hi Benoit,

Great work and thanks for sharing! I found your thesis after finding this repository and it is being a great read!

I was wondering which firmware for the CF2.0 you would advise to download and if you had done any tests comparing your firmware against the firmware by bitcraze? do you know if there is any major update they have done comparing to your latest firmware?

I was planning to use your estimator and the model you identified on my application. I am running the whoenig/crazyflie_ros and was interested to improve the controller to do some precise landing and was thinking of running an LQR with your model. In case you have any tips, they would be greatly appreciated!

Thanks a lot!

Best,
José

@blandry
Copy link
Owner

blandry commented Dec 24, 2015

Hi José,

I know Bitcraze has been busy improving their firmware since I have forked. I was hopping to put some time into rebasing soon. There is actually some good overlap between the things they have changed and the things I had in my own fork (ex: handling of CRTP packets and linearization of the motor thrusts).

Re-using the estimator is a good idea. But it does require a steady stream of raw IMU data which might require some customization of the firmware if you decide to use upstream.

If you want to do off-board control I would suggest paying a good amount of attention to the communication code. Bitcraze did a good job a building flexible logging but they never really optimized for high rate telemetry/control (low latency, high rate etc.). For example, sending new motor commands should be the preferred strategy over waiting for acks. Probably one of the few pitfalls I can think of.

Good luck!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants