Client library that fully support ROS 2

[threeal]

Feature Request

Feature Description

The ros2-web-bridge currently only support roslibjs as the clients library that communicates with it. The good things is they both use the same rosbridge v2 protocol so we could still use some of the roslibjs features like service and topic for the ros2-web-bridge, despite if it was developed for ROS 1. But the problem arise when we need to use other features like parameter as ROS 2 treat the parameters differently, It simply won't work.

Implementation Considerations

I consider there could be 2 options to solve the problems as follow:

• Modify the roslibjs to Fully Support ROS 2.
• Create a separate client library that would fully support ROS 2.

[minggangw]

Hi @threeal thanks for your suggestion! Indeed, the roslibjs cannot fully support all the features rclnodejs offers, which is a Node.js client of ROS2. Because there are some new concepts/params in ROS2, meanwhile, some ROS1 concepts/params are deprecated.

Date back to the beta stage of ROS2, it was about 3 years ago. Our initial aim of this project was to be compatible with roslibjs by adopting the rosbridge v2 protocol, thus developers could migrate their apps to ROS1 smoothly. Along with the development of ROS2 during the past 3 years, it seems that the roslibjs is not enough to expose the capabilities of ROS2. We should have implemented a specific version of roslibjs for ROS2 only and extended the rosbridge protocol as you suggested.

The fact is that we have limited resources now, we need to implement a new protocol and the frond-end JS library if we want to resolve these current problems. So we may need more developers together to achieve this goal 😄

[threeal]

I could help to create a new front-end JS library that could support ROS 2. As the roslibjs already support some of the feature in the ROS 2, I considered we could create a library that wrap the roslibjs library to be compatible with ROS 2 for now. This will make the roslibjs could still be used in ros2-web-bridge without modifying the protocol, and we would have another library that could use some of the feature in ROS 2 that is not supported by the roslibjs.

but where to start? should it be part of the RobotWebTools project or i created it in my own repository?

[minggangw]

That's great and thanks for your support! Some suggestions and ideas

I considered we could create a library that wrap the roslibjs library to be compatible with ROS 2 for now.

I'm not sure we should wrap the current roslibjs, I prefer we could extend/change the interfaces/parameters.

but where to start? should it be part of the RobotWebTools project or i created it in my own repository?

Yes, this should be part of RWT project and I reckon we can divide the whole work into two parts:

• Frond-end: We could fork the current roslibjs and implement new features based on that. I suggest you could hold the code on your own repo at this stage. Once the functionalities are done, we can create a new repo (e.g. ros2libjs) under the RWT org or create a new branch on the current roslibjs.

• Back-end (this repo): We could create a feature branch, like ros2libjs, and push the patches onto that. Once the frond-end is ready, we could merge it back onto develop branch

My question is how we deal with the rosbridge v2 protocol, shall we upgrade it to rosbridge v3 protocol (meaning for ROS2)?

How do you think @threeal? Also, I'd like to listen to @jihoonl's suggestions, thanks!

[threeal]

Should we extend the ros2libjs (or rcljs if a could prefer) syntax to be like the rclnodejs? so instead of creating a Topic object and then call to subscribe(), it requires to create a Node object first, then create a Topic object from it that include the subscribe callback? The point is it would preserve the ROS 2 syntax for client library across language, even if the rcljs wouldn't directly interfacing the rcl library.

For rosbridge v3 protocol, i think we could look at how rmw handle the communication between nodes (if there is any? i don't exactly know how the rmw works). So the ros2-web-bridge would be another version of rmw that works on top of websocket instead of dds?

[minggangw]

Should we extend the ros2libjs (or rcljs if a could prefer) syntax to be like the rclnodejs? so instead of creating a Topic object and then call to subscribe(), it requires to create a Node object first, then create a Topic object from it that include the subscribe callback?

Oh, I misunderstood the "wrap" you mentioned and we'd better keep the interfaces as the current ones if possible. "extend" means that we could expose new interfaces to the web developers to extend the current scope of roslibjs.

For rosbridge v3 protocol, i think we could look at how rmw handle the communication between nodes (if there is any? i don't exactly know how the rmw works). So the ros2-web-bridge would be another version of rmw that works on top of websocket instead of dds?

rmw acts the middleware in ROS2 stacks which rcl based on, and rclnodejs is kind of Node.js wrapper of rcl which ros2-web-bridge uses to access to ROS2, looks like:

rmw <- rcl  <- rclnodejs <- ros2-web-bridge <===(WebSockets)====> roslibjs

[caelinsutch]

So is someone making a ROS2 client side JS library?

[minggangw]

So is someone making a ROS2 client side JS library?

You may find more information RobotWebTools/rosbridge_suite#345 and https://github.com/RobotWebTools/rosbridge_suite/issues?q=ros2