Category: Software

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

Raw gyro while flying

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

For a while Invensense’s gyros has been the MEMS sensors to use in multirotor  applications due to their good performance and vibration rejection. ST Microelectronics are also big when it comes to MEMS sensors but their gyros has not been that good when it comes to handle vibrations. In the beginning if 2013 they released the 3-axis gyro L3GD20 which are advertised to improve this and we thought we finally would do an investigation. So we bought a Pololu  AltIMU-10 board which has ST sensors and also the iNEMO module, LSM9DS0, which is a very sweet 9-axis 4x4x1mm chip. After a bit of a soldering exercise we got them both attach to an accompanying Crazyflie. The AltIMU-10 board we glued to the bottom and connected to the expansion I2C buss. The LSM9DS0 was a bit trickier and we removed the MPU6050 and used some of its components for the LSM9DS0 so we could glue it up-side down to the board. I think the picture speaks for itself. After some quick and dirty coding we managed to get them both working and flying. The flying capability is very similar to the MPU6050 and we can’t really tell the performance apart. We will have to investigate it in more detail and for that we are adding a SD Card breakout to write raw data from all sensors at full speed. That will be the exercise for next week so stay tuned!

 

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

It’s been a long time now since we released new versions of our software. So it’s about time :-)

Here are some highlights from the releases:

  • Altitude hold support in firmware, PC client and Raspberry Pi SD-card image
  • Bitcraze VM upgraded to Saucy Salamander (13.10)
  • Lot’s of bugfixes

One of our big topics of discussion at Bitcraze is how to release and when to release software. Our plan has changed over time and this time around we are trying something new. First off the version naming is (as before) constructed using the year and month. New for this release is that we decided to make a beta release before making the real release. If the feedback is good on the beta, we will just rename the release after a week of testing.

When it comes to handing the issues in Bitbucket we have tried an approach were we minimize administration. After every release we create a new milestone named after the last release (i.e 2013.11+). Everything that is supposed to go into the next release is then added to this milestone. When we do a new release all the resolved issues/implemented features that are closed and added to this milestone makes up the change log. Issues that are not resolved are moved to the next milestone.

The discussion we have had for the last week resolves around the release schedule and whether or not do do a pre-release (release candidate). Up until now we have had the goal to do feature-based releases (although there haven’t been that many releases…) but we have now started leaning towards trying period-based releases. We feel that it’s very easy to drag on and not release a new version since we want more and more features and fixes in it. Ideally we would select a few that would go in and then stick to it, but we are having a hard time doing this. Below is a quick outline of the idea we have for the future releases:

The idea is to release a new version of the firmware/client about every two months (8 weeks). First we create a new milestone that we assign issues/features that we think we will be able to fit in (i.e for the next release this would then be 2014.01). After 7 weeks we branch and create a release candidate that the community can download and try. If any major bugs are found they are fixed and then the release is done. Our goal with this is to release more often, even if the releases might contain less things.

So what do you think about doing period-based releases instead? We think that the community should have a say in this, since you are the ones using the releases. So go ahead and vote, we know you want to!

How should we do new releases of the firmware/software?

View Results

Loading ... Loading ...

The Crazyflie 10DOF has a pressure sensor that can be used as an altimeter. This sensors was waiting to be used and we had many contributors implementing altitude hold/hover mode for it. We recently merged one of the best working contributions to the main branch of both the Crazyflie client and firmware so that it is now a bit easier to experiment with it. The current code is based on the work done by omwdunkley who did a great initial job and you can read more about it in his post.

The altitude-hold is another control-loop that will try to keep the copter at the same altitude by using the altimeter and the accelerometer to sense the altitude and vertical speed. This is controlled by keeping a button pressed on the game-pad. When altitude hold is activated the thrust joystick axis controls the altitude set-point and thus are used to make the copter rise or fall.

Foam on the Crazyflie 10DOF altimeter

Foam on the Crazyflie 10DOF pressure sensor

From our test in a calm pressure stable room the altitude is held at roughly ±15cm. However we had some problems when we where moving around. The Crazyflie sometimes suddenly rose and went to the ceiling. After some debugging we found that the problem was mainly physical, the pressure sensor is exposed of dynamic pressure when flying. To fix that we cut some of the foam we have in the Crazyflie box (yes that was planed all along ;-), and we stuck it on top of the pressure sensor. Doing so greatly improve the stability when flying more aggressively! (Something we kind of knew from peoples suggestions but it is nice to see it working in reality)

This functionality still require some debugging, tuning and code clean-up, but if you want to test it just grab the latest version of the firmware and client from Bitbucket. To begin with check that the altitude hold function is well configured for you joystick mapping (we found that it is best set on the shoulder button of the thrust hand). The altitude lock will be activated as long as the button is pressed. It can be pressed while the copter is flying or while it is in the ground. If pressed when the copter is in the ground, you will have to press the thrust joystick up a bit to make the copter fly higher. We also recommend to be a bit experienced with flying the Crazyflie as the altitude hold sometimes requires a quick recovery manoeuvre ;-).

This Monday post we are devoting to the community development and we will try to give a short summary of what is going on there. We recently haven’t our selves had that much time to help out with this development, something we intend to change, so all credit goes to the community!

  • A port of the OpenPilot CC3D firmware to the Crazyflie done by webbn. Still under development but video already shows promising results.
  • Altitude hold functionality which is being developed in parallel by many, omwdunkley, phiamo, et. al. We hope we soon can contribute to this as well.
  • Improved thrust control which is being discussed a lot and hopefully we will soon see some ideas realized.
  • A Ruby cfclient written by hsanjuan.
  • The Android client with a lot of work from derf and sebastian.
  • The FPV implementation driven mainly by omwdunkley and SuperRoach. Omwdunkley has made an awesome HUD (Heads Up Display) which we hopefully sometime will see integrated into the cfclient. Check out the video!
We have probably forgotten some of the great development that has been going on recently and if that is the case please write a comment about it and we will update the post with it.

For the last couple of years (!) we have been discussing on and off about automatically flying the Crazyflie from a PC using OpenCV and a camera. We did a try a while ago using a PS3 Eye camera that wasn’t very successful. One of the issues we were having was detecting the distance from the Crazyflie to the camera. Another issue was a lag of about 1 second which made it impossible to control the Crazyflie using the video as input. So last week this discussion came up again and we finally decided to buy a Xbox360 Kinect. The image resolution is higher than the PS3 Eye and of course it has the ability to detect the distance from the camera to the objects it’s seeing.

Crazyflie and Kinect

The goal was to create a proof-of-concept application that shows that it’s possible as well as providing a stub for anyone that’s interested in doing more development. The application uses the normal image as well as the depth image from the Kinect to estimate where the Crazyflie is. This can easily be done by attaching a small colored ball to the Crazyflie and using a white background for flying. The images are processed and the current X/Y/Z co-ordinates given to a control loop. The control loop consists of thee PID regulators that will correct the roll/pitch/thrust that is sent to the Crazyflie to reach a X/Y/Z set-point in the image. The X/Y set-point can be selected by clicking the image or you can hold down the mouse button and drag it around. A cool feature that we would like in the future is to draw a geometric shape that the Crazyflie could follow. But there’s still a lot of work to be done with the control loop before we can achieve that.

After seeing the video you might be asking yourself where the James Bond theme music or the inverted pendulum is. Well, we are’t quite there yet and we will probably not even get near it. But still, this shows that the concept works. And for anyone that’s interested, it’s possible to do some basic trajectory planning algorithms at home with a Crazyflie and a Kinect.

For a more technical details have a look at the Kinect page in the hacks section of the wiki.

Last year we quickly hacked together a client for Android to show that it was technically possible to use the Crazyflie/Crazyradio on the platform. It worked, but it wasn’t very good. After that not much has happened, until now. Thanks to contributions being made by fredg02, Sebastian Sams and bug tickets from Sascha Heymann, the hackish prototype we did is now turning into something that is actually usable. It’s still under heavy development but there’s already some new features. Here’s a quick run-down of what’s been added:

  • An external controller can be used instead of on-screen thumb sticks
  • You can scan for Crazyflies
  • The same flight control settings that are in the cfclient are now available (i.e advanced mode, X-mode, max roll/pitch/yaw and thrust)

So the Android client works with phones and tables that support USB host or OTG. Anything else? Well, there just happens to be an Android platform that even comes shipped with an external controller…the Ouya! So if you have an Ouya and a Crazyflie you can just side-load and you are ready to go! Since we are used to the PS3 gamepad we had some issues getting used to the Ouya controller. If you have the same issue you can pair your PS3 controller with your Ouya and use it instead!

Once the software becomes more stable an APK will be released, but until then the repository with the code and issue tracker can be found here.

 copter_ouya

In order for users to be able to pilot the Crazyflie from platforms without a graphical user interface there’s now a headless client in the repository named cfheadless. It’s intended to be run the command-line and is still under development, but working.

The main reason it was made in the first place was to enable flying from the Raspberry Pi. The QT interface was very sluggish and it required all the QT dependencies to be installed. So the cfheadless client doesn’t depend on QT and doesn’t have a graphical user interface at all. For users to quickly get something working with the Raspberry Pi we prepared a pre-configured SD-card image that is based on the Raspian Wheezy. We didn’t remove anything from the image, we just added the things needed to fly the Crazyflie. It works out of the box with the Crazyradio and a PS3 controller. In order to switch to anther controller you will have to connect to the Pi and edit the configuration.

To use the image you have to edit the configuration if needed and then just connect your controller, power on the Crazyflie and lastly connect the Crazyradio. The cfheadless client will now automatically start and connect to the Crazyflie.

The image can be downloaded using this torrent or via direct download. The torrent is preferred since the direct download is limited to 6 simultaneous downloads. For more information on how to use the image have a look at the wiki page and if there’s any issues or suggestions drop by the project tracker at Bitbucker and add them. If you already have a Raspian image downloaded and running and you want to be able to use it with the Crazyflie then have a look at how we made the image or the hacks page with the original instructions.

Crazyflie and Raspberry Pi

There’s an updated version of the Bitcraze virtual machine out. The VM has all the pre-requisites for using the Crazyflie/Crazyradio and also the full development environment for our projects. Here’s a list of the improvements from version 0.2:

  • Upgraded version to of Xubuntu to 13.04
  • Improved README and instructions inside VM
  • Updated to the latest version of repositories
  • Added script for updating all the project repositories
  • Added pre-configured JTAG debugging for Eclipse using BusBlaster
  • Added KiCad and the Crazyradio design files

More information on the Bitcraze VM can be found here and it can be downloaded from this link. If you don’t want to download our virtual machine but instead make your own then have a look at this guide on the wiki.  It details how to get Xubuntu running in VirtualBox with all the pre-requisites for the development environment.

We have finished cleaning up the Crazyradio design files and they are now added to a Bitbucket repo. The project includes a cache file with all the components from our library that we have used. Once we are finished with cleaning up the component library it will also be uploaded.