We have already had a few discussions about putting more Rust into the Crazyflie ecosystem. One of the places where we find it could be the most beneficial is to replace the current Python-based Crazyflie Lib.
Why a Rust Crazyflie Lib
Rust is a modern system programming language that prioritizes reliability and productivity. This means that it is a language that will have enough performance for any current use-case of the Crazyflie lib, and nice enough to use that we can write code that is correct and easier to maintain. So in a way, switching from Python to Rust, is a move to benefit the main lib developers, us here at Bitcraze.
Furthermore, Rust has binding capabilities to almost everything. So, with a Rust implemented lib, we can target languages for all current users of the Crazyflie: mainly Python and C++ (for ROS). This means that we can make and maintain one lib for everyone.
This would be mainly interesting for the Crazyflie ecosystem because it would lift the Crazyflie API one notch. Currently, if you want to talk to the Crazyflie in C++, Swift, Kotlin, or any other language that is not Python, you have to re-implement the radio link as well as all binary radio packet handling that communicates with the Crazyflie. Our goal is to raise that to the Crazyflie lib: the Crazyflie lib would then become the Crazyflie API.
This does not mean that we want to prevent anyone from playing around with the radio packets, but we do not want that to be a requirement for interacting with the Crazyflie.
Status
Since we last talked about it, there has been quite some progress with the Crazyflie rust lib. First of all it has been moved from my personal GitHub to the Bitcraze Github. It is now an official day-time Bitcraze project :).
The lib has also been used by Marcus to make a Crazyflie-cli. This is a very useful tool when developing or working with the Crazyflie. It makes it possible to observe values, set and get params, and more, directly from the command line.
Finally, the Crazyflie Rust lib is now used in the production test rig for the Crazyflie 2.1 Brushless. We have a new rust-built test system for production that was developed for Crazyradio 2.0, and the Rust Crazyflie lib is now part of it for producing Crazyflie 2.1 Brushless. This means that the Rust lib is now officially in use and needs to be maintained! A side-project it is no more :-D.
Future, where are we going?
We have been thinking for (way too) long about what strategy we would take to introduce the Rust Crazyflie lib. The plan we currently have is to replace the current python lib, but to keep as much as possible of the current python API. The goal being to run the Crazyflie client on top of the Rust lib.
This would not only improve the client and lib reliability and performance, but it will also prove that the Rust lib is full featured enough to be used by more clients. Then we can target C++ and even Swift and Kotlin to finally improve our mobile clients.
Finally, one ‘dream’ that might be enabled by this move is to be able to make a Web-client. There are still a couple of technical hurdles (for example the fact that we for now only support the Tokio async executor), but this lib would be the foundation for a WASM mobile client. Imagine configuring and controlling your fleet of Crazyflie directly from a web-browser. Of course we need to focus on what can work today first, but this might become possible in the future thanks to Rust.