Proposal to replace RPClib with ZeroMQ

[SijmenHuizenga]

Currently communication to and from the simulator happens using the rpc protocol. The reason for this is that AirSim uses it and this project was forked from AirSim. I believe ZeroMQ is a better fit. Therefore I propose to replace RPC with ZeroMQ. Note that msgpack encoding stays unchanged when moving to ZeroMQ.

The main problem with RPC is that it is a request-reply protocol. This results in clients having to poll to stay up-to-day with the available data. For sensordata this results in delays:

An rpc example: a lidar running at 20hz will capture a point cloud every 0.05 second. This pointcloud is stored in memory within the simulator. A client (the ros bridge) requests the latest pointcloud from the simulator at 20hz. There is no way to sync this timer with the simulator timer. When the client requests the pointcloud, the pointcloud is already outdated up to 0.049999 second. This latency could be minimized by requesting sensordata more frequently, but having all sensors execute request at, let's say, 500hz is doomed to introduce new performance issues.

A publish/subscribe architecture would better fit what we are trying to do. The simulator would be able to push sensor data to clients as soon as it becomes available. Clients get lower latency sensordata.

Only few mature, open-source, cross-language, broker-free, networking libraries supporting both publish-subscribe and request-reply exist. From my googling I have come to believe ZeroMQ is the best option as it has the great documentation, seems easiest to use and performs great.

Before I start with a prototype to test the feasibility of ZeroMQ as a replacement for RPClib, I would like to hear if this plan in general makes sense to you. I would love to hear questions, remarks and concerns!

[davidoort]

I have no experience with ZeroMQ but the overarching argument you are making that a publish/subscribe method is more suitable is something I definitely agree with. How much work (time, #files that have to be changed) do you expect this replacement to be?

[mateusz-lichota]

A long time has passed, but I believe there might be some value in restarting the discrussion on this topic. However, if we were going to use a pub/sub messaging system to communicate with the ROS bridge, why not use ROS itself? It literally is a pub/sub messaging system, so this would eliminate a level of indirection and instead of having UE4 <-> fsds_ros_bridge <-> autonomous system we'd have UE4 <-> autonomous system, at the cost of having to use ROS in the python client, but gaining substantial performance improvements. @wouter-heerwegh what's your opinion on that?

[wouter-heerwegh]

I'm not sure that would work, as Unreal Engine would have to build the ROS code. You would probably need to send your data in some way to a node that will convert your data and send it to ROS topics. I do think it is best to use a pub/sub system, and it seems like ZeroMQ is quite nice. This also makes it so that if the python API is used, no ROS is required.