Blog

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.

crazyflie vision architecture

 

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!

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

Bitcraze booth

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!

Maker Faire Bay Area 2015

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!

Malmö to Bay area 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! cf2 - kinect2 We are really looking forward to this event and we really hope you can pay us a visit if you are attending the Faire!

mf_bayarea_seeusthere

 

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.

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.
  1. 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.

  1. 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.
  1. 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. wolfgang_config_dialog

    3. 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.
    4. 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!
    5. wolfgang_connection_dialog

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!

Recently I got a Chromebook, mostly out of curiosity for this odd “computer that runs only a web browser”. While playing with Google dev tools I quickly saw a possibility to make a Crazyflie client as a Chrome app: the Chrome API provides USB connectivity,and HTML5 has a javascript gamepad API. A chrome app is designed to look and feel like a native application: the app does not require internet connection and is launched in its own window.

This week-end I finally got around to test it, it’s not pretty but it works :-)

crazyflie_chrome_client

The current functionality is:

  • Channel and datarate can be changed
  • Read input from a gamepad, the mapping is fixed to mode 3 and the sensitivity is fixed
  • Sends set-points to Crazyflie 33 times per seconds.

I haven’t had time to do any layout work on it (that is pretty obvious in the screenshoot :) ), but the plan is to use Angular Material to handle the GUI.

This is only a proof of concept but we are seeing a lot of potential: the Chrome app runs on Linux, Mac, Windows and Chromebook, is easy to install and is written in HTML/CSS/Javascript which seems to be a very popular platform nowadays.

I have pushed the code on Github so if anyone is interested in helping to shape up the app head to the forum to read the discussion about it.

 

When we were developing the Crazyflie, going from our hackish prototype to a production version, we decided to start posting a blog-post every week. Back then we always used to meet after work on Mondays to work on our project, so we named our “once-a-week” update “Monday posts”. The purpose of the posts was to show that things were happening behind the scenes, even if things looked pretty quiet. Developing something from scratch takes a lot of time and there’s not always something interesting happening, so the Monday-posts covered all sorts of things related to the project. We’ve written about the good times, the bad times and everything in between; covering tech, manufacturing, our community and trips that we’ve done.

It’s not always easy to come up with something to write about every week. Sometimes we spend lot’s of time investigating and writing about something (like RPM measurements part 1, 2 and 3) and sometimes it’s just a quick note about what’s happening. But we’ve made a point of always posting something (even on Christmas eve), and have been doing so every Monday since January 2012. So we were a bit shocked this week when we realized that it was Tuesday and we have missed posting something yesterday. But don’t worry, we’re still here and things are still happening :-)

Next month we will be attending the Bay Area Maker Faire. Last fall we visited the Maker Faire in Rome and really liked it! While there we met people from Make that invited us to the Bay Area for the next Maker Faire. It’s an awesome event with lots of technology and geeks around, so we’re really looking forward to it!

In other news we will be switching domain shortly to our bitcraze.io domain and also switching on SSL for the blog/wiki/forum. Our old bitcraze.se will still be around linking to the same site. The move is planned for this week, but like always there might be something else happening that postpones it.

Don’t forget that we still have the CCW-propeller replacement running. So if you have a Crazyflie 2.0 from the first batch and you are having issues with your propellers, then fill in the form and we will ship you a set of replacement propellers.

Last Saturday it was Arduino day 2015 and it happens that the Arduino office in Sweden is in the same building as ours. So we where invited and presented Crazyflie. It was a really fun event with a lot of interesting people passing  by and we had a lot of fun.

Arduino day 2015

There was also Helium balloon, which gave us a perfect occasion to use the blimp hack we did more than a year ago. We attached a brunch of ‘Arduino colored’ balloon to it and flew it around using the Deviation TX. It is definitly something we have to port to Crazyflie 2.o.

blimp_scaled

Finally as the event was hosted by Arduino, and we do not have Arduino compatibility (yet … ; ), we thought we would make something with Arduino and present it. We ended up making a Crazyflie Controller using an Arduino and using a thumb stick and ultrasonic distance sensor that was lying around the office. We attached everything to a glove to make it a ‘wearable’ controller.

arduino_glove

 

 

glove_action glove_closeup

The glove is working as follow: you place your hand over a hard surface (concrete floor or table), click the thumb-stick button to set the zero and from now-on rising the hand higher will increase the Crazyflie thrust. Then the thumb-stick can be used to steer the Crazyflie. The program is quite simple and implemented in a single loop.

Technically the most work has been put in enabling the serial port of the Crazyradio so that the Arduino can send commands to the Crazyflie using the Crazyradio directly without a computer. As there is a lot of pins available on Crazyradio and a voltage regulator capable of accepting up to ~16V, the aim has always been to be able to use it as a radio module for other system. Our first thought was PPM input, but now serial control will also be possible. We are still cleaning up the code and working on other new functionality on the Crazyradio. We plan to release a new firmware soon that will support PPM, UART and a more efficient USB protocol to communicate with many Crazyflies using one radio dongle.

As many out there think is is more fun to fly the Crazyflie rather then develop upon it (like we do :-)) we have quickly looked at ways to pilot it with a RC transmitter. This forum thread is a good starting point for a developer discussion. To summarize it a bit there are many ways of implementing it which all require more or less development and has different pros/cons

  • Attach the Crazyradio PA to the expansion module/port of an RC transmitter.
  • Implement the E-Sky transmitter protocol or other nRF24L01+ protocols in the nRF51.
  • Using the DeviationTx code and a nRF24L01+ module.
  • Attaching a RC receiver to the deck (expansion port) interface.

Today I will write a bit more about the DeviationTx as it is a great open source project and that it has support for the Crazyflie. It was over a year ago we got contacted by Victor who wanted to implement the Crazyflie protocol in the DeviationTx code base, which he did pretty quickly. We feel ashamed for taking so long to try it out. So during the weekend I freed up some time and gave it a shot. The DeviationTx project replaces the firmware in Walkera transmitters with a better one which has the possibility to support a great amount of RC models. However many of them use different transceivers modules so this must be added to the hardware. Well a bit of hardware hacking is always fun and we had a nRF24L01+PA module laying around. They have a module installation document but I found it easier follow this guide as I had the same type of module and transmitter (Devo7e).

devo7e nRF24L01 module

The module installation was done pretty quickly but what took time was to update the firmware. The instructions tells one to download the walkera update tool but I just couldn’t find it on their website, nor the original walkera devo7e firmware (which they recommend to test with first). Thankfully I could find one using google and ended up using this link. Next thing was to fire up a windows 7 virtual machine to install it in which it worked without problems. So did the flashing of the DeviationTx firmware, I flashed the nightly build 4.0.1 and copying the file system according to the instructions. What I forgot though was to edit the hardware.ini file to enable the module which I understood when the protocol selection had a star in front of the name <*CFlie> (OK, I admit, I thought the hardware wasn’t working at first…). Then I setup a new model using the <CFlie> and I used the Fixed ID to setup the address, The data rate and channel are combined in the fixed id using channel as lowest two decimal digits and the rate the first were 0, 1, and 2 for 250kbit/s, 1Mbit/s, and 2Mbit/s respectively. So channel 80 on 2Mbit/s is encoded as 280 and channel 80 on 250kbit/s as 80.

And boy I was happy when I saw the green led (radio com led) blink on the Crazyflie 2.0, but nothing happened when I pushed the trust… Then I remembered, we recently implemented a lock so that a zero thrust must be sent at least once for it to unlock (to prevent Crazyflie to fly away if the gamepad is not setup correctly and constantly sends 100% thrust :). Looking into the source code one could see the trust was at minimum 5535 which was never unlocking the thrust. Removing this lock in the Crayflie 2.0 firmware and it was flying! but in plus mode… The Deviation cflie module code seem to rotate the pitch/roll setpoints.

Next step will be to do some modifications to the Deviation cflie module for Crazyflie 2.0, adding code to unlock the thrust and disabling the axis rotation, then make a pull request to the DeviationTx project for everyone to enjoy.

A big thanks to the DeviationTx project and to Victor for the cflie module implementation! Ohh, and by the way, they are making a universialTx module that will support almost any RC model out there, including Crazyflie, can’t wait to see that.