Author: Arnaud

Last week half of Bitcraze, Kristoffer, Tobias and Arnaud were at IROS 2018 where we had an exhibitor booth. We have had a great week and met so many interesting and inspiring people, both users of the Crazyflie as well as persons curious in what we do. Thanks to everyone that passed by the booth, it is awesome to hear how Crazyflie is used and how we can improve it even more.

This year we invited Qualisys to share the booth with us, they kindly provided a motion capture system and we had the pleasure to be joined by Martin to help us and present Qualisys.

Demo-wise we had prepared a bunch of demos which you can read about in our previous post about IROS. It won’t surprise anyone to hear that not everything has been working as planned. The Lighthouse demo did not work when we set it up in the booth (it did in the office!) but some live hacking solved the problem on Tuesday. We also had unexpected issues with the Crazyswarm demo: our landing pad design and flight trajectory was working very well in the office, but in the booth we experienced much more instabilities that prevented us to successfully fly and land all 6 crazyflies in Crazyswarm. We still need to investigate what happened. The autonomous demos, both using the UWB Loco Positioning System and Lighthouse (when fixed), have been surprisingly robust: they do not require a connection to a computer and they worked almost all the time, when they failed they failed without drama and could be reset very quickly.

Overall we have been able to accumulate flight time and experience much quicker in this last week than in the last months, now we have a lot of things to test and improve and also a lot of things we can be much more confident about. We have been fixing and improving the demo during the event and we will write more blog posts in the coming weeks about things we have developed and improved for and during IROS.

To conclude, thanks again to everyone that dropped by the booth, this kind of event always make us come back with a boost of motivation and fresh new ideas and it is all thanks to you!

As mentioned in an earlier post, this year we are going to exhibit at iROS 2018 in Madrid. Every time we go to fairs and exhibition, it is the occasion for us to work more on integration to put together the latest development into a demo we can show at the event. One of the latest development we will show at iROS is the lighthouse deck.

Work on the lighthouse deck have continued during the summer and we are now at a stage where things are starting to work quite well with Lighthouse V1 base stations. We are quite impressed by the performance: we have measured a positioning noise bellow 1mm. We are flying the Crazyflie using Crazyswarm which allows us to fly smooth trajectory using the high-level controller:

The goal for iROS is to stabilize and push the code in the main Crazyflie firmware repos. We will have a couple of Crazyflie setup with the Lighthouse deck and that we will be able to demonstrate. In the future we are also thinking of making a general purpose tag that could be used with other robots. One of the great advantage of the lighthouse tracking technology is that the position and orientation is available in the receiver, in the robot. This means that, like the LPS, the robots are autonomous and do not require an active data connection with a computer in order to locate themselves.

There is still a lot of challenges and work to be done on the deck. For once, this is currently using HTC Vive lighthouse base station V1, Valve has release the base station V2 that allows to cover much more space for each base station and to use more than 2 base stations in the same system, we plan to implement support for it. We will also need to work on multi-sensor localization and setup procedure. Currently the Crazyflie calculates its orientation using only one lighthouse receiver and requires to be in direct light of sight of both lighthouse, it is possible using more receiver to get a position and orientation with only one base station in sight which will increase the system reliablility. As for the system setup we are still using SteamVR to obtain the lighthouse positions using at least one Vive controller, the goal is eventually to be able to setup a system with the Crazyflie alone, without needing to install SteamVR. All that will most likely be discussed in more details in future post.

If you are attending iROS 2018 feel free to come and meet us at booth #91.

Log and param are the two Crazyflie subsystems that have become the core means of communication with the Crazyflie.

The Log is a subsystem that contains functionality to transfer values of variables in the Crazyflie to a client. The client can setup log blocks, which are a list of variables, and start logging this log block at a certain rate. The Crazyflie will then send radio packets at the requested rate with the current values of the variables, thus enabling the client to read changing variables in the Crazyflie in near realtime. It is very useful for monitoring the state of the Crazyflie and further more, any log variable can be graphed in the python client.

Param is a subsystem that contains functionality to get and set the values of variables in the Crazyflie. This is essentially the opposite of Log, it allows the client to read or write variables that are read-only in the firmware.

Both subsystems are based on a Table Of Content (the TOC): at connection time the client pulls the list of log/param variables. This means that there is no hard-dependency between client and firmware and that we can develop new functionalities in the Crazyflie, adding log and param variables to access it without modifying the client.

The Log and Param subsystems have served the Crazyflie community very well, allowing for quick development of experimental and new functionalities. There has been a limitation that has become more and more painful lately though; we were limited to 255 variables due to the protocol using only one byte to encode the variable ID. This issue has now been fixed in the Crazyflie firmware and in the Crazyflie ROS driver by a pull request from Wolfgang at USC. We have recently also implemented the required changes in the Python lib to make it available in the python client (and any other python script using the lib). In the process, some bugs unfortunately found their way into the code, but they have quickly been fixed by a pull request from simonjwright. Thanks to every one involved!

So now Crazyflie supports up to 65535 log and 65535 param variables. This time we should be good for the foreseeable future! ;-).

We have been thinking for a while about making a Crazyflie control board that could be used to make a bigger quadcopter using the Crazyflie firmware and deck. This idea has materialized in the Crazyflie RZR project.

The Crazyflie RZR is a quadcopter controller board based on the Crazyflie design, as pointed if our previous blog post, it is intending to bring the strength of the CF2 but in a little bit bigger package :-). It runs the Crazyflie firmware and feature the Crazyflie 2.0 deck port. It is capable of driving brush-less motor controller and has an uFL port for an external 2.4GHz antenna. It also contains the new quadcopter-optimized Bosch BMI088 IMU. We have made some progress lately on the Crazyflie RZR, we have just got the first initial sample from the manufacturer shown in the picture above.

We are not sure yet when the RZR will be in the shop, but the project is definitely going forward. We will keep posting information about the project as it develop. 

We already wrote in a previous blog post that we where working on a Lighthouse positioning receiver deck for the Crazyflie 2.0. In this post we will describe a bit what has been the development process so far for this deck as it is an example of how to develop with the Crazyflie. Basically, our way of working often is to try to get one things working after another, this is what we have done here: we start from a hack and then we replace hardware and software pieces one after the other to make sure we always have one half (hardware of software) we can relie on.

The lighthouse deck started as a Fun Friday project, and as such we usually want to hack something together to see if the idea can work. So I looked around the web to get some information as of how to receive the lighthouse positioning signals and decode it. I found the vive-diy-position-sensor GitHub project by ashtuchkin. The project describe the schematic and contains the software for a Teensy board to receive a lighthouse 1.0 signal and calculate the position of the receiver. I went forward and cabled the circuit on a Crazyflie prototyping deck and attached a Teensy board to another prototyping deck. The idea is to install these two board above and bellow a Crazyflie:

Discreet-component Lighthouse receiver

Teensy to decode the lighthouse signals

The signal from the lighthouse receiver goes to the Teensy, then the serial port of the Teensy is connected to the serial port of the Crazyflie. As a first approach the Teensy was configured and we could get the position data using the Teensy USB port. When everything was working correctly I could implement a small deck driver in the Crazyflie to receive the position and push it in the Kalman filter. This way I could get a Crazyflie 2.0 flying in lighthouse with minimal firmware work.

The obvious next step was to get rid of the Teensy, this was done by implementing the lighthouse pulse acquisition and interpretation in the Crazyflie. Once that was done, we could make our own deck. Instead of using op-amp we used the official receiving chip available at this time, the TS3633:

First lighthouse receiving deck prototype

This board implements up to two receiver which would allow to get the orientation as well as the Position of Crazyflie. Due to questionable soldering only one receiver has ever worked but the prototype was useful to test the concept anyway, one of the lesson learned is that the receiving angle of the two flat is not big enough to fly very high, with the two lighthouse base station near the ceiling we could only fly up to ~1.5m before loosing the signal.  We would need a microcontroller or other chip capable of acquiring the signals on the deck since the Crazyflie 2.0 deck port only has two input capable of acquiring the pulses.

At this point informations about Lighthouse 2.0, the next version of Lighthouse tracking that will allow to cover much bigger area, started appearing on the internet and a new receiver chip was release to receive the signal, the TS4231. One big difference was that Lighthouse 2.0 would transmit data in the laser carrier. The data transmitted are in the range of 1 to 10MHz dixit the TS4231 datasheet so it makes them impractical to acquire with a microcontroller. This gives us a perfect opportunity to play with the iCE40 FPGA and the icestorm open-source toolchain that has just been release. 

The result is a deck containing enough receiver to cover a much bigger flying space and an iCE40UP5K FPGA to acquire the signals sent by the lighthouse. There is already two prototype of this design: one without SPI flash, so the Crazyflie would have to embed the FPGA configuration bitstream and program it at startup and the latest one has an SPI flash so the deck can start by itself:

First FPGA-Based lighthouse deck prototype

 

Partially populated second FPGA-Based lighthouse deck prototype, now with SPI flash

As a first approach the FPGA will acquire the Lighthouse 1 pulses and send the raw timing via a serial port to the Crazyflie. The Crazyflie can then decode and interpret the pulse. I am currently playing with the idea of maybe running a picorv32 Risc-V 32 bits CPU core in the deck, this will allow to acquire and interpret the pulses in the deck and send angles to the Crazyflie, this would greatly lighten the processing load on the Crazyflie 2.0. Eventually this FPGA should be able to acquire and decode the Lighthouse 2.0 signals.

This is very much work in progress and we will write more about the Lighthouse deck when we have further results.

 

Last week we received the visit of Wolfgang from USC, he is the creator of the Crazyswarm project. It was great to have him here at the office. One of the subject of discussion was to prepare a demo for iROS 2018 on October 1-5 2018 in Madrid.

We will be in booth 91, if you are attending iROS 2018 feel free to pass-by and say hello. We are planning a couple of demos:

  • Crazyswarm with at least 6 Crazyflies flying in a Qualisys mocap system.
  • Running a fully autonomous Crazyflie with the Loco Positioning System.
  • Hopefully, some demo of autonomous flight using the lighthouse positioning. This is still not fully working but I have at least 2 full months to get something flying :-).

If you would like to see us demo anything more/else tell us in the comments and we will see if we can setup something.

We used Wolfgang’s visit to finalise the Qualisys support for Crazyswarm. It is now pushed and documented, this means that if you have a Qualisys system and a couple of Crazyflies you can now fly them autonomously using the Crazyswarm framework. It also means that we now have Crazyswarm up and running flawlessly at the office, it will help us testing related pull-request and supporting advanced functionality like the high-level-commander in the Crazyflie python lib.

 

As a side note, Bitcraze is spread very thin these weeks since most of us are in vacation (I am basically alone). We usually miss one Monday post per year, it was last week and the Wolfgang visit is my excuse :-). Sorry in advance if there is any delay to answer mail, forum or other requests. From next week, the rest of the team will slowly start to come back.

Like every summer, things slow down and people starts to go on vacation. This is a perfect time to sit down and start fixing various things that we never have time to fix. We call that the Summer cleanup. This summer there will still be a bit of development though as we are finishing the multiranger deck.

On the cleanup side, there is at least a couple of things we plan to look at:

  • Updating the virtual machine to the latest Ubuntu version
  • Looking at the Crazyflie firmware build system to make it cleaner and easier to expand for new platform. There is the RZR and the LPS Tag boards that will come later in the year and will need to be supported by the Crazyflie firmware.
  • Implementing a startup test that can detect bad propeller and bad batteries. This would improve a lot the experience of flying a Swarm of crazyflies.
  • We have been continuously improving the webpage last year, this will continue during the summer.

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.

A while ago we bought an HTC Vive for the Bitcraze office. This was partly for having fun with VR, but is was mostly because we had hope to use the vive tracking system with the Crazyflie. We are making progress with the idea and we just received our latest prototype:

The Lighthouse tracking system is the hardware component of steamvr tracking, it is used by the HTC vive to get the full position and orientation of the Vive VR head mounted display and game controllers. It has sub-millimeter precision and low latency, which is key to achieve immersive VR experience. The system works by having base-stations installed in the room. The base station sweeps two rotating infrared laser planes. A receiver is basically a photodiode, by detecting when the photodiode is hit by the sweeping lasers, the receiver can measure at which angle it is seen by the base station. With enough receivers and/or base-stations, it is possible to calculate the receiver position and orientation. If you want to read more about how lighthouse works, there has been awesome work of reverse engineering and documentation made by the open-source community.

As far as Crazyflie is concerned the lighthouse system has one major advantage: the position and orientation can be calculate in the tracked object which means that the Crazyflie can be completely autonomous and there is no limit in the number of Crazyflies that can be tracked at the same time.

Lighthouse has been my fun-Friday project for a couple of month and the early results are very encouraging.This is still very much work in progress, so stay tuned for future blog-posts about the subject :-).

The Bitcraze Virtual Machine is designed as a quick and isolated way to start development with Crazyflie and other bitcraze projects.

The current VM is starting to get very old, even though we keep it updated it is based on XUbuntu LTS 14.04. This month Ubuntu LTS 18.04 is being release which is a good reason to upgrade the VM!

The main update will then to switch from XUbuntu 14.04 to XUbuntu 18.04. There is a couple more things that we are looking at updating:

  • Updating Eclipse and CDT to the latest version Oxygen.3a
  • Fixing Eclipse code completion and hinting configuration
  • Pre-configuring eclipse with gnu-mcu-eclipse to make it easier to flash and debug Crazyflie. 
  • Updating KiCad to the latest stable version 4
  • Fixing the virtual machine Crazyradio communication bugs

We are writing this blog post as a request for comment:

  • Is there anything else that you would like to add/remove in the new virtual machine?
  • Anything we could do to make it easier to start developing for Crazyflie?

The virtual machine is generated automatically using packer and VirtualBox, the code is hosted on GitHub. If you want to help making the VM or want functionality to be added to it do not hesitate to open a ticket in the bug tracker.

We though we could use this Monday blog post to do a small state of the Crazyflie clients. What we call a Crazyflie client is a piece of software that connects a Crazyflie and allows to control it and get telemetry back from it. In this post we will concentrate on single-crazyflie client we have on our GitHub page, there exists a lot of libraries and software to control one or many Crazyflies, we will write another blog post about them.

Crazyflie PC client

The Crazyflie PC client, is what we consider the reference client. It supports connecting one Crazyflie using the Crazyradio (PA) dongle or direct USB connection to Crazyflie 2.0. It supports the full Crazyflie telemetry (ie. log), parameters (ie. params) and firmware update. It has support for all the Crazyflie 2.0 deck that can use client support. It is updated each time it is needed when new functionalities are added in the Crazyflie which makes it actively developed and maintained by the community and Bitcraze. A bluetooth link has not been prioritize so far since its multi-platform implementation is non-obvious and bluetooth will introduce some latency and lower the radio bandwidth compared to Crazyradio. However, if anyone would want bluetooth support for the Crazyflie PC client, we welcome contributions :-). The Crazyflie PC client is using the crazyflie-lib-python to communicate with the Crazyflie.

We have three mobile clients on our Github. They have various level of functionality depending on community involvement. Our philosophy is to have the mobile clients at least able to control a Crazyflie, this allows to use them to test Crazyflies without requiring to setup a computer. We will help and support anyone that is interested in adding functionalities to the mobile clients but we generally do not have time to add much functionalities by ourselves.

The Andoid crazyflie client is currently maintained by Fred from the community. It is mobile Crazyflie client with the most feature. It supports both Crazyradio and Bluetooth link. Using Crazyradio it currently supports the part of telemetry and parameter required to support a couple of deck like the led-ring and buzzer deck and supports updating the firmware. Using bluetooth there is currently no telemetry, parameter or firmware update functionality so no deck support. Development is in progress to support more decks and to bring the bluetooth link to the same functionality as the Crazyradio link. The Android client is written in Java and Fred has developed a Crazyflie Java library that is used in the Android client but that can also be used in any other Java program.

 

Crazyflie Android client

The iOS Crazyflie client, works on iPhone and iPad. It supports bluetooth link. It does not have any telemetry or parameter support, so no deck control support. It has firmware update support over bluetooth. It has mainly been developed by me with great contributions from the community for, among others, the port to swift.  The iOS client is written in swift. The Crazyflie and Bluetooth part of the code could be a good starting point if anyone wanted to make a native mac Crazyflie client.

Crazyflie iOS client

Finally we have a prototype of a Windows UWP client developed by theseankelly. It supports Bluetooth low energy. It currently does not supports any telemetry or parameters. It is working both on Windows phone and on Windows 10 on computer, it is currently the only way to connect a Crazyflie using Bluetooth from a laptop. The windows client supports manual control of the Crazyflie using a gamepad or with gesture using HoloLens. This original set of functionality makes it both the most simple and the most advanced Crazyflie client :-).

If you are interested in developing for any of these client, of by making your own, feel free to make a ticket on the relevant github repo or open a thread in the forum. We migh not have much time to develop for the mobile clients, but we will always be glad to help and guide anyone that wants to implement software in relation with the Crazyflie. The Crazyflie clients (running in a computer or phone) and the Crazyflie firmwares (running in the Crazyflie itself) are open source and in active development, it means that is possible to modify both side, this makes it a great target to experiments and to play around with new ideas :-).