Example of package with `srv` definitions

[michalfita]

I have a C++ package that has a definition of a service in srv directory. That was a working one that I'm tasked to covert to Rust.

Apart of lack of good documentation easily available (#275), I think I figure out most of easy things apart this one.

My package.xml has among others:

  <buildtool_depend>ament_cargo</buildtool_depend>
  <buildtool_depend>rosidl_default_generators</buildtool_depend>
  <buildtool_depend>rosidl_generator_rs<buildtool_depend>

  <build_depend>rosidl_runtime_rs</build_depend>
  <build_depend>rosidl_generator_rs</build_depend>

  <exec_depend>rosidl_runtime_rs</exec_depend>

  <export>
    <build_type>ament_cargo</build_type>
  </export>

but I can't find anything resembling mypackage::srv::ServiceType like my C++ package has.

It would be nice if there's an example how to set up such thing right where the service isn't actually specified in extra package (like example_interfaces).

Thank you.

[michalfita]

@nnmm as you seem to be most active contributor to this project, maybe pinging you would prompt some response. I'd be really glad to get some hint as if I cannot progress I would have to declare this project unusable for us = delaying pick up of Rust for very long. Thanks.

[esteve]

@michalfita it's tricky because we don't have support for generating messages directly from a Cargo project, in the future we might be able to generate messages dynamically, but not now.

Your C++ project works because it uses CMake, which has macros for triggering message generation. As a general guideline in the ROS world, it is recommended to separate message packages from code, that way your projects can talk to each other without integrating the messages in the same package. For example, the ROS 2 Python bindings don't support mixing code and message definitions either.

I'm closing this issue, but feel free add more comments if you need further clarifying.

[esteve]

@michalfita I suggest you move the message definitions to a separate package (you can use many of the existing message packages as a template) and have your code separate from the messages. Having said that, we don't support many of the standard features that other client libraries have (mainly lifecycle nodes, actions and timers), so if those are important in your project, you'll have to reevaluate whether you can use ros2-rust or not, but contributions are always welcome 🙂

[michalfita]

Thanks @esteve!

Your C++ project works because it uses CMake, which has macros for triggering message generation.

Anything what build.rs would lift? Is it matter of running some tool prior to rest of the process?

I suggest you move the message definitions to a separate package (you can use many of the existing message packages as a template) and have your code separate from the messages.

In this case it's actually only one that uses rest defined elsewhere. My experience with ROS is zero, so I have no idea why it's done this way, I'll try to poke some souls.

mainly lifecycle nodes, actions and timers

Is it deliberate choice, or matter of effort required to add them? Time to switch to Rust is now...

but contributions are always welcome 🙂

I'd love to, but neither my main role is doing ROS code nor Rust code at the moment. This is only feasibility demonstration.

[esteve]

Anything what build.rs would lift? Is it matter of running some tool prior to rest of the process?

Perhaps that would be the place, but I strongly encourage you to the messages to a separate package, we won't support generating messages from a ros2-rust project` and neither does the Python, Java and the other client libraries. Generating code from messages involves many parts in the ROS 2 infrastructure that makes no sense to replicate in Rust (e.g. generate C and C++ messages, adding entries to the ament registry, handle dependencies, etc.)

In this case it's actually only one that uses rest defined elsewhere. My experience with ROS is zero, so I have no idea why it's done this way, I'll try to poke some souls.

I can only speculate, but perhaps that was done to quickly iterate and because the project was already in C++. In any case, this approach against ROS's best practices.

Is it deliberate choice, or matter of effort required to add them? Time to switch to Rust is now...

Just a lack of time. @jhdcs is working on lifecycle nodes right now and I'm working on actions (see #295)

I'd love to, but neither my main role is doing ROS code nor Rust code at the moment. This is only feasibility demonstration.

No worries! Thanks for your interest in ros2-rust 🙂 Let me know if you need help.