Using ROS 2 Rust Message Crates without Patching

[maspe36]

Hey all, I've been noodling on this for a while, but I've got an end-to-end example that allows a ROS 2 cargo package to depend on a generated message crate without any confusing .cargo/config.toml patching from colcon-ros-cargo.

https://github.com/maspe36/ros2_rust_shim_message_example/tree/main

This is a potential approach we could take to remove the need for patching and maybe even cargo-ament-build entirely (This part is still more of a WIP).

Let me know what you think :)

[jhdcs]

Your README at https://github.com/maspe36/ros2_rust_shim_message_example/blob/main/from_crates_io/rclrs_example_msgs/README.md says that this is not intended to be used within a Colcon workspace? Is there something about this approach that doesn't work well with Colcon?

I'm very interested in any build method that allows us to avoid patching, but I feel like it needs to be compatible with how we build ROS 2 projects.

[maspe36]

Because it would have a duplicate package name as the actual message package unfortunately.

These shim crates are helpful for standard messages because we can upload them to crates.io, removing the need to vendor anything. However, I think the gold standard is to also allow them in Colcon workspaces as well because then people could use them for their own custom messages without creating two packages

[esteve]

This is really cool, thanks @maspe36 A while ago I wrote a rosmsg parser in Rust, I wonder if we could combine both and with a little proc_macro magic create messages on the fly and avoid any issues with rosidl_generator_rs.

[esteve]

Yeah, I think the majority of problems that first time users have with ros2-rust are caused by message generation. If we find a way to generate messages on the fly in a more or less idiomatic way, we could get rid of vendored messages, the entire ROS-based message generation pipeline and would perhaps make it easier for users who don't want to use colcon, while at the same time being a good ROS citizen and being fully integrated in ROS.

[esteve]

In any case, that may come later and perhaps it may not be even possible to achieve, so for now focusing on getting rosidl_generator_rs into ROS is IMHO the best approach short term

[maspe36]

I agree, a lot of the problems our new users experience stems from us doing message generation a ROS-y way. I haven't honestly considered simply dropping the generator entirely, I'll spend some time thinking about what message generation would look like without rosidl_generator_rs.

Just off hand, what do you think the entry point for message generation would be? A similar approach as I've taken here where an external crate is pulled down and in that crates build.rs we generate messages based on .msg, .idl, etc files found in share/? What about for a custom message?

Do we just expect a user to have a macro call somewhere in their application code?

[esteve]

Do we just expect a user to have a macro call somewhere in their application code?

Yeah, I can imagine something like use_ros_message!('std_msgs/msg/String'); at the top of any file, which would internally access the ament registry, find the .msg files (and eventually the .idl files) and parse them, use proc_macro to create structs on the fly and then use those the structs normally.

[mxgrey]

One issue worth considering here is the diamond of death problem.

Suppose I have two independent libraries A and B which both want to do something with TF messages. They each separately generate bindings for tf2_msgs. Now I want to use both libraries A and B in my ROS node, but I can't get those libraries to work with each other because they've each generated their own versions of tf2_msgs which don't consider themselves to be the same since they were generated within different crates.

We're already seeing issue reports similar to this with the vendored messages being used inside rclrs.

[maspe36]

Just keeping a running list of cases where a user runs into an issue, and reports it, where a shim crate would have in theory avoided

• std_msgs version 4.2.3 is yanked #472