Officially moved to GitHub

2014-02-24 | Marcus | 5 Comments

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).

Logging and parameter frameworks tutorial

2014-02-18 | Marcus | 4 Comments

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.

Firmware/client release 2014.01

2014-02-03 | Marcus | 2 Comments

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.

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:

Crazyflie pc client: Windows installer
Crazyflie pc client: Source tarball
Crazyflie firmware: Image for bootloader (How to upgrade)

New firmware/software release candidate

2014-01-27 | Marcus | 9 Comments

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.

Holiday contest results

2014-01-13 | Marcus | 4 Comments

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.

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 ;).

[Show as slideshow]

Trying out GPS with the Crazyflie

2014-01-06 | Marcus | 3 Comments

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” ]

Bored during the holidays? We have the solution!

2013-12-16 | Marcus | Leave a comment

With roughly one week to go until the holidays most people are still stressing about getting presents, food and trees. We have done our best to get into the holiday spirit, but December isn’t well known in the south of Sweden for delivering a white Christmas. So with no snow and +7ºC outside it’s a bit hard to get into the holiday spirit.

After the holiday stress has leveled out, you might find yourself having some extra time on your hands. Being off from work is great, but unless you get tech toys for Christmas you might get some abstinence being away from your high-tech things. At least we get this feeling. So this year we thought that we would try to help everyone that is a bit bored during the holidays, by announcing a little competition! We have two different categories of fun things to do: Mechanical and software.

Software: Controlled decent when free falling
Mechanical: 3D model for a plastic hull

For the first category the goal is to implement a controlled decent of the Crazyflie. The idea is to do this without any user interaction. Imagine dropping the Crazyflie from your hand and the controlled decent algorithm kicks in and lands it graciously without the user doing anything. Or why not throwing it away :-) This could be implemented using firmware, host software or a mix of the two. Here’s roughly what we had in mind:

Connect to the Crazyflie and enable controlled decent mode in free fall
Pick up the Crazyflie and drop it (preferably above a soft surface)
The free fall can be detected using the accelerometer. When in free fall all three axis of the accelerometer will be very close to 0 (see image below)
Control the decent of the platform and land graciously (unlike in image below :-) )

Plot of accelerometer before, during and after free fall from 1,5 meters

For the second category the goal is to create a nice looking body for the Crazyflie. A while back we put together a home made vacuum plastic molder (something similar to this). Our idea was to create a 3D model of a body and then use it as a base for the vacuum molding hack. The end result would be very durable and light. The only problem is that we are really bad at 3D graphics (and at graphics in general) so this has been a blocker for this hack. We need some help with creating the 3D model. If you don’t have a Crazyflie you can always have a look at the mechanics repository. It contains a great model of the Crazyflie that Erik did a while back.

Aside from satisfying the geek inside you during the holidays, we will also be awarding the winner of each category with a Crazyflie Nano Quadcopter 10-DOF with Crazyradio and additional spare parts! In order for the projects to be judged we will need some video/images and code/model. The projects will be judged on how good the solution works and also how good the implementation is. The competition will end on Sunday the 12th of January and we will announce the winners in our Monday post on the 13th of January.

So what will we be doing during the holidays? Well we had something else in mind. A couple of weeks ago we picked up a uBlox MAX 7 GPS breakout. It’s about 2.1 grams with a chip-antenna and is small enough to fit on the Crazyflie. We won’t exactly have path-following functionality after the holidays, but we are hoping for something that will report back the location to the client.

Happy hacking!

Edit: We forgot the most important part, where to submit your entries if you want to join in. Send them to holiday_hacking_2013@bitcraze.se before the end of 12th of January 2014.

Plotting and logging

2013-12-02 | Marcus | Leave a comment

While working on the PyQtGraph integration we have also started looking a bit more at the logging. There’s two limitations that we would like to remove. The first is that it’s only possible to plot logging configurations that are created for the PlotTab, but there’s more configurations that are running in the background. For instance all the values in the FlightTab are received via the logging framwork, and there’s no reason for these values not being plottable on the PlotTab. The second one is that you can only save one logging block at a time (and you have to plot this). We will add a new tab that shows all the logging configurations that are active and also add the possibility to save any number of these to file. After selecting a directory for logging data, the files will be created and the data logged. The format will be CSV (as it is today) and the timestamp will be the Crazyflie ms tick. Using the common timestamp it will be possible to plot multiple files together in an external application (like SciLab or Octave). If you have any other suggestions for the plot/logging functionality let us know.

During this work we have noticed that there are some stability issues with the Param and Log frameworks. Sometimes no parameters are downloaded and sometimes there’s no data that is being logged. We have also seen that the Crazyflie reports that there’s no memory to add more configurations when connecting. Those will be worked out.

The Crazyflie Nano Quadcopter 10-DOF is out of stock at Seeedstudio, but we are expecting new units to arrive just before Christmas. But if you are eager to get one before then have a look at our distributor page.

Log block debugging tab

PlotTab and PyQtGraph

2013-11-25 | Marcus | Leave a comment

We have finally gotten around to work a bit on the PlotTab in the cfclient. It’s been kind of working for a while, but there’s been lots of bugs and missing functionality. One thing that kept us back a bit was that we couldn’t decide what to do about the plot itself. Currently there’s a hackish implementation we did ourselves by drawing directly in the paint method of a QtWidget. This was done since PyQwt (QwtPlot) was too heavy for our netbooks. We have been looking around for a lib that supports “realtime” plotting and that’s not made for “static” plotting, but so far we haven’t found anything. The best alternative that we have found is PyQtGraph. It’s a pure Python lib that uses numpy and PyQt. We were a bit hesitant to bring in more dependencies, but we feel that PyQtGraph and numpy might be useful in other parts of the cfclient in the future. We are still working on the integration and when it gets a bit more stable we will merge it to the main branch.

With the PyQtGraph integration and the pull request from David to fix the reloading of the log configuration, we are hoping that the PlotTab will become a lot more useful. Below is a screenshot of the new PlotTab plotting the raw gyro output (logged at 100Hz) while hovering (and trying to press the PrintScreen button). The data that is plotted uses the time-stamp that is sent together with the data from the Crazyflie.

Raw gyro while flying

Logging the MPU-6050 and L3GD20/LSM303DLHC

2013-11-12 | Marcus | Leave a comment

Like we wrote last week we have been working on testing ST MEMS and comparing the performance to our current MPU-6050. Last week we had the sensors in place and were flying with them, this week we added a uSD card so we can log them and compare them offline. Before we added the uSD card we had a discussion on how to easiest log the sensors simultaneously. Since the current logging framework isn’t made for this kind of high speed logging we thought about regressing back to our old logging for this test. In the old logging we packed as much data we could into each radio packet (31 bytes) and just sent it to the PC at a high rate. Instead of being a generic solution, like we have now, this requires changes in the client/firmware to change any variables logged. Even if we changed to this scheme we weren’t sure if the radio link would handle it. The idea was to log about 56 bytes @ 500Hz (~28kb/s) which would be accelerometer/gyro from the InvenSense/ST sensors and a time-stamp. Since the radio link is only specified to an air data rate of 2Mbit (about 400Kbit true downstream rate), and because adding a uSD card was something we wanted to try, we decided on the uSD solutions. We also wanted the option to log more data if we needed to. It was just supposed to be a quick hack, a couple of hours….. So the plan was:

Download and integrate FatFS. We could have gone with PetitFS, but more features is always better (even if you are just going to log to one file…)
Find an open source SPI driver back-end for FatFS for the STM32F103
Build, fly, investigate and go to lunch :-)

The estimated time for executing this plan was about 4 hours (we actually said about 1 hour from the beginning, partly kidding..,). The execution was not as smooth as we planned. After working as developers for years, we still can’t avoid doing over-optimistic time-estimations. The goal with this was to be able to log all the data, but we never reached it. We encountered some of issues a long the way and the biggest one was the latency for the SD. From time to time it took > 200ms until the uSD was ready again after writing data to it. Buffering this much data was a problem. On a system with only 20kb RAM, lots of tasks (and stacks) and lots of queues to synchronize between them, it’s hard to create very large buffers. Finally we managed to allocate a ~5kb buffer, but we still had problems of it overflowing. We can’t spend more time on this right now so we have to settle for the data we have, but one day we will free up some time and come back to this.

Since most of the time was spent trying to get the data, there wasn’t much time over for the analysis. So far we can just say that the sensors are pretty similar in performance where the MPU-6050 have a little edge. The ST gyros seems to have a little more stationary drift and noise.

Sensor drift stability

X-axis of gyro while hovering

Stationary noise