Revision history [back]

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.
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.

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.