Crazyflie communication stack Dev Meeting

2023-02-20 | Arnaud | Leave a comment

As we have talked about in previous blog post, a big work, and a big change, coming to the Crazyflie is the development of a new communication stack. We are organizing an online dev-meeting about this the Wednesday 22th of February 2023 at 15:00 CEST, if you have any feedback, opinion, ideas or just want to talk to us, you are welcome to join. More information on github discussion.

The current communication protocols used by the Crazyflie are 10 years old by now and starts to be the limiting factor for new experiments and for improving the platform. We are starting to work on it to make the Crazyflie protocol for the next 10+ years. Among the things we have been looking at, and want to work on, are:

Making a new USB radio dongle with extended capabilities: Crazyradio 2.0
Making new low level radio protocol implementing channel hopping and P2P communication making use of the new Crazyradio 2.0 capabilities.
Making a new RPC-Based communication protocol to make it easier to develop new functionality and interfacing with framework like ROS2
Defining interface with other part of the system like decks using the same RPC protocol, this would make it easier to develop new deck by limiting the number of project to modify each time a deck is developed.
It has also been pitched internally to write the Crazyflie lib in Rust with binding to Python/C++/Javascript/… unifying the host part of the ecosystem and so simplifying the development of application connecting the Crazyflie.

As you can see, this discussion spans to everything that touches communication from the Crazyflie to outside systems as well as with decks. We think there is a way to make things much better and easier to work with. If we have some time left in the hours we can also handle some general support questions.

If you are interested in the topic please join us on Wednesday and let’s talk about it! You can check the joining information on github discussion. These dev-meeting are not recorded, they are intended as a forum where we can talk together about the Crazyflie and its ecosystem. Welcome!

Crazyradio 2.0

2023-01-30 | Arnaud | Leave a comment

As already announced in a previous blog post, we have been working on a replacement for the Crazyradio PA. Crazyradio is the USB dongle used to communicate with Crazyflie 2.1, Crazyflie Bolt and any other 2.4GHz radio board we are making. We are also visiting FOSDEM in Brussels at the end of the week and will organize a community dev-meeting about Crazyradio and communication end of February: more on that at the end of the post.

Crazyradio 2.0 will have the following characteristics:

Based on the nordic-semiconductor nRF52840
- 64MHz Cortex-M4
- 1024KB flash, 256KB ram
- Radio supporting Nordic protocol, Bluetooth low energy as well as IEEE802.15.4
- 1Mbps and 2Mbsp bitrate to Crazyflie
- USB full speed (12Mbps) device
Radio power amplifier providing up to +20dBm output power
‘Drag and drop’ bootloader with physical button to start in bootloader mode
Same debug port as on the Crazyflie for ease of development

One of the main changes versus the Crazyradio PA will be the available CPU power and ease of development: this will allow to experiment with and implement much more advanced communication protocol like channel hopping and peer-to-peer communication.

On the software side, there will be two modes available for Crazyradio 2.0: a compatibility mode that emulate a Crazyradio PA and should work with all existing software as well as a new Crazyradio mode that will have a much improved USB protocol allowing for more efficient communication when controlling multiple Crazyflie as well as making it easy to support more protocols in the future.

These two modes will be available as two different firmware and the user can ‘drag and drop’ the firmware with the wanted mode.

As for the Crazyradio PA (version 1), sourcing the components for it has been a bit challenging lately. We will sell Crazyradio PA as long as we have stock for it and the software will continue to support it for the foreseeable future.

Announcements

Kimberly and I, Arnaud, will be visiting the FOSDEM conference at the end of the week in Brussels. If you are there too and want to meet us do not hesitate to drop a message in the comment there, in Github discussions or by mail. It would be great to meet fellow Crazyflie users!

We are also planning an online dev-meeting about Crazyradio 2.0 and communication the 22nd of February 2023. The information about joining will be on Github Discussions. We are interested in talking, and bouncing ideas about radio and communication protocol: with the new Crazyradio we have an opportunity to work on communication protocols to improve them and makes them more useful to modern use of the Crazyflie.

New Crazyradio and new communication architecture

2022-11-21 | Arnaud | Leave a comment

The communication protocols between a PC, a Crazyradio and a Crazyflie are critical parts of the Crazyflie ecosystem, they allow to communicate with and control the Crazyflies in real time. These protocols have been documented in a couple of blog posts already. They exist since the origin of the Crazyflie, in 2011, and where originally designed with one use-case in mind: controlling one Crazyflie manually from a game-pad connected to a PC. The Crazyflie can of course do much more nowadays, like flying in big autonomous swarm, but the underlying communication protocols are still an evolution of these simple manual-flights single Crazyflie origin.

Over time we have felt the limitations of the communications protocols and of the Crazyradio (PA). For this reason, lately, we have been starting to work at making a new, more modern, Crazyradio dongle and at revamping the communication protocol used to communicate with the Crazyflie. The aim is to start with the current Crazyflie use-cases including flying in centralized and decentralized swarms with varying levels of autonomy of the drone itself.

The first project is to make a new Crazyradio dongle: the current Crazyradio PA is based on an old nRF24 chip from Nordic semi. It runs on a 8051 microcontroller and has a mostly hardware-driven radio. This means that the processing power is quite limited and the radio has no flexibility with the on-air protocol and packet size limited to 32 Bytes. We are working on a new Crazyradio dongle based on an nRF52840 microcontroller and a RF power amplifier. We expect the new radio to be available sometimes before the summer 2023:

The main advantage of using the new nRF52 microcontroller is that it is an ARM Cortex-M4 chip with quite a lot of flash and ram. This will make development much easier and faster. It is also a much more capable chip which will improve communication performance. The output power will be similar to the Crazyradio PA so the range should be similar. The radio being more flexible, it will allow development of new protocols including the capability to send packets bigger than 32 bytes.

On the USB protocol side, we will take this opportunity to improve the USB protocol. We are making it more flexible so that it can be expanded more easily in the future and it will also be much more efficient when controlling swarm of Crazyflies.

The first version of the new Crazyradio will implement the same air-protocol as the current one, so there will not be a need to change the Crazyflie firmware right away.

However we are already thinking of a couple of new radio protocol that we want to develop for the new Crazyradio and the Crazyflie 2:

A low latency channel hopping protocol: This protocol would allow to connect one or a swarm of Crazyflie using channel hopping. This means that the user does not have to setup a channel for communication anymore, the protocol will automatically hop form channel to channel randomly. This will make it much easier to connect to Crazyflies and make the link more reliable
A P2P protocol that will allow Crazyflies and Crazyradios to talk to each other: the main idea is to make the P2P protocol a proper supported protocol and to make the Crazyradio able to be a node in the P2P network. This should simplify a lot the development of autonomous swarm.

On the higher level protocol, CRTP, we are stating to think of ways to make new protocols as well. On that side, there has been no work started yet but a lot of ideas and general direction based on our experience and on feedback in iROS 2022 and other conferences. The basic lose ideas currently are:

Integrating the concept of connection in the protocol: currently there is no such concept so for example if a logging is setup and the link is lost, the logging subsystem will continue to try to send packets forever. A more logical implementation would tell the logging subsystem that the connection is lost and so that the logging can be canceled.
Basing the protocol on Remote Procedure Call: A lot of that we currently do in CRTP is to emulate procedure call with packets and parameters. Making procedure call the base unit of the protocol would make it much easier to use and extend
Versioning! One of the problem currently is that without clear versioning, it is very hard to make the protocol evolve in a documented way. We will find a way to version so that we can improve, add and remove functionality when needed.
Finally. We are not planning on running (micro) ROS in the Crazyflie 2, however the goal is to make a protocol that would make the interface to (micro) ROS and Crazyswarm as thin and boring as possible. Today the Crazyswarm ROS Crazyflie server is a full fledged client, the hope is to make the Crazyflie protocol in such a way that it would look more like a proxy to the Crazyflie RPC API.

If you have made a client that communicates directly with the Crazyradio PA, the change in the new Crazyradio will affect you. We will soon make the new Crazyradio 2 repos public with documentation of the new protocol to give the possibility to have discussions before release.

Those are still very lose ideas and the main goal of this blog post is to bring awareness to the future work: if you have any ideas, opinion or wishes when it comes to the communication protocol please come in contact with us and let’s discuss. The best forum is our github discussion page. Also we are planning to have an online townhall meeting so that we can handle any questions about implementation or discuss the proposed protocol, so keep an eye on this discussion thread: Townhall meeting (7 Dec 2022) · Discussion #426 · bitcraze (github.com).

Rust, Wasm and the Crazyflie

2021-06-14 | Arnaud | Leave a comment

For quite a while now, I have been very interested in the Rust programming language and since Jonas joined us we are two rust-enthusiast at Bitcraze. Rust is a relatively recent programming language that aims at being safe, performant and productive. It is a system programming language in the sense that it compiles to machine code with minimal runtime. It prevents a lot of bugs at compile time and it provides great mechanisms for abstraction that makes it sometime feels as high level as languages like Python.

I have been interested in applying my love for Rust at Bitcraze, mostly during fun Fridays. There is two area that I have mainly explored so far: Putting Rust in embedded systems to replace pieces of C, having such a high-level-looking language in embedded is refreshing, and re-writing the Crazyflie lib on PC in rust to make it more performant and more portable. In this blog post I will talk about the later, I keep embedded rust for a future blog post :).

Re-implementing Crazyflie lib

To re-implement the Crazyflie lib, the easiest it to follow the way the communication stack is currently setup, more information can be found on Crtp in a pevious blog post about the Crazyflie radio communication and the communication reliability.

Since I am currently focusing on implementing communication using the Crazyradio dongle, I have separated the implementation in the following modules (A crate is the Rust version of a library):

Physical: Crazyradio crate.
Link + CRTP: Crazyflie-link crate.
Service: Crazyflie-lib crate.

This organization is very similar to the layering that we have in the python crazyflie-lib, the difference being that in the Crazyflie lib all the layers are distributed in the same Python package.

At the time this blog post is written, the Crazyradio crate is full featured. The link is in a good shape and even has a python binding. The Crazyflie lib however is still very much work in progress. I started by implementing the ‘hard’ parts like log and param but more directly useful part like set-points (what is needed to actually fly the Crazyflie) are not implemented yet.

Compiling to the web: Wasm

One of the nice property of Rust is that compiling to different platform is generally easy and seemless. For instance, all the crates talked about previously will compile and run on Windows/Mac/Linux without any modification including the Python binding using only the standard Rust install. One of the Rust supported platform is a bit more special and interesting compared to the other though: WebAssembly.

WebAssembly is a virtual machine that is designed to be targeted by system programming language like C/C++ and Rust. It can be used in standalone (a bit like the Java VM) as well as in a web browses. All modern web browser supports and can run WebAssembly code. WebAssembly can be called from JavaScript.

The WebAssembly in the web is unfortunately not as easy to target as the native Windows/Mac/Linux: WebAssembly does not support threading yet, USB access needs to be handled via WebUSB and since we run in a web browser from JavaScript we have to follow some rules inherited from it. The most important being that the program can never block (ie. std::sync::Mutex shall not be used, I have tried ….).

I made two major modification to my existing code in order to make it possible to run in a web browser:

crazyflie-link and crazyflie-lib have been re-implemented using Rust async/await. This means that there is no thread needed and Rust async/await interfaces almost seamlessly with Javascript’s promises. The link and lib still compile and work well on native platforms.
I have created a new crate named crazyradio-webusb (not uploaded yet at the release of this post) that exposes the same API as the crazyradio crates but using WebUSB to communicate with the Crazyradio.

To support the web, the relationship between the crates becomes as follow:

The main goal is to keep the crazyflie-lib and crazyflie-link unmodified. Support for the Crazyradio in native and on the web is handled by two crates that exposes the same async API. The crate used is chosen by a compile flag (called Features in the rust world). This architecture could easily be expanded to other platform like Android or iOS.

Status, demo and future work

I have started getting something working end-to-end in the browser. The lib currently only implements Crazyflie Param and the Log TOC so the current demo scans for Crazyflie, connects the first found Crazyflie and prints the list of parameters with the parameters type and values. It can be found on Crazyflie web client test server. This doesn’t do anything useful now, but I am going to update this server when I make progress, so feel free to visit it in the future :).

Note that WebUSB is currently only implemented by Chromium-based browser so Chrome, Chromium and recent Edge. On Windows you need to install the WinUSB driver for the Crazyradio using Zadig. On Linux/Mac/Android it should work out of the box.

The source code for the Web Client is not pushed on Github yet, once it is, it will be named crazyflie-client-web. It is currently mostly implemented in Rust and it will likely mostly be Rust since it is much easier to stick with one (great!) language. One of the plan is to make a javascript API and to push it on NPM, this will then become a Crazyflie lib usable by anyone on the web from JavaScript (or a bit better, TypeScript …).

My goal for now is to implement a clone of the Crazyflie Client flight control tab on the web. This would provide a nice way to get started with the Crazyflie without having to install anything.

Switching to Crazyflie-link-Cpp by default

2021-05-10 | Arnaud | Leave a comment

A little while ago we made a blog post talking about the communication reliability, one part of this work did include an alternative CRTP link implementation for the Crazyflie lib. This week we will make one of the native CRTP link implementations, the Crazyflie-link-Cpp, the default link for the Crazyflie python lib.

In the Crazyflie communication stack, the CRTP link is the piece of software that handles reliable packet communication between a computer and the Crazyflie. In the Crazyflie it is mainly implemented in the nRF51 radio chip (for the radio link), in the computer it is part of the Crazyflie python lib + Crazyflie client and for Ros and Crazyswarm it is implemented in crazyflie-cpp. Other clients like Lamouchefolle also have re-implemented their own versions of the CRTP link.

The CRTP link is the most critical part in the communication with Crazyflie, if it is not working properly, nothing can work properly, all communication with the Crazyflie passes though the CRTP link. This code duplication in multiple projects means that we have many places for diverging behaviour and creative bugs which makes it hard to develop new clients for the Crazyflie.

One way we are trying to solve this problem is to unify the links: let’s try to use the same link in all the clients. In order to do so we need a link that can act as a minimum common denominator: it needs to work with Python in order to accommodate the Crazyflie Python lib, work with C++ for Crazyswarm and LaMoucheFolle and be high-performance to be able to handle swarms of Crazyflies. The C++ link implementation can full-fill all these requirements using a python binding, and it will give higher performance to the Python lib.

Switching to the native C++ link will give us a lot of benefits:

It is higher performance, it has about 20% higher packet throughput than the pure python implementation
It will unify the Python lib and Crazyswarm a bit more. Crazyswarm will be able to use the same link as soon as broadcast packet support is added.
The Cpp link supports dynamic allocation of radios, no need to choose what radio to use for each connection, the link will distribute connections over all available radios by using a star instead of the radio number (radio://*/80/2M) in the URI.

The biggest drawback so far is that the CPP link needs to be compiled for each platform. We are compiling a python Wheel for it in Github actions for Windows/Mac/Linux on X86_64, any other architecture (including raspberry pi) will use the existing python CRTP link for the time being.

We are in the process of enabling the new link as the default in the lib. There are still some outstanding bugs related to boot loading that needs to be ironed out, but we expect this change to be included in the next release.

Release 2021.03: Lighthouse is stable!

2021-03-29 | Arnaud | 4 Comments

We are happy to anounce the availability of the 2021.03 release of the Crazyflie firmware and client! This release includes new binaries for the Crazyflie (2021.03), the Crazyflie client 2021.03 as well as the Crazyflie python library 0.1.13.2. The firmware package can be downloaded from the Crazyflie release repository (2021.03) or can be flashed directly using the client bootloader window. The firmware package contains the STM firmware (2021.03), the NRF firmware (2021.03) and the Lighthouse deck FPGA binary (V6).

The main feature in this release is the stabilization of the Lighthouse positioning system. The main work done has been on the system setup and management, it has taken a lot of work spawning all the projects and a brunch of documentation, but we think we have reached a stage where the lighthouse positioning system is working very well and is very easy to setup and get working. We have now published the new Lighthouse getting started guide and will be working this week at updating all required materials to mark Lighthouse as released!

When the Lighthouse positioning system was released in early access, it required to install SteamVR, run some custom scripts and flash a modified firmware to get up and running. This has been improved slightly over time with scripts that allows to setup the system without using SteamVR and some way to store the required system data in the Crazyflie configuration memory rather than hard-coded in the firmware. With this release, everything is coming together and it is now possible to go from zero to an autonomous Crazyflie flying in a lighthouse system in minutes by just using the Crazyflie client.

Lighthouse positioning setup and management tab in the Crazyflie client

Another major improvement made to support the lighthouse is the modification of the bootloader Crazyflie update sequence in the client as well as in command line. The new sequence will restart the Crazyflie a couple of times while upgrading the Crazyflie, this allows for an upgrade of the firmware in the installed decks if required. The lighthouse deck firmware has been added to the Crazyflie .zip release file and will be flashed into the deck while flashing the release to a Crazyflie that has the deck installed.

An alternative, robust TDoA implementation has been added for the Loco Positioning System. This change has been contributed by williamwenda on Github and can optionally be enabled at runtime.

An event subsystem has also been added to the firmware. It allows to log events onto the SD-Card which can be very useful when acquiring positioning data from the various positioning system supported by the Crazyflie. We have described this subsystem in an earlier blog post.

There has also been a lot of smaller improvement and bugfixes in this release. See the individual project releases not for more information.

We hope you are going to enjoy this new Crazyflie and lighthouse release. Do not hesitate to drop a comment here, questions on the forum if you have any or bug reports of github in the (very unlikely ;-) event that there are bugs left.

New storage subsystem and new CI

2021-01-11 | Arnaud | Leave a comment

Storage is one of these very simple functionality that actually ends up being quite hard to implement properly. It is also one of these functionality that is never acutely needed, it is possible to hack around it, so it gets pushed to be implemented later. Later is now, we have now implemented a generic persistent storage subsystem in the Crazyflie.

In Crazyflie 1.0, we originally stored settings in a setting block in flash and required the bootloader to change the settings. When designing Crazyflie 2.0 we added an I2C EEPROM to make it easier to store settings, though until now we only stored a fix config block very similar to the one stored in the Crazyflie 1 and that only contained basic radio settings and tuning. This implementation is hard to evolve since the data structure is fixed in one point of the code.

What is now implemented is a generic key-buffer database stored in the I2C EEPROM. From the API user point of view, it is now possible to store, retrieve and delete a buffer using a string as a key. This allows any subsystem, or apps, in the Crazyflie to easily store and retrieve their own config blocks. There is 7KB of space available for storage in the EEPROM.

The first user of this new storage subsystem is the Lighthouse driver. The storage is used to store lighthouse basestation geometries and calibration data, this allows to configure a Crazyflie for a system/lab and have it running out of the box even after a restart.

A future use-case would be to implement stored-parameters: we have been thinking about implementing optional persistence for the parameters for a long time. This would allow to modify and then store new default values for any parameters already present in the Crazyflie. This would allow to very easily implement things like custom controller tuning in a quad made from a bolt for example.

At low level, we where hopping to be able to find a ready-to-use library or file system to store data in our small EEPROM, but unfortunately we did not find anything that would fit our needs. We then had to implement our own storage format.

The low level structure is documented in the Crazyflie firmware repos. Basically the data are stored as a table of “length-key-value” entries with a possibility for an entry to he a “hole”. When new buffers are added they are added at the end of the table and when they are deleted they are replaced by a hole. When the end of the table is reached, the table is de-fragmented by removing the holes and moving the data as much as possible to the beginning of the memory. This structure works very well for an EEPROM and could even be adapted to work well on FLASH.

New CI

When we started activating continuous integration/automatic build to our GitHub repos we did so using Travis CI for firmware builds and AppVeyor for windows builds. However, the GitHub CI offering, GitHub actions, has become quite complete lately and now supports Linux, Windows as well as MacOS builds.

We have now transitioned to GitHub actions for all our repos and we will also implement most of the release process using GitHub actions as well. This will hopefully streamline the release process and allow us to release new version of our projects more often.

New client and python lib release

2020-09-14 | Arnaud | Leave a comment

Following firmware releases we have now released a new version for the Crazyflie client and python lib (cflib). It took a bit more time to test and fix various last minute bugs but we now have released Crazyflie client 2020.09 as well as Crazyflie lib 0.12.1.

Crazyflie python lib 0.12.1

The main new funcitonalities of the lib are:

Python 2.x support is now dropped. Python 2 official support has ended beginning of this year and it is not installed by default in Ubuntu 20.04, it was time to stop supporting it in cflib
Some documentation work
Capabilities to abort a bootloading operation

Crazyflie client 2020.09

There has been a brunch of cosmetic and functional changes in the client. Some themes have been added so that the client can now be used with a dark blue or even green-on black hacker theme. The used Qt theme has also been forced to be drawn by Qt on all platforms: this means that the client will not look like a Windows or Mac app on Windows and Mac, but the styling will be consistent on all platform. This will simplify development and make documentation consistent with all platform.

The bootloader has been changed to automatically download releases of the firmware from Github by default. This is a great quality of life feature made by victor this summer that makes it very easy to run Crazyflies with a clean release build.

There are also a brunch of bugfixes, the full changelog can be read on the release page.

Future plans

Semantic versioning for the lib

We have been thinking of using semantic versioning for the lib and bumping the version to 1.0. This will allow us to communicate the state of the lib more accurately: it is not perfect but it is perfectly usable. As well giving more freedom to break compatibility. A lot of things could be made better but we are always very careful not breaking backwards compatibility. Proper semantic versioning would allow us to make a Crazyflie client lib 2.0 making it clear that if you update from 1.0 to 2.0 you might have to make changes to your scripts.

Client binary release for more platform

So far, the Crazyflie client has had a binary release for Windows and some work to make one for MacOS. By Binary release we mean releasing the client in a form that does not require installing python, and then the crazyflie client pip package, on Windows it is an installer and on Mac it would be an app bundle.

Last week we have also been working on Linux releases, after all most of us uses Linux at Bitcraze so we might as well show it some love. Today we have released a snap of Crazyflie client. This means that you can install Crazyflie client from the Ubuntu software application on Ubuntu, or directly via the snap install –edge cfclient command on any Linux system with snap installed. There is still some rough edges, and a stable version will only be available for next release, but this should make it much easier to get started with the Crazyflie.

Crazyflie radio communication

2020-08-24 | Arnaud | Leave a comment

I am back from parental leave and during this time I tried not to think too much about Crazyflie-related things to get a little break. However, over time, while geeking around, I eventually ended-up back to Crazyflie and Crazyradio designing a new channel-hopping communication protocol. This will likely be the subject of a future blog post but for the time being I thought I could write a bit about how the current Crazyflie radio communication is working.

Protocol layers

Like Many protocols, the Crazyflie communication protocol is layered. This allows to plug different elements at each level. When it comes to a Crazyflie client talking to a Crazyflie over the radio, the layering looks as follow:

Services are high-level functionalities like log that allows to get values of Crazyflie variables at regular interval. At this level there is essencially an API with commands like addLogBlock.

CRTP is a protocol that encapsulates the commands for each sevices. It multiplexes packets on the link using port numbers, this is very similar to TCP/UDP port on a network, each service is listening and sending packet on a pre-specified port.

Finally the radio link only deals with raw packets. The role of the radio link is to deliver packets from the PC to the Crazyflie and vice-versa. At this level, we have many link implementations, the most used are the radio and the USB link but there also is a Serial link that uses the Crazyflie serial port.

Radio link

The radio link is currently implemented by the Crazyradio (PA) on the PC side and the Crazyflie on the other side. The Crazyradio uses a nordic semiconductor nRF24LU1 USB/Radio chip and the Crazyflie a nRF51822 MCU/Radio. This is importance since, while the nRF51 has a quite flexible radio, the nRF24 does use a standalone SPI radio that has most of the packet handling hard-coded to a protocol that nordic call Enhanced Shockburst (ESB).

The ESB protocol handles sending packet and receiving acknowledgement automatically. A packet is sent on a radio channel, using a 5 bytes address, and when this packet is received on the other side an acknowledgement is sent back using the same address on the same channel. Both the original packet and the acknowledgement can contain a payload.

To implement a bi-directional radio link, the crazyradio is the one sending packets and the Crazyflies continuously listens and, when receiving a packet, sends back an ack. We do use the payload capabilities of both packet we send and of the ack to implement an uplink (PC->Crazyflie) and downlink (Crazyflie->PC) data link.

Of course, one problem with this setup is that while the PC can decide to send a packet at any moment, the Crazyflie needs to wait for the PC to send a packet to have a chance to send one back in an ACK. To make sure the Crazyflie has enough opportunity to send packets back, we are sending packets regular interval to the Crazyflie even if there is no packet to be sent. This polling allows to implement a continuous downlink.

The most important to see here is that the radio link gives to the upper layer, the CRTP layer, the illusion of a full duplex link. On the radio side this is implemented by polling regularly for downlink packets.

Communicating with multiple Crazyflies

In order to communicate with multiple Crazyflie, we just send packet to each Crazyflies one after each-other. This way we give equal chance for each Crazyflie to send back packets and doing so we divide the available bandwidth between them.

The main advantage of the polling protocol versus a more traditional P2P protocol where the Crazyflies would send when they want, is that when using polling the Crazyradio is the master and we can guarantee that we are not introducing any packet collision when we communicate.

Limitation and future

One major limitation of the current protocol is that it communicates on a single channel and requires the user to set manually channel and address for each Crazyflies. This means that the user has to tinker with parameters to find a good channel and has to manually handle all addressing.

Another limitation is that the polling is done over USB by python or, in case of ROS/Crazyswarm, in C++. This adds the USB latency to the equation and complexifies the client implementation.

I have been working on defining a new protocol that would be implemented efficiently in a Crazyradio and that would implement addressing and channel hopping. The idea is to get closer to a connection style more like bluetooth low energy where you do not have to care about channels and setting address, you just connect your device. Unlike BLE though, this protocol will be optimized for low latency. Stay tuned, we will likely talk about that more in future posts :-).

Crazyflie flying with Lighthouse V2!

2020-02-24 | Arnaud | 5 Comments

We are happy to announce that we have gotten Crazyflie 2 to fly autonomously using the Lighthouse deck and Lighthouse V2 base-stations. This was a very requested features, and while this is not stable and ready to use yet, it is a great milestone toward Lighthouse V2 support.

There exists two incompatible versions of the Lighthouse positioning system. Version 1 was released with the original HTC Vive VR system. In this system base-station are using two rotating laser beam that sweeps the room, one horizontal and one vertical, and an omnidirectional synchronization flash to allow IR light receiver to be located in the room. One limitation of this version is that up to two base-station can be used and no more, this is mainly due to the fact that beam identification is done using a TDMA scheme: base stations switch-on their laser in a dedicated time-slot one after each-other and adding more time slots for more base-stations will greatly reduce the update rate of the system.

Lighthouse V2, was released with the HTC Vive PRO headset and is also used by the Valve Index. The big change is that laser sweeps now carries modulated data and that there is only one rotor with two angled slit instead of the two rotors for V1. The V2 sweep data is described as ‘Sync on beam’ and contains timing information of how long it has been since the synchronization event (ie. when the rotor crossed 0 degree). The sweep data also allows to identify the base-station that has transmitted the sweep. This removes the need for an omni-directional synchronization pulse and allows more than two base-station to operate at the same time in the same space, since their sweeps can now be identified and timed.

The lighthouse V2 system is very elegant and scalable. However, actually decoding the signal from the sweeps has taken a lot of time since it is not documented and we needed to find-out what the encoding actually was. There has been effort on the internet to understand how the system worked, the most useful one is this github ticket that goes from raw data acquisition to fully unlocking the beam encoding.

I have been working on-and-off for a long time on making an FPGA design for the lighthouse deck to acquire and decode Lighthouse V2. The main blocking point until now was that I had not been able to reliably acquire useful signal from the system in order to allow real-time decoding on the Crazyflie. Added to that, there was some inconsistency between what we though the system was doing and what we could gather from the base-stations debug console. Recently though, the last piece of the puzzle, was to discover that the beam encoding was not Manchester, as we though, but Bi-phase mark code FM1 (BMC). Once this decoding was used everything made sense and worked.

Added to that, I started using SpinalHDL instead of raw Verilog to write the FPGA design which allows for much quicker iteration, much less frustration, and it also allowed me to easily make the design multi-clock which is required to decode the BMC signal: the beam decoder runs at 48MHz, and the rest of the system works at 24MHz. This design is required since the FPGA we use in the lighthouse deck is not fast enough to run everything at 48MHz.

The result, is a new FPGA firmware for the lighthouse deck that receives, identify and decode Lighthouse V2 sweep signal and send them over to the Crazyflie. The Crazyflie still has a little pulse packing to do (putting together pulses from a single sweep received on multiple sensors) and then can use pulse timing information to calculate azimuth and elevation at which the base-station sees the Crazyflie. This information is the same as the one we get from Lighthouse V1 and so the same algorithm can be used to calculate the Crazyflie position.

I hacked a proof of concept was this last fun Friday and it flies!

If anyone is curious the code for this demo has been uploaded as an out-of-tree driver and the code for the FPGA parts is already in the lighthouse-fpga project. The current Crazyflie code is too incomplete to be usable, but it is a nice starting point if anyone wants to play with Lighthouse V2 and the Crazyflie right away ;-).

As a side note, the Bitcraze team will shrink temporary as I, Arnaud, will go in parental leave until mid-August. I look forward to this new adventure and I trust the lighthouse V2 development and the forum will be in good hands in my absence.