Two weeks ago, Arnaud, Barbara and Rik were at ICRA 2024 in Yokohama. At our booth we showed our current products as well as the upcoming brushless Crazyflie and the camera deck prototype.
As usual, the conference has been very busy with a lot of visitors and a lot of very interesting discussion. Thanks to everyone that passed by the booth, we have come back to Sweden with a lot of energy and new ideas!
The autonomous lighthouse swarm demo demo has worked pretty well. If you are interested to know more about it you can visit our event page. It is an autonomous demo with 3 brushless Crazyflies and 6 Crazyflie 2.1s flying autonomously. With the extended battery life of the brushless, we could operate the demo pretty much continuously.
If you’ve been at the conference, you may have spotted someone proudly sporting our exclusive ‘Bitcraze took my poster’ button. We’re excited to have received posters covering a wide range of topics, the walls of our office are eagerly awaiting these visual representations of your hard work and dedication. Thank you to everyone who has contributed.
The Crazyflie client has a quite long history, like a lot of things in the Crazyflie ecosystem it has been started when the Crazyflie was used alone using mainly manual control. It has evolved to follow new use-cases of the Crazyflie but it still has traces of its origins and some limitation are still there with us. Moreover, the Crazyflie client and lib are written in python, one the main goal was to make it easily cross-platform. Unfortunately making a cross platform graphical program that accesses hardware in Python has proven to be quite challenging and we feel Python is not the way to go anymore. In this blog post we would like to discuss a bit the current state of the Client and what we are looking at for the future.
A Crazyflie connected to the CFclient
The Crazyflie client was originally design to be able to fly, inspect and work with one Crazyflie. It still serves this purpose quite well: with the client you can connect your Crazyflie, observe graphs of internal log values in real time, setup different decks and sets and store parameters. It is a very good tool to explore and work with the Crazyflie.
However, it is only working with one Crazyflie at a time will take over the radio, so another script cannot talk to the Crazyflie at the same time using the radio. Unless the script uses the ZMQ API that allows an external program to control client and so to control the Crazyflie while the client is connected and active. This functionality can be very useful but, since it is disabled by default, has not seen a lot of use.
The worst, for us, in the current client state is Python and PyQT distribution situation: we used to have an easy-to-use installer on windows, a Linux Snap package and plan for a Mac App. All these have been pretty much abandoned because they kept breaking down over time and the support weight for us was too big. So the only way to install the client is via Pip, the python package manager. This means that you already need a well setup Python environment to run the client. That is nice unless you have a Mac or a Raspberry pi: the latest MacOS broke part of the client that prevents it to run and there is no PyQT build for raspberry-pi available on PyPi. This is the kind of paper-cut that keeps happening at regular interval with distributing a Python application and that we keep having to look at.
So, we have been looking at ways to improve the situation. The Crazyflie client is more than 10 years old now, so a rewrite would not be such a crazy thing to consider. There are at least 2 angle of attack to make a new client better suited for the next 10 years of Crazyflie development:
Multi-platform and distribution
Making a multi-platform program is and will always be challenging. However, we have discovered that doing it in a dynamic interpreted language like python is even more so. The main challenge come from the fact that things tend to break on the user side depending of the user configuration: we all run a slightly different version of python, python evolve and package management evolves as well, so when things break it breaks at random depending of how up-to-date a particular system.
One solution would then be to switch to a compiled programming language. This increases the probability of finding problem at compile time and not at runtime, which means that we will hopefully be the first to know then Apple decided to change the location of one fundamental piece of library and so allow us to hopefully fix the problem before any user is impacted (assuming we can run CI on the latest version of MacOS early enough…).
So, as you might have guessed, our current idea is to write the client in Rust. We are currently looking at Tauri for the UI which is Web based. We still have ideas of also making a web-client so having a web-based IU on PC would simplify development of that.
We are not letting Python go away though, the idea is still to support Python, but to use it for what it is good at: a great language for developer and experimentation. Rust has great bindings to python so in this plan, the python lib is backed by the Rust lib.
Modularity
The other side of the current client limitation is the fact that it connects one Crazyflie taking over the radio. We actually love using the client to observe and poke the state of a Crazyflie so it would be really great to use it when writing a script or controlling a swarm with Crazyswarm. The current ZMQ implementation was designed to solve this issue, but it goes at it the wrong way around: the client becomes the gateway to the Crazyflie and must always be ON. It would be much nicer to be able to launch the client to connect and inspect a Crazyflie currently control by a script.
One design we are currently looking at would be to use use a protocol like Zenoh between the client and the lib. Basically, when connecting a Crazyflie, be it from a script or from the client, a server would be launched in the background that would handle the connection. All communication would pass through this server and so multiple programs would be able to communicate simultaneously with the Crazyflie.
This would allow us to build easily bridges to ROS to get the client to communicate with a Crazyflie currently connected in ROS. And since ROS2 is working on supporting Zenoh officially a bridge might not even be required.
As an added bonus, the Crazyflie server idea would greatly improve the situation when it comes to supporting Virtual Machines and WSL on Windows: it would move the USB connection handling to a Windows program and only require fast network connections which is something that works really well on WSL or VMs.
Conclusion
In this blog post I have tried to describe our current challenges and some way forward we see. The main message though is that we want to change things when it comes to the client, if you have wishes or ideas now is a good time to get in touch. Let’s make the next 10 years of Crazyflie client problem-free.
There is a new release of the firmware, version 2024.2. The main change, and almost only change, in this release, is the Bluetooth stack that was updated from the Nordic’s semiconductor S110 to S130, which affects the firmware on the NRF51 on the Crazyflie. This was mainly done to be able to pass the listing requirement on Bluetooth SIG, but it will also have beneficial technical effects on the Crazyflie radio communication state of affairs.
The new stack and bootloader are distributed in the normal release .zip, which means that it can be updated from the client as normal. Please note that the latest lib and clients are required as we have had to implement new procedures to flash the bootloader and stack.
First of all, let’s define what is a soft device. Nordic semiconductor radio chips are awesome in the way that the radio hardware is fully documented, this means that we can implement our own radio protocols but we would also be able to implement our own Bluetooth stack (I have attempted that a long time ago with some success, the nRF5 radio hardware is really powerful and can be set up to do much of the work!). However, backing your own Bluetooth stack would require passing a full suite of validation at the Bluetooth SIG to prove the stack conform to specification. In order to avoid that, the usual strategy is to buy a Bluetooth device and to talk to it over UART. What Nordic did is to implement a “Softdevice”, a binary blob that runs in the same CPU as the user application and that talks to the application using software interrupt. This keeps the application completely separated from the Bluetooth stack and so means that we get the benefits of a pre-qualified Bluetooth stack that has already been tested and approved.
Currently, we have ported the bootloader and the nrf firmware to the new S130 stack. This opens a lot of potential benefits for the future:
The new stack should be at least 6 times faster than the old one. This makes implementing BLE communication for the Crazyflie to a PC/Chromebook much more appealing and should allow to make the existing mobile client more full features.
We are now able to update the bootloader, so we can make a new improved version of it in the future (ie. with safe link, swarm optimization, much faster Bluetooth boot loading….)
The new stack supports device and host mode. So things like pairing a gamepad with the Crazyflie becomes a technical possibility! (actual implementation is left as an exercise for the contributor ;-).
One very important thing to note is that working on the bootloader requires a debugger: if you flash a bugged radio bootloader you need a SWD debug probe to be able to fix your Crazyflie. The bootloader+softdevice flashing procedure is very safe, as long as you flash a working firmware.
This change should open quite new exciting possibilities. It will be interesting to see what we can achieve with BLE and updated bootloaders in the future. Please note that we had to make a change to both the Crazyflie python library and the CFclient in order to flash this new firmware so make sure that you update those as well to try out this new release.
Developer meeting
The next developer meeting will be on the 6th of March 2024, we will talk about the Crazyflie Supervisor subsystem… We have made some changes to the supervisor recently, and we will continue working more on it in the next couple of weeks mostly preparing for the arrival of the Brushless Crazyflie. We will talk about the current state and what we are working on. Follow the thread on Bitcraze Discussions to be up to date on how to join!
Lately we have been thinking about and using the Rust programming language more at Bitcraze. In this blog post we will talk a bit about our current use, current experiments and potentially future use and how it will affect our ecosystem.
Rust is a system programming language that has good performance, is reliable and productive. Practically it means that it can be used to run small and fast code (well suited for embedded systems for example), be quite fun to write, and be reasonably sure that if it compiles, it works.
On servers
Over the year we have written and maintained a server system to handle a lot of things related to production and sales. This system is the one generating shipping quote when you order in our store, telling us that there is an order, printing packing lists and shipping labels for the order as well as keeping track of stock and telling us when it is time to order a new batch of product.
This system is used every day and has been invaluable to how we work at Bitcraze. It is mostly implemented as NodeJS micro services.
We have started writing new functionality for it in Rust instead of in a new monolithic service. This has been a great experience, not always easy, but the bonus is that once it compiles there has been almost no run-time error. This has allowed us to gain experience with Rust in an environment that is well documented: servers on PC.
In test rigs
Every manufactured product must be tested: there is no guarantee a board will work when it exits the re-flow oven. This test usually happens in a test-rig that measures and affects various signals on the board (look under your favorite Bitcraze deck and you will see test-points: round pads designed to enter in contact with test probes). Attached to this test-rig is a computer running our test software. We have used a Python-implemented test software for all our products so far and this system started showing its age by being harder and harder to work with and, most importantly, hard to deploy on computers in the factory.
For Crazyradio 2.0, we decided to completely re-write our test software, in Rust of course :-). The design of the test framework is very inspired by OpenHTF: the framework provides the basic architecture of the test and the executor, tests are implemented in Rust and implement all the required test phases. Test statuses are streamed to a web browser as well as to our server (to one of the newer parts of our server system written in Rust). There are two big advantages of using Rust in this application: making sure the test software works reliably and without errors saves a lot of time during manufacturing and helps make sure no bad board leaves the factory. Rust is also awesome to deploy and distribute: the software written on our Linux machine can be compiled for Windows/Mac/Linux on any architecture, no more Python environment to set up!
As for the deployment we actually choose to deploy the test software on a Raspberry pie managed by Balena cloud. This means that we can remotely update the test rig software and we are always sure that the right version is running in production. Rust has allowed that to be painless: we develop on our amd64 PCs and it compiles out-of-the-box and works on the ARM64 Raspberry Pi.
In embedded systems
Now we are coming to our more experimental use of Rust, until now on fun-Fridays project but soon on prototypes. We have been playing with Rust on embedded for quite a while: I have re-written the Crazyflie2’s stm32 boot-loader in Rust, we have experimented with Rust on a couple of our ESP32-based prototypes. Embedded systems are never as easy as programming on PC and the way Rust libs are organized to guarantee good usage of the peripheral does not always yield good error messages from the compiler. But, for sure, it does not feel good and it feels very scary to come back to C: the Rust compiler checks so many things that it makes programming fun, with C, any small mistake will bite hard a couple of weeks later.
We have just started working seriously on a new deck (more about it in a future blog post ;-) and we have started in Rust. We do still take that as an experiment: we keep our options open to coming back to C if there is any hiccup. But so far it looks quite good.
In the Crazyflie lib?
That is a future plan, that we have not started to work on seriously at all, but that we are planning for the future. We are planning to write a new version of the Crazyflie lib in Rust with binding to other languages.
According to our experience so far, Rust is safe, fun to write, and very easy to distribute to all the systems we currently support with the Python lib and more. On top of Windows/Mac/Linux, Rust would enable support of our official lib on the web, in embedded systems (ie. ESP32), as well as on iPhone and Android.
The plan would be to have the low level of the lib, ie. communication with Crazyradio and the Crazyflie and subsystems drivers, implemented in Rust. Then binding to Python, C++, Ros, Javascript, … can be made to allow usage of the lib in these languages. This would have the advantage of allowing every current user to use the official lib without having to re-implement their own special-purpose version. On the Python side, nothing would change, in the sense that a Rust-implemented lib can be installed with “pip install cflib” …
Conclusion
This blog post is a request for comments: if you are a user of the Crazyflie and have strong opinions for or against Rust we would like to hear about it. We want to make it clear that we are not planning on porting the Crazyflie firmware to Rust: the Crazyflie is designed as a development platform and we are aware that Rust is not yet as used or well-known as C or Python. However, the firmware running on a deck CPU or in the bottom of the lib would benefit a lot from Rust’s advantages and do not need to be modified so often outside Bitcraze (it is of course always open-source and we encourage contributions :-D).
We will keep you updated if we make more progress on the new deck and the lib, in the meantime we will keep having fun experimenting :-).
As you might have noticed, most of our bundles are currently unavailable because Crazyradio PA is out of stock. We are currently finishing the production for the Crazyradio PA replacement, Crazyradio 2.0 which means that, if everything continues to go well, it should be in stock and ready to ship in a couple of weeks.
One of the first produced unit of Crazyradio 2.0, fresh out of a successful run in the test rig
Crazyradio 2.0 is designed to be a drop-in replacement for Crazyradio PA as well as an improvement that will allow new development and improvement for the communication with Crazyflie(s). Among the hardware change we have:
Much more powerful microcontroller: the nRF52840, a Cortex-M4 at 64MHz, 1MB of Flash, 256KB of ram with a much more flexible 2.4GHz radio hardware compared to Crazyradio PA.
Safe and easy to use Bootloader with button to launch it for easy upgrade
RGB LED for richer status indication
The same SWD debug port as on the Crazyflie 2.0 for easy development and debugging
As on Crazyradio PA, a radio power amplifier with a 20dBm (100mW) output power
Only support 1Mbit/s and 2MBit/s bitrate (Crazyradio PA also supported 250Kbit/s)
The improved microcontroller and safe and easy to use bootloader are the most important as they will allow us to experiment and implement new radio protocols over time. Things like peer-to-peer protocols, channel hopping and link cryptographic protection are now possible to work on.
All these new functionalities will come later though. So far we have been really hard at work to get the hardware ready and out as a Crazyradio PA replacement. To achieve that goal we have developed two version of the Crazyradio 2.0 firmware:
The Crazyradio2 firmware that implements the same radio protocol as the Crazyflie 2.0 but has a new improved USB protocol that improves performance and allows for the development of new radio protocols. It will also not require any driver on Windows.
The Crazyradio2-crpa-emulation firmware that emulates a Crazyradio-PA USB and Radio protocol. This version of the firmware allows to use the Crazyradio 2.0 with any client that supports Crazyradio PA.
Since support for the new USB protocol is not implemented in any clients yet, we are shipping the Crazyradio 2.0 in bootloader mode. When plugged in a computer for the first time, Crazyradio 2.0 will appear as a USB disk drive:
Clicking on README.HTM will open the web-browser to the Bitcraze website page that lists both available firmware with explanations of which one to choose. At first the CRPA-emulation firmware will likely be the most useful but over time the new Crazyradio2 protocols will be the best choice. Once the firmware downloaded it can just be drag-and-dropped in the Crazyradio 2 drive and the radio will restart in firmware mode and be ready to use!
Pressing the button on the Crazyradio when inserting it in the PC will launch the bootloader again and we are planing on making future updates possible via the Crazyflie clients as well. This is an exciting time as we will now be much more free to experiment, iterate and eventually greatly improve the communication capabilities of Crazyradio as well as of the Crazyflie quadcopters!
Now for the more practical information: if everything goes well Crazyradio 2.0 will be available in the bitcraze store the last week of April 2023, we are going to sell it for 40 USD. This means that most bundles should also be back in stock with Crazyradio 2.0 replacing Crazyradio PA in the bundles.
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!
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 our 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.
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).
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):
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.
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.
