Blog

As early as when the first Crazyflie prototype did it’s first flight back in 2009, we where dreaming about a local positioning system that would allow our future micro quadcopter to fly autonomously indoor. This dream is now becoming a reality with the development of the Ultra Wide Band radio that we have been using the last months to develop our own local positioning system for the Crazyflie 2.0. We are now reaching a very important milestone: the first early access production batch has been ordered!

We sat down to find a name for the system and since ‘Crazy’ is kind of a theme for our products here at Bitcraze we settled for “Loco Positioning”. So the two products we are about to launch are the Loco Positioning Node and the Loco Positioning Deck.

If you want to receive information as the system evolves, sign up to our mailing list. If you want to talk to us directly do not hesitate to comment or send us a mail at locopositioning@bitcraze.io.

The positioning system is based on the Decawave DW1000 Ultra Wide Band radio chip. These radios work by transmitting very short pulses instead of full sinus waves the way a standard radio would, and the advantage for positioning is that it is possible to measure the time at which these short pulses are received very precisely. By using clever algorithms it is possible to measure the time it took for the radio signal to “fly” from one radio to another and from that we can calculate the distance between the radios.

A basic system is composed from a number of Anchors (Loco Positioning Nodes) at fixed positions and a Tag on the Crazyflie 2.0 (the Loco Positioning Deck). The system continuously measures the distances from the Tag to the Anchors and calculates the position of the Tag from that information. The concept is similar to GPS where the Anchors represent the satellites and the Tag the GPS-receiver. 4 Anchors is the theoretical minimum required to calculate a 3D position, but 6 has turned out to be more realistic number.

We have designed the Loco Positioning Nodes as standalone boards containing a micro controller and the DWM1000 UWB radio module. The nodes are intended to act as Anchors: they are setup at fix positions in the room and will serve as references for the system.

locopos_node

The Loco Positioning Deck, also based on theDWM1000 module, acts as a Tag and plugs into the Crazyflie 2.0 expansion port. It allows the Crazyflie 2.0 to calculate its absolute position in space and this is all we need to start flying it autonomously in the room. In this case the Crazyflie 2.0 acts as a Tag, but since we are always striving for flexibility, the nodes can also act as Tags for example for other robotic application.

logopos_deck

We consider the first batch to be an early access release. This means that the hardware is finished and tested but the software is still very much work in progress. Currently the Crazyflie ranges with the Anchors, while a PC running ROS interprets the ranges and calculates the estimated position. More in depth information will come if future blog-posts and e-mails on the list. For a video and some more information see our previous post “Update on Local Positioning System“.

Two weeks ago we had the opportunity to make a field trip to Gothenburg (Sweden) where we visited the students and teachers at Chalmers University of Technology.

chalmers3

The Crazyflie 2.0 is used by the students as a development platform for the course “Embedded control systems“, which makes us all very happy since we are passionate about education. I mean how cool is it not to see how students use your product to gain new knowledge!

While visiting Kristoffer held a guest lecture to the students and we also took the opportunity to discuss with Associate Professor Knut Åkesson about why and how the Crazyflie 2.0 is part of the course.

education-blog

A few of the topics that were mentioned was the big benefit with Crazyflie 2.0 being open and how that enabled the students to easily getting started implementing their own code.

If you want to read more about why the teachers at Chalmers choosed the Crazyflie 2.0 and how they use it for education, visit our newly added web section “Used in education”.

As some of you might know, we are working full ahead on developing a local positioning system for the Crazyflie 2.0 ecosystem. There are many things to be done and we just took two major step by improving the stabilizer code architecture and moving the position control code into the firmware. Getting the position from an external system is fine and dandy, but we also have to control the pitch, roll and yaw of the Crazyflie to keep its desired position. Up til now we have been running this control algorithm outside the Crazyflie in an external computer, but now we have moved it into the Crazyflie itself. The controller is a simple PID controller and can definitely be improved, but the main purpose of the work has been to improve the architecture in this area. We know there are people in the community working on position related features and we hope the new architecture will make it easier for us all to implement the bits and pieces needed to get an autonomous Crazyflie. The estimation of the position has not been implemented in the firmware yet but the architecture now has support for it.

The general layout of the new architecture is as follow:

  • The sensors are gyroscope, accelerometer and pressure sensor. More could and will be added in the future like position and altitude measurement.
  • The state estimator calculate an as good as possible estimate of the Crazyflie state using the sensor values. The state contains the Crazyflie orientation (roll, pitch, yaw), its position and speed. Currently the state estimator has complementary filters for the orientation and the altitude. In the near future the full position will be estimated as well.
  • The commander generate a setpoint to be followed by the Crazyflie. Currently this is only done by receiving commander packet from the ground using Crazyradio or bluetooth low energy.
  • The state controller generates control output to achieve the requested setpoint from the current state.
  • Finally the power distribution is translating controls from the controller into driving the actual motors.

This is implemented in stabilizer.c and each block is implemented in there own file. Stabilizer.c used to be very verbose and complex to read and modify, it has now been greatly simplified and the above architecture is implemented in one short loop (see the full code in GitHub):

while(1) {
  vTaskDelayUntil(&lastWakeTime, F2T(RATE_MAIN_LOOP)); // 1KHz

  sensorsAcquire(&sensorData, tick);
  stateEstimator(&state, &sensorData, tick);
  commanderGetSetpoint(&setpoint, &state);
  stateController(&control, &sensorData, &state, &setpoint, tick);
  powerDistribution(&control);
  tick++;
}

Our philosophy with this new architecture is to keep the code as simple as possible and to allow customisation at compile time. The high-level functions have as simple as possible interface and so can be exchanged easily. So if tomorrow, we have a shiny new controller we just have to compile it instead of the current PID controller. We think that this fits the way the Crazyflie is used, as a development tool.

This is just the beginning: there is still some more to clean-up in the functions and we will most certainly enhance the code from feedback. Please tell us if this is useful and how it can be enhanced even more.

Crazyflie 2.0 already has two mobile clients, one for Android maintained by Fred and the iPhone client. Now we officially have a new one on development: the Windows client.

IMG_20160425_202412

Theseankelly, from the community, has started a Windows client for Crazyflie 2.0. It connects Crazyflie using bluetooth low energy and works both on phone and on PC running windows. Last week, he transferred the source code repos in the Bitcraze github so that it can have more visibility. We plan to eventually released it in the Windows store, but first it needs to have a little bit more features :-). To this end we have created a milestone on GitHub and have filled a couple of tasks. The plan is to get to a minimum set of functionalities. That for, we will focus on phone support first but if you are interested in PC support do not hesitate to say so and push tickets for it (gamepad support and configuration is the first thing I can think about for desktop support).

Last week Fred released a new version of the Android client. The outstanding new feature is a support of the LED and Buzzer decks when using Crazyradio! It means that you can now change the light effects and play sounds on the Crazyflie from the phone. This is even better because it means that the Android client code is now able to access the param subsystem and soon the log subsystem: this will allow for much more interactions in the future (like access to advanced Crazyflie settings and supporting more decks). The support of decks using BLE and more are on going so stay tuned and if you have any functionality request please head to the GitHub ticket tracker.

aclient-deck

We have just released a new version 2016.04.1 of the Crazyflie client.

client_2016.4.1

The biggest change is actually not so visible but very important: we have now separated the GUI client from the Crazyflie lib. The great advantage is that the lib became a small project and could be pushed to pypi. This means that if you want to control Crazyflie from your own Python program all you have to do is to “pip install cflib” and you are ready to “import cflib” in your program to control the Crazyflie.

For the new release of the client we also pushed the client in pypi as well. This will be mainly useful in Linux and Mac where you are now able to install the client with “pip3 install cfclient”. One little drawback however: since the GUI lib we are using, pyqt, is not in pypi it has to be installed on the side. This can be done in Ubuntu with something like “sudo apt-get python3-pyqt4 install python3-pyqtgraph” or on Mac with homebrew or MacPorts.

Last but not least we have enabled Windows continuous integration with appveyor and fixed the Windows build. This means that a Windows build and installer are going to be generated for every commit in the Crazyflie client repos. Maintaining the Windows client has always been a challenge to us since we are mainly Linux users, so the this will help a lot to keep good Windows support. We still consider this Windows build to be somewhat experimental so please test it and report any bug you are hitting.

The last system to support for executable distribution is Mac. We did put some time trying to generate a mac app out of the client without any success. If anyone wants to give it a try or have some tips please head to the ticket on github.

Historically the main way to control a Crazyflie has been by using a computer running a Crazyflie client and communicating with a Crazyradio (PA). However since very early we have made an Android client that also communicated using the Crazyradio. This was at the very beginning of USB On-The-Go for Android and it allowed to fly without a PC. When we released Crazyflie 2.0 with Bluetooth LE support we made an iPhone client as well as adding bluetooth to the Android client.

The Android App is the oldest and thanks to the community the most fully featured. It has a community maintainer, Fred, that is doing a great job a keeping the app stable and adding features.

android_client

With the Android app you can fly with both touchscreen control and game-pad control. It works with Bluetooth and Crazyradio. It can update Crazyflie 1.0 and Crazyflie 2.0 firmware using Crazyradio and soon Bluetooth for Crazyflie 2.0. Soon the possibility to use deck functionality like LED ring and Buzzer will be added.

The iPhone app is, for the moment, a bit more simple:

ios_main

 

It allows to fly and update Crazyflie 2.0 using Bluetooth low energy. There has already been a couple of contribution to keep the app up to date with Apple dev tools and more featured are currently being pushed.

Finally there is a new one coming soon. A windows 10 app prototype has been done by theseankelly and is just waiting to be enhanced. The exciting parts is that it works on Windows phone but it is also the first Bluetooth GUI client for Crazyflie 2.0 on desktop platform (there is nodejs libs that supports BLE on computer but no GUI that I know off, if I am wrong please comment!).

windows_client

A great thanks to all the contributors, the mobile clients for Crazyflie would not be that far without you! If you are interested in mobile development you are welcome to contribute, these clients started as a “just to fly” remote control but they could do so much more.

Last week we had some great contributions at our hackster.io platform page that you really should check out.

The first project is made by our good friend Fred that created a tutorial about how to do a FPV setup inspired by this video from LaDroneShop.

 

The second really cool project was made by Jim that have experimented with making “long exposure light paintings” using Crazyflie 2.0 and the LED-ring deck.

IMG_9534

We are always very excited to see how people are using our Crazyflie, what is especially inspiring for us is to see that the diversity between the different usage areas is so great.

Finally please don’t hesitate to share you projects with us, we are more than happy to post them on our blog or promote them on our hackster.io page.

As we already talked before in a couple of post, we are currently developping a local positioning system for the Crazyflie based on ultra-wide-band radio DWM1000. This is one of our main focus currently so we wanted to post a short update on our progress.

We have assembled and shipped a couple of LPS system already and so far the performance and progress are great. We now think that we have the copter flying as good as we can have it without running sensor fusion and the control loop in the Crazyflie microcontroller. Next step is to integrate algorithms in the Crazyflie.

We are currently working hard at finishing the design to make it ready for production. We will write more updates about that so stay tuned :).

We have shot a short video demonstrating the current state, see after the video for more information about the setup:

To make this video we have installed 6 anchors. 3 are above the room and 3 at about 50cm from the ground. The Crazyflie has a LPS deck and ranges in a round-robing fashion with all 6 anchors. The ROS driver pulls the ranging, estimate the Crazyflie position, and calculate a corrected roll/pitch/thrust in order to keep it at the pre-defined setpoint. The Yaw is not controlled externally, it is kept by the Crazyflie internal gyroscope only.

The ROS computer was setup according to the instruction on our wiki, and by launching the pf_hover launch file:

roslaunch bitcraze_lps_estimator dwm_loc_pf_hover.launch uri:=radio://0/110/2M x:=1.5 y:=5 z:=1.2

Last week we where happy to learn that engineers at Stanford’s Biomimetics and Dexterous Manipulation Lab have been using the Crazyflie 2.0 as a prototyping tool when creating the robot SCAMP Stanford Climbing and Aerial Maneuvering Platform.

This very impressing work centers around the ability for a drone to actually land on vertical surfaces. In addition to this  the robot climb along that surface. Read more here and here. Really cool!

One of the future usages the researchers mention is to help out in the rescue work after earthquakes and other catastrophes. We are so proud that our drone is used in this research field!

 

We have stared to look at what is needed to make the Crazyflie position aware and to integrate the upcoming positioning system. The rough idea is to add a position estimation module to the firmware of the Crazyflie that will be responsible of estimating the current position based on data from internal or external sensors. The sensors could be mounted on the Crazyflie but it should also be possible to inject the position over radio from an external system. A control module will use the estimated position to try to navigate the copter to a desired position that could be set for instance by a user or by some navigation algorithm. If you want to participate in the design discussions or implementation head over to github where we will use issues for this conversation.

We decided that a suitable first step was to improve the altitude hold, so that is what we did last week. The code has been refactored and improved and we think the altitude hold is now working much better than before. It’s not perfect, still room for improvements :-)

Tilt compensation

While we were at it we also added a thrust compensation to avoid loosing altitude when tilting the copter. It turns out it makes flying easier as the pilot does not have to add extra thrust when moving around. Good for both human and automatic pilots.

Hackster.io

Have you checked out our projects on hackster.io? Help out and make Bitcraze a featured platform by adding your own project or just follow us, we need 10 projects and 25 followers to be featured. You can make a difference!