Pollen Robotics call for #Rust2018: toward stability on embedded systems

Robotics developers face two main problems:

• Embed complex algorithms for IA, motion planning, vision analysis, communication protocols, etc. in tiny low-power microcontrollers and running in real time.
• We also have to deal with an almost total lack of standard to access a variety of low-level sensors, effectors, and protocols.

You can imagine that these two issues combined make roboticists really fearful! Until they found out about Rust!

Rust at the rescue

No need to remind rustaceans how Rust core features are also central for embedded systems and robotics (safety, fearless, zero-cost abstraction). The embedded community already developed some great tools such as the cortex-m, xargo, or svd2rust crates. Rust for embedded brings the best of two worlds:

• the efficiency and performance required for the embedded world,
• with safety and advanced abstraction (e.g. Traits), as well as modern tools for packaging and testing.

Close the gap even further in 2018

In our team we are mostly working with ARM-cortex M0, the tiniest of ARM processor. We discovered Rust about 4 months ago and we have been re-writing our whole library stack in Rust since then. We are so pleased with the result that we decided to release it as open source.

Yet, for 2018 we hope that Rust for robotics can become even better!

First, we only know nightly. In 2018, I simply wish we could switch to beta or even stable! That would be a big statement from Rust toward embedded systems. As already pointed out by others (e.g. here and here), many features already developed still need to be stabilised.

Second, I feel like there is still a lot of confusion about how to develop a library that can work both on std and no_std. Indeed, most of the std can in practice be used even in our really constrained environment (128K Flash, armv6 architecture without most atomic instructions). std subparts such as io, alloc, fmt can be compiled for embedded targets and used without too much difficulties. Yet, the entire std won’t compile and thus you have to manually relink all the std features you used within your no_std context.

As an example, making euclid, a geometry primitives crate, works on no_std is not really complex but forces you to modify most of the modules by adding import such as:

#[macro_use(vec)]
extern crate alloc;
use alloc::{String, Vec};

I wish there was a simpler solution and that we would not have to worry about writing two different versions of our code (or having to use #[cfg(not(std))] everywhere) one for std and one for no_std. Some discussion already started. If an official method is not released in early in 2018, I’m afraid to see duplicate versions of the same libraries, adding confusion and making it all harder to maintain.

As I said before we are new comers in the Rust community, and the above may only be due to lack or experience or hindsight on my part. We discovered Rust in late 2017 and are absolutely convinced about its tremendous potential for embedded systems and robotics. It helped us already so much to be fearless and write more reliable and more collaborative code.

We hope we can participate and contribute to make it even better in 2018!

If you are interested to know more, we explained why we think Rust is the future of robotics !