ROSDUCT: expose remote ROS topics, services and parameters locally thru rosbridge

General
1

Hello fellow ROS users,

The package: GitHub - uts-magic-lab/rosduct: Proxy to expose remote ROS topics, services and parameters locally thru rosbridge

Its history:

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 :slight_smile:

Let me know if you find it interesting/useful!

2

Hi @awesomebytes! Just yesterday we published something pretty close to what you’ve built: https://github.com/gramaziokohler/roslibpy

cheers

3

Hello,

I m quite curious, as this relates with https://github.com/pyros-dev things…

A few questions :

  1. why keep the json (rosbridge) conversion in there ? It introduces delays, and can be in some cases unneeded (like when someone tries to connect to ROS through MQTT for example)
    The “ROS not required part” is indeed interesting but this could be done without all the web things… not sure if it would be “better” though, but this is one of the pyros intents, treat the web as an option, not the core.

  2. While we start to see a few solutions popping up for ros interoperability over the network, it would be good to have some objective metrics to compare them, even if one is not familiar with ROS or network intricacies… There is the usual network metrics (speed, bandwidth), but not only… we could imagine other metrics such as resistance to disconnection, speed of connection, etc. maybe something similar to usual game servers ?
    Any idea about that ?

4

why keep the json (rosbridge) conversion in there ? It introduces delays, and can be in some cases unneeded (like when someone tries to connect to ROS through MQTT for example)
The “ROS not required part” is indeed interesting but this could be done without all the web things… not sure if it would be “better” though, but this is one of the pyros intents, treat the web as an option, not the core.

The data needs to be tunneled thru the rosbridge so it needs to be in JSON (the main point for us was that we could not connect to dynamic changing ports, so we cant really send/receive ROS messages otherwise).

While we start to see a few solutions popping up for ros interoperability over the network, it would be good to have some objective metrics to compare them, even if one is not familiar with ROS or network intricacies… There is the usual network metrics (speed, bandwidth), but not only… we could imagine other metrics such as resistance to disconnection, speed of connection, etc. maybe something similar to usual game servers ?
Any idea about that ?

Would be cool to have those metrics indeed :slight_smile: But I currently have no time to make any of my package. The best point to it… is that you can code from your computer like if you had a completely operational ROS (which just happens to be tunneled thru rosbridge).

The rosbridge python implementation is nice, but it’s just something we needed to make this work.