We announced the release of the Flow breakout board yesterday and we were happy to finally get it into the store. A few hours later we got some samples of the first production batch to the office and we discovered that we have messed up a bit.
First of all there has been a mixup when the pin headers were packed into the plastic bag, there are only 4 pins instead of the intended 10. We are sorry about this and if you get a bag like this, it is a standard pin header and the best way to fix it is to buy it in your local store.
The second problem is only cosmetic, the print on the bag states “Crazyflie Flow Breakout”. The Flow breakout is not intended for the Crazyflie but can of course be used with virtually any other hardware such as an Arduino for instance.
We were very eager to get the Flow Breakout, with its awesome functionality, into the store as quickly as possible, but maybe we were a bit too fast. The problems will be fixed in the next batch and for those of you who get a bag with the wrong pin header, we are really sorry! We hope it will not be too much of an inconvenience.
The Flow breakout board is built around the Pixart PMW3901 optical flow tracking sensor and the ST VL53L0x ranging sensor and measures motion in 3 dimensions. We have used the same sensors in the Flow deck which is used by the Crazyflie drone for autonomous flight, but we thought that the functionality is so awesome that we developed the Flow breakout and made it compatible with Arduino to make it easy to use. With the Flow breakout it is possible create applications such as motion tracking of a robot, counting people entering a room or gesture tracking.
When you get your Flow breakout, follow the getting started guide to quickly get up and going by hooking it up to an Arduino and measure motion.
In the following weeks we are going to make a couple of Hackster project around the Flow breakout board so stay tuned for more motion tracking!
We have had an implementation of a Time Difference of Arrival algorithm (TDoA) in the Crazyflie 2.o and the Loco Positioning System for quite a long time. The coolest feature of the TDoA algorithm is that it can be used to position virtually unlimited number of Crazyflies concurrently as opposed to the standard Two Way Ranging algorithm that is limited to one (or very few Crazyflies). The original implementation is working pretty well but contains some flaws that we are not completely happy with, hence we have not released it officially and are still calling it experimental. Since support for tracking multiple objects is a requirement for flying swarms and we like swarms, we have started to iron out the problems.
A small swarm using the old TDoA algorithm, from February 2017.
In the current implementation each anchor transmits the time of the transmission and the times of the latest reception of transmissions from all other anchors about every 16 ms. From this information it is possible to calculate the difference in time of flight for the radio waves from two anchors to the Crazyflie. When we know the difference in time of arrival, by multiplying with the speed of light we get the difference in distance and can calculate the position of the Crazyflie. This all sounds fine and dandy but the set up has some problems, the biggest one being error handling. If one or more packets are lost, either from anchor to Crazyflie or anchor to anchor, there is no deterministic way to detect it in some cases. The current algorithm relies on sanity checking the calculated result and discarding data that looks suspicious, which is usually easy as the distances quickly gets unrealistic (several thousands of meters!). We suspect that some erroneous values slip through the check though and we would like to be able to really understand when data is valid or not.
TDoA 2.0
What we are working on now is to add a sequence numbering scheme to enable the receiving party to understand when a packet has been lost. With this information it will be possible to discard bad data as well as use the available information better. While we are re-writing the code we are also moving a part of the algorithm from the Crazyflie to the anchors, after all there is a CPU in the anchors that is not fully utilized. The idea is to let each anchor continuously calculate the distance to all other anchors and add this information to the messages it transmits, which will reduce the work in the Crazyflie.
This is work in progress and we are not completely sure where we will end up, but we are aiming at making the TDoA mode part of the official release at some point.
Sensor fusion
Related to the Loco Positioning system is our line of other positioning sensors; the Z-ranger deck and the Flow deck. The Flow deck has really good precision at low altitudes but can not provide absolute positioning while the Loco Positioning system does not have the same precision but absolute position capabilities. So what if we fuse the information from the Flow deck with the Loco Positioning system? We have tried it out and it works pretty well, we can get the best of two worlds! The Z-ranger can also be used in the same way to improve the Z component of the estimated position when flying bellow ~1m.
Even though it works using multiple positioning sensors at the same time, there is room for improvements and some tweaking will be required to make it rock solid.
The Crazyflie, the original one, usually called Crazyflie 1 to avoid confusion, was the first commercially available open source nano quadcopter back in 2013. After getting feedback on the platform and having a lot of ideas of things that could be improved, we developed the Crazyflie 2.0 during 2014 and released the same fall. We decided we wanted to keep full backward compatibility with Crazyflie 1, both in the firmware project and in the different clients and support libraries even though we now had more processing power and RAM.
But during the last year we’ve almost exclusively been adding functionality that is Crazyflie 2.0 specific, while still trying to stay inside the constraints of the Crazyflie 1. We’ve also seen a decline in the discussions and interest of the Crazyflie 1. So this week when we once again broke the build because we run out of RAM in the Crazyflie 1, we decided to remove the Crazyflie 1 support from the Crazyflie firmware project. It’s of course with a heavy heart we do this, but we feel that in order for the Crazyflie 2.0 to move forward it’s a must. The last release that’s compatible with the Crazyflie 1 is 2017.6.
But if you’re still using the Crazyflie 1, don’t worry we’re not completely dropping it, we will continue to carry spare parts and if anyone wants to continue firmware development we will be happy to assist. If anyone is motivated, the code can be branched from the last release and we could make a new repository to host the Crazyflie 1 code.
As we announced recently, the Flow deck for the Crazyflie has been released. There was a high demand the first days and we were unfortunately out of stock in the store for a short time, but now we are restocked and the deck is available again. We also got a shipment of a few production Flow decks to the office, and of course we wanted to play a bit with them to find the limits. During development of the deck we only had one or two working prototypes at a time, but now there were manny, so what could we do?
Swarm with the Flow deck
Aggressive flying
So far we have flown slowish when using the Flow deck and we know that works, but what about more aggressive manoeuvres? We modified the flowsequenceSync.py script in the examples directory of the crazyflie-lib-python library. The original script flies a figure 8 at 0.5 m/s, and we spiced it up to do 1.5 m/s instead.
It works pretty well as you can see in the video but we get a drift for every finished figure 8 and we have not really figured out yet the origin of this error. There are a number of potential error sources but it needs further investigation to be fully understod.
Flying one Crazyflie above another
What if one Crazyflie flies above another? How will that affect the performance of the Flow deck? The optical flow sensor is in essence a camera detecting the motion of the floor, a Crazyflie passing through the field of view could potentially confuse the system.
We set up two Crazyflies to fly on a straight line in opposite directions, one 0.5 m above the other. The result was that the top Crazyflie was almost not affected at all when the other passed under it, just a small jerk. The lower one on the other hand, passed through the turbulence of the top one and this caused it to swing quite a lot, though it managed to more or less continued in the correct direction it was decidedly out of track. As expected, flying above another Crazyflie is not a good idea, at least not too close.
Flying a swarm with the Flow deck
When flying with the Flow deck all navigation is based on dead reckoning from the starting position, is it possible to fly a swarm using this technique? We thought that by putting the Crazyflies in well known starting positions/orientations and feed them trajectories that do not cross (or pass over each other) it should be possible. The start turned out to be critical as the system is a bit shaky at altitudes under 10 cm when the sensors on the Flow deck are not working very well yet. Sometimes the Crazyflie moves slightly during take-off and this can be a showstopper if it rotates a bit for instance, as the trajectory also will be rotated. It worked pretty well in most cases but sometimes a restart was required.
We were inspired by the Crazyswarm from USC and decided to fly 5 Crazyflies with one in the center and the other 4 spinning around it. Note the center Crazyflie turning but staying on the spot.
We used the Swarm class in the python library to control the 5 Crazyflies. The code used to connect to the Crazyflies one by one which takes quite some time, we changed it to a parallel connect while we were at it and got a significant speed up.
It is a lot of fun playing with the Flow deck and scripting flights. I know it might be silly, but we laugh the hardest when we fail and crash, the more spectacular the crash the more happiness!
The Flow breakout
For other robotics projects that don’t use the Crazyflie, remember that the same functionality as the Flow deck delivers soon will be available in the Flow breakout board. It is compatible with Arduino and other hosts.
Last week we released the Flow deck, it enables you to get really stable autonomous flight with the Crazyflie without requiring an external positioning system. We have been lucky to get access to the brand new Pixart PMW3901 optical flow sensor, the core of the Flow deck, very early and we wanted to bring this awesome functionality to everyone, including those without a Crazyflie. The solution is the Flow breakout board, it enables anyone to use this new optical flow sensor for any kind of motion tracking.
The flow breakout contains a PMW3901 optical flow sensor and a VL53L0x time of flight ranging sensor, the same sensors that are mounted on the flow deck. We have also added voltage translation logic that allows you to use the flow breakout with a system voltage of 3 to 5V that makes it possible to use it directly with any Arduino board and most embedded system. Further more we have written an Arduino driver for the PMW3901 optical flow sensor to make it easy to use the breakout deck. For the VL53L0x there are already a couple of drivers available out there.
The flow breakout is currently being manufactured and will be available in our shop in a couple of weeks. If you want to be notified of the Flow breakout board availability, please sign up in the shop or follow us on twitter.
There have been a few requests from the community for a brushless Crazyflie and we blogged about a prototype we are working on a few weeks ago. The most common reason for wanting brushless motors is to be able to carry more load, in most cases a camera. A camera could be used for FPV flying or open up various image processing use cases like understanding the would around the drone using SLAM. Image processing on-board requires quite a lot of processing power and the CPU in the Crazyflie could not handle that, so more processing power would be required for a scenario like that. It is summer time (with a slight touch of play time) so we wanted to see what we could do with the CF Rzr and if it would be a useful platform for these types of applications. We hope that we might get some insights on the way as well.
We set the goal to try to add a camera, a small “computer”, the Flow deck for assisted flying, FPV capabilities and support for a standard RC controller.
We chose the Raspberry pi zero-w in order to get video processing and video streaming from the quad as well as more computing power. The Raspberry pi zero is not the most powerful board our there but it has a couple of advantage for our prototype:
It has a readily available, good quality camera and good software support for it
It has an analog video output and hardware streaming support, which means that the quad could be flown FPV using the Raspberry pi camera
It has hardware JPEG and H264 encoders that will enable us to save and stream images and videos if we want to
Raspberry pi and camera mounted on the top part of the frame
For assisted flight and improved stability, the XY-part of the Flow deck works fine outdoors but the laser height sensor on the deck has a maximum limit of 1-2 meters, and further more it does not go well with direct sunlight. We decided to add an ultrasound sonar distance sensor to measure the height instead. The ultrasound sonar connects via I2C and was simply soldered to a breakout deck that plugs into the CF Rzr.
Crazyflie Rzr with ultrasonic sonar, breakout deck and flow deck mounted on the lower part of the frame
The first step is to see if we can physically fit everything on the frame. With some 3D printed mounts for the camera and the Raspberry pi, we think it starts to look pretty good. Next step will be to squeeze in the FPV video transmitter board, the RC receiver board and finally connect everything together.
The current setup with everything mounted
We are far from done but it is a good start, and it is fun.
We are pleased to announce the release of a new expansion deck for Crazyflie 2.0: the Flow deck. The flow deck is a new expansion board for Crazyflie 2.0 that contains an optical flow sensor from Pixart and a ranging sensor. These two sensors allows the Crazyflie to understand how it is moving above the floor and using this information the Crazyflie can fly itself.
The Flow deck can be used for manual flight where it allows to super easily fly the Crazyflie: if you realease all joystick the Crazyflie just stays there and hovers! The flow deck is even more interesting when used in combination with scripting: it is now possible to script the Crazyflie movement to achieve autonomous flight without needing any external positioning system.
It is summer again in Sweden and things are now starting to slow down and people are going to vacation. The last couple of years we have used the summer to look back and clean-up the technical dept accumulated during the year: when trying to get things done we have to prioritize which means that some things have to be left on the side (at least until we invent a way to add more hours to each day). This year is no exception, the last couple of weeks we have been working very hard to get the Flow products out and now the production is hopefully on rails so the cleanup can begin.
There is a lot of things we could do but here is a sneak peek of what we are currently looking at:
Crazyflie Client gamepad handling and configuration: The current input device handling is complicated and the architecture is hard to work with. There is a lot that can be done both in the front-end and the back end to make it easier to use and to work with.
Loco positioning system support for multiple Crazyflie, we have two mode implemented for that, TWR-TDMA and TDoA, both are very experimental and need some more work.
Cleanup of the webpage, information and documentation: we already have done a lot of work to make better documentation but there is always margin for improvement.
Cleaning up and improving the Crazyradio firmware: the Crazyradio starts to show its limits when flying swarms of Crazyflie. There is some improvement that could be done in the Firmware to make it more efficient. The first step is clean up the current implementation.
If you have any ideas of areas you feel we should focus on, even better if you want to help with some things and fix it together with us, just tell us in the comment.
On a side note, the manufacturing of the Flow products is still on progress and it should soon be on the Bitcraze shop and the Seeedstudio bazaar, stay tuned.
Robots that can both fly and drive – in particular wheeled drones – are actually somewhat of a rarity in robotics research. Although there are several interesting examples in the literature, most of them involve creative ways of repurposing the wings or propellers of a flying robot to get it to move on the ground. Since we wanted to test multi-robot algorithms, we needed a robot that would be robust, safe, and easy to control – not necessarily advanced or clever. We decided to put an independent driving mechanism on the bottom of a quadcopter, and it turns out that the Crazyflie 2.0 was the perfect platform for us. The Crazyflie is easily obtainable, safe, and (we can certify ourselves) very robust. Moreover, since it is open-source and fully programmable, we were able to easily modify the Crazyflie to fit our needs. Our final design with the wheel deck is shown below.
A photo of the Crazyflie 2.0 with the wheel deck.
A model of the Crazyflie 2.0 with the wheel deck from the bottom
The wheel deck consists of a PCB with a motor driver; two small motors mounted in a carbon fiber tube epoxied onto the PCB; and a passive ball caster in the back. We were able to interface our PCB with the pins on the Crazyflie so that we could use the Crazyflie to control the motors (the code is available at https://github.com/braraki/crazyflie-firmware). We added new parameters to the Crazyflie to control wheel speed, which, in retrospect, was not a good decision, since we found that it was difficult to update the parameters at a high enough rate to control the wheels well. We should have used the Crazyflie RealTime Protocol (CRTP) to send custom data packages to the Crazyflie, but that will have to be a project for another day.
The table below shows the mass balance of our miniature ‘flying car.’ The wheels added 8.3g and the motion capture markers (we used a Vicon system to track the quads) added 4.2g. So overall the Crazyflie was able to carry 12.5g, or ~44% of its body weight, and still fly pretty well.
Next we measured the power consumption of the Crazyflie and the ‘Flying Car.’ As you can see in the graph below, the additional mass of the wheels reduced total flight time from 5.7 minutes to 5.0 minutes, a 42-second or 12.3% reduction.
Power consumption of the Crazyflie vs. the ‘Flying Car’
The table below shows more comparisons between flying without wheels, flying with wheels, and driving. The main takeaways are that driving is much more efficient than flying (in the case of quadcopter flight) and that adding wheels to the Crazyflie does not actually reduce flying performance very much (and in fact increases efficiency when measured using the ‘cost of transport’ metric, which factors in mass). These facts were very important for our planning algorithms, since the tradeoff between energy and speed is the main factor in deciding when to fly (fast but energy-inefficient) versus drive (slow but energy-efficient).
Controlling 8 Crazyflies at once was a challenge. The great work by the USC ACT Lab (J. A. Preiss, W. Hönig, G. S. Sukhatme, and N. Ayanian. “Crazyswarm: A Large Nano-Quadcopter Swarm,” ICRA 2017. https://github.com/USC-ACTLab/crazyswarm) has made our minor effort in this field obsolete, but I will describe our work briefly. We used the crazyflie_ros package, maintained by Wolfgang Hönig from the USC ACT Lab, to interface with the Crazyflies. Unfortunately, we found that a single Crazyradio could communicate with only 2 Crazyflies at a time using our methods, so we had to use 4 Crazyradios, and we had to make a ROS node that switched between the 4 radios rapidly to send commands. It was not ideal at all – moreover, we had to design 8 unique Vicon marker configurations, which was a challenge given the small size of the Crazyflies. In the end, we got our system to work, but the new Crazyswarm framework from the ACT Lab should enable much more impressive demos in the future (as has already been done in their ICRA paper and by the Robust Adaptive Systems Lab at Carnegie Mellon, which they described in their blog post here).
We used two controllers, an air and a ground controller. The ground controller was a simple pure pursuit controller that followed waypoints on ground paths. The differentially steered driving mechanism made ground control blissfully simple. The main challenge we faced was maximizing the rate at which we could send commands to the wheels via the parameter framework. For aerial control, we used simple PID controllers to make the quads follow waypoints. Although the wheel deck shifted the center of mass of the Crazyflie, giving it a tendency to slowly spin in midair, overall the system worked well given its simplicity.
Once we had the design and control of the flying cars figured out, we were able to test our path planning algorithms on them. You can see in the video below that our vehicles were able to faithfully follow the simulation and that they transitioned from flying to driving when necessary.
Our work had two goals. One was to show that multi-robot path planning algorithms can be adapted to work for vehicles that can both fly and drive to minimize energy consumption and time. The second goal was to showcase the utility of flying-and-driving vehicles. We were able to achieve these goals in our paper thanks in part to the ease of use and versatility of the Crazyflie 2.0.
