[Documentation] [TitleIndex] [WordIndex

Stack Proposal

Proposers: Daniel Stonier, Jihoon Lee

Simply add comments and address concerns here with your name in brackets [] after the comment before October 1st 2012.


So we're all on the same page:


The gateway will be the public frontend for a ros master and is intended to act much like a gateway on a local area network controlling what is exposed and what is forwarded between the local ros master and the outside world (other ros systems). The intention is to generalise this kind of interface beyond tools that previously existed (foreign_relay, master_sync and fki_multimaster) and also make their configuration/usage as simple as possible.




Other Notes


Gateways as relays only?


In the initial implementation, will gateways act as relays? i.e. all topics in the public API will be subscribed by the gateway and republished to the foreign gateway?

I had thought about this as well. One problem is that there is currently no way to guarantee unreliable connections. Unreliable transport hints go in at subscriber creation - there is nothing at the publisher end (if an unreliable subscriber requests a connection with a publisher, it will be an unreliable connection if the transport types can do it - i.e. roscpp can do it since it has a udpros implementation, but rospy connections can't). This has some interesting consequences.

Still, at least it would ensure that the gateway has done it's part in making sure the connections would be unreliable. I'd like to raise some of these issues on the ros-ng sig [DS].

Transport Types


Gate_G09 will be a difficult problem. Currently you can't configure a connection's type or transport hints from the system level, e.g. from roslauchers, like remaps are done. You can't introspect on them either (introspection would allow you to interpose relays if desired). See the discussion on Transports [DS].

The TF Tree


Exposing TF is important as it allows out of the box usage of a number of existing ROS applications. Ideally, only a subset of the TF tree should be exposed as part of the public ROS API. This is necessary for ensuring some privacy of data of the local machine, as well as not burdening foreign TF trees with unnecessary transforms.

Good point - Nick said they compressed TF trees. Also we should see what has changed with tf2 and whether it is easier now [DS].

Clock Synchronization


This might be important for things like tf, but I am not sure how crucial it is.

Topic type availability


What if you wish to flip a message type to a remote gateway that knows nothing of that topic type? This will probably fail when registering using the remote's ros master api...

Message types are generally publicly accessible (even for closed source systems). It could be the role of a higher level system to make sure that these are always locally available (with tools to guarantee this) for multimaster participants. Should this in anyway be the responsibility of the gateway? At least the gateway should provide error handling, i.e. inform the gateway that wishes to flip, that it fails... [Daniel]

Message Compatibility


How to ensure all participants in a multimaster system resolve message compatibility issues?

They talked about this at roscon. Until now I think they haven't really had an absolute need for it since they are so publicly accessible. Next gen ros is talking about moving to protobuffs which actually do implement message version compatibility. Given that things might change, it may be better just to wait and see what happens. [Daniel]



2024-05-18 13:28