Windows survey results

As you may remember, back at the end of July we sent out a survey to get a better idea of how the community is using ROS 2 on Windows: Feedback Requested: Future of ROS 2 Windows Support

104 people responded to that survey, which was many more than we were expecting. Thank you for that! Given the number of people who responded, there is clearly interest in having ROS 2 continue to work on Windows.

We’ve put together a presentation showing a subset of the results in: 2024 ROS 2 Windows survey results - Google Slides

Based on the information we received, here is a proposed plan:

  1. We will stop shipping the Windows Debug binary archives. They are infrequently used, and eat up a lot of disk space and bandwidth. Note that we will continue to test Windows Debug in CI, as that finds bugs, but we won’t be shipping it to end-users anymore.
  2. We will mark Ubuntu 24.04 on WSL2 on Windows as a Tier-3 supported platform in REP-2000. A Tier-3 supported designation means that it is community supported, and the core team won’t be adding additional CI for it (at least for now). But putting it in REP-2000 recognizes it as a common platform people are using.
  3. We will invest some more time into producing Windows native libraries. In particular, we will switch to MSVC 2022 and Windows 11 (hopefully for Kilted). We’ll also switch to using Conda as the preferred solution to install our dependencies (rather than our current hodge-podge of dependency installation). This does not mean that ROS packages will be available in Conda by default; the RobotStack team is handling that for now. But it does mean that installation of the ROS 2 core on Windows should get significantly easier.

We’d like to hear your input on the above proposal, and anything else you’d like to share with us about ROS 2 on Windows. Thanks!

7 Likes

Great news and thanks for sharing the result of the survey!

Just a couple questions:

It is likely that ROS on Windows users are primarily using IsaacSim or Unreal.

Just a curiosity, why do you think that is the case? My guess would have been the most ROS on Windows users use Gazebo Classic, but I am probably biased. Were there indications on that in the survey responses?

Note that we will continue to test Windows Debug in CI, as that finds bugs, but we won’t be shipping it to end-users anymore.
[…]
We’ll also switch to using Conda as the preferred solution to install our dependencies (rather than our current hodge-podge of dependency installation).

Just a curiosity, as conda-forge does not provide Windows Debug libraries and Debug and Release C++ libraries ABI is not compatible as soon as the STL is used, is there a plan to continue to use non-conda provided Windows binaries just for the Debug CI?

2 Likes

Interesting results. But this probably means the apparent stagnation will continue with the ROS project. This and similar design decisions make every change much more costly for everyone, and the project roadmap gets empty as a result.

If there is an interest in Windows support, separating codebases would be much a better solution (probably funded by interested companies, Microsoft, and the US government). Furthermore, I often think the best exit plan for the ROS project is to position itself as an API rather than a single implementation. This would fit better with the current structure of the Foundation above companies.

1 Like

Thanks for the report! I’m excited that installation of the core will be getting easier.

Was there any information about whether people are using WSL1/WSL2 on Windows?

1 Like

This was mostly based on feedback from the Gazebo devs that the number of Gazebo users on Windows is small. But I’ll admit that I didn’t clarify with them whether that was Gazebo Classic or New Gazebo. Either way, it is speculation, so maybe I shouldn’t have made that statement at all :).

This is an interesting point, and worth digging into. In our current Windows install, these are the packages that we install (via various methods) before we invoke colcon build:

  • cmake
  • cppcheck
  • curl
  • git
  • openssl
  • vcredist140
  • vcredist2013
  • winflexbison3
  • asio
  • bullet
  • cunit
  • eigen
  • tinyxml2
  • opencv
  • MSVC BuildTools
  • Qt5
  • libxml2
  • zlib
  • iconv
  • RTI Connext
  • Python
  • python-lxml
  • python-pyqt5
  • python-numpy
  • python-cryptography

However, for our current Windows Debug build, the only custom packages we install are Python (Debug), python-lxml (Debug), and python-numpy (Debug).

(everything else we build from source)

Looking through the above list, cmake, cppcheck, git, winflexbison3, and MSVC are all tools, so the ABI doesn’t matter.

curl, openssl, cunit, libxml2, zlib, and iconv are all C libraries, so the C++ ABI doesn’t matter.

asio and eigen are both header-only libraries, so the C++ ABI doesn’t matter.

That leaves bullet, Qt5, and opencv as potential problems. All I can say is that we don’t explicitly install anything special for them right now, and they do seem to work. I’m hoping that whatever mechanism currently makes them work will continue to work when we switch to Conda.

That said, if we do run into problems, then probably we will have to vendor more of these dependencies explicitly for Windows Debug, or build our own packages.

2 Likes

So the survey explicitly asked about WSL 2. And based on the response to it, it seems like quite a number of people are using WSL 2 (this was also borne out by the Jazzy tutorial testing party). I don’t have any information about WSL1 users, sorry.

2 Likes

Interesting, indeed this is interesting! I am afraid on conda-forge you can’t get debug versions of python-numpy, while for python it seems that there are some packages available in a non-main label, see Including Python debug builds · Issue #1017 · conda-forge/conda-forge.github.io · GitHub .

1 Like

I am curious about the issues mentioned with HID and other external devices on WSL2, I see mention of “device issues” a lot with any system (native linux, windows, macos, etc). Reality a lot of time is that it’s just knowing how to properly setup user permissions. IE adding user to tty and dialout group on linux to use an FTDI/CH340 for serial.

Specific example for claimed problem: WSL2 works with the very common linux supported Joysticks that we use to control our simulated digital-twin vehicles in gazebo (for the few that are forced by IT to use a windows machine in our group). If user was not added to plugdev group though it would be an issue.

1 Like

Was there a specific reason, why the survey did not include non windows users ?
It would have been interesting, to know the percentage of ros linux vs ros windows users.

Mostly because we were specifically looking for feedback from our Windows users. We were somewhat concerned that the Windows responses would be overwhelmed by non-Windows responses.

That said, one of the questions on the survey was whether our Windows users also used alternative operating systems, and which ones they used. Overwhelming the answer was “yes, we also use Ubuntu” (94% of respondents).

1 Like

It’s commonly reported that you need to customize the WSL2 kernel to use joystick devices, see here and here.

However, I wonder to what extent that’s limited to XBox and XBox-compatible gamepads vs. more generic devices. This seems to suggest a Logitech F310 works fine.

Just an update on this from direct experience (2024-09-21). I tried to get my Logitech F710 gamepad to show up in WSL2 (Ubuntu Noble 24.04) intending to try it with the ROS 2 joy package.

I can attach it to WSL2 using usbipd and it shows up:

dan@<computer>:~$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 046d:c219 Logitech, Inc. F710 Gamepad [DirectInput Mode]
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

But it does not show up as a /dev/js0 device or even a /dev/input device. It does show up as /dev/hidraw0.

I’ve seen basically the same with a genuine XBox controller. It can be attached to the WSL 2 instance but cannot be used.

My user is a member of the plugdev group by default:

dan@<computer>:~$ groups
dan adm dialout cdrom floppy sudo audio dip video plugdev users netdev

Both gamepads I’ve had issues like this with are plug-and-play on a native Linux installation and are immediately usable with the joy package.

I’ve had the same kind of issue with flashing Jetson Xavier devices from WSL. Block-level access to SD card devices is not available without updating the kernel, as I understand it.

Issues we have run into typically revolve around NAT level HW drivers, and other applications interfering with NAT level drivers preventing WSLs network interfaces from working entirely (even for docker etc).

Because the nat is virtualised on WSL (windows 11 apparently has a feature to forward the NAT directly) drivers that expect
To have the low level control end up not working as they don’t have true access to the HW NAT