News from the comunity

2017-10-23 | Arnaud | Leave a comment

It has been a while since we have made a blog post about the the community and quite a lot has happened, and is about to happen, so we though we would do an update for this Monday post.

Fred, the Crazyflie android client community maintainer was visiting us last week. He is making great progress on the Java Crazyflie lib that is going to be used in the Android client as well as in PC clients. The lib is still experimental but when finished it will allow to connect and use a Crazyflie from any Java program, there has already been some successful experimentation done using it from Processing.

Thanks to Sean Kelly, the Crazyflie 2.0 is now officially supported by the Betaflight flight controller firmware. Betaflight is a flight controller firmware used a lot in the FPV and drone racing community. This is the announcement by theseankelly in the forum:

Betaflight 3.2 was officially released this month. This is the first release that contains the Crazyflie 2.0 target by default, so you don’t need to clone and build from source anymore. It’s available as a target in the betaflight configurator from the google chrome store! I’ve tested it out and it works as expected. Haven’t tested the BigQuad variant, but that’s also available in the app by default.

Thanks to denis on the forum, there is also support for Crazyflie 2.0 in the PX4 flight controller firmware. PX4 is a comprehensive flight controller firmware used in research and by the industry.

The Crazyswarm project, by Wolfgang Hoenig and James A. Preiss from USC ACTlab has been presented at ICRA 2017. It is a framework that allows to fly swarms of Crazyflie 2.0 using a motion capture system. There is currently some work done on merging the Crazyswarm project into the Crazyflie master branch, this will make it even easier to fly a swarm of Crazyflie. In the meantime the project is well documented and can be used by anyone that has a couple of Crazyflies and a motion capture system.

Automated anchor position estimation

2017-10-16 | Kristoffer Richardsson | 4 Comments

One of the pain points when setting up the Loco Positioning system is to measure the anchor positions and enter them into the system. I wanted to see if I could automate this task and let the system calculate the positions, and if so understand what kind of precision to expect. I have spent a few Fun Fridays playing with this problem and this is what I have found so far.

The problem can be broken down into two parts:
1. How to calculate the anchor positions. What data is required?
2. How to define the coordinate system. To make it useful the user must to be able to define the coordinate system in a simple way.

How to calculate the anchor positions

The general idea of how to calculate the anchor positions is to set up a system of equations describing the distances between the anchors and/or the Crayzflie and solve for the anchor positions. The equations will be non linear and the (possibly naive) plan is to use the Gauss Newton method to solve the system.

To understand how to calculate the anchor positions we must first take a look at the data that is available. The Loco Positioning system can be run in two different modes: Two Way ranging (default mode) and TDoA.

Two way ranging

In the Two Way ranging mode we measure the distance between each anchor and the Crazyflie and to get enough data we must record ranging data for multiple positions. The anchor positions are unknown, and for each new Crazyflie position we add yet a new unknown position, on the other hand we measure the ranges to the anchors so these are knowns.

The equations used are simply to calculate the distance between the assumed position of each anchor and the Crazyflie and then subtracting it from the measured distance.

TDoA

In TDoA we measure the Time Difference of Arrival, that is the difference in distance to two anchors from the Crazyflie’s position. It is probably possible to use this information, but I was looking for a different solution here. In our new TDoA implementation that we have been playing with a bit, we get the distance between all anchors (calculated in the anchors) as a side effect.

In this case the Crazflie is not really needed and the equations describe the distance between assumed anchor positions versus measured distances.

How to define the coordinate system

To get a useable positioning system, the coordinate system must be well defined and oriented in a practical direction. For example when writing a script you probably want (0, 0, 0) to be at some specific spot, the X-axis pointing in a certain direction, the Z-axis to point up and so on. My initial idea was to use the anchors to define the coordinate system, use anchor 0 as (0, 0, 0), let the X-axis pass through anchor 1 and so on. Just by looking at our flight lab I realised that this would be too limiting and decided that the coordinate system should be completely disconnected from the anchor positions, but still easy to define. I also realised that a really good way to tell the system about the desired coordinate system would be to move the Crazyflie around in space to show what you want. The solution is to place the Crazyflie at certain positions and click a button to record data at these positions. The steps I have chosen are:

Place the Crazyflie at (0, 0, 0)
Place the Crazyflie on the X-axis, X > 0
Place the Crazyflie in the XY-plane, Y > 0
Move the Crazyflie around in the space with continuous recording of data

In this scheme the XY-plane is typically the floor.

Results

I have written basic implementations for both the Two Way ranging and TDoA modes and they seem to work reasonably well in simulations. I have also tested the Two Way ranging algorithm in our flight lab with mixed results. The solution converged in most cases but not always. When converging the estimated anchor positions ended up in the right region but some were off by up to a meter. Finally I did run the algorithm and fed the result into the system and managed to fly using the estimated positions which I find encouraging.

I will continue to work on this as a Friday Fun project and maybe it will make its way into the client code base at some point in the future? There are probably better ways to estimate the anchor positions and more clever algorithms, feel free to share them in the comments.

Glow deck

2017-10-02 | Tobias | Leave a comment

A long time ago we got a request for a bright LED deck from a community member. When working with high powered leds heat becomes a problem that needs to be taken into account. From the community member we got suggestions of using one of the luxeon rebel leds and so we did. We designed a prototype pretty quickly but also realized that it is a bit harder than we first thought. If using a simple control scheme such as PWM and a mosfet the circuit is simple but brightness will be effected by battery voltage. Using a dedicated LED driver the brightness would be stable but the circuit more complicated and expensive. Trying to list the pros and cons:

MOSFET
+ Low complexity
+ Low cost
+ High efficiency
– varying brightness depending on battery voltage
– Might stress LED (could be solved with low ohm resistor)

LED driver
+ Stable brightness
+ Not as high efficiency (~80%)
– Higher cost
– Higher complexity

We ended up trying booth. The LED driver design failed due to that the battery voltage needed to be lower than the LED voltage + schottky and it is just in the middle. The PWM design half failed since the LED anode and cathode was swapped in the design but was possible to patch afterward. So at least we got something up and running.

The effect is very nice and it is what we used for the wedding show. The question now is, is this something we should finish and put in the store?

Wedding show

2017-09-25 | Tobias | Leave a comment

It was inevitable. At some point we needed to do a drone show of our own and wouldn’t the best occasion be on one of our coworkers wedding party! Well we have done demos before on maker fairs and conferences but never a one time show. This time we also had the possibility to collaborate with an acrobat, namely Arnauds brother, Adrien. Perfect match! The only problem was that we only had one day to pull something off and no possibility to rehearse anything with Adrien before the live show. Probably a piece of cake for a true artist such as Adrien but for newbies like us it was definitely increasing the stakes. There was no time to wank about that but better to get our hands dirty.

We wanted to create a choreography with a Crazyflie interacting with Adrien as he did some awesome acrobatics. The Crayzflie should be clearly visible with lights and we wanted it all to be synchronized to music. The final requirement was to minimize the equipment required since the wedding was abroad and we did not want to carry too much equipment.

We decided to use the Loco positioning system as a base to be able to do scripted flight and chose Two Way Ranging to reduce the number of anchors needed. We used only four anchors arranged as a 3×3 m square, three of them on the floor and the fourth 1.5 meters up on a tripod. Two Way Ranging works very well outside of the convex hull (which is really small in this case) but with the drawback that we only could position one Crazyflie – no swarm show.
For the visibility we used a prototype deck with a high intensity LED pointing downwards.

Photo by Eric Cunha

Again to minimize the equipment we decided to pre-program the sequence in the Crazyflie and put a start button on it to run the sequence. The piece of music to be used (composed by the groom during the bachelor party) was about one and a half minute long and the idea was to start the music and the sequence manually at exactly the same time and let them run without any further synchronisation.

We based our purpose built firmware on the demo code from ICRA earlier this year. It contained the sequencing but we had to add functionality to control the LED. We wrote a python script that generated data for the sequence that could be pasted into the firmware. A button was soldered on top of the Loco Positioning Deck and connected to a GPIO pin to be used as a start button.

We are engineers and not choreographers but after some trial and error we managed to create a sequence with light that was synchronized to the music. The overall idea was to start the Crazyflie on the floor in the center of the space, go out into the audience during the intro and turn on the light over Adrian (that was carefully positioned on the correct spot) and guide him onto the “stage”. While Adrien improvised acrobatics on the floor the Crazyflie circled around and above him with flashing lights. At the end of the music the procedure was reversed and the Crazyflie guided him back into the crowd and landed quietly in the center of the stage.

Photo by Eric Cunha

After dinner when it was time for the show we set up the positioning system and the crowd gathered. The first two attempts failed as it turned out that the ceiling of the venue was lower than expected and the Crazyflie hit a beam! What to do? We had a pre-programmed sequence that was going too high! We simply moved the anchors 30 cm away from each other and “stretched” the space to trick the Positioning system a bit. We had not tried this before and live hacking is a bit stressful, but we were possibly strengthened by one or two glasses of wine :-)

The third attempt was almost perfect with an incredible performance by Adrien! Phhuuu and what a success on the third attempt. Heart failure was close but did not kill us this time! :-) Maybe this is why we stay away from live shows and rather sitt down in a dark basement coding :-).

Touchless mouse with flow breakout

2017-09-11 | Arnaud | Leave a comment

Las week we announced that we released the Flow Breakout board. During the week we also played a bit with the board and the outcome is a hackster project that describes how to make a Touchless Mouse using the flow breakout.

The idea is that we can detect the proximity of the hand with the ranging sensor contained in the flow breakout and detect how the hand is moving with the optical flow sensor. The flow sensor is very similar to an optical mouse sensor so we are just inverting the concept to move the environment (the hand) instead of moving the flow sensor against a table. Using an Arduino Leonardo our hack is recognized as a regular mouse by any computer.

As a result, it works quite well but it requires some training to get the mouse to go where we want. We would not use this as our regular pointing device any time soon but we think is a nice example of what can be achieved with the flow breakout board:

Wrong pin header in the Flow breakout board package

2017-09-05 | Kristoffer Richardsson | Leave a comment

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 released

2017-09-04 | Arnaud | Leave a comment

We are proud to announce that the Flow breakout board is available in our store!

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!

Improved swarm support in Loco Positioning with TDoA 2.0

2017-08-28 | Kristoffer Richardsson | Leave a comment

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.

Playing with the Flow deck

2017-08-14 | Kristoffer Richardsson | 9 Comments

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.

Link to video

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.

Link to video

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.

The code for the swarm is available as an example in the python library.

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.

Crazyflie-based quadcopter with Raspberry pi camera

2017-07-31 | Kristoffer Richardsson | 6 Comments

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.