Firmware and Software releases 2018.10

2018-10-22 | Arnaud | Leave a comment

Last week we have been focusing on making a release for nearly all our firmware and software. This was done mainly to support the new products we will release this fall but it also contains a lot of other functionality that have been added since the previous release. In this blog-post we will describe the most important features of this release.

New Loco Positioning status and configuration tab

New deck support

The Crazyflie firmware and Crazyflie client 2018.10 adds support for a range of new decks that are about to be released:

Flow deck V2 and Z-Ranger V2: New versions of the flow and Z-Ranger deck that uses the new VL53L1 distance sensor. Drivers are implemented in the Crazyflie firmware and the client has been updated to allow flying up to 2 meter in height hold and hover modes when the new decks are detected.
Multiranger deck: Diver for the new Multiranger deck is implemented in the Crazyflie firmware, support code is now present in the lib as well as an example implementing the push demo that makes the Crazyflie fly in hover mode using the flow deck and move away from obstacles:

The Flow deck V2 is already available in our webstore. The Z-Ranger V2 and Multiranger will be available in the following weeks, stay tuned on the blog for updated information.

Crazyswarm support

During the year, functionality implemented for the Crazyswarm project has been merged back to the Crazyflie firmware master branch. Practically it means that the Crazyflie firmware 2018.10 is the first stable version to support Crazyswarm. The main features implemented by Crazyswarm are:

Modular controller and estimator framework that allows to switch the estimator or the controller at runtime. Practically it means that it is not required to recompile the firmware to use a different controller anymore.
Addition of a high-level commander that is able to generate setpoints for the controller from within the Crazyflie. The high-level commander is usable both from Crazyswarm and from the Crazyflie python library. It currently has commands to take-off, land, go to a setpoint and follow a polynomial trajectory. It is made in such a way that it can be extended in the future.
Addition of the Mellinger controller: a new controller that allows to fly much tighter and precise trajectories than the PID controller. It is tuned pretty tight so it is currently mostly usable using a motion capture or lighthouse as positioning and togeather with the high-level commander.

Improved and more stable Loco Positioning System

A lot of work has been put in the Loco Positioning System (LPS) this summer. The result of this work is the creation of a new ranging mode: TDoA3. TDoA3 allows to fly as many Crazyflie as we want in the system and to add as many anchors are needed, see our previous blog-post for more information. With this release TDoA 3 is added as a stable ranging mode for LPS. The added features related to LPS are:

Added TDoA3 as a ranging mode in the LPS-Node-firmware, the Crazyflie 2.0 firmware and the Crazyflie client
Revampted the Crazyflie client LPS tab and communication protocol to handle more than 8 anchors
Implementation of a new outlier detector for TDoA2 and TDoA3 that drastically improve positioning noise and flight quality

Release notes and downloads

As usual the release build and release note is available on Github. The Crazyflie client and lib are also available as python pip package as cfclient and cflib.

Back from IROS 2018

2018-10-08 | Arnaud | Leave a comment

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!

Demo for iROS2018: The lighthouse deck

2018-09-10 | Arnaud | 1 Comment

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 protocol V2

2018-08-27 | Arnaud | Leave a comment

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! ;-).

Crazyflie RZR control board progress

2018-08-06 | Arnaud | Leave a comment

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.

Lighthouse prototype deck development

2018-07-30 | Arnaud | 4 Comments

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.

Bitcraze at iROS 2018 in Madrid

2018-07-23 | Arnaud | Leave a comment

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.

Summer cleanup

2018-07-02 | Arnaud | 2 Comments

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.

Lighthouse positioning for Crazyflie

2018-06-25 | Arnaud | 3 Comments

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 :-).

New Bitcraze VM development

2018-04-23 | Arnaud | Leave a comment

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.