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

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

• Crazyflie Nano Quadcopter Firmware 2013.11-beta1 (download)
• Bitcraze VM 0.4 (changelog) (direct download) (torrent)
• Crazyflie PC Client 2013.11-beta1 (changelog) (source download, Windows installer download)
• Bitcraze Raspberry Pi SD-image 0.2 (changelog) (direct download) (torrent)

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!

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