No returned status for the roslibjs APIs that interact with bridge

[qiuzhong]

When roslibjs interacts with a ros bridge, it sends JSON format requests based on the protocol. For example, there is an API: Ros.setStatusLevel().

Ros.setStatusLevel(level, id)

When we call Ros.setStatusLevel('error', '/example_id'), it might send a request like {set_level: 'error', id: '/example_id}') and the web socket will receive a response. But this API doesn't handle the response. Users will never know whether this calling succeed or fail.

Is it possible to return a status for the APIs that communicates with bridge?

[T045T]

this is a good idea - I'm assuming you're asking because rclnodejs actually implements status messages (rosbridge_suite does not, as far as I can tell)?

it shouldn't be too hard to implement this, with one caveat:

roslibjs would have to check every status message against the list of ids for all the actions that might receive a status response, but haven't yet.

(that means the response would have to be delivered to the caller via a callback, but that's neither here nor there)

but since the status level ist adjustable (even to none in the most extreme case), those responses might never come, so that list of IDs to check for would almost certainly just keep growing forever.

I can't think of a good solution to this; You don't want to send an "ack" message after every publish call, for example, because that would take up valuable bandwidth. That sort of "ack" would be an info message, so one could set the status_level to error, but then if no errors happen, we'd leak memory :(

This is just me thinking about it for 15 minutes though, maybe someone else can think of a more elegant solution.

[minggangw]

Hi @T045T the reason why we raised this issue is that we want to verify the compatibility of ros2-web-bridge with roslibjs on ROS 2 platform.

We have developed some kind of white box tests which are focusing on the protocol only, further we want to target on the roslibjs which is exposed to the user finally. But during writing those cases, we found the problem @qiuzhong mentioned above. As you said it is a double-edged sword, so I think if we can change the story on ROS 2? Thinking about controlling a robot remotely, you never know if it does execute your command which should be reliable.

I have an aggressive idea that if we can revise the current rosbridge v2 protoco (an update?) to align with ROS 2 (I have listed some compatibility problems which can not resolved under the scope of current protocol). I want to change least to migrate it to ROS 2 platform and let our current RWT modules move to ROS 2 smoothly. Any suggestions?