Category: Crazyflie

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

CF2 release

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.

    Random corrupt I2C transaction when used in VM

    Random corrupt I2C transaction when used in VM

icon_Berlin_dt-150x150@2x

Maker Faire Berlin 2016 is coming up and we will be there to show of the latest and greatest from our lab. The plan is to show:

  • the Loco Positioning system and autonomous flight
  • a (small) swarm – we hope to get more than one Crazyflie in the air at the same time, even though the space is very limited
  • there are ideas of some sort of synchronized sound- and light show with an autonomous Crazyflie, all controlled from a MIDI sequencer
  • a virtual cage to stop a Crazyflie from escaping when flown manually
  • a preview of the Arduino based controller to fly the Crazyflie
  • a Loco Positioning tag that can be used to track other devices/robots than the Crazyflie
  • ROS integration with the Crazyflie and Loco Positioning system

We’re not sure we will succeed with them all, but let’s hope for the best. Is there anything special you are interested in? Please let us know!

Maker Fair Berlin is Sept 30 to Oct 2 at Station Berlin. You will find us in hall 3, stand 149.

We love your feedback and are looking forward to meeting you all and talk about your projects, what we do and future ideas.

See you in Berlin!

 

 

What’s better than a single Crazyflie? A swarm of them! Over a year ago our research group at the University of Southern California posted a blog post with the title “Towards CrazySwarms“, explaining how to fly six Crazyflies at the same time. Since then, we’ve expanded our fleet to 49 Crazyflies. It turns out that flying 49 requires a completely different approach. We will outline the additional challenges, and of course show a fun video!

Why is flying many Crazyflies hard? It comes down to two different categories:

  1. Communication Limitations: The standard Crazyflie software does not support controlling more than one crazyflie per radio. Putting 49 radios on a PC is possible, but would cause very high latencies because the Universal Serial Bus (USB) operates, as the name suggests, serially in 1 ms intervals. Earlier, we showed that we can share a radio for two Crazyflies by using different addresses, but 25 radios are still too much to be handled on one PC reasonably. We can overcome this issue by reducing the amount of data to be transferred. However, this forces us to increase the autonomy of the Crazyflie. Instead of sending attitude control input for each Crazyflie at a high rate, we move the controller on-board and send high-level trajectory descriptions and external position information at a low-rate. In particular, we need to:
    1. Move the position controller on-board, and
    2. Be able to handle packet losses more gracefully.

    i) is relatively easy, apart from the testing and tuning. For ii) we use an Extended Kalman Filter to estimate the state on-board. This state, consisting of the position, angle, and the translational velocities, is estimated by combining the on-board sensors (gyroscope, accelerometer) with external position information. Even if we are not able to send the external position for a while due to packet drops, the on-board sensors will keep the estimated state correct for a while.
    Finally, we implemented broadcasts (rather than 1-to-1 communication between PC and each Crazyflie) and used a number of compression tricks in order to limit the required bandwidth further. We are able to broadcast the pose (position and rotation) for all 49 Crazyflies using just three Crazyradios 100 times per second. Each Crazyflie can handle several packet drops in a row before the state estimate becomes too unreliable to fly.

  2. External Position Feedback: The on-board sensors of the Crazyflie are not sufficient to determine its position, so we need some external position feedback. In academia, optical motion capture systems are frequently used. They consist of a number of specialized, synchronized, high-speed infrared cameras. Each object to track is equipped with at least three retroreflective spheres (so-called markers), which reflect infrared light sent out by the IR light sources next to the cameras. If we know the pose of all cameras, we can use triangulation to determine the 3D positions of all retroreflective markers.Traditionally, motion capture systems require that each object has a unique arrangement of markers; this allows to determine each object’s position from a single frame of marker data by searching for its unique pattern. Unfortunately,  the Crazyflie is too small to have 49 unique marker arrangements that can be reliably distinguished. To solve that issue, we put the Crazyflies at known positions initially and use their marker arrangement to track their position and pose over time, at 100 Hz. This allows us to use the same marker arrangement for each Crazyflie.

 

Putting that together (combined with an improved controller), allows us to create nice formations:

So what is next? Eventually, we will integrate our changes into the various projects (including the firmwares and the ROS driver), allowing everyone to work on and with CrazySwarms.

Have fun flieing!

Wolfgang Hönig
PhD Student
Automatic Coordination of Teams Laboratory
University of Southern California
James Preiss
PhD Student
Robotics Embedded Systems Laboratory
University of Southern California

Summertime is a good time to get outside and play :-). For a long time we have been having an assembled Turnigy tylon frame here at the office just lying around and it was time to put a camera on it and test its wings. It is not really a frame built to host a camera, and the least to put a gimbal on it but the size supports it so why not. So that is what I did, which included plenty of tape, zip-ties, drilling etc. Wouldn’t really recommend this frame and maybe that is why they quickly made a new version. I had a really hard time fitting the motors to the mounts which required getting some motor mount adapters and drilling into the aluminium mount to make them fit. To make the gimbal fit I made some wood extensions of the legs, as that was what I could find lying around. Anyway the result wasn’t that bad so I decided to give it a go. The first flight is always a bit nervous and especially with bigger quads so I took a lot of precautions and triple checked important things. The flight went well without any crash and I just used the stock PID settings when building the firmware. I flew it with the python client and a PS3 gamepad as I normally fly the CF2 and a was watching the signal strength carefully when getting far away. It will not survive a drop from 50m as the CF2 might. The basic functionality of the BiqQuad deck works well but I must admit that there are plenty more to implement before it has a rich feature set.

Unfortunately I’m not allowed to publish the onboard GoPro video I took as it captured some public areas (if I interpret the Swedish law correctly).

As noted in a previous post, Mike Hamer from ETH Zurich has been implementing an Extended Kalman Filter (EKF) for the Crazyflie. The beginning of this week I am visiting Michael at ETH and we have now pushed the EKF to the Crazyflie master branch!

Visiting ETH is really nice, and it is very impressive to see the Flying Machine Arena in real life. Though, owing to the Crazyflie’s size, we do not need such a big space and can work in a more regular-sized room.

The EKF has now been added to the master branch but is not enabled by default. It is currently intended to be used with the Loco positioning system (although it should be easy enough to integrate with onboard GPS, or potentially offboard motion capture measurements). While it does fly better than the currently used, offboard particle filter for autonomous flight, it requires some care to work properly. I am going to update the wiki description for the loco positioning to document how to get started with the EKF during the week. Our hope is that through community engagement and feedback, we can continue to improve and tune the filter, now that Mike has put the basic functionality in place.

The greatest enhancement is that the Crazyflie is now able to estimate its own position, without the help of an external computer. Coupled with the onboard controller, the Crazyflie can now fly fully autonomously. I have also pushed a new example in the Crazyflie python lib that shows how to send an X/Y/Z set-point to fly the Crazyflie, allowing it to fly through waypoints.

In the near future we (Bitcraze, and hopefully, the community!) need to work on a couple of more things to make it fly even better

  • Revamp of the controller: the current controller is a position controller, splitting it in two controllers, one for position and one for velocity, would allow for a more stable flight and to finally use TheSeanKelly new PID settings!
  • Implementing TDOA positioning on the LPS would allow more than one Crazyflie to fly at the same time
  • Implementing the new commander packet in the Crazyflie, python lib and ROS driver. This will allow us to stop hacking the current commander each time we need a new functionality (such as onboard position control) — and since I have push rights, only my hacks get pushed, which is unfair ;-).

Mike will describe the Kalman filter in greater details in a future post. In the mean time we will update on the progress in the Loco Positioning mailing list.

The loco positioning hardware is now manufactured and we are working hard on making it available. Loco positioning is still in early access, which means that we have tested the hardware but that the software still requires some love.

One of the big features still to implement is a position stabilization and position sensor fusion in the Crazyflie. This has been worked on from two fronts in the last weeks.

Community member jackemoore has been working hard on getting the Crazyflie 2.0 with a GPS deck working with position hold. He is getting close to having a GPS position hold working but has stumbled upon some system bugs that have to be solved first. You can follow, or even better help out, with the development on the forum post.

Mike Hamer, from ETH Zurich, has started to implement a Kalman filter, based on one of his publications, for the Crazyflie 2.0 firmware. This is still very much a work in progress but the initial results look promising. Mike has found and fixed a bunch of bugs on the way, which has greatly improved the firmware quality and stability. Since it is able to fuse the position estimate with the internal sensors, the Kalman filter will pair nicely with the GPS implementation from jackemoore to add a new layer of stability, as well as with the Loco positioning system. In addition, the Kalman filter is being written in such a way that it should be easy to incorporate additional sensors into the estimate. Keep your eyes open for a blog post in a couple of weeks with more detail on the Kalman filter’s inner workings, and hopefully a fully functional Kalman filter in the Crazyflie shortly thereafter :-).

We are right now eagerly awaiting the first batch of the Loco positioning system to be done and ready for shipping. The interest for the early access release has been very encouraging and we are super happy about the attention we have received from all around the world.

We have made a new video about how to get started with the Loco positioning system that we hope you will enjoy. The video is showing the process from receiving the Loco Positioning system up to having an autonomous flying Crazyflie. The written information can be found on the wiki.

We are excited to announce that we have just started the production of the first boards for the Loco Positioning system!
Since this is the first batch of a complex new product, we thought we should be there in person. This time, Tobias and Kristoffer went to visit Seeedstudio, our product manufacturer. It is always very nice to meet them in person and to visit the factory.
Also visiting the factory is always an opportunity to discover a new fashion style!

DSC_0525

The first boards to be produced are the Loco Nodes:

DSC_0529

After a minor problem: we specified the LEDs to be mounted reversed, quickly found and fixed for this first batch by the Seeedstudios engineers, the production of the nodes is looking good and the first 8 pieces are flawless!

DSC_0538

To go with the nodes, we need to have the Loco decks. Like for the other decks we have implemented the test rig based on a Crazyflie 2.0 programmed with special flags for the test. We found some issues with the rig software but it has been quickly sorted out. So the launch of the deck production, tomorrow Tuesday, should be without any hick-ups. This is what a deck test rig looks like (note the Crazyflie 2.0 being attached on the bottom):

DSC_0534
In other news we’re welcoming Aman in the Bitcraze team for the summer. Aman is flying straight from Kiruna at the very north of Sweden (before that from Germany and even before from his university in the US). He will be looking at improving control and stability of the Crazyflie. The fist step today was to learn how to fly it manually :-).

While it is a central part of a quadcopter the core of the Crazyflie 2.0 had not moved since we released it. We deemed it to be good enough, it was flying and going fast after all.

Recently TheSeanKelly from the community did not hear it that way and started investigating the flight performance starting by the attitude control PID. The results so far are impressive!

Sean tuned the rate loop a lot, this is the loop responsible to control the angular rate of the Crazyflie in roll and pitch. Doing that and the attitude loop could be tweaked which we did a bit, the one responsible to control the absolute orientation of the copter. And the results is that two major issues with the flight performance seems to be greatly improved:

  • The take-off behavior: Crazyflie is currently not taking-off straight by itself. With the new settings this is fixed and at any thrust Crazyflie just goes straight up.
  • Attitude control: We had a lot of overshot in the attitude control. Basically it means that if you go forward 10 degrees and request 0 degree (level) the Crazyflie will overshoot with a negative angle causing it to stop. With the new tighter control if you ask +10degrees pitch the crazyflie accelerates and if you ask 0 it just stop accelerating. It will then continue at nearly constant speed. This is the “correct” behavior. This also means that the Crazyflie now reacts much more precisely and quickly to joystick controls.

We have tried to make a short video to show the new performance. Though the attitude control is really hard to show. We installed a test pilot on our Crazyflie that shows how much the new parameters helps in overall stability (I have tried to steer with old parameters as hard as I was steering with the new one). We also show more stability in pretty windy condition.

These new parameter have been pushed protected by an experimental flag. After more testing the official firmware will have much better flight performance out of the box :-).