Service topics_and_raw_types missing when using webviz

[maxlein]

Missing service when using webviz:

See ticket here

JSON command received: {"op":"call_service","id":"call_service:/rosapi/topics_and_raw_types:1","service":"/rosapi/topics_and_raw_types","type":"rosapi/TopicsAndRawTypes","args":{}} +11ms
  ros2-web-bridge:Bridge Response: {"op":"status","level":"error","msg":"call_service: Error: The message required does not exist: rosapi, srv, TopicsAndRawTypes","id":"call_service:/rosapi/topics_and_raw_types:1"} +0ms

[minggangw]

rosapi, as a bunch of services, is implemented by the rosbridge_suit for ROS1, but ros2-web-bridge doesn't offer this kind of functionality for ROS2 until now. Some previous discussion could be found #129 #122 #73, thanks!

[mis-eu]

@minggangw has this been implemented for ROS2 Foxy yet?

[minggangw]

Not yet, I'm afraid I don't have the bandwidth to work on it, so we need volunteers to develop more features😄

[jtbandes]

Hi @minggangw 👋
I work on Foxglove Studio and we're interested in helping to push forward this work in order to support WebSocket-based connections to ROS 2. Is there any guidance you can give on the best/desired approach to implement equivalent functionality in ros2-web-bridge?

I was poking around and it seems like the services that are implemented today (for parameters) are implemented inside rclnodejs parameter_service.js, not the ros2-web-bridge, and the service definitions come from rcl_interfaces.

The ROS 1 implementation of these services used definitions from the rosapi package, which doesn't look like it's part of ROS 2 (was this an intentional omission?).

So it seems like the steps needed would be:

1. Add necessary msg/srv definitions upstream to rcl_interfaces (I'm assuming this package is kind of a replacement for rosapi?)
2. Implement the service(s) for reading the list of topics and datatypes in rclnodejs, similar to the parameter-based services
   • Possibly modify ShadowNode and HandleManager if needed to fetch topics/datatypes from rclcpp?

Does this sound right? I'd appreciate any advice if you think more work will be needed, or have tips on how to list topics and datatypes from rclnodejs or the C++ API.

[minggangw]

Hi @jtbandes thanks for your question and welcome 😄 Yeah, the ROS2 has a different story from ROS1, ROS2 integrates more functionalities into its clients, e.g. rclpy/rclnodejs, although all kinds clients are based on the rcl library to implement some platform-specific features. Another feature that were implemented by the roslibjs for ROS1 is the actionlib, which has been implemented by rcl. #73 tracks the rosapi feature for ROS2 currently.

Some suggestions:

Add necessary msg/srv definitions upstream to rcl_interfaces (I'm assuming this package is kind of a replacement for rosapi?)

If you want to implement it quickly, I suggest you could put the .msg & .srv files into the ros2-web-bridge, which are not included by the upstream.

Implement the service(s) for reading the list of topics and datatypes in rclnodejs, similar to the parameter-based services
Possibly modify ShadowNode and HandleManager if needed to fetch topics/datatypes from rclcpp?

I think this can be achieved within JavaScript part.

[jtbandes]

Thanks for the response, I spent some more time reading code and now I have some more detailed questions 🙂

If you want to implement it quickly, I suggest you could put the .msg & .srv files into the ros2-web-bridge, which are not included by the upstream.

Where would these go? It seems like this repo currently doesn't have any .msg/.srv files except for one in the test code. And more importantly, how would these be picked up by the generate-messages step in rclnodejs? Currently, it looks like generate-messages only generates JS for messages that live in the AMENT_PREFIX_PATH: https://github.com/RobotWebTools/rclnodejs/blob/8ebe705e4f3a5df9ecc3e80ee224ce907298e0e6/rosidl_gen/index.js#L23-L25

I think this can be achieved within JavaScript part.

Currently, it looks like the raw message definition (the original contents of the .msg or other IDL file) is not included in the generated JS. There is a JSON representation included as get ROSMessageDef(), but consumers of topics_and_raw_types will need the raw .msg contents. Would you agree that we should change the generator in rclnodejs to include this in the generated JS?

(For reference I looked at the implementation of ros2 topic list, which uses the rcl/rmw graph introspection API called get_topic_names_and_types, but this only provides type names. It wouldn't be sufficient to get topics and raw types. Furthermore, the code generation for C/C++ doesn't include the original msg definition contents, although it does have a list of fields...)

[minggangw]

I see, so a separate project is suitable for this case.

[jtbandes]

I learned that the rosbridge_suite project already has some basic ROS 2 compatibility in the ros2 branch, so I made a PR to add get_topics_and_raw_types: RobotWebTools/rosbridge_suite#574

It's not perfect, because it has to reconstitute the .msg files since they aren't included in the generated message classes / typesupport. But it does allow basic subscription functionality to work in Foxglove Studio with https://github.com/foxglove/studio/pull/1480. (I haven't tested publishing yet — that might be a separate piece of work, but it might work by default since it doesn't use the raw binary format.)

[jtbandes]

Done in RobotWebTools/rosbridge_suite#574