[Documentation] [TitleIndex] [WordIndex

This is the beginnings of what I hope we can present as a formal proposal for a multimaster framework in RoS, starting with the most fundamental block - the gateway. It should also help us clarify and crystallise exactly the design goals we wish to meet.

Definitions

So we're all on the same page:

Concept

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.

Design Goals

Design Decisions

Other Notes

Comments/Issues

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.

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.

Other

There are alot of different ideas on exactly how to implement the higher level components (linking, co-ordination etc). Quite likely they will require different variations. Since the target is a long way off, we're not worrying about it just yet.


2022-05-28 12:37