local vs. remote registration of publisher/subscriber in ROS Master
Alexander Tiderko
Jeff Rousseau <jrousseau@aptima.com>
> the current solutions to synchronize the ROS masters (foreign_relay of master_sync) make registrations
> in both ROS masters (local and remote). Correct me, if it's wrong.
If we’re talking foreign_relay then you have to choose if you’re advertising on a foreign master or subscribing to a foreign master explicitly.
master_sync is a bit different in that it’s a “strong” master sync, and such has issues with connections going bad (not really recommended for syncing masters over wifi as it stands due to this fact).
The currently trending _proposed_ solution is a sort of “gateway” node that’s not really a master, but is similar in that it syncs local master topics to itself and then forwards traffic to other gateways. Gateways would maintain a heartbeat to each other over ICMP or UDP so they would know when a connection has gone bad and trigger notification callbacks on appropriate nodes through a yet-to-be created Gateway API.
> Some issues of this solution:
> 1. What happening, if the connection go loss? The remote changes will be stay on the remote ROS
> master? It's bad?
In the current proposed solution, the window for “things to go bad” is during a single XMLRPC registration call which is definitely possible, but if the connection has gone bad (XMLPRC is over HTTP/TCP so it’ll be reliable between two connected machines) then result would be that the gateway would eventually time out and no harm is really done.
> 2. Complicate this solution the debugging of the data flow using e.g. rxgraph?
Not sure what you mean here. No changes should be needed in rxgraph to support our current solution.
> Are the changes of local ROS master not sufficient? I mean, if I will get the sensor data of a (or more)
> remote robot, I can register their topics (pub/sub) in local ROS master. I don't need any changes in the
> ROS master of the robots.
We plan (so far) on leaving the current “local” master code unchanged and instead introducing a gateway as mentioned which applications can use only if they need the functionality.
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Alexander Tiderko
Am Montag, 14. Mai 2012 17:59:53 UTC+2 schrieb Jeff Rousseau:
> 2. Complicate this solution the debugging of the data flow using e.g. rxgraph?
Not sure what you mean here. No changes should be needed in rxgraph to support our current solution.
> Are the changes of local ROS master not sufficient? I mean, if I will get the sensor data of a (or more)
> remote robot, I can register their topics (pub/sub) in local ROS master. I don't need any changes in the
> ROS master of the robots.
We plan (so far) on leaving the current “local” master code unchanged and instead introducing a gateway as mentioned which applications can use only if they need the functionality.
Jeff Rousseau <jrousseau@aptima.com>
> I mean, if the 'gateway' subscribes the local topics, then will I see in the rxgraph the
> 'gateway' as subscriber. Further subscriber on remote maschines will not be displayed
> in rxgraph. But this is not a really handicap ;)
True, we most likely don’t want to just forward connection information from a local master through a gateway, but instead will “relay” over a more suitable transport by subscribing to the topics of interest indicated in the whitelist and republish. This has the downside of rxgraph showing “gateway” instead of the foreign address for pub/sub nodes. However, the topic would be prefixed with a unique id of some kind which should help indicate where it’s actually coming from. I think that’s a livable solution.
> With "changes of local ROS master" I mean the registration of subscriber/publisher using the Master
> API through XMLRPC. The needed remote topics then are registered on local ROS master without
> registration on remote ROS master. Thus no unregistrations "at the end" on remote ROS master are
> need...
I don’t see why we wouldn’t want to forward (un)registrations across gateway boundaries. Why might you not want to? If all the XMLRPC calls start adding up to trouble we can investigate another solution (some R/UDP RPC, custom PGM/multicast solution, etc)…
Piyush
> I mean, if the 'gateway' subscribes the local topics, then will I see in the rxgraph the
> 'gateway' as subscriber. Further subscriber on remote maschines will not be displayed
> in rxgraph. But this is not a really handicap ;)
True, we most likely don’t want to just forward connection information from a local master through a gateway, but instead will “relay” over a more suitable transport by subscribing to the topics of interest indicated in the whitelist and republish. This has the downside of rxgraph showing “gateway” instead of the foreign address for pub/sub nodes. However, the topic would be prefixed with a unique id of some kind which should help indicate where it’s actually coming from. I think that’s a livable solution.
Jeff Rousseau <jrousseau@aptima.com>
One solution would be to allow setting transports for certain topics in the configuration of the gateway and allow a “passthrough” option (which would just pass the connection info on from the local master).
PGM support isn’t ready yet and it’ll only work with c++ at first (although a python wrapper should be easy). With the currently discussed approach it may not make sense to have a PGM or UDP transport in roscpp or rospy directly if only the gateway will be the only thing making use of it.
Armstrong-Crews, Nicholas - 1002 - MITLL
Wait, are we now discussing the possibility of having the gateway node subscribe to all “exported” topics, such that messages published on those topics are received by the gateway node and then re-published to remote subscribers?
Presumably there’s a reason that the original implementation of ROS master didn’t function as a forwarder…
Also note that there currently exists a forwarder node that can relay messages on a different transport… so we may not want to duplicate that functionality and conflate it with the multi-master concept. At the very least, if we really want, we could have a simple script that spawns a relay node for each exported topic... giving the same features but maintaining a de-coupled solution.
-N
Daniel Stonier
Wait, are we now discussing the possibility of having the gateway node subscribe to all “exported” topics, such that messages published on those topics are received by the gateway node and then re-published to remote subscribers?
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Armstrong-Crews, Nicholas - 1002 - MITLL
As an aside, tf is a special case in that the way it is typically used is to transmit *all* transforms on a *single* topic. For multiple robots, this is not desired: bender2 doesn’t care about bender1’s left finger angle. Since (in the proposed solution) we’re doing topic-level selection of “exported” and “local” data, we can’t achieve the necessary granularity required for tf filtering. It may not seem like a big deal, but the PR2 has a pretty complex kinematic model and generates a *lot* of tf traffic.
An easy way to address this issue is to split “local” and “exported” transforms onto two topics: /tf and /exported/tf . Then, we expose via the gateway only the /foreign/tf topic, and we have a mux node that re-publishes /foreign/tf onto /tf (this is transparent to all transform-subscribing nodes in the system, but you need to re-map transform-publishing nodes to use /tf or /exported/tf).
An alternative would be to use the tf_remap node with a regex whitelist with that filters on tf frame names (also a hierarchical namespace, just like topic names).
In practice, it might be wise to use /robot_uuid/[the rest of your tf namespace], and/or to do some tf namespace resolutoin/remapping (“private” versus global namespace) … but I haven’t really thought through all the implications…. and it seems more like a “would-be-nice-if” feature that could probably be left to be done manually, on a case-by-case basis, for now.
-N
From: ros-s...@googlegroups.com [mailto:ros-s...@googlegroups.com] On Behalf Of Jeff Rousseau <jrou...@aptima.com>
Sent: Monday, May 14, 2012 12:00 PM
To: ros-s...@googlegroups.com
Jeff Rousseau <jrousseau@aptima.com>
> Wait, are we now discussing the possibility of having the gateway node subscribe to all “exported” topics,
> such that messages published on those topics are received by the gateway node and then re-published
> to remote subscribers?
>
> Presumably there’s a reason that the original implementation of ROS master didn’t function as a forwarder…
I only mentioned this as a possibility if we in fact want don’t want to add new transports to ros itself, but instead left all the unreliable transport code in the gateway node. That makes for a simpler ros for the majority of those who don’t care about “syncing” between machines with flaky connections (no transport hints to deal with, unreliable relays etc.)
> Also note that there currently exists a forwarder node that can relay messages on a different transport…
> so we may not want to duplicate that functionality and conflate it with the multi-master concept. At the
> very least, if we really want, we could have a simple script that spawns a relay node for each exported
> topic... giving the same features but maintaining a de-coupled solution.
If we don’t have multiple transports in ros (roscpp,rospy, etc), transport relay nodes wouldn’t be necessary.
As far as being a “bottleneck” goes, the amount of internal traffic would only be on the order of what you’re going to pass over your limited gateway pipes (802.11b/g/a/etc) anyways. Presumably local masters would operate on the loopback interface, where traffic is largely free.
Daniel Stonier
> Wait, are we now discussing the possibility of having the gateway node subscribe to all “exported” topics,
> such that messages published on those topics are received by the gateway node and then re-published
> to remote subscribers?
>
> Presumably there’s a reason that the original implementation of ROS master didn’t function as a forwarder…
I only mentioned this as a possibility if we in fact want don’t want to add new transports to ros itself, but instead left all the unreliable transport code in the gateway node. That makes for a simpler ros for the majority of those who don’t care about “syncing” between machines with flaky connections (no transport hints to deal with, unreliable relays etc.)
> Also note that there currently exists a forwarder node that can relay messages on a different transport…
> so we may not want to duplicate that functionality and conflate it with the multi-master concept. At the
> very least, if we really want, we could have a simple script that spawns a relay node for each exported
> topic... giving the same features but maintaining a de-coupled solution.
If we don’t have multiple transports in ros (roscpp,rospy, etc), transport relay nodes wouldn’t be necessary.
As far as being a “bottleneck” goes, the amount of internal traffic would only be on the order of what you’re going to pass over your limited gateway pipes (802.11b/g/a/etc) anyways. Presumably local masters would operate on the loopback interface, where traffic is largely free.