Simulator: Connection and data flow between simulator and script through rosbridge

[dr563105]

Hey!
I made a data flow diagram for the simulator. I made webUI and simulator as two components connected to each other through localhost:8080. The simulator then connects to a python script through localhost:9090. I'm using normal ros2 nodes python scripts and not python-API. The ros2-web-bridge is established in the 9090 port.

1. Am I correct about how the connection is established?
2. When the WebUI sees localhost:9090 in the simulation tab, what does it do? Does it make simulator listen to this address periodically?
3. How is JSON parameters parsed? As I understand from the code, it is partially done in WebUI and the rest is sent to the application.
4. In client-server architecture, what roles do WebUI, Simulator app and script play?

I used the lanefollowing docker image. There a script file has the instructions to establish the rosbridge. Just like here -- https://www.lgsvlsimulator.com/docs/create-ros2-ad-stack/#running-rosbridge. Use dashing instead of crystal. In the dockerfile, ros2-web-bridge is installed.

1. So my question is when LGSVL converts data types to ROS2 message standards does it have rosbridge on its side or ros2-web-bridge? or are they same?
2. Can you help me understand the difference between these two? Because in ros2-web-bridge it is described that a node.js wrapper wraps the ros 2 messages.
3. Does it also do the same when sending to the simulator? If so, on the simulator side how is it parsed? If not, how does the data look like when sent to simulator from script?

If you can have a look at the diagram and let me know please of its accuracy. Simple concepts confusing me. Appreciate any help. Thank you.

[EricBoiseLGSVL]

@dr563105 Great image! I'll ping @hadiTab to confirm but I think you have the architecture down

[dr563105]

Thanks @EricBoiseLGSVL. If it is accurate, you can use it in the wiki for the community. Updated question #7. Basically want to understand how data transfer occurs.

[martins-mozeiko]

I'll let others answer first 4 questions.
But here are answers on bridges:

5) rosbridge is custom protocol implementation over websocket or TCP socket used by ROS1. It is implemented in Python. Its protocol is documented here (v2.0 in name is just version of protocol, not ROS). ros2-web-bridge is same protocol implementation in node.js for ROS2 environment - as it uses different native API & message formats than ROS1. It still sends ROS messages over websocket in JSON format. But on server side they are converted to ROS2 messages.

6) Simulator implements rosbridge protocol (as in JSON format over websocket) in C#. Once it receives message, it parses JSON and then uses data for its purposes. It doesn't really care is it ROS1 or ROS2 message, because both of them are sent in same rosbridge protocol form (formatted as JSON). To send message, the opposite happens - simulator prepares message data as JSON, and sends over websocket. And on server side either ROS1 based Python rosbridge server or ROS2 based ros2-web-bridge server receives this JSON, parses it, and creates native ROS1 or ROS2 message that it publishes using native ROS1/2 API's.

7) When simulator parses json, then afterwards it needs to know what to do with data. Each sensor specifies what kind of message it supports (its datatype). We have created bunch of C# structures corresponding to each ROS message. You can see them under Scripts/Bridge/Ros/Messages folder. These classes have same content as ROS messages. The received JSON is unserialized into these data structures automatically. For ROS you can see mapping between ROS messages and C# classes in Scripts/Bridge/Ros/RosBridgeFactory.cs file where it registers conversions.

Note that we now have new ros2-lgsvl-bridge available. It implements custom TCP based protocol between simulator and native ROS2 node in C++. This was done for performance reasons. No more JSON, no more websocket, no more node.js. Simulator sends ROS2 message data in custom binary form that native ROS2 server receives over TCP socket, parses it, creates native ROS2 message and publishes with native ROS2 API's. Memory usage, performance and latency are greatly improved using this bridge over ros2-web-bridge. The old ros2-web-bridge is pretty obsolete now.

[dr563105]

Great stuff. Lots to digest. Thanks a lot @martins-mozeiko .

[hadiTab]

@dr563105 as @martins-mozeiko pointed out we now have the ros2-lgsvl-bridge. I'd also like to note that as of the 2020.06 release ros2-web-bridge is NOT supported anymore and ros2-lgsvl-bridge is the default ROS2 bridge now. So I wouldn't suggest putting a lot of effort into figuring out how ros2-web-bridge works with the simulator.

For the other questions:

1. The diagram looks more or less accurate to me except for a few things:

   • I'm not sure what you mean by 'node.js wrapper' written under the connection for the bridge. The data that is being transmitted is serialized to JSON so it seems to me that 'JSON' would be what you want written there. Also, the bridge on the simulator side isn't called 'ros2-web-bridge'. I don't know what a good name would be for it, but maybe 'simulator rosbridge' or something since it only uses the rosbridge protocol.
   • It's not really clear to me why the names of some of the classes in the simulator are written in the simulator box.

2. localhost:9090 is the address of the ros2-web-bridge connection. If it were running on another machine localhost would be replaced by the IP address of the machine it was running on. The WebUI passes the address along with all of the other information (sensor configuration, vehicle, map name, etc.) to the simulator when the play button is pressed on a simulation in the WebUI. A bridge instance is created (in this example a ROS/ROS2 bridge) which establishes a connection with the ros2-web-bridge (or other bridge being used) through websockets which use an underlying TCP connection that is kept alive which is used to send and receive messages.

3. I'm not very familiar with the WebUI code but I think it just forward the JSON to the simulator. It checks if it's a valid JSON before sending it though.

4. What 'script' are you referring to? The WebUI is hosted on the simulator and your browser will act as a client. For the bridge connection, the ros2-web-bridge acts as a server and the simulator bridge is a client.

[dr563105]

Thanks @hadiTab. I did my thesis with January through May versions. So I need to mention ros2-web-bridge unfortuanately.

I'm not sure what you mean by 'node.js wrapper' written under the connection for the bridge.

The node.js wrapper is written because when I opened standard ROS messages present inside ~/ros2-web-bridge/node_modules/rclnodejs/generated, I saw them written in javascript.

It's not really clear to me why the names of some of the classes in the simulator are written in the simulator box.

Well, I have to mention what happens inside simulator once data from the environment reaches. I didn't know other ways to put the classes. Can you suggest me a better idea?

Also, the bridge on the simulator side isn't called 'ros2-web-bridge'. I don't know what a good name would be for it, but maybe 'simulator rosbridge' or something since it only uses the rosbridge protocol.

Yes, just rosbridge makes sense.

What 'script' are you referring to?

A python script that collects data from the simulator using ROS 2 nodes. Similar to the script found in lanefollowing repo.

[hadiTab]

Well, I have to mention what happens inside simulator once data from the environment reaches. I didn't know other ways to put the classes. Can you suggest me a better idea?

I guess it's fine if there is an accompanying explanation. Without an explanation it's hard to understand what they are if you are not familiar with the source code.

A python script that collects data from the simulator using ROS 2 nodes. Similar to the script found in lanefollowing repo.

The ros2-web-bridge acts as a ROS 2 publisher/subscriber node. The 'script' would just be another ROS2 node that lives in the same domain as the ros2-web-bridge.

[dr563105]

closing this issue as it answers my questions. Thank you.