Hello fellow ROS users,
The package: https://github.com/uts-magic-lab/rosduct
In my lab, we had this problem with setting up machines (new students, visiting students, hackathons…) to talk with ROS robots where the network was always an issue. Installing ROS, setting up ROS_MASTER_URI, ROS_IP, being in the same local network or setting up a VPN, or many other things. Including machines running Windows, Mac, weird linux versions…
The easiest solution was to stuff the ROS nodes in a Docker container that they could run from any machine. We thought we could not just expose all ports and use the same ip as the host (we were wrong, use the flag –net host and you’ll be doing exactly that… but it doesn’t work on Mac!). So we went with the rosbridge way (as all our robots are running rosbridge anyways).
From the package description:
ROSduct, the duct of ROS messages. ROSduct acts as a proxy to expose ROS topics, services and parameters from a remote roscore into a local roscore via the rosbridge protocol.
Say you have a ROS enabled robot in your network and you want to communicate with it but you have a network configuration that does not allow direct communication (for example, from inside a Docker container). With ROSduct you can configure a set of topics, services and parameters (action servers too, as they are implemented internally as topics) to expose in the local roscore to transparently send and receive ROS traffic to the robot ones.
The package internally contains an implementation of a rosbridge client in Python, by the way. We are planning giving it a bit more love and publishing it in PyPI separately. This effectively allows a computer without ROS installed to communicate thru ROS messages via Python (without those messages installed).
You can run multiple rosduct to separate every one just dealing with a set of topics/services. Recommended if any of them deal with topics publishing fast or big amounts of data. You can also remap different robots topics into one single roscore locally and deal with them as if they were sharing the same roscore.
Note that going thru rosbridge implies an amount of overhead by transforming things to/from JSON. I randomly tried small topics to go up to 500Hz, joint_states to 100Hz, TF 200Hz… with a well performing network of course. And you have the delay introduced by rosbridge too. Think of rosduct as a convenience tool
Let me know if you find it interesting/useful!