To kick things off, I’d like to suggest some initial topics. Also, forgive me if some of this is elementary for most ROS users, but for the sake of our fellow Rustaceans, new to the ROS community, I’ll be including references to general ROS concepts throughout this post.
Client Library
Client libraries are the APIs that allow users to implement their ROS code. They are what users use to get access to ROS concepts such as nodes, topics, services, etc. Client libraries come in a variety of programming languages so that users may write ROS code in the language that is best-suited for their application.
https://index.ros.org/doc/ros2/Concepts/ROS-2-Client-Libraries
The ROS2 client library for Rust, rclrs, was first announced by @esteve in early 2018:
As rclrs development stalled, a call for more maintainers was posted this year:
Stewardship of the rclrs client library could become a primary objective for the Rust Working Group, contributing to its further development and continual maintenance. Solidifying support for an additional client library would not only positively reflect the maturation of the ROS2 ecosystem, but also help diversify our community; garnering more developers by making ROS more accessible via more programming languages. Additionally, the emergence of an alternative high performant client library could further motivate RCL discipline, curbing feature creep in rclcpp, otherwise eroding feature parity and consistency between all client libraries.
Although Rust has particularly good FFI support for C, enabling RCL to be wrapped largely via auto generated bindings, rclrs doesn’t yet expose an idiomatic Rust API for all common functionality. Many core features are still missing, such as services, actions, parameters and component nodes. Additionally, due to the current ROS2 support of non-default clients, code generation for using rosidl message data types with Rust is currently tedious, given rosidl_generator_rs isn’t shipped/registered with binary releases, necessitating recompilation of message packages used by rust packages. Advancing the Rust client library to eventual Tier 1 support could go a long way in improving the out-of-the-box experience for ROS users using Rust.
http://docs.ros2.org/latest/developer_overview.html#the-rosidl-repository
Building and Packaging
A workspace is a directory containing ROS 2 packages. Before using ROS 2, it’s necessary to source your ROS 2 installation workspace in the terminal you plan to work in. This makes ROS 2’s packages available for you to use in that terminal.
https://index.ros.org/doc/ros2/Tutorials/Workspace/Creating-A-Workspace
Workspaces in ROS2 are built using colcon, a build tool for building, testing software packages, regardless of language or build system details. Analogously, workspaces in Rust are built using cargo, a build system for building, testing Rust crates.
https://doc.rust-lang.org/cargo/reference/workspaces.html
In addition however, cargo also manages dependencies, downloading and compiling external crates as needed for workspace compilation, a task explicitly out of scope for the colcon build tool. An extension for colcon to support Rust projects built with cargo was initiated, but is not complete enough for rclrs nor example ROS node packages using rclrs.
The current build setup for rclrs is not very robust, and uses a complex hybrid of cargo and cmake to generate and export the targets respectively. Native cargo support in colcon could help simplify Rust integration with ROS workspaces, with rclrs being a prime candidate for dogfooding usability improvements.
Special considerations would include:
-
interplay between cargo and colcon workspaces
-
packaging shared target directories and precompiled rlibs
-
dependency resolution across rust crates/packages
https://wiki.debian.org/Teams/RustPackaging/Policy
Documentation
One beloved aspect of the Rust ecosystem that draws so much attention, perhaps also driving user adoption, is it’s great documentation. The Rust ecosystem holds high standards for library documentation; fortunately it also ships with a standard documentation generator.
https://doc.rust-lang.org/rustdoc/what-is-rustdoc.html
Similarly, documenting the Rust client library API and examples will go a long way in attracting more users and subsequent contributors to help sustain development. As per package documentation requirements are in the process of being formalized, it may be helpful to help flesh out ideas for supporting other languages by prototyping an out-of-box solution using rustdoc for ROS packages written in Rust.
CC: @jhdcs @OTL @lucasw @tomoyafujita @azazdeaz @lelongg @tprk77 @bergercookie @deb0ch