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
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 :-)
- 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 ;-).
Our products at the Seeedstudio Bazaar are almost out of stock. Currently there are still some 10-DOF bundles in the Seeedstudio US warehouse, but the 6-DOF is old out. Below is the estimations for when things are back in stock. If you are eager to get any of the products that are out of stock, then you can always check with our distributors. If the bundles go out of stock it is also possible to buy the 10-DOF kit and Crazyradio separately.
- 10/6-DOF bundles and kits will be restocked mid November
- Spare motors will be back in stock mid October
The new motors have a little neat update, the top bearing is concealed inside the motor housing. This will make it much more crash resistant from forces to the top since there is no bearing to depress. The small downside is that it might be little bit more difficult to remove hard sitting propellers.
We have been in need of a 3D printer for a while now, in order to print parts designed by community members and also prototype new parts. After talking about it for ages we finally got around to buying an Ultimaker. For now we have mostly been playing around (printing various things found online) but our plan is also to make some models that users can print themselves. Let’s see if we run out of plastic before we get that far :-)
Below are some parts we printed. The Crazyradio cover designed by foosel and the frame designed by VGer.
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.