During the design-phase of the Crazyflie 2.0 products last year, we sat down and had a long discussion about testing. In order to make sure things runs smoothly, it’s best to make sure that the hardware you’re designing can be tested properly in manufacturing. It could be as simple as adding a few test-points or a bit more complicated like making sure the product can run self-tests to cover some of the testing. There’s also other factors that count, such as the time it takes to test one unit. The better the tests are the less hassle you will get down the line and the happier your customers will be. The cost of finding a faulty board during production is very low, while finding faulty units in the field can be a costly process.

When it comes to the Crazyflie 2.0 we tried to think all of this though during the design-phase, walking though the schematic and making sure that everything could be tested properly in manufacturing. Since the new design is more complex then the old one, we also ended up with a test procedure with more steps and more things that could potentially go wrong. So we felt we needed some way to keep track of the products all the way from the production, to faulty units we might get from customers. Figuring out how faulty units might get passed the testing is crucial for improving it. But in order to acheieve this you need some way to track each board, thankfully for us this was already solved.

Both the Crazyflie 2.0 and all the decks fitted with a 1-wire memory have a unique identifier, a serial number. So these can easily be used for tractability. But without any information to trace it not very useful. So we built a simple framework for reporting as all of the test data back to our servers where we could easily look up what was happening. Here’s a screenshot of what it looks like for a tested Crazyflie 2.0 (1-wire memory products look similar):

So what’s all the information? Well, here’s a quick rundown:

• Run list: Each test that involves the serial is listed, so it’s easy to select which one you want information about
• golden_sample: Serial of the golden sample unit
• power and power_d: The measured power and power deviation from the golden sample
• freq and freq_d: The measured frequency and frequency deviation from the golden sample
• Tests: The framework allows for a number of tests to be defined, the result of each test is reported and if the test fails it’s possible to see in which step this happened
• Console output: For the Crazyflie 2.0 there’s a special case of being able to see the console output when the unit is started

There’s of course a lot of other nifty features with having this setup, like getting production updates in real-time and being able to look at lots of statistics. All in all we’re pretty happy with the system, but there’s still lots of things to be added. Oh, and if anyone is wondering what happens if the internet connection is lost: It’s all saved locally as well (and uploaded when the connection is recovered). Plan for the worst and hope for the best :-)

If you’re interested in seeing what some of the rigs looks like, then have a look at this old post with some pictures from when we started up the Crazyflie 2.0 manufacturing.

So last week we had a bit of fun connecting the Crazyflie 2.0 to a bigger quad frame. This is something we did a while ago with the Crazyflie Nano (1.0) , see this forum thread. This time it was the Crazyflie 2.0 turn and we wanted to use the deck port and the proto-deck so it would be easy to attach and remove, which is a great thing with the deck expansion port. Rewriting the current motor drivers would be the easiest way forward so finding 4 suitable timer outputs on the deck port was the first step. Looking at the pin mapping from the STM32F405 datasheet and the deck port you get something like this.

From this map one can identify a couple of timers and on pin 7,8 left as well as pin 1,2 right there are some suitable ones, TIM3_CH2, TIM3_CH1, TIM2_CH3 and TIM2_CH4 respectively. The timers will be used to generate a PWM control signal for the brushless motor controller (BLMC). As the deck port also has the VUSB input, from where the Crazyflie 2.0 can be powered (and charged), it can be externally powered from 4.5V – 6V. The Crazyflie 2.0 electronics consumes about 100mA without power optimization, can be good to keep in mind when powering it from something else. With all this information we took a prototype deck, a 2.54mm header, some small wire and got to work. As we already had a frame we wanted to interface with we tailored the output for this, but one could of course tailor it for other quad setups.

And viola, the final results looks like this.

We must inform you that this setup is very experimental, and as we are now dealing with dangerous things, much more care must be taken. So don’t do this if you don’t know what you are doing. The software also needs additional safety features before we think it is really usable in a bigger setup.

Next post will be about what to change in the software to make it all work, until then, happy hacking!

By the way Fred released a new version of the Android app last week, nicely done Fred!

While we where in the US we finally received our long-awaited HackRF Blue. Our plan was to use it to sniff the Crazyradio and Crazyflie communication in order to be able to better debug the communication.

HackRF Blue is a lower cost build of the open source HackRF One. It is a Software Defined Radio (SDR), you can think of it as a sound card for radio. It allows to observe and manipulate radio signals from ~1MHz up to 6GHz within a maximum bandwidth of 20MHz. We use it with GNU Radio on the PC which is a signal processing library that contains all we need to do using SDR. Gnuradio has a nice GUI, the Gnu Radio companion, that allows to start testing without having to write code (this GUI actually output a Python program). Getting into SDR is not easy, we have been looking at the Michael Ossmann’s SDR videos (I suggest you look at them if you want to learn about SDR!) and it helps a lot understanding what to do. In this post I will try to briefly explain the step to detect and decode the Crazyradio nRF24 signal. We wrote an howto in the wiki if you want to set up an nRF24 sniffer.

To test the HackRF I just created a very simple python script that sends 10 packets per seconds with Crazyradio:

from crazyradio import Crazyradio
import time

cr = Crazyradio()
cr.set_channel(26)
cr.set_data_rate(cr.DR_1MPS)

while True:
    cr.send_packet((0,1,2,3,4))
    time.sleep(0.1)

Then we just tune HackRF to the Crazyradio frequency, and we can see the GFSK signal!

GFSK is a kind of Frequency Modulation. Which means that it should be a cosine wave of constant amplitude. So calulating the magnitude of the complex signal allows to locate data packets by setting the scope trigger:

Now that we can synchronize on a packet, we can add a filter and a quadrature demodulator to demodulate the fm signal and show the data packet (in green):

The preamble (series of 0101010101) is clearly visible followed by the radio address which is 0xe7e7e7e7e7. Now the ‘only’ things left would be to decode the packet. Hopefully for us Cyber Explorer already did the hard work and all we have to do is to send the demodulated data in a unix fifo and send the fifo in the decoder. This procedure is explained in the wiki. As a result we receives the packets:

As a conclusion we found that with the current setup we have a lot of packet lost. We also have a sniffer made out of an nRF51 evaluation kit and it gets much more packets so it is still preferred to analyse protocols. However we can still enhance the SDR algorithm and the 20MHz bandwidth of the HackRF will allow us to sniff on many channels at once, making it perfect to debug channel hopping when we implement it for the Crazyflie.

More people

Bitcraze is expanding and we would like to present them

Kristoffer – co-worker

Kristoffer has a background as software developer in various areas such as synthesizers, audio/video compression, mobile phones, finance and web. Even though programming is his main trade, he has a keen interest in automation, test, agile methodologies and self organising companies. There will be interesting times ahead!

Theodor – intern

Theodor studies international trade in france and he will help us on the marketing side of our business.

Viswanth and Khalil – master theses

Viswanth and Khalil are studying wireless communication at LTH and are doing their master theses on dynamic mesh networks. They plan to finish their work in Q4.

MIT

While we are trying to fly over a kinect, this is what MIT is doing. Cool stuff!

Read the paper and look at the code in github.

On a side note, we have been featured on a website called eeweb. It contains lots of news about embedded electronics, nice to be featured.

So we are back at our office and the “great” Swedish weather. We don’t miss the California sunshine at all, we promise.

We have spent the last days documenting the setup we used to fly the Crazyflie autonomous using the Kinect2 for position control. It is still a work in progress but we think it worth sharing as we think many of you out there will be way better at improving it than we are. What we like so much with this setup is that it’s affordable compared to the professional systems such as VICON and PhaseSpace which makes it possible to play with at home, in the office or at school. It might be limiting in volume but until an affordable system such as the Valve’s lighthouse is available it is a pretty good alternative.

We have put all documentation on the wiki and hopefully it should be pretty straight forward to setup and get up and running.

The Kinect uses its IR time of flight sensor to detect the altitude of the copter. The image processing is detecting the copter and then gets its position. The controller can the compare the current versus wanted position and then sends correction to bring the copter closer to the wanted position. These correction are sent to the copter until a new image is taken by the Kinect and a new correction is calculated. This closed loop process will keep the Crazyflie in the wanted position.

Here is a short video showing it in action.

We also thought it would be nice to show some more pictures from the Makar Faire Bay Area and our visit to USC!

[Show as slideshow]

We were at Maker faire bay area 2015 and that was an awesome experience! Thanks a lot to everyone that came to meet us.

Our demos finally worked quite well. We had a Crazyflie flying autonomously for a total of about 24 hours during the faire and we could play music using a Crazyflie with a Buzzer expansion boards.

We are still in the US with limited Internet access but as soon as we return to the hyper-connected Sweden we will push codes and documentation Online so that you too can get autonomous flight with your Kinect 2.

So we did it again, forgot to post our Monday post on Monday. Are we getting sloppy or maybe it was the 16 hour travel to US that put us off track, well we need to shape up anyway! :) This Tuesday we have been visiting the USC robotics labs, more about that will come on a later post. Thanks Wolfgang for organising our visit and everybody for showing us around.

So now it is all about Maker Faire Bay Area for us. We have been putting in a lot of time to get the demos working and now we are getting really close. The autonomous control with Kinect 2 is starting to work but we must say, tuning the position PID controllers has turned out to be hard but we have some basic hovering working.

We have also been working on some LED-ring and buzzer control from the PC side. That is working really well and it is all setup using 0MQ to the cfclient. We are now able to play MIDI over the Crazyradio to the Crazyflie: MIDI -> 0MQ -> cfclient -> Crazyradio -> Crazyflie -> buzzer & LED-ring.

As soon as  we are back from Maker Faire we will make all the code available (because now it is in the quick and dirty stage)!

So once again, we would love to meet up so please come and visit ut as at our booth at the Maker Faire Bay Area!

Yes, next week we are packing our bags and traveling the ~8500 Km from Malmö, Sweden to visit the Maker Faire Bay Area outside San Francisco and it is going to be great!

We are planning some nice demos including autonomous flight with kinect2 and wireless computer controlled light effects using the LED-Ring so be sure to check us out! We are really looking forward to this event and we really hope you can pay us a visit if you are attending the Faire!

This weeks Monday post is a guest post written by Wolfgang Hoenig from University of Southern California.

What’s better than a single Crazyflie? A swarm of them! Our research group at the University of Southern California is the Automatic Coordination of Teams (ACT lab), and we research collaborative problem-solving with multiple robots. The Crazyflie is a great platform for research because of its openness and extensibility; additionally, the size allows us to test algorithms on a swarm of robots even in space-limited indoor environments.

Picture of the lab taken when 6 Crazyflie 2.0 are flying. Crazyflie are a bit small so an ellipse is drawn around them.

After obtaining 6 Crazyflie 2.0 quadcopters and 1 Crazyflie 1.0 for our lab, we started looking into how to fly them at the same time — a basic requirement for any swarm experiments. The official Bitcraze GUI can only connect to a single Crazyflie at a time, although the underlying library comes with basic MultiFlie support. In particular, there is an URI (Uniform Resource Identifier), which has the following format if you connect using the Crazyradio: “radio://<radioIndex>/<channel>/<datarate>”. Here, radioIndex is a number starting from 0 for each attached Crazyradio, the channel is a number between 0 and 125 describing the frequency, and datarate is either 250K, 1M, or 2M. The obvious solution is to just buy one Crazyradio per Crazyflie and use separate radio indices in the URI. To avoid any form of interference, different channels need to be chosen as well. This approach has two drawbacks:

1. The number of Crazyradios increases pretty fast, and using 7 radios for 7 Crazyflies definitely becomes unwieldy.

2. The 2.4 GHz band becomes occupied – finding enough free frequency bands might not be easy if there are many other networks, such as Wifi or BlueTooth, around.

Bitcraze addressed the first issue a long time ago, by allowing to use a single radio for multiple Crazyflies. This approach uses PC-sided timeslicing: The radio sends a packet to the first flie and waits for an acknowledgment. Afterwards it switches the channel to the next one, and so on. The higher level requests are stored in a queue in Python, with a separate thread for each radio working on the queue. The code lived in its own branch and wasn’t updated for a while, but merging this branch with the master branch was fairly easy. There were a bunch of race conditions in the code, but most of them are hopefully fixed in my branch.

The second issue can only be solved by extending the URI itself by another unique number.

Luckily, the underlying communication protocol (Enhanced ShockBurst) by Nordic Semiconductor does have a notion of addresses. The address can be up to 5 bytes long and was simply set to 0xE7E7E7E7E7 for each Crazyflie. Making this number configurable is easy, but touches many different places in the code. It was implemented specifically for the Crazyflie 2.0, so the following discusses how it works:

1. NRF-Firmware: This firmware runs on the NRF51, the chip which manages the power and integrates the radio. The address can be set in here, but where should we get the value from? I simply mimicked the code for setting the channel, as this was already a feature of the firmware.

In this case, the data comes from the syslink interface, which is a simple serial connection between the NRF51 and the STM32, the second microcontroller which runs the control algorithm.

2. STM32-Firmware: This firmware has access to an EEPROM, which is able to store configuration data permanently, even during power loss. That EEPROM currently stores trim values for roll and pitch, channel, and datarate. Adding another field for the address was easy — Bitcraze even already had a version field and checksum which improves the behavior if the firmware is updated.

3. Python Client: The Python client required three changes:
   1. Adding another configuration option field to allow a 5 byte device address. I basically copied the code for handling the channel again, plus did some additional UI work to allow a user to input hexadecimal numbers.

   

   2. Updating the URI to “radio://<radioIndex>/<channel>/<datarate>/<address>”, where address is a 5-Byte hexadecimal number. For compatibility, the following URIs are equivalent: “radio://0/80/250K” and “radio://0/80/250K/0xE7E7E7E7E7”. This allows all existing code to work exactly like before.
   3. Adding an input field in the connect dialog to select an address. Scanning over all possible addresses isn’t feasible: There are 2^40 different possibilities!

   

What does this mean in practice?  That it’s now possible to control 6 Crazyflies just with 3 radios.

All these changes are already part of the official repositories; however, you’ll need the multi_radio branch to use multiple flies per radio.

And there’s even more to look forward to: An improved firmware of the Crazyradio could greatly improve the performance of the timeslicing and thus allow us to control more flies with fewer radios. Luckily, Bitcraze has already started working on it.

If you’re a researcher and use ROS, you can use our ROS driver to create your own CrazySwarm. It supports Crazyflie 1.0, Crazyflie 2.0, and the Multi-Radio and Multi-Addressing described above. It even comes with a controller to use with a motion capture system!

Have fun flieing!

Wolfgang Hoenig
PhD Student
Automatic Coordination of Teams Laboratory
University of Southern California

If you haven’t already noticed, you’re not on bitcraze.se. You’re actually on bitcraze.io (and on HTTPS). After a long week of researching, testing and holding our breaths, we’re finally on our new domain. You would think that it’s not very complicated, but as always the hole is deeper than you think… We will keep our old bitcraze.se address for a long time to come, but it will be redirecting to the io domain (this includes email). The only thing we have left to move is the forum, and it’s on it way.

A couple of weeks ago we wrote about our Monday post tradition where we post a blog-post every Monday. Sometimes we spend lots of time testing and documenting to come up with something to write, and sometimes it’s just a quick note. And that’s the way it’s been for years. But last week one of our community members (Wolfgang) offered to write a post about what he’s been up to in the USC ACT-lab. We were really excited about the offer and it spawned the idea of letting more people write guest posts. We’re really happy to see that there’s lots of interesting things happening in the community and we would really like people to get a chance to show off what they have been working on.

So if you’re working on something with your Crazyflie and would like to write a blogpost about it, drop us an email and we can see if we can fit it in!