As you may know, ROS 2 has supported Windows as a Tier 1 platform since its inception. However, providing Windows support is costly, and we need to do some serious work to keep it going over the next several years.
At the moment we don’t have a great idea of how many ROS 2 users are using Windows, and how they are using it. Towards that end, we have put together a survey:
If you or your organization is using ROS 2 on Windows, please respond by August 12 (the survey should take about 5-10 minutes). Once we close the survey, we’ll report back with some statistics.
In the survey, listed as a con for WSL 2, is “GPU Hardware acceleration does not work (which affects RViz)”.
However I don’t think this is the case anymore. Work has been done in Mesa to add a DirectX Gallium3D backend, so OpenGL apps should “just work” out of the box with hardware acceleration on Ubuntu 22.04+ WSL 2 guests.
OK, thanks for the info. We have some conflicting reports about this; the Gazebo team seems to have had some trouble with using WSL2. We’ll take a closer look and see what we can find.
Those articles are dated 4 February 2022 and 8 November 2023. I think I tested the WSL2 option sometime in late January and while I don’t recall rviz being problematic, Gazebo definitely was. Especially Ignition with its as of yet unoptimized PBR rendering pipeline that grinds to a complete halt without full gpu acceleration.
Might be worthwhile yeah, once Jazzy is more up to speed. I was mainly testing the TB4 simulation at the time which does use ODE by default iirc (we wanted to give WSL2 as an option to students taking the ROS class). I doubt physics was in any way the bottleneck there though.
Great that you send out a survey for this! I have a dualboot of windows and PopOS! (ubuntu), but I need to be on Windows due to better graphics driver support for CAD/simulation/graphical tools, so for simplicity I have just installed ROS on WSL2
I’ve been using the install WLS2 most of the time, and I’ve also tested some things out on the latest Jazzy tutorial party on it, and it seems to be working pretty good for me! WSL2 was a bit buggy for a while before but I haven’t had any issues with it in the last months.
I’ve just filled in the questionnaire. Curious what comes out of it
I’m part of prefix.dev, where we’re tackling cross-platform package management using the conda-ecosystem. Our team, mostly ex-roboticists, knows firsthand how challenging environment management can be in professional robotics.
Our CEO Wolf Vollprecht, along with Tobias Fischer and Silvio Traversaro have started the RoboStack project. We’re looking to build on this work and make it even better with your help. Collaboration with OSRF and the ROS community is crucial to developing a solution that works for all ROS users.
Check out our minimal demo project: pixi-turtlesim. With pixi, installing and interacting with ROS projects will be seamless across Linux, macOS, and Windows, simplifying tutorials and usage.
Leaving this here as I believe Open Source and cross-platform package management would change the story for ROS Windows support.
I filled out the survey with details, but a couple of quick notes for the discussion here. I’m a big fan of the Robostack approach, and the team’s work there has supported most of my use of ROS and ROS 2 on Windows.
I think having the option to decouple a ROS installation from system dependencies has many benefits. Tier 1 Windows support according to REP-2000 still ties us to Python 3.8.3. The decoupling and isolation from system dependencies have a lot of utility beyond Windows.
Regarding WSL2, I have had an uneven experience with graphical tools, but another issue is hardware access. Simple hardware interfacing like webcam or joystick access require kernel customization as far as I can tell. I’ve used USBIPD for serial port devices, but I think the stock WSL 2 kernel only supports serial port and basic mass-storage devices.
The fact that the Robostack approach decouples and isolates complex dependencies and builds native binaries are both big pluses in my book. I happen to be a long-time Python programmer and Conda environment user, so using Robostack has been very comfortable for me as well.
I guess I have missed the survey but I submitted today anyway. I would like to share my use case here.
My working PC is running Windows, when I need to run ROS, I need to find another PC running Ubuntu, which makes me difficult to use other office tools at the same time.
I choose to use Ubuntu not because ROS with Ubuntu is better, but because I just can’t run ROS on Windows, the documented process to install ROS on windows is not standard. For example, why use Chocolatey? I never heard of it before. If there is a better experience to use ROS on Windows, I will not use Ubuntu.
I would suggest mingw as the 3rd option. It’s native Windows binaries actually but not same as the native option mentioned in the survey. mingw has 2 big advantages on Windows, one is its standard package management tool called pacman, just like apt in Ubuntu. The other one is its full coverage of dependent packages needed by ROS2. Some of them are still missing but easy to get work or at least be installed manually from source on mingw. I actually tried to compile ROS2 jammy with mingw, I had some problems with some packages which can’t pass compiling with mingw gcc (it is a little different from the linux version of gcc), but overall it’s very promising.
I’m actually a little surprised to see WSL is listed as a separated option. WSL is actually linux/ubuntu, when you say ROS supports Ubuntu, it implies that it supports WSL. There is less point to list it as a Windows option. When WSL is the only way to run ROS on Windows, it’s same to say: we are sorry that Windows is not supported, please use WSL to run the Ubuntu version of ROS.
Last thing I would like to point out, keeping ROS cross platform is a good way to force real standard usage of c++, cmake, etc. If only linux OS/Compiler is tested, there soon will be linux only code in the code base.
