Line protocol description for porting to other languages

[kegsay]

Desired behavior

I am interested in writing code to control a Gazebo simulation in something other than C++. I'm aware that this library is C++ and does not have support for other languages.

Gazebo, pre-Ignition, didn't have any real way to do this as it just used dynamically linked code - there was no network API. With Gazebo Ignition there is a network API, this repository, but it seems like there isn't any fixed line protocol to talk beyond "we use protobufs and 0mq". There seems to be no clear separation between "this is the line protocol you can hook into with any programming language" and "this is the C++ SDK which can talk the line protocol".

There is good support for ZeroMQ and Protocol Buffers in many many languages, so it is entirely possible for 3rd-partities to write code to integrate into the ecosystem if only the protocol was described.

Alternatives considered

Competitors like Webots also don't seem to expose a network API, forcing you to write simulation code in one of the officially supported SDKs (C/C++/Python/Java, all based on a C API which is then SWIG generated to different languages). They allude to "Interfacing Webots to Third Party Software with TCP/IP" but in reality they do not support it (you have to write your own client/server protocol). Hardly any robotic simulation frameworks expose their API via network calls and hence supports any arbitrary programming language, save possibly Gazebo Ignition and from what I can see Coppelia.

Implementation suggestion

• Write a document which explains how to communicate with Gazebo via 0mq/protobufs. This could just be as simple as saying "here's some proto files" and "these are the socket types and ports we use".
• Ensure the line protocol is stable and well-documented when it breaks in a backwards incompatible way e.g Talking across versions #105 (comment)

Something like what Coppelia provides would be great:

• https://www.coppeliarobotics.com/helpFiles/en/zmqRemoteApiOverview.htm
• https://github.com/CoppeliaRobotics/zmqRemoteApi#protocol

Additional context

My overall goal is to write some controller code (that is, read-input -> make decision -> instruct-movement) in something like Go or Rust. Reading the input would be via 0mq, and likewise instructing movement would also be via 0mq. The benefit to doing this is that I am not arbitrarily restricted by the simulation software into what tools I can or cannot use, whilst preserving portability from simulation into reality (it's a small amount of work to hook up sensors to topics but otherwise not particularly difficult). Yes, I could write my own line protocol, but then I would need to do the same for the simulation software (basically what Webots forces you to do), which seems a shame given Gazebo Ignition is already talking a protocol, it's just not part of the public API exposed to end-users.

[caguero]

I think this is a good idea! Some time ago, I started the process for discovery here. It's totally incomplete and probably not up to date.

The only caveat that I can imagine of this approach is that potential implementations might have slightly different behaviors due to inherent different in languages, as opposed to creating wrappers on top of the current implementation.

I probably don't have time to work on it directly right now but I'd be able to help if someone wants to volunteer.