Before it’s time for the holidays we thought that we would do a new video with a Christmas theme, showing our vision of Christmas gift delivery. For anyone that has seen the Amazon Prime Air video, it’s pretty easy to see where we got the inspiration for our video. Needless to say we didn’t have the same budget as Amazon, but to be fair our quad does cover more ground :-)
Merry Christmas, and don’t forget our holiday challenge!
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.
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:
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.
A quick update on the Seeedstudio stock situation. The preliminary restock date for the next batch of products is the 21st of December, just in time for Christmas :-) This will include batteries, motors and Crazyflie Nano Quadcopter 10/6-DOF. If you can’t wait until then, you might have better luck finding a distributor with units in stock. Have a look at our distributor page.
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
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
Last week was mostly spent preparing for, and travelling to Devoxx. It’s always great to get out a bit and meet other nerds, discuss technology and do some flying. Devoxx is a Java conference so we didn’t think that many people would be interested in hearing about quads and low-level embedded. But we were really happy to see that lots of people showed up for the presentation.
Presenting is fun, but the most fun part is always hanging around before and after. Meeting people, discussing and flying. This time we also got a chance to do some hacking with the team from MYO. Hopefully we will get our hands on a developer unit early next year :-)
The Crazyflie Nano Quadcopter kits, bundles and spare parts are now back in stock at Seeedstudio, but we are still waiting for the Crazyradio to be re-stocked. Our products are selling quicker than we expected, so if you want one for Christmas don’t wait too long to place the order.
[pe2-gallery album=”http://picasaweb.google.com/data/feed/base/user/115721472821530986219/albumid/5945707587870624705?alt=rss&hl=en_US&kind=photo” ]
Here’s some video of the FPV flying demo taken from someone in the audience.
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:
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 :-)
Here are some highlights from the releases:
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 ...As you can see the webpage looks a bit different this Monday. For a long time we have had the feeling that new users coming to our webpage don’t get an overview of what we do and what the Crazyflie is. So we decided to put in a front page that is intended to introduce Bitcraze and the Crazyflie to new visitors. Since we feel that our blog is an important part of what we do we also added the last blog post to the bottom of the front page. If you are looking for the full blog it’s moved here, also there’s a link in the top menu.
We have also gotten the comment that there’s no information on the actual website, it’s all on the wiki. So we have added some new pages with a bit more descriptions of the development environment and the products. We will keep adding more and more information as we go. There’s still lots of work to do for the page and to enhance the website design, but we decided on doing it incrementally :-)
The nice new photos (in the slider and other images) are courtesy of our friend Johan Jeppsson, thanks!
It’s always fun get a change to meet fellow geeks/makers so during this fall we will be holding two presentations, first in Denmark and then in Belgium. They will be held at CIID in Copenhagen in October and at Devoxx in Antwerp in November. If you are close by then make sure to come by and say hello!
Here are the details:
If you don’t have the possibility to attend any of these and still want to hear us speak, have a look at our presentation at Oredev we did last fall or at the video from Devoxx after the conference. If you watch our old presentation, then pay attention at around 42:00 when Arnaud flies a Crazyflie into my forehead… It was just a matter of time before it happened :-)
If you have any suggestions on conferences/events were you would like to see the Crazyflie then leave a comment below.
