Blog

It’s been more than a year now since the Crazyflie Nano Quadcopter was released and it’s been a great journey! It’s been great to see users all over the world assembling their Crazyflies and doing all kinds of things with them. The list of cool things that have been done is long! During this time we have gotten feedback on what we can improve. We have also had time to reflect on what we think we could do better. So since some time now we have been discussing what we should change if we had the chance to make a second version of the Crazyflie. We think the time has come for an upgrade, so during the last 6 months we have been trying to sort out what we can do (and what is just too crazy..) and we have finally landed on a design that we hope you will like.

So it’s finally time to announce our new Crazyflie, the Crazyflie 2.0! Honestly we tried coming up with a cool name, but 2.0 just felt so geeky we couldn’t resist :-) During the upcoming months we will write lots of post detailing the features and design of the new version, but here’s a quick overview. First some of the things that we have seen users requesting:

  • No more soldering: The new design features connectors for the motors so you will not need to do any soldering.
  • More robust shape: We redesigned the PCB shape to withstand more punishment by changing the + shape to an X shape and also making the “wings” thicker.
  • Bluetooth Low Energy: Lots of users would like to fly the Crazyflie directly from their phone. To accomplish this we decided on adding Bluetooth Low Energy support while keeping compatibility with the current Crazyradio.
  • More payload: Lot’s of users would like to lift more payload than the current Crazyflie can handle. To accomplish this we have upgraded the motors from 6 mm to 7 mm, which increases the payload with about 2-4 times. It also makes it a lot more aggressive and fun to fly ;-)

Aside from user requests, we also have a couple of things that we wanted to improve and would give users much more possibilities to experiment and explore flying robotics:

  • Improved expansion-port: We have removed the old 2×10 header and instead added an expansion interface that has better mechanical stability and is easier to use. The interface is two 1×10 2.0 mm pitch connectors, spaced 22.0 mm apart. To maximize the flexibility users are able to stack boards on top of each other, both on the bottom and on the top. This will of course affect aerodynamics and flight time, but gives users lots of exciting possibilities.
  • Improved radio range: To be able to do more experiments using the Crazyflies outside we wanted to improve the range of the radio. This has been done by adding a radio power amplifier to the Crazyflie and also to the Crazyradio.
  • Dual-MCU architecture: Dedicated MCU for power-management/radio-communication and updated main MCU for control and application.

When moving to the new platform we don’t want to have two different firmwares for the new and current Crazyflie. Therefore we are doing major changes to the firmware in order to support multi-platform. Our goal is to keep full compatibility with the current Crazyflie as far as the hardware will permit, so any improvements done on the new Crazyflie will also be available on the current Crazyflie. We are still hashing out the details of what this will look like, but we are looking at abstracting all hardware-related code from the core platform.

Much of the design is in place for the Crazyflie 2.0, but there still some things we don’t know yet. Here’s a list of things we will haven’t decided on or tested, that we think you might be interested in:

  • Flight time: We still haven’t decided exactly on the battery so we have no measurements for this yet, but we are aiming for something similar to the current Crazyflie.
  • Weight: The size of the bounding box of platform will be the same (i.e. length and height) but the board is packed with more things, the PCB is a tiny bit larger, the motors are heavier and the motor mounts are different. Due to these things not being finalized we don’t have a final weight yet.
  • Radio performance: We are still tweaking and measuring the radio performance, so we don’t have any exact measurements that we can share.
  • Release date: We are always careful when promising specific dates, since we know it’s hard to keep them. At this point we could still hit some major roadblocks, but so far things are going according to plan. That being said, our aim is doing a pre-order of the new version at some time during the late fall.

We think that all of this sounds great (of course :-) ), but we are very eager to hear what you think about it. Does the Crazyflie 2.0 sound interesting? Is there something you would like to add or remove? Leave a comment below and let us know what you think!

Like we mentioned a couple of weeks ago we went to Devoxx UK last week exhibiting the Crazyflie. We got a chance to do lots of fun things, like flying the FPV quad in the keynote and also over the exhibition floor. The image is a bit faded, but we had the luck of having a projector next to us that we hooked up the FPV receiver to so the video feed was projected on the wall behind our booth. Our booth was next to the NFC ring exhibition which had a nerf gun that was unlocked when wearing their NFC ring. We quickly came to the conclusion that trying to shoot the Crazyflie down with the nerf-gun was the way to go :-) It can actually take a couple of direct hits before going down!

On Thursday night we jointed the IoT hackathon hosted by IBM. We got an Arduino with lots of sensors that we were supposed to interface from Java. Unfortunately we didn’t do too well on the Java front, but we managed better with the Arduino. We decided to use on the thumb-joysticks for controlling roll/pitch and a light sensor for controlling the thrust. Our first plan was to use a microphone for controlling the trust with the sound-level, but we realized that might be a bit too tight with time. The joystick and light values are sent via the UART to the PC and picked up in the Crazyflie Python Client using a modified version of the joystick drivers. Instead of reading events from PyGame we read data from the serial port. This makes it alot easier to debug since we get feedback from the input-device directly in the UI. In the end we got it working (kind of..) so we could fly and actually won the hackaton! So now we have a box of sensors that we can  play around with. Below is an image of the sensors connected to the Arduino.

arduino_devoxx_uk

We are glad to announce that we got a reinforcement to our team. His name is Miguel Piteira Gomes and just got out of school where he studied mechanics. Now we can finally do other stuff then electronics and software! Miguel comes from Portugal and will help us out during the summer. We wish him a big welcome!

Miguel

We are always looking for fun things to hack together using the Crazyflie. The last couple of weeks we contributed to two exciting open hardware campaigns on Indiegogo that we are hoping to get our hands on soon.

The VoCore

First up is the VoCore, a coin-sized SoC breakout with WiFi running Linux. Based on the RT5350, it could be used for WiFi control (with AP support) or to add extra power for doing calculations.

The second one is the 3Dpad, an open source gesture controller. We have been using the Leap Motion for flying before, and we are really eager to try the concept but with an open source project. Even tough the 3Dpad doesn’t support the same hand/finger tracking as the Leap Motion, we are hoping that we can hack together a usable controller for the Crazyflie. It uses capacitive technology that makes it possible to place it behind materials that are not transparent. Imagine placing it under the desk and flying with your hand above the desk!

Best of luck to the projects with financing and development!

This week we were planning on recording some FPV videos around the office with a new transmitter that gives us better range. But after battling with our USB capture device for a while we finally gave up. We will have to try to find a better one (that hopefully works in Linux!). But until then here’s two videos. First one from BBC is about the exciting future for flying robots (thanks to phenoptix for tipping us off to this one) and the second one is the recording from our presentation at Devoxx France a couple of months ago. The presentation is in French and you can pretty quickly guess who is the native French speaker and who is not :-)

Last year we presented the Crazyflie at Devoxx Belgium and last month we got a chance to do it again at Devoxx France (but in french). To complete our Devoxx tour we also accepted an invitation to Devoxx UK. But this time we won’t be presenting, we will only be flying :-). Normally when we speak conferences we hang out at the conference before and after the presentation. It’s a really great way to meet other geeks, discuss and have a lot of fun. So this time around we will only be hanging out in the exhibition hall. If you are going make sure to come by our table and do some flying!

It’s been a while since we summed up things happening in the community so here’s some of the things that are happening. There’s lots of more things, so if you think we are missing something, then post it in the comments below.

Ralph has been doing some work on an semi-automatic flip feature in the client. There’s more info on the forum and video below.

Last week we tested some modifications made by otto for a headfree mode (i.e yaw only rotates the platform, not the referance direction). It’s a really nice feeling just rotating without taking care of the direction you are going in :-) There’s more information and links to code on the forum.

The SHERPA project have been working on swarm algorithms using a vision system and the Crazyflie.

Geof from Centeye have been working on optical flow stabilization using the Crazyflie. He has a prototype board working and there’s lots of information in the forum about this build. To see the results have a look at the video below.

Thanks to Victor the Deviation firmware for Devo-7e (custom firmware for Devo RC-controllers) now has support for the Crazyflie (needs hardware hack). If you would like to give it a try have a look at the code or grab one of the nightlies.

Researchers at the University of Tokyo have been testing a new concept for a HoverBall using the Crazyflie. Imagine throwing a ball into the air that doesn’t come down (well not right away at least..). Here’s some more info and a picture.

We have also seen some nice stand alone controllers for the Crazyflie, one by  MidLifeCrisis (more info here) and one by ivandevel (video below) . There’s also more info in the forum.

There also some updates on the work done by Oliver on the Kinect tracking of the Crazyflie. A demo video is shown below (it looks great!) and there’s more information on the forum.

And finally here’s a nice video we found on Youtube showing position control of the Crazyflie using a VICON system.

Continuing our post last week here’s a video showing the Adafruit NeoPixel ring and some of the effects that we did. The client code still needs some cleaning up, but the firmware is pushed here.

The firmware implementation includes two parameters, ring.neffect and ring.effect. The first parameter is used to know how many effects are implemented and the second one is used to set the index of the effect that should be used. For our current implementation we just loop though all the effects with either a joystick button or using the thumb together with the Leap Motion. It’s also possible to use these parameters directly from the UI as seen in this blog post.

Params for NeoPixel

 

Some of the effects we implemented are just blinking patterns, but we also wanted the ability to show feedback from the firmware using the ring. This has been enabled by adding an API in the firmware to access variables exposed though the logging framework. Using this API the firmware can access the same variables in the logging as the client. This enables all kinds of fun possibilities. In the video you can see (blurred) our implementation showing which direction the Crazyflie is tilting, but we have also been working on showing thrust (think rocket :-) ) as well as other things. We have done our best to implement a couple of effects, but there is so much more cool effects that could be done. So the firmware allows for custom effects and also for mixing multiple effects together (see this code).

A couple of weeks ago we found the NeoPixel ring from Adafruit at a local shop, we had to attach this neat board to our copter and see what cool effect we could make with it. The ring has 16 RGB LEDs that can be driven independently with only one data wire. The LEDs the Neopixel contains are called WS2812.

This post is describing the development of a WS2812 driver for the Crazyflie. A later post will show the usage we did of it (fairly limited in comparison of the seemingly endless possibility, as usual we have more ideas than time to execute them :-).

The WS2812 LED

First of all we needed to see how to control the LEDs. The protocol used by the WS2812 is quite simple but special. All LED on the ring have a data input and a data output pin in a chained manner. Colors of the LED is send over the Data line to the first LED that will save it internally. When sending a second color the first LED will send the saved color to the second LED. And so on, by sending 16 color data we can set the color of all LEDs of the ring independently. Colors are sent as 24 bits (8 bits per component).

Up to there nothing is really peculiar, the system is pretty neat and allows to control a lot of LEDs with just one IO. The problems comes with the Bit encoding:

ws2812_format

Bits are encoded with pulse width: a short pulse means 0 and a long pulse means 1. The bitrate is of about 800KHz and the tolerances on bit timing is pretty tight. As there is no hardware peripheral dedicated for this (on common microcontrollers), this bitstream needs to be implemented either by bit-banging or by being a bit creative with the peripheral we actually have at our disposal.

Driver implementation

Adafruit did implement a driver for the WS2812 for Arduino, this is a software implementation that uses the CPU to implement the signal. However at that bitrate a software/bit-bang implementation have to be timed carefully and the easiest for that is actually to implement it in assembler. Arduino runs on an AVR processor and these processor are very predictable: each instruction runs in a specified number of clock cycle which makes it possible to implement a timed loop like the one of Adafruit. However this becomes impractical on bigger CPU that implements caches and other optimization that makes it really hard to predict how much cycle each instruction will take.

The Crazyflie runs a STM32F103 based on an ARM Cortex-M3. This is just complex enough to make the ASM-timed loop impractical: The CPU core runs at 72MHz but the flash is slower so a simple cache memory is inserted in the middle and depending of the state of this cache it may take from 1 to 3 cycles to execute an instruction. There is an even bigger problem: a CPU timed loop requires to stop all interrupt and to have the CPU running exclusively on updating the WS2812. We cannot allow that on the Crazyflie that require a 250Hz control loop to stay (controllably) airborne.

We asked Google to see if someone already came with a solution and actually someone did. The Elia’s Electronics Blog posted a neat, well documented, solution using the STM32 Pulse Width Modulation (PWM) capabilities of the STM32 to generate signals that the WS2812 understands. All we needed was a timer/pwm output then. It happens that we have one timer1 output on the Crazyflie extension port:

crazyflie_neopixelring

This is only 3 wires: VCOM for the battery voltage, GND and the timer output.

I started porting the Elia’s code to the Crazyfle. The only free timer we could easily use was different and much more complex than the one Elia uses. So part of the frustrating implementation was to figure out WHY the signal was looking weird on the scope! Finally after an hour or so the code was working:

IMG_20140411_202251

Enhancements

Now that was not quite enough. The driver is using the PWM to generate the 1’s and 0’s pulse width and the DMA is used to feed the bit width independently of the CPU (so that it can do something else, like controlling the copter attitude…). It requires all the 16 LEDs data to be written in the memory buffer before starting the DMA. Each LED has 24 bits color data and each bit will be encoded as 16bit pulse length for the timer. It means that the full ring will take 768Bytes in RAM. It sounds small but its a bit too much for us and, most importantly, it does not scale: if we want a second ring the ram requirement will double.

To fix this I implemented two things: An easy one is that the DMA can do some type conversion and one of these is that it can read 8 bit in memory and write 16 bit in the peripheral. This allows to store only 8 bits pulse width in memory and so divides by 2 the memory requirement, but it still doesn’t scale.

The fix to scaling is double buffering. The STM32F103 does not implement DMA double buffering as such but what it has is close enough: circular DMA with half-transfer interrupt. The idea is to load the 2 first LED in a buffer and to start the DMA for 42 bytes in circular mode. When the DMA has transferred the first LED it triggers the half-transfers interrupt which allows the CPU to replace the first LED data by the 3rd. When the 2nd LED is transferred the transfer-complete interrupt is triggered by the DMA and the CPU fills in the 4th LED in place of the 2nd one. The DMA roll-over at the beginning of the buffer and sends what is now the 3rd LED data. This continues until all the LEDs has been  sent. This solution scales: it requires a 42 bytes buffer for as many LED as we want!

Conclusion

All that process was not really simple. However the result is simple, now the only thing required to control a Neopixel ring in the Crazyflie is:

 

#define BLACK {0x00, 0x00, 0x00}</span>
static uint8_t color[][3] = {{40, 40, 40}, {32, 32, 32}, {16,16,16}, {8,8,8},
                             {4,4,4}, {2,2,2}, {1,1,1}, BLACK,
                             BLACK, BLACK, BLACK, BLACK,
                             BLACK, BLACK, BLACK, BLACK,
                            };

/* ... */
ws2812Send(color, 16);

And it will run nicely without interrupting other tasks like control and communication. Replace 16 by 32 to control 2 Neopixel rings. The current implementation has been pushed in the crazyflie-firmware neopixel_dev branch (still require some clean-ups!). Actual implementation is in ws2812.c and neopixelring.c.

neopixel_flying

The only problem left is not software: At the end of the battery life, the voltage is not enough to fully lit the blue LED. That make all white look orange-ish. The only way to fix this problem would be to step-up the battery voltage higher then the forward voltage of the blue LED. Though it works well enough without that.

Stay tuned for a following post about actual usage of the ring.

Most of last week was spent at the Devoxx France conference in Paris. Even though we didn’t have our talk until the end of the week, we hung around most of the time just developing and working. And of course we also got the chance to meet lots of interesting people and demo the Crazyflie. We worked on some code for the NeoPixel ring from Adafruit, implementing some different effects. We also did a quick hack to be able to change effects when flying using the Leap Motion. Since we haven’t had any time to prepare videos/photos of it and to clean up the code, we will post more about that next week.

We also got a chance to do some other fun things, like flying the FPV Crazyflie over the crowd at one of the keynotes and also record some video while flying though the conference.

 

[pe2-gallery album=”http://picasaweb.google.com/data/feed/base/user/115721472821530986219/albumid/6002584693333310545?alt=rss&hl=en_US&kind=photo” ]