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

Introducing ROS1 on Windows

release
melodic

#1

Microsoft, Open Robotics and the ROS Industrial consortium are working together to bring ROS1 (Melodic Morenia) to Windows.

We’re looking forward to bringing the intelligent edge to robotics by exposing Windows Machine Learning, Azure IoT Edge, and other Microsoft technologies to home, education, commercial, and industrial robots.

Find out how to get started using the experimental builds at http://aka.ms/ros.


ROS 2 TSC Minutes October 17th, 2018
#2

From the link posted above:

Microsoft will host the Windows builds for ROS1 and shortly ROS2, as well as provide documentation, development and deployment solutions for Windows.

That’s nice to see Microsoft will hosting the some ROS build infrastructure, given if Microsoft wants to see ROS support for windows, they’ll need to help support the ROS community to do so.

About the Porting Status: Will we see Microsoft directly contributing back to existing ROS packages directly upstream, or will we see more of a support via fork :fork_and_knife:, where ported packages are made windows specific? I ask this as many existing packages released often have some *nux assumptions, like launch files or code with default /dev device for things like /video webcams, /tty for serial, /usb for openni sensors, what /dev/nvidia* GPU to use for a tensorflow node, your occasional hardcoded / path delimiter, etc. At lease in ROS1 these assumptions are kind of numerous, and I’d like to know how this will be reconciled upstream?

Also curious; is there a large demand from current ROS1 users for windows support, or is it that Microsoft see’s a large untapped market share for window users who might like to use something like ROS1. If the later is the case, how is this expected to play into the ROS2 transition plan? E.g. is it sensible to introduce new ROS windows users to ROS1 if ROS2 will soon replace it? I’ve always thought the majority of core windows users as being corporate customers, where EOL support expectations are usually long in the tooth.

To be clear, I’m not dismissing the effort; on the contrary, the more that the ROS community grows the better. I just want to be sure new users will be given the support they’ll need, and that community resources are wisely allocated.

Another related articles I’ve seen:


#3

Hello @ruffsl, and the ROS community
One of the things I love about ROS is the ROS community. We wish to participate in the community honestly, respectfully and - now that the work is public - openly. We started discussions with Open Robotics and ROS Industrial Consortium well before starting this work, and they have guided us along the way.

There will not be a Windows fork of ROS.

When enabling ROS on Windows, we are making every effort to minimize the delta between Linux and Windows.
We are staging changes in a GitHub fork of ROS which will go away when the changes are contributed upstream. We have already started contributing changes to the ROS repos. We’re working through the tests cases on Windows and validating on Linux before pushing upstream. We do expect this process to take time, as we worked on many repositories.

Open Robotics asked us to host the Windows builds for ROS1 and ROS2. We have started the ROS1 build farm, and will point that farm at main repos as we push changes upstream and remove our forks. As we transition engineers off ROS1, we will set up the builds for ROS2.

To answer your question about launch files: this is something we’d like community input on. For our ports, we created new launch files with a -win added. This leads to unnecessary duplication, so I’ll start another post soliciting input.

During our porting so far, we have encountered surprisingly few Linux only code paths. We have a porting guide which addresses situations we’ve seen, but it is not exhaustive. We’ve migrated threading and path handling to boost, and with minor config changes serial migrates readily to COM ports. Most cases of usb go through libusb which works on Windows.

That said, there will be many cases where porting is extremely difficult or impossible. In these cases, we recommend using Windows Subsystem for Linux (WSL) with Ubuntu.

Microsoft wants to meet customers where they want to be. Prior to starting this work, I spoke with dozens of customers who wanted to leverage ROS, but required Windows in their environment.

ROS1 on Windows will not only be viable for those projects, but will also serve as a stepping stone to ROS2, especially for customers who want to use ROS2 on Windows. Once ROS1 on Windows is at feature and performance parity with Linux and committed upstream, we will redirect resources to feature work in and with ROS2, while maintaining ROS1 on Windows until EOL.

Microsoft participates in the ROS2 technical steering committee and is committed to the transition to ROS2.

@ruffsl, I hope this addresses your concerns.
Thank you for reaching out, (and sorry for the delay in responding, I was at ROSCon)
Lou