We have been discussing the information architecture on the Bitcraze forum after getting some really good feedback from Fred (derf) one of our forum members. Before starting to make changes to the forum we thought it would be a good idea to take the opportunity and ask all of our forum members for feedback about how the forum is structured. The forum should be easy to navigate and comprehensible for both new and old members so feedback from people actually using our forum is very valuable. So if you have any suggestions post a comment to this post or send us an email.
Öredev
Also this week on Thursday 10/11-16 we are going to the developer conference Öredev that is taking place here in Malmö. We are exhibiting the same demo as we did at Maker Faire Berlin so if you are going to the conference expect to see an autonomously flying Crazyflie 2.0 enabled by our Loco positioning system (code and doc for demo published here). We are there the whole day so come by and have a chat :-).
New Crazyflie 2.0 firmware release
We released a maintenance release of the Crazyflie 2.0 firmware last week. The new release improves the stand-by time for the Crazyflie 2.0 and doesn’t effect the Crazyflie 1.0. The release can be found here.
Progress on TDoA for Loco positioning
We’ve started working towards positioning using TDoA and last week we pushed updates to both the Loco positioning node and to the Crazyflie 2.0 firmware. The changes are still largely untested but we’ll be continuing the work during this week. We’re really excited about the possibilities this brings, virtually unlimited number of Crazyflie 2.0s being positioned at the same time!
Loco positioning system is still in Early access which means that things are moving fast. Since the release of the loco positioning system a Kalman filter has been contributed by Mike Hammer at ETH Zurich. The Kalman filter allows to calculate the position estimate in the Crazyflie and merges the Loco positioning system information with internal sensor to generate a much better estimate. We also worked on improving the anchor firmware, it is now ranging faster and we fixed a bug that was making the anchor hang sometime. Finally stephanbro on github pushed an improved position controller that improved the stability of flight a lot.
Because of all these changes we have decided to make a new video and to rewrite the documentation on the wiki a bit. Enjoy!
On the development side, we have extended the Loco Positioning system to position 2 concurrent Tags by using TDMA (Time Division Multiple Access) where each Tag is allocated a time slot to use to range to the anchors.
This works fine for a few Tags, but does not scale very well for a larger numbers of tags. If you want to experiment by yourself there is some instruction in the git commit. Be aware that this is still experimental enough for us to break it without warning so keep track of the git commits when you pull the latest version of the firmware. Currently we are working on a TDoA (Time Difference Of Arrival) mode that will scale to concurrently position virtually an infinite number of tags, hopefully you will soon be able to see commits on that on our Github projects.
The logging subsystem of the Crazyflie 2.0 is fairly flexible and easy to use, but despite its nice properties it may still be limiting in some scenarios. Two areas where it is lacking are offline- and high-speed logging. As a step towards solving these problems we are happy to announce support for micro SD-cards in the Crazyflie 2.0 firmware.
We have had a prototype for a micro SD-card expansion deck lying around in the office for a long time but have not had time to write any code for it. Finally we decided to go ahead an fix it and now there is a first basic version in the master branch of the firmware. What we have added so far is a driver for communicating with the deck and support for the FAT file system and that means that it is possible to read or write files to/from a SD-card. We have not yet implemented any means for configuring parameter logging to file but that is something we would like to do in the near future.
DIY
The hardware design for the expansion deck is very simple.
If you are eagerly waiting for this functionality it should not be too hard to create your own deck, otherwise we plan to release one sometime in the near future. We can not promise when, but if you need it please let us know as it might change our priorities when deciding what to do.
When the deck is installed all you have to do is build the firmware with
CFLAGS += -DDECK_FORCE=bcUSD
in the tools/make/config.mk file to enable the SD-card functionality and add your own code in src/deck/drivers/src/usddeck.c to read or write to your SD-card.
We have always been interested in controlling Crazyflie with various devices. For example we had the Leap Motion that enabled us to control the Crazyflie with our bare hand. Then we hacked a glove for Arduino day. At Maker faire Berlin 2016 we met the team from Specktr. Specktr is a midi glove and since our demo was controlled with midi we had to try connecting the Specktr with Crazyfile 2.0 flying using Loco Positioning System!
We met in the evening, after the faire was closed, and started hacking to map the midi messages transmitted by the glove to our midi to position ROS node. After a couple of mandatory crashes and crazy behavior (like setting the flight area way too big and sending the Crazyflie high speed away at the snap of a finger, too bad we have no video of that …) we had things working well and the glove could control the Crazyflie X position:
The second and last day of the faire we did a more proper connection where both X and Y could be controlled. The result is quite nice. It looks near magic, and quite fun, to control Crazyflie just by just moving the hand:
Speccktr is currently running a crowd funding campaign and we cannot wait to get ours to be able to hack more with it together with Crazyflie and Loco Positioning System.
One week ago we where presenting Crazyflie 2.0 and the Loco Positioning System at Maker Faire Berlin 2016. It was a lot of fun being there, we enjoyed it very much, and it also required a couple of weeks of preparation. The preparation was both mechanical and markerting: out booth was built with and outdoor tent frame and we featured the first roll-ups of Bitcraze history (almost felt a bit too ‘corporate’ for us :-).
On the technical side it was an opportunity to test Crazyflie and the Loco Positioning System in real event situation. This required stabilizing the system and testing it so that no bad surprises would happen during the faire. The result is pretty good: we flew more than 91% of the opening time, we had 2 fly-away the first day, fixed the problem and had none the second day. We were flying with 2 Crazyflie sequentially and had not broken any motor mount or other part during opening hours (some crazyness did happen after-hours though, maybe more on that on a later post ;-).
For our demo the Crazyflie was flying autonomously with the loco positioning system using the Kalman filter to fly towards a given x/y/z set-point. We made a midi-to-crazyflie bridge in ROS that allowed to give control of the Crazyflie position via a midi cable. We actually used a physical midi cable which was the safest and simplest. On the other side of the midi cable was a computer running a midi sequencer, lmms. Part of the sequence was playing actual music to make the Crazyflie dance and part was just silent movement. The setup looked like that:
Midi can encode notes pitch (ie. where in the piano you play) and velocity (ie. how hard you press the piano key). The midi track contained 4 tracks: X, Y, Z and LED-ring. In X, Y, Z tracks the note pitch converted into a position and we don’t use the velocity. The led ring track maps the note pitch to a color and the velocity to a brightness. It looks like that:
This setup was a bit of a test, we found it to be very reliable. Some functionality were implemented on-site after Friday morning experience: automatic landing when the battery was low and reconnect on take-off to allow taking off without restarting anything in the PC just at a press of a button. The midi link worked well even though it feels a bit hackish to setup a choreography like that. If you have any better idea what to use to make a Crazyflie dance please tell us!
Last but not the least we have share all the codes, files and documentation for this demo on github so that you can run it yourself with an loco positioning system. We also made a short video showing the demo in action:
We are just back from the Maker Faire Berlin where we have met lot of interesting people and shown the loco positioning system. We have calculated that Crazyflie 2.0 has flown for more than 91% of the faire thanks to the autonomous flight with Loco Positioning System.
Our neighbor at the Maker Faire was Gerhard Fließ from Deskbreeze and he was presenting a mini desktop wind-tunnel:
This was a great opportunity for us to test the Crazyflie in a wind-tunel. The result is really impressive slow motion videos:
The wind-tunnel is mainly designed for education. The wind goes at 1 m/s which is apparently too slow for aerodynamic study but nevertheless we can see some interesting effects. Then the propeller pulls the air, we can see the lines getting tighter just before the propeller, this is a sign of higher speed flow and lower pressure. The difference of pressure between the bottom and the top of the propeller is what makes the Crazyflie fly. When the Crazyflie pushes the airflow, simulating a descent, we can see an oscillation of the air flow. This is most likely what can cause instability when descending fast.
We will post more about the Maker Faire Berlin and our autonomous flight demo in the following weeks so stay tuned. Thanks to all we have met, it is awesome to meet and talk about the Crazyflie in person. A mostly great thanks to Fredg (derf on the forum ;), that was there to help us during the whole week end.
The last couple of weeks has been really busy getting ready for the Maker Faire Berlin. The plan is to show multiple Crazyflies flying autonomously enabled by the Loco positioning system. To spice up the experience of autonomous flight and to inspire the visitors to imagine future applications we have made a small light and sound show where the Crazyflie is dancing to a soundtrack Kristoffer made.
Here is a teaser where we are maybe stretching the limits a bit too far ;-):
Taking the opportunity to exhibit what we do at events like the Maker Faire Berlin is really exciting and we are looking forward to hanging out with cool people and getting feedback about what we do.
So come and visit us at Maker Faire Berlin is Sept 30 to Oct 2 at Station Berlin. You will find us in hall 3, stand 149.
Until now, the Loco Positioning System have been limited to flying only one Crazyflie autonomously. In this post we will try to explain the reason of this limitation and what are the way forward.
The loco positioning system is based on Ultra Wide Band (UWB) radios that can very precisely measure the time of departure and arrival of a radio packet. This allows us to do two things:
Use these times directly to calculate the flight time of the radio packet. This is called time of arrival (ToA) measurement, it can be done by simply pinging one anchor. No extra synchronization is required.
Use the difference between the arrival of packets from two different anchors. This is called time difference of arrival (TDoA), it requires the system of anchors to be synchronized together.
The method 1) is simpler to implement since it does not require the anchor system to be synchronized, though it requires bidirectional communication between the tag (eg. Crazyflie) we want to locate and the anchors. It means that if you want to locate more than one tag you have to somehow share the air by not ranging all at the same time. The method 2) requires extra work to synchronize the system of anchor and is theoretically more sensitive to measurement noise. However TDoA measurements have a huge advantage: they can be made to work with unidirectional signal sent from the anchors. This means that the tag only has to listen to the air to receive all information needed to locate itself. This allows to scale the location system to as many tag as we want since adding a tag do not have to share the air, they are not transmitting anything.
So far we have been concentrating on ToA measurement since it could easily be implemented and gives us the best theoretical ranging performance. This allows to develop the algorithms to calculate position estimates and stabilize the autonomous flight. The problem is that, since we are just ranging as fast as possible with all the anchors of the system, one Crazyflie will take all the available air-time and we cannot fly another Crazyflie at the same time. We have just implemented a solution to fly more than one Crazyflie with ToA measurement using time-slots, this is called TDMA for Time Division Multiple Access, and it can be done without anchor code modification. We are working on the Maker Faire demo using this method and it is starting to work quite well:
For TDMA we define frame and time slot. One time slot is a space in time where one tag will be allowed to communicate without risking collision with others. One frame is a group of timeslot. Each Crazyflie is configured to use one time slot in each frame.
TDMA frame structure. Image from the Wikipedia TDMA article.
Normally implementing TDMA would require some kind of synchronization to make sure each Crazyflie knows when its time slot starts. With the LPS we are in luck though since transmitting time is part of the way the ranging is working: we do not have to implement new messages or even to modify the anchors to implement TDMA.
We chose the timer in anchor 1 as our master clock for TDMA. When a Crazyflie starts it ranges with anchor 1 which allows to get the current time in anchor 1, then the start of the next frame can be calculated and the Crazyflie can schedule to range in its next time slot. We range with one anchor per time slot and each time we range with anchor 1 we get a chance to re-synchronize.
The TDMA has been pushed to the Crazyflie master branch. It is documented in the commit message so please feel free to test it, report, and pull-request ;-). We have tested running in 2 slots mode with success. Very quickly though, when adding more time slots, the performance deteriorates because the rate of ranging per Crazyflie decreases. Then TDoA will lead to better performance which is the next target, after the Maker Faire Berlin :-).
It’s been over six months since our last Crazyflie 1.0/2.0 firmware release and it was about time to do a new one. We have always had the idea to release often but can’t really say we have succeed. Something we are trying to improve but it has turned out to be really hard. Since it has been quite some time since the last release a lot of things have happens. To summarize the bigger ones:
There is now a Kalman filter option to use with the Loco Positioning system and hopefully later with other systems such as GPS and camera based systems (thanks to @mikehamer)
Improved altitude hold
Rewrites of low level code to improve stability
Architecture updated to support on-board position awareness
New streamlined I2C driver
Driver for Loco Positioning deck
CMSIS-DSP added to the firmware project
Improved PID tuning for the Crazyflie 2.0 (thanks to @theseankelly)
More reliable radio communication link
Please go to this page for instructions about how to upgrade to release 2016.09
ST Microelectronics have become quite known for their complex and somewhat buggy I2C peripheral, especially for their STM32F103 device (see errata). Where for instance the I2C interrupt priority needs to be the highest in the system, otherwise some I2C events might be lost which could cause random behavior. Since we use the STM32F103 for the Crazyflie 1.0 we have been using ST provided drivers as a solution for not having to take care of these cases. On the Crazyflie 2.0 we’re using the STM32F405 which doesn’t have the same I2C implementation and where ST has moved over to using the CPAL library for I2C drivers. This driver has turned out to be “bulky” and cause compatibility problems with our FreeRTOS due to handling of CPAL timeouts. Therefore we recently decided to see if we could write our own driver for the STM32F405 instead. How hard can it be..? Well after two weeks of pulling my hair and swearing it turned out to be a bit harder than we first thought. But now we hopefully have a slick and optimized I2C driver that works great for our purpose. Instead of polling it uses interrupts for I2C writing and DMA for I2C reading to keep MCU intervention low, leaving more processing power to Kalman filters etc :-).
Like I said, there was a few more obstacles along the way than we initially thought. So here are are some pointers I collected on the way:
I quickly dropped the interrupt event handling the ST-LIB suggest, I2C_GetLastEvent(…), because during the address event status register 2 (SR2) needs to be cleared (by reading it) after DMA has been setup (as noted in the datasheet when reading the fine print…). The I2C_GetLastEvent reads SR1 and SR2 at once which thus doesn’t work out.
This took most time to find, but using my I2C analyser I found that the I2C connection suddenly stopped after a small period of time with a START then STOP event of 3.9us. Doing a lot of trial and error a eventually found that the only way to trigger such a quick start-stop condition was if both the start and stop flag in the control register where set at once. I therefore tried manipulating the CR1 register only with a write operation and not a read-modify-write which solved the problem. This requires that you know what the whole content of the register needs to be when setting it. Luckily such is the case. A very strange behaviour but now it’s working, let’s leve it at that :-)
And finally don’t always trust the tools. I found that using my TotalPhase Beagle I2C analyzer I sometimes got corrupt transactions. I tried a lot of things in my I2C driver but I didn’t get why. I posted a topic in the ST forum to get some desperately needed help but then one of my colleges suggested that I should try a different analyser. Well there was no problems with the I2C bus according to that analyser. Turned out that the problem was that I was using the Totalphase Data Center software in a virtual machine. I couldn’t get it to run natively on Ubuntu, which must have been causing slow USB communication or something that the Data Center software doesn’t handle correctly.
