Author: arnaud

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.

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.

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.

Link to video

The Flow deck is available in the Bitcraze shop and at Seeedstudio.

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.

A couple of weeks ago Qualisys visited us at the Bitcraze office, they came with the Miqus motion capture system that they installed temporary in the office. This gave us the opportunity to play with their motion capture system and the Crazyflie 2.0 :-).

It was our first hands-on experience with a motion capture system. We were eager to try the algorithms that have been developed for the loco positioning system with the more precise position information offered by the motion capture. The result was above our expectations. You get a bit amazed when it is just sitting there in the air. The normally difficult in-air photo shoot became a breeze since you suddenly have plenty of time to focus and shoot.

After running a couple of simple stabilized flight demos, we endeavored to run the ICRA demo with motion capture instead of our loco positioning system. As the loco positioning deck isn’t needed it was removed and instead the measured position was sent using Crazyradio. Doing so made the demo work pretty much out of the box. The ICRA demo had 2 buttons, one for playing a pre-recorded trajectory and one for recording a path and playing it back as soon as the Crazyflie is dropped. Both modes worked seamlessly without requiring any code change. We tried the path recording and playback functionality and were pretty impressed by the precision:

Link to video

We look forward of meeting and working more with Qualisys. One goal is to provide better information, documentation and tools to get started with Crazyflie in a motion capture system.

A couple of weeks ago we played with recording and retracing trajectory directly from the Crazyflie using Loco Positioning System. The result was quite nice and resulted, a first for us, in a fully autonomous Crazyflie, no computer or controller required:

We decided to expand on this experiment for our demo at ICRA. We have modified the retracing code to accepts multiple modes, including running pre-programmed sequence. The plan for the demo is to have Crazyflies that can:

  • Record and retrace a manual trajectory
  • Record and replay in a loop a manual trajectory
  • Play a pre-defined trajectory in a loop
  • Land automatically when the battery level is low

With this we should be able to demonstrate quite well the capabilities of both the Crazyflie and the Loco Positioning system, and since we do not require a computer in the loop it simplifies a lot running the demo. Of course we keep the possibility to connect the Crazyflie with the Crazyflie client and with ROS while the crazyflie is flying.

Having a completly autonomous Crazyflie is also new to us and it brings its share of problems: how to we choose the working mode and how to we stop the flight if something happens (things tends to happen …).

To solve the former we have made a button deck that adds 2 push-button to the Crazyflie. One means “Start autonomous sequence”. The second means “Record trajectory”. If the recorded trajectory is a loop (if the end point is close to the start point) then the loop is played back as soon as the crazyflie is dropped, otherwise Crazyflie retraces the trajectory and stop.

We solved the later problem by making an autonomous emergency stop button that sends a radio watchdog signal. If the signal stops to be sent or if an emergency stop signal is sent (ie. by pressing the button), the Crazyflie will stop all motors and drop. The button is implemented using a Raspberry pi, a Crazyradio and an Arduino to interface the button:

If you are curious about code, we have created a github repos where we push all code we are making for this demo. As usual, this conference is an opportunity for us to hack new functionalities, though not everything can be done in the master branch. Later some things can be merged, others (like the retrace trajectory recorder/player that looks more like a user app.) will need much more though if we want to merge it in the Crazyflie firmware.

The past

The Crazyradio has been designed as a radio dongle to control the original Crazyflie 1. It is based on a Nordic Semiconductor nRF24LU1. It is basically the radio from Crazyflie 1, the nRF24L01, with a microcontroller and a USB device peripheral. Crazyradio has been designed from the beginning to be extended for other used: the code is completely open-source, can be powered with 12V and has an expansion port with possibility of implementing a serial port to communicate with the radio.

When we designed Crazyflie 2.0, we extended Crazyradio to make Crazyradio PA. It is basically the same hardware but we just added a power amplifier to make sure Crazyradio is transmitting with the same power as competing radio in the same 2.4GHz band: Wifi and Bluetooth. Crazyflie 2.0 is not using an nRF24 chip anymore but an nRF51822 which integrates a microcontroller and implements bluetooth low energy as well as nRF24 compatible radio.

 

The present

The Crazyradio (PA) has been used for a couple of hack like our glove controller. Another popular use has been by security researcher to experiment with the security of wireless mouse and keyboard. Indeed the nRF24 serie of chip is extensively used in wireless mouse, keyboard and even quadcopters ;).

We are often very quiet about the Crazyradio since ‘it just works’. It does not means that it is finished or perfect, there is actually a lot that was planned to make the radio link more efficient, to be able to control more Crazyflie per Crazyradio, etc… Some of this work has been done in the context of the Crazyswarm project by Wolfgang from USC but a lot more could be done. One of the main blockers for Crazyradio development is that it is based on a very old microcontroller, an 8051, and that it does not have a safe bootloader or (open) debugging access. It means that each modification is potentially a big commitment in time and since the radio already work quite well it is hard to put much time in it.

The absence of a safe bootloader means that if you flash a firmware that crashes, you will need an SPI programmer to recover the radio in working mode. This makes it quite stressful to work with the radio. However there are a couple of programmers made for this and we recently published a Hackster project about using a Raspberry Pi to recover the bootloader:

The future

We have been looking at making a Crazyradio with an nRF51-series chip, these chips have a Cortex-M0 CPU which means that they are much easier to program using a modern development environment. However none of the chip in the nRF51 series have USB which forced us to prototype the concept with an added microcontroller for USB. This creates a bigger and more populated Crazyradio:

We did not like this design very much since having 2 microcontrollers is always much more haste to program, debug and maintain. Thankfully Nordic semiconductor will release a nRF52 chip with USB support. Adding to that a powerful Cortex-M4 microcontroller, a lot of ram, still Bluetooth low energy and nRF24 radio compatibility but they also added iEEE802.15.4 2.4GHz (ie. the protocol used by Zigbee). This new chip is a very good candidate for the next Crazyradio.

We are very much in the pre-study phase for the next Crazyradio (and mass production for the new nRF52 is planned for Q4 2017 anyway…), so if there is functionality that you would like to see in a future Crazyradio it is time to speak up! Please tell us in the comment section bellow or in the forum ;-).

We are happy to announce that we have released new versions of the Crazyflie Firmware and the Crazyflie client, both are now in version 2017.4. The main feature of the release is support for the new Z-Ranger deck.

To support the Z-Ranger, a new flight mode has been added to both the firmware and the client: the Height-hold mode. This mode allows to fly with the Z-ranger deck at a fixed height above the floor.

There are also a number of other improvements and bug fixes in the releases, mainly related to the Loco Positioning system and autonomous flight.

On the client side, this new release is also a come-back of the windows build. It means that it is now easier to get started and fly your Crazyflie directly from Windows as you can install it as a native app. We really want to build the client for Mac OS too but have met some problems. If anyone has experience in building pyqt apps for mac OS, with your help we might be able to have a mac build for the next client version ;-).

For instructions on how to upgrade see the getting started guide.

Have fun!

At Bitcraze we have some history with trying to fly our Crazyflie autonomously. The most recent step is the Loco Positioning System that allows us, and you, to fly in a full room. The Loco Positioning system has boosted development of advanced algorithms for onboard position estimation and control.

Our earlier attempts where mostly based on different kinds of cameras, either a 3D camera like Kinect or regular webcams. Though, at that point, we only had the camera for position estimation and where doing the position control on the PC and not onboard the Crazyflie. This has the disadvantage to be brittle and requires a very high quality positioning from the camera: any frame where we loose the Crazyflie has a huge impact on the control behavior since the position controller relies exclusively on the camera detection.

With the Kalman filter and onboard position controller, the Crazyflie can now handle lost position information for at least a couple of seconds without big problems. This has the potential of making webcam-based position detector much more robust!

To test this theory we have grabbed the 2 years old crazyflie-ar-detector from the dawer github, updated it to OpenCV 3.2.0, and fed the position output to the Crazyflie 2.0 external position port. The crazyflie-ar-detector program is using ZeroMQ to communicate position and so we made a simple external position tab for the Crazyflie Client that receives position from ZeroMQ and sends it to the connected Crazyflie.

Using the new position-hold mode recently introduced in the client we can test and fly the Crazyflie under the webcam. We have taken a short video to show the performance. The result is promising and we will continue to play with ways to fly the Crazyflie autonomously.

The Crazyflie client, the software running on a computer that is used to control and get telemetry from the Crazyflie, is written in Python and used PyQt4 as graphical user interface framework. This has worked quite well and has the advantage of running on windows/mac/linux without much effort. However Qt5 and PyQt5 have been released for a long while now and what should happen is starting to happen: PyQt4 is starting to get depreciated.

The first sign came from macOS, a ticket was reported on the Crazyflie client github indicating that it was not possible anymore to install PyQt4 using the Homebrew package manager. The problem was solvable since PyQt4 was still there but moved in the Homebrew ‘backyard’, so for the time being it still works but is a bit worrying. More recently Python 3.6 was release and there will apparently not be a release of PyQt4 for Python 3.6, this means that if we do not do anything the client risk to not be supported on linux anymore (the next Ubuntu LTS is planned to use Python 3.6).

This was enough to push us to port the client to the new Qt/PyQt5. The port was started by sighmon when the first macOS related ticket was reported but we had a bad bug with the Gamepad reading on macOS, this bug was the main blocker but has been fixed last week so we are now very close to having the port functional!

If you are curious about it, we have the port in a branch on github. We are planing on merging it in the following days and releasing a new version of the client in the process.

We are also planing on releasing a Windows build and installer this time. The Windows installer has been built automatically in AppVeyor for a couple of month now and it seems stable enough to become an official version. We still want to make a macOS app out of the client but are still blocked in doing so. If you have experience making macOS app out of PyQt5-based software, we would greatly appreciate some help in getting a mac build, we have a github ticket for it.