Blog

Last week was a hectic but exiting week for me. First I visited Embedded World in Nürnberg and then made a visit to TUM university in München.

I was actually visiting Embedded World because ST Microelectronics contacted us and wondered if we could do a Crazyflie version with the more powerful STM32F3 and use ST MEMS sensors. So during the winter we did some prototypes where we fitted the pin compatible STM32F303CB and a LSM9DS0 9-axis MEMS module. Porting the code was pretty straight forward and took about a week. It was manly the drivers that needed porting but getting the FPU running also took some time. Our quick bench-marking test showed an ~35% increase of the floating point intense code and by using further speed boosters like the core coupled memory (CCM) it could probably be increased a lot more. Right now these extra CPU cycles aren’t really needed but for the future when more complex sensor fusion algorithms might be used they will be valuable. Therefore the STM32F3 series it very interesting as it packs plenty of processing power in a small package.

Having the ST-prototype on display in the ST booth at embedded world was quite a strange feeling. Something that started out as a fun thing to do on our free time is now sitting on a wall at big cenvenstion as EW, kind of hard to grasp. Unfortunately we where not allowed to fly around and play with it due to restrictions but I had a great time there anyway. I also participated in a short interview which ST arranged, really strange seeing yourself like that. I should probably focus on my engineering career instead… :-)

After the EW I went to visit the Techische Universität München TUM, as one of our most active users Oliver is studying there. Oliver made an awesome HUD and also contributed with most of the altitude hold code, and since München only is an hour away by train it was a great opportunity to go visit him. Oliver arranged so that Jacob from the computer vision group invited me to their department where they demonstrated some of their work, especially their work done with computer vision and quadcopters. Amazing stuff! I really hope we can do something together in the future and make this technology widespread.

Finally after some issues and lots of interruptions we made the move to GitHub. We will keep the BitBucket repos (but as read-only) since there’s lots of inbound links for code and issues.

If you are interested in doing the same move here’s what we did.

Create the reposiory on GitHub, then pull in Mercurial project from BitBucket into a local git repos using git-remote-hg:

git clone hg::https://bitbucket.org/bitcraze/crazyflie-firmware

The new github repos can then be added to the local git. Tags and branches can then be pushed to github. As Mercurial and Git have very different way to handle branches you will have to chose which branch to push and push them manually (we did not find any way to push all at once and we did not want to push all the branches anyway…):

cd crazyflie-firmware
git remote add github git@github.com:bitcraze/crazyflie-firmware.git
git push github master
#Pushing tags
git push --tags github
# Tracking and pushing all interesting branches
git branch --track 2014.01 origin/branches/2014.01
git push github 2014.01
git branch --track gps_ublox_dev origin/branches/gps_ublox_dev
git push github gps_ublox_dev

 

Copying the issues from BitBucket to GitHub can be done using this script. It takes the source user/repo and destination user/repo as arguments. Keep in mind that GitHub doesn’t have the same metadata as BitBucket does. So there’s a JSON file where you set up the mapping between BitBucket kind/status/priority/component and GitHub labels. In this you can set up zero to multiple labels. If a mapping for components is missing then a label with the same name is used. Milestones on BitBucket is mapped 1:1 to GitHub. The needed labels and milestones will be created as they are used while copying the issues.

If you are copying issues to an organization repository you will have to use a GitHub API token for identification, since you cannot log in using the organization username. Here’s an example for what we did for the Crazyflie python clients:

#Migrating tickets from Bitbucket to Github
python migrate.py -g bitcraze -d crazyflie-clients-python -u bitcraze -s crazyflie-pc-client -k your_api_token_here

Two tips: Create a new user that does the migration (like bitcraze-issue-importer) and make sure that you haven’t created any issues in the target repositories before the migration. If you don’t have any issues before then the number will match and all the references will work out of the box (from commit messages and other issues).

To show the functionality in the logging and parameter frameworks we did a video. It shows how to use the Bitcraze virtual machine to add variables and parameters to the firmware and to flash it using the radio bootloader. It also shows how to visualize the log-data using the plotter and to modify parameters from the client.

While cutting the video we noticed that the temperature goes down when we touch the pressure sensor. Either we are more cold-blooded than we should be or there’s a bug in there somewhere…

Edit: Turns out it not a bug. After some discussions this morning (and testing) we arrived at the conclusion that the measurement was correct. The PCB get’s a bit warm when running/charging and a fingertip isn’t necessarily 37C.

We have started the migration to GitHub, as usual with this kind of things it is not as obvious as we had thought at first. We decided to start with the most active repos which is currently the PC client. In the process it will be renamed crazyflie-clients-python to show that it contains the python libs and it works on more than just PC (ie. raspbery pie at least).

The source code migration is a little challenge due to the very different way Git and Mercurial handle branches. Using git-remote-hg we could pull the mercurial repos in a newly created git repos and then push the interesting branches and tags to github. This seems to work quite well but the last things we would like to have is the possibility to pull changes made in git to mercurial so that we could keep the current mercurial as a read-only mirror. Internally some of us plan to still work with mercurial anyway using hg-git and the great TortoiseHG.

For migrating the issues from BitBucket to GitHub we forked this script to add some functionality. Aside from copying the title/text/comments, we also wanted to map the metadata from BitBucket to labels/milestones on GitHub. So the modified script first creates/sets the correct milestone on GitHub and then creates/sets the labels according to a JSON mapping of BitBucket metadata to GitHub labels. It supports mapping of kind, status, priority and component to zero or more labels. The modified script is available here. While doing tests we discovered that github was sending a mail for every single ticket and comment, a collateral damage was one of our mailbox that got 303 messages in a couple of minutes (the smartphone attached to the mailbox actually played notification tunes for hours…).

ticket-mails

 

 

After a week of fixing things for the Crazyflie firmware/software RC (release candidate) we have now tagged and built the final release 2014.01 of the crazyflie PC client and firmware. Last week we listed the changes, but for the final version we also made improvements for the logging and communication. This mostly effects the connection and downloading of TOCs and parameters, which improves the connection reliability.

Screenshoot_2014.01.0

With this release there are some updates to the Python API for the Crazyflie. In order to more easily keep the examples in sync with the API we have added some basic examples in the example folder in the repository. We will also update the wiki with these changes.

To download the new version the links are:

A while back we had a poll about when and how we should release new firmware and software. Since this we are aiming at at least doing a release every 7- 8 weeks of firmware/software that has been updated. So last week we branched and build release candidates of the firmware and the pc client. We will keep the RC until the end of the week or until we think it’s stable enough. During that time we will fix any serious bugs that come up. So if you are up for it download/flash it and give it a try. If you find any issues, don’t hesitate to let us know on the issue tracker (client / Crazyflie firmware).

Here are the files:

Some of the new features include:

  • Client: Playstation 4 controller configuration
  • Client: Improved plotting functionality (using PyQtGraph)
  • Client: Improved logging functionality (UI and logging to file)
  • Client: Added credits tab for Crazyflie PC client
  • Client: Updated API for logging and crazyflie
  • Client: Application icon added
  • Client: Fixed bug that prevented using Crazyradio/pyusb if the software “gopro studio” was installed
  • Client: Various bugfixes
  • Firmware: A couple of new default log variables (acceleration, magnetometer)
  • Firmware: Fix of the pitch/roll/yaw calculation: it is now correct all around roll.

We are also working on a Mac OSX release of the client using py2app. It’s not something that we have done before, but hopefully it will be ready by the next planned release (before 2014.03).

Last week we had a poll about moving to GitHub. For once there was a clear message from a poll, Move to GitHub! So after this release we will make the move. We will move things over gradually and in the move we will most likely make some structural changes as well, like splitting up the PC client and API into different repositories.

The last couple of weeks we have tried to become a bit more active on twitter (@bitcraze_se) and we will keep writing about smaller and bigger things that’s happening at Bitcraze. So if you are interested in keeping up to date this is a good source of info.

As our source control system, we have been using Mercurial since a few years now and we like it. But lately we have been thinking about migrating our projects to GitHub, which would also mean a migration to git. One of the key reasons we are thinking about this is of course popularity, but also that GitHub seems to be better at handling cooperation and contributions. Our experience with GitHub is limited, but we have been using git in projects every now and then. So we would love to get some feedback on this. Even though it’s possible to push code on both (even easily between git/hg) we would like to stick with one alternative for bug tracking, milestones and such.

Should we migrate to git and GitHub?

View Results

Loading ... Loading ...

During the week we are working on preparing a new software release, at least for the pc client. A couple of things happens since last release including better log graph and altitude hold. Also the driver situation for windows will become better as we found a way to install the Crazyradio driver without restarting windows in maintenance mode. Finally we now have a mac and are planning more support for it in the future, no promises for this release though.

We hope everyone had a great holiday! We are really happy that some of you decided to join our holiday challenge. After looking though all of the submissions we finally decided on a result.

First of all there was the mechanical challenge of creating a hull or cover for the Crazyflie. When finding the winner we looked at features such as wight, design and manufacturing. After a long discussion we decided on Gottfried Dungl’s submission, the Crazysheild, that you can see below. Even though it might be tricky to manufacture/3D-print, it’s lighter than the other submissions while still being durable as he showed by crash simulations.

Crazyshield submitted by Gottfried.

Crazyshield submitted by Gottfried.

 

Secondly there was the free-fall detection and recovery. For this challenge we only got one submission and it’s from Oliver Dunkley. That doesn’t matter since his solution works really well and has great potential. The implementation is done in the Crazyflie client, where both free-fall detection and recovery is done. There’s lots more information about this solution which we will post on the wiki or forum during the week. You can have a look at the code here.

 

Great job and big thanks to everyone that participated! Gottfried and Oliver will receive a Crazyflie 10-DOF kit and we have also decided to reward all others that participated with a little gift so check you email ;).

 

Before the holidays we said that we would be doing some testing with attaching a GPS receiver to the Crazyflie. For now it’s just a bit of a quick hack, but we are planning on doing more development. Here’s a quick summary of where we’re currently at (yes, that’s a bad joke..).

We attached a GPS module based on the u-blox MAX-7 chip which is interfaced using the UART. The initial plan was to interface it using I2C, but this will probably not work out. We thought that we could use the I2C interface for reading out the data via a normal memory map (like an EEPROM), but the module will continuously stream the data on the bus. This means that the module probably won’t play nice with other devices on the bus (which kind of defeats the purpose of the bus in the first place). So UART it is. By default the module sends NMEA data every second over the interface. There’s lots of information to get here, but what we focused on was the fix status of the module and latitude/longitude/altitude. Currently the firmware doesn’t contain any string library so parsing data from strings sent on the UART isn’t that easy. Instead we decided to just forward all the incoming data on the UART to the CRTP console. On the client side the NMEA data is picked up from the console and parsed. This data is then visualized using KDE Marble, where the position is shown on a map fetched from OpenStreetMap.

So what now? Well, there’s a few things more that we would like to do. First of all the data shouldn’t be sent over the CRTP console, the logging framework should be used for this. So we need to parse the lat/long/alt/fix data coming from the module and place into variables that can be logged. But there’s functionality that we would like that doesn’t fit within the logging/parameter framework, so a new gps port will be added. Using this port we are planning on making more data available (like information about satellites). But the main reason for this new port is to be able to send data to the GPS implementation in order to implement A-GPS to minimize the time to get a position fix. So by downloading the GPS almanac online and uploading via the radio to the Crazyflie the first time to fix should be shortened considerably.

If you would like to give it a try then have a look at the GPS hacks page om the Wiki for instructions. Note that on Ubuntu 13.10 (and probably other distros as well) the Marble build doesn’t include the Python bindings, so you will have to build Marble from source and enable them. If you would like to play around a bit with Marble here are some docs: Python examples and C++ API. If you don’t have a GPS module but still want to try it, then enable the DebugDriver. It will send fake lat/long/alt data to the UI. Oh, and if you figure out how to plot a path over the map, let us know ;-)

A quick note about dependencies for specific tabs in the Crazyflie python client. New tabs are added to the cfclient by creating a python file in the lib/cfclient/ui/tabs directory. So if you would like to add a tab for GPS you would just create a GpsTab.py file and this will automatically be picked up when the application starts up. Since we are now adding some dependencies that are just for specific tabs (like Marble for the GPS and PyQtGraph for the Plot) we have also added some decency checking. This means that if you don’t have Marble or PyQtGraph installed when starting the cfclient these tabs will still be listed in the menus, but will be disabled.

Finally, don’t forget about our holiday competition where you can win Crazyflies! There’s still one more week to go before it ends.

[pe2-gallery album=”http://picasaweb.google.com/data/feed/base/user/115721472821530986219/albumid/5964703597351683761?alt=rss&hl=en_US&kind=photo” ]

We wanted to wish everyone a Happy New Year! A big thanks to our users and community for supporting us during the year. We are really looking forward to 2014, there’s going to be lot’s a exiting things happening!

Don’t forget about the holiday contest where you can win Crazyflies! If you feel like joining in, submit your entry to holiday_hacking_2013@bitcraze.se before the end of Sunday the 12th of January 2014. It’s going to be interesting to see how much spam we get when we write the address without obfuscation and even link it ;-)

Oh, and in case you missed it, here’s a shameless re-post of our holiday video. To be fare it does say Happy New Year at the end.