Announcing Rust bindings for ROS2

Hi,

I hacked together a generator and a client library for writing ROS2 applications in Rust over the holidays, and finally found some time to write a README file… the last 10% is always the hardest part :slight_smile:

Anyway, publishers and subscriber work, along with simple messages. There’s still missing a bunch of things and I’m still learning Rust, so if anyone is interested in contributing (including criticizing my Rust), you’re more than welcome!

25 Likes

I mentioned an idea to do this to Mikael at ROSCon last year. I’m glad to hear it’s underway.

Is there any material or documentation that gives an insight into why use Rust for ROS? I have never used Rust before so would like to get an understanding why before deciding to go down that path. Any reference material would be helpful to me. Thank you.

I’m far from being a Rust expert, so take my advise with a grain of salt.

I’ve found Rust to be a more modern (perhaps better) version of what C++ would be if it were designed today. The tooling is much better (actually, the tooling in C++ is non-existent, so that’s easy to beat): things like a proper package manager (Cargo) and an official repository of packages (crates.io) make the Rust ecosystem much easier to start with and contribute to.

The language itself feels better designed as well. Concurrency in Rust is much more pleasant: among other things, variables are immutable by default and values are moved instead of assigned, and thanks to that, the compiler will tell you before compiling your program whether it’s valid or not, preventing most data races (you can still deadlock a Rust program, though https://doc.rust-lang.org/beta/nomicon/races.html). Rust doesn’t have a runtime, so when you compile a program it’ll already have all the dependencies, so crosscompiling for embedded devices becomes trivial (or even crosscompiling Rust for WASM!). You can also compile a Rust program without Rust’s standard library, and thanks to that, you can have Rust programs running on a microcontroller.

And that’s only a few things that are directly applicable to robotics. But there are many other advantages in general. For example, template metaprogramming in C++ is difficult since the language does not yet support concepts (try debugging an ill-formed template), whereas Rust has traits (https://doc.rust-lang.org/book/second-edition/ch10-02-traits.html) that will check that a template implements a given behavior before being instantiated. Rust is also very is to embed, you can write your library in Rust and expose a C API. For example MesaLink (https://github.com/mesalock-linux/mesalink) uses the Rust rtls and sct cryptographic libraries and exposes a OpenSSL-compatible C API that can be used by C and C++ programs as a replacement for OpenSSL, while having all the advantages of Rust. Unlike Go, Rust doesn’t have a garbage collector, so it’s closer to C and C++ than to higher-level languages like Java or Python.

That being said, there are a few things in Rust that need to be properly stabilized (e.g. it doesn’t have a defined memory model, it just inherits whatever model LLVM has https://github.com/rust-lang/rfcs/issues/1447). In any case, I think Rust has a lot of potential and IMHO it’s on the right track to become a serious alternative to C and C++.

BTW, if you want to try out Rust on ROS1, check out Adnan Ademovic’s rosrust https://github.com/adnanademovic/rosrust It might help you get a better idea of what’s possible with Rust while not having to learn ROS2.

7 Likes

I looked at crate.io, but as someone who actively uses Rust, what’s the availability of libraries like compared with C++? Both on the STL-equivalent side and on the broader ecosystem side?

Also, what is the quality level like overall of the available and commonly-used libraries?

1 Like

I’ve been learning rust recently, going through The Book, as well as The Cargo Book to get a better grasp on both the memory safety features of the compiler and build ecosystem. Would there be any other folks who’d like to help start a working group for developing rclrs client library?

1 Like

Absolutely! I was thinking the very same thing yesterday!

Should we open a new thread to poll others interested for an inaugural meeting time?

I don’t know if it needs to be a new thread or not, but yes, I think polling for a meeting time is a good idea.

Yay! So happy to see more people interested in ROS2 and Rust. However I can’t help but wonder what’s the need for a meeting. The code is up there for anyone to contribute to, there’s still a lot of work to do and any contribution is more than welcome.

Well, a lot of other working groups meet and organize regularly to catch up and discuss new ideas: Some concepts I’d like to float for an agenda off the top of my head:

  • improving cargo build integration: colcon_cargo + tools::cargo-plugins?
  • how much of rclrs could be shared with rust’s ecosystem: crates.io
  • soliciting guidance from the larger friendly rust community: users.rust-lang.org
  • improving message IDL integration: avoid re-generating default messages
  • design goals for making the API overall more idiomatic with rust code

Others may have more ideas I’d like to listen to. I think syncing up over a discussion would be a lot quicker than prematurely cycling across timezones on tickets that may be otherwise too unclear to tackle.

I’d say those items would make great GitHub tickets.

Gérard Long has just added support for Crystal after I opensourced rclrs a year ago, and he also added support for Cargo to colcon a couple of months back.

I’d love to see more activity in rclrs, but I don’t see how a working group and meeting would solve that. rclrs has been opensource for well over a year, the code is there and available for everyone to contribute to in any way they feel capable (e.g. reviewing pull requests, proposing new features, suggesting improvements, filing bug reports, etc.)

Cool, sounds good! I’ve opened some tickets:

Most aren’t as informative as I’d like, but barring any prelmerary dialogue, this is what I came up with.

Ok, it’s just there hasn’t been much rclrs activity ‘for well over a year’, so I was thinking we could try and organize our efforts a little more. Also, I prefer brainstorming over a call given my typing impairment.

What I personally need to be able to contribute is a list of contributions that a rust beginner could handle. I don’t have much experience with rust so I can’t handle complex contributions or write idiomatic code yet.

1 Like

Thanks!

Yeah, it’s unfortunate that rclrs hasn’t attracted more attention since I opensourced it, but I’m happy that it has now and I’m hopeful users will file tickets and submit pull requests.

That’s a great idea. However, I’d argue that any contribution is great, no matter how small or unidiomatic they may be, I believe more in iterating than in getting it right at the first try. I’ll create tickets for issues that might be straightforward to work on, however there’s the added difficulty of learning the internals of the message generation pipeline in ROS2.

Hey all,

What’s the status of the ROS2 rust bindings?
This is a project that I would potentially be very interested in contributing as I am a big believer of rust in future robotics…

After taking a look at https://github.com/ros2-rust/ros2_rust I gather that it’s not under active maintainance. Am I wrong? Is support for rust bindings at any point of your roadmap for ROS 2?

1 Like

It’s still somewhat maintained, unfortunately I haven’t been able to dedicate much time to continue development lately, but I’m more than happy to accept pull requests and tickets.

https://github.com/ros2-rust/ros2_rust/pull/3 is pending for merging which will add support for Crystal, but I’m waiting for some feedback to be addressed. I’ll make the changes myself in the following days if the submitter can’t do it.

Hey @esteve,

Thanks for your work on this. :slight_smile:
I’ll take a look at the next couple of days

For folks still subscribed to this old thread, check here for more recent news about a Rust WG: