I recently discover that a few users of
gazebo-yarp-plugins are using Gazebo on WSL (a.k.a. Ubuntu on Windows, https://msdn.microsoft.com/en-us/commandline/wsl/about ).
See https://bitbucket.org/osrf/gazebo_tutorials/pull-requests/364/tutorial-for-installing-on-ubuntu-on/diff for a tutorial on how to run Gazebo on WSL.
For middleware that support Windows such as YARP, this is an interesting alternative to get Gazebo running on Windows, because it permits to have just the minimum amount of Gazebo-related code running under WSL, while the rest of the software can run on the actual Windows system, communicating with WSL-processes using regular network sockets.
However, I noticed some WSL-specific problem in Gazebo, that I think it is worth reporting (even if most of them are actually WSL bugs).
Error setting socket option (IP_MULTICAST_IF)
Related WSL issue: https://github.com/Microsoft/BashOnWindows/issues/990
All code using ignition-transport (including Gazebo 8 and 9) fails on the regular WSL with the following error:
Error setting socket option (IP_MULTICAST_IF). Error setting socket option (IP_MULTICAST_IF). Did you set the environment variable IGN_IP with a correct IP address? [192.168.1.100] seems an invalid local IP address. Using 127.0.0.1 as hostname. terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check: __n (which is 0) >= this->size() (which is 0) Aborted (core dumped)
This is due to the fact that the
IP_MULTICAST_IF socket option is not supported in the released version of WSL, and support for it have been introduced only in Windows build
16176 ( https://github.com/Microsoft/BashOnWindows/issues/990 ) that is currently only available if you use the "Insider" version of Windows.
I am not an expert of the schedule of Windows update, but I think waiting for the fix to be released is the easiest option. People interested in running the latest version of Gazebo in the meanwhile can update to the "Insider" version of Windows.
clock_nanosleep with clockid CLOCK_REALTIME fails with error EINVAL
Related WSL issue: https://github.com/Microsoft/BashOnWindows/issues/2503
Related Gazebo issue: https://bitbucket.org/osrf/gazebo/issues/2058/use-clock_monotonic-in-sleep-and-timer
ign::common::Time::Sleep(...) methods use the system call
clock_nanosleep(CLOCK_REALTIME, ... ) to sleep the current thread. However, clock_nanosleep in WSL works only with the clock
CLOCK_MONOTONIC. I opened an issue for this on WSL issue tracker https://github.com/Microsoft/BashOnWindows/issues/2503 , but I don't it will be solved anytime soon.
One possible solution is to check if
Apparently switching to
clock_nanosleep(CLOCK_REALTIME, ...) is supported during the Time class initialization, and switch otherwise to use
clock_nanosleep(CLOCK_MONOTONIC, ...) . A more complicated possible solution is to migrate the Time classes to the new C++11
<chrono> functions, that seem to work fine also on WSL (even if I imagine that they are internally implemented using the
clock_nanosleep system calls.
CLOCK_MONOTONIC was already planned to avoid problems with system clock reset (see https://bitbucket.org/osrf/gazebo/issues/2058/use-clock_monotonic-in-sleep-and-timer) so that would be the easier solution.