ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org

# Exchange data between C application (without ROS) with some PC's running ROS using Ethernet

Dear community,

I am currently starting to work with ROS and try some things out. For one future project, I am planning to use ROS in a multi machine fashion (in total 4 PC's running ROS and Linux) together with a Non-ROS PC (Windows) that runs a C application. Now I need to pass data between those two systems back and forth.

From what I saw so far, the ROS side is straight forward and I can easily exchange data between ROS nodes that are executed on different PC's that run ROS and are connected in a network via Ethernet.

The challenge seems to be how to pass the data from the C application to the ROS-cluster. Several solutions that came to my mind are:

1. Connect the Windows PC to the same local network of the ROS-cluster and send messages using TCP/IP and afterwards load the data into ROS on one of the cluster-PCs and distribute the data afterwards to the other PC's in the cluster that subscribed to the Topic (of course the message that comes from the C application needs to have a flag for the topic).

2. Implement the C application in a way that it already sends message that have the same structure as messages sent with TCPROS. -> Seems to be not easy to do it according to my previous investagations

3. Using the package cROS (see https://github.com/ros-industrial/cros ) since it is a small library that could realize ROS on the Windows Side.

Do you think one of these solutions could really work in practice? Which way would you pick in order to achieve the data transport and set up the network?

Thanks you for reading my question - Looking forward to a fruitful discussion :)

Best regards

Manuel

edit retag close merge delete

Sort by » oldest newest most voted

There are actually a few more options:

1. (probably the least feasible one) port your C application to Linux: if it doesn't need to be on Windows, it's always beneficial to consider doing this, as you'll get native support for ROS.
2. use a client library that is supported on Windows: you've already found cROS, some other options: ROS.NET, rosjava and rosnodejs (there are more, this was just what I could quickly find).
3. use a bridge: this translates ROS msgs and service invocations into some other format that -- ideally -- is more suited for exchange with non-ROS applications. Two examples: rosbridge_suite (with Rosbridge .NET Client or java_rosbridge fi) and rosserial (don't get confused by the overpresence of embedded platforms there, that just happens to be the most popular application of it).
4. use ROS2 and the ros2/ros1_bridge: ROS2 natively supports Windows (10, although some ppl appear to be able to run things on Win7 as well) and it can integrate with ROS1 nodegraphs as well using the ros1_bridge pkg.

Some of these might be more involved than others: the ROS2 bridging fi will be some work, but it will get you the best integration of your Windows machines into your ROS1/2 nodegraph, which might be such an advantage that the extra work is worth it.

The rosbridge_suite and rosserial approaches will probably require the least amount of work, as they were essentially created for your scenario.

cROS is definitely also an option: if you hadn't already mentioned it I would've included it in the list of client libraries with Windows support. A recent PR makes compilation with VS much more straightforward and seeing as it has very few depencies, is ANSI C and doesn't need any generated headers for its message and service structures could be a nice lightweight way to extend a regular C application with ROS interfacing.

more

Thank you for the quick reply and the great information provided! Especially the Visual Studio cROS seems to be right now the most promising approach. I am going to try that out first and let you know the outcome.

( 2017-08-25 04:11:29 -0500 )edit