Revision history [back]

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though, so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however, and I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: ''bla" most of the times don't result in the error above, and no data. Pub or sub from remote machines fails similarly (but that is to be expected).

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial.tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though, so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however, and I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: ''bla" most of the times don't result in the error above, and no data. Pub or sub from remote machines fails similarly (but that is to be expected).

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376).

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though, so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however, and however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: ''bla" most of the times don't result in the error above, and no data. Pub or sub from remote machines fails similarly (but that is to be expected).

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376).

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though, so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: ''bla" most of the times don't result in the error above, and no data. Pub or sub from remote machines fails similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376).

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though, so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: ''bla" most of the times don't result in the error above, and no data. Pub or sub from remote machines fails similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work. work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376).

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though, so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: ''bla" most of the times don't result in the error above, and no data. Pub or sub from remote machines fails similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376).

edit: it could be that things will improve after the Anniversary Update (from Microsoft/BashOnWindows#567):

We are working to enhance the networking/socket level support post Anniversary update release. Stay tuned!

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though, so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: ''bla" most of the times don't result in the error above, and no data. data being exchanged. Pub or sub from remote machines fails fail similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376).

edit: it could be that things will improve after the Anniversary Update (from Microsoft/BashOnWindows#567):

We are working to enhance the networking/socket level support post Anniversary update release. Stay tuned!

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though, though (or more precisely, the Ubuntu root fs that is used, after you install ROS), so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: ''bla" most of the times result in the error above, and no data being exchanged. Pub or sub from remote machines fail similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376).

edit: it could be that things will improve after the Anniversary Update (from Microsoft/BashOnWindows#567):

We are working to enhance the networking/socket level support post Anniversary update release. Stay tuned!

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though (or more precisely, the Ubuntu root fs that is used, used does, after you install ROS), so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: ''bla" most of the times result in the error above, and no data being exchanged. Pub or sub from remote machines fail similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376).14376 14905).

edit: it could be that things will improve after the Anniversary Update (from Microsoft/BashOnWindows#567):

We are working to enhance the networking/socket level support post Anniversary update release. Stay tuned!

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though (or more precisely, the Ubuntu root fs that is used does, after you install ROS), so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: ''bla" most of the times result in the error above, and no data being exchanged. Pub or sub from remote machines fail similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376 14905).

edit: it could be that things will improve after the Anniversary Update (from Microsoft/BashOnWindows#567):

We are working to enhance the networking/socket level support post Anniversary update release. Stay tuned!

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though (or more precisely, the Ubuntu root fs that is used does, after you install ROS), so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: ''bla"'bla'" most of the times result in the error above, and no data being exchanged. Pub or sub from remote machines fail similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376 14905).

edit: it could be that things will improve after the Anniversary Update (from Microsoft/BashOnWindows#567):

We are working to enhance the networking/socket level support post Anniversary update release. Stay tuned!

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though (or more precisely, the Ubuntu root fs that is used does, after you install ROS), so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: 'bla'" most of the times result in the error above, and no data being exchanged. Pub or sub from remote machines fail similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

Update (2016-11-11): the Anniversary Update didn't improve things, but as of Build 14965, the below mentioned getifaddrs preload library is no longer needed. Network interface enumeration now works correctly. If you are having problems (permission denied errors from Python netifaces.interfaces(), see this comment about the Teredo interface.

RQT runs (after export DISPLAY=:0 and installing an X server on Windows). RViz could work, if you have an X server supporting OpenGL.

One remaining issue is that there is still a problem with publishing and subscribing from WSL.

Note that new installations of WSL will install Ubuntu Xenial (16.04), requiring you to install ROS Kinetic. Just follow the Ubuntu ROS Kinetic installation documentation.

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376 14905).

edit: it could be that things will improve after the Anniversary Update (from Microsoft/BashOnWindows#567):

We are working to enhance the networking/socket level support post Anniversary update release. Stay tuned!

(note: the following text is left here for reference only. Most of the comments about the networking stack don't apply to recent builds any more)

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though (or more precisely, the Ubuntu root fs that is used does, after you install ROS), so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: 'bla'" most of the times result in the error above, and no data being exchanged. Pub or sub from remote machines fail similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

Update (2017-02-02): Build 15019 hasn't improved things significantly, but at least most of the tricks for getting networking to work (Teredo issue etc) have been addressed.

See Microsoft/BashOnWindows/#issues/1450 and Microsoft/BashOnWindows#1391 for an issue issues tracking current state / progress.

Update (2016-11-11): the Anniversary Update didn't improve things, but as of Build 14965, the below mentioned getifaddrs preload library is no longer needed. Network interface enumeration now works correctly. If you are having problems (permission denied errors from Python netifaces.interfaces(), see this comment about the Teredo interface.

RQT runs (after export DISPLAY=:0 and installing an X server on Windows). RViz could work, if you have an X server supporting OpenGL.

One remaining issue is that there is still a problem with publishing and subscribing from WSL.

Note that new installations of WSL will install Ubuntu Xenial (16.04), requiring you to install ROS Kinetic. Just follow the Ubuntu ROS Kinetic installation documentation.

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376 14905).

edit: it could be that things will improve after the Anniversary Update (from Microsoft/BashOnWindows#567):

We are working to enhance the networking/socket level support post Anniversary update release. Stay tuned!

(note: the following text is left here for reference only. Most of the comments about the networking stack don't apply to recent builds any more)

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though (or more precisely, the Ubuntu root fs that is used does, after you install ROS), so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: 'bla'" most of the times result in the error above, and no data being exchanged. Pub or sub from remote machines fail similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

Update (2017-02-02): Build 15019 hasn't improved things significantly, but at least most of the tricks for getting networking to work (Teredo issue etc) have been addressed.

See Microsoft/BashOnWindows/#issues/1450 and Microsoft/BashOnWindows#1391 for issues tracking current state / progress.

Update (2016-11-11): the Anniversary Update didn't improve things, but as of Build 14965, the below mentioned getifaddrs preload library is no longer needed. Network interface enumeration now works correctly. If you are having problems (permission denied errors from Python netifaces.interfaces(), see this comment about the Teredo interface.

RQT runs (after export DISPLAY=:0 and installing an X server on Windows). RViz could work, if you have an X server supporting OpenGL.

One remaining issue is that there is still a problem with publishing and subscribing from WSL.

Note that new installations of WSL will install Ubuntu Xenial (16.04), requiring you to install ROS Kinetic. Just follow the Ubuntu ROS Kinetic installation documentation.

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376 14905).

edit: it could be that things will improve after the Anniversary Update (from Microsoft/BashOnWindows#567):

We are working to enhance the networking/socket level support post Anniversary update release. Stay tuned!

(note: the following text is left here for reference only. Most of the comments about the networking stack don't apply to recent builds any more)

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though (or more precisely, the Ubuntu root fs that is used does, after you install ROS), so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: 'bla'" most of the times result in the error above, and no data being exchanged. Pub or sub from remote machines fail similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

Update (2017-04-05) by @RodBelaFarin:

Status quo in build 15063: roscore, turtlesim, rviz, rqt_graph starting up, rostopic list works, even rostopic echo works sometimes, but no communication between nodes. Using WSL 14.04 and Indigo binary install, just added localhost to .bashrc as ROS_MASTER_URI and ROS_HOSTNAME. Using Xming and DISPLAY=:0.

Update (2017-02-02): Build 15019 hasn't improved things significantly, but at least most of the tricks for getting networking to work (Teredo issue etc) have been addressed.

See Microsoft/BashOnWindows/#issues/1450 and Microsoft/BashOnWindows#1391 for issues tracking current state / progress.

Update (2016-11-11): the Anniversary Update didn't improve things, but as of Build 14965, the below mentioned getifaddrs preload library is no longer needed. Network interface enumeration now works correctly. If you are having problems (permission denied errors from Python netifaces.interfaces(), see this comment about the Teredo interface.

RQT runs (after export DISPLAY=:0 and installing an X server on Windows). RViz could work, if you have an X server supporting OpenGL.

One remaining issue is that there is still a problem with publishing and subscribing from WSL.

Note that new installations of WSL will install Ubuntu Xenial (16.04), requiring you to install ROS Kinetic. Just follow the Ubuntu ROS Kinetic installation documentation.

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376 14905).

edit: it could be that things will improve after the Anniversary Update (from Microsoft/BashOnWindows#567):

We are working to enhance the networking/socket level support post Anniversary update release. Stay tuned!

(note: the following text is left here for reference only. Most of the comments about the networking stack don't apply to recent builds any more)

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though (or more precisely, the Ubuntu root fs that is used does, after you install ROS), so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: 'bla'" most of the times result in the error above, and no data being exchanged. Pub or sub from remote machines fail similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

Update (2017-05-09):

There is now a PR against ros_comm (ros/ros_comm#1050) which appears to address one of the main remaining issues with ROS on WSL.

A regular ROS install with ros_comm (really only roscpp) with the patch built from sources in an overlay workspace now results in an (almost) working ROS install running on WSL on build 16188.

Update (2017-04-05) by @RodBelaFarin:

Status quo in build 15063: roscore, turtlesim, rviz, rqt_graph starting up, rostopic list works, even rostopic echo works sometimes, but no communication between nodes. Using WSL 14.04 and Indigo binary install, just added localhost to .bashrc as ROS_MASTER_URI and ROS_HOSTNAME. Using Xming and DISPLAY=:0.

Update (2017-02-02): Build 15019 hasn't improved things significantly, but at least most of the tricks for getting networking to work (Teredo issue etc) have been addressed.

See Microsoft/BashOnWindows/#issues/1450 and Microsoft/BashOnWindows#1391 for issues tracking current state / progress.

Update (2016-11-11): the Anniversary Update didn't improve things, but as of Build 14965, the below mentioned getifaddrs preload library is no longer needed. Network interface enumeration now works correctly. If you are having problems (permission denied errors from Python netifaces.interfaces(), see this comment about the Teredo interface.

RQT runs (after export DISPLAY=:0 and installing an X server on Windows). RViz could work, if you have an X server supporting OpenGL.

One remaining issue is that there is still a problem with publishing and subscribing from WSL.

Note that new installations of WSL will install Ubuntu Xenial (16.04), requiring you to install ROS Kinetic. Just follow the Ubuntu ROS Kinetic installation documentation.

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376 14905).

edit: it could be that things will improve after the Anniversary Update (from Microsoft/BashOnWindows#567):

We are working to enhance the networking/socket level support post Anniversary update release. Stay tuned!

(note: the following text is left here for reference only. Most of the comments about the networking stack don't apply to recent builds any more)

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though (or more precisely, the Ubuntu root fs that is used does, after you install ROS), so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: 'bla'" most of the times result in the error above, and no data being exchanged. Pub or sub from remote machines fail similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).

Update (2017-10-28): @k-okada

I have successfully running ros, rviz + stage or rviz + gazebo (though the gazebo screen is black), on Windows Fall Creators Updates

• Windows 10 Pro, 64bit, Version 1709, Build 16299.19
• ros_comm 1.12.7
• PubicDomain version of Xming (http://www.straightrunning.com/XmingNotes/), rviz/gazebo clashes with Xming-mesa
• need to install ubuntu-gnome-desktop manually (https://github.com/Microsoft/WSL/issues/2016)

Update (2017-05-09):

There is now a PR against ros_comm (ros/ros_comm#1050) which appears to address one of the main remaining issues with ROS on WSL.

A regular ROS install with ros_comm (really only roscpp) with the patch built from sources in an overlay workspace now results in an (almost) working ROS install running on WSL on build 16188.

Update (2017-04-05) by @RodBelaFarin:

Status quo in build 15063: roscore, turtlesim, rviz, rqt_graph starting up, rostopic list works, even rostopic echo works sometimes, but no communication between nodes. Using WSL 14.04 and Indigo binary install, just added localhost to .bashrc as ROS_MASTER_URI and ROS_HOSTNAME. Using Xming and DISPLAY=:0.

Update (2017-02-02): Build 15019 hasn't improved things significantly, but at least most of the tricks for getting networking to work (Teredo issue etc) have been addressed.

See Microsoft/BashOnWindows/#issues/1450 and Microsoft/BashOnWindows#1391 for issues tracking current state / progress.

Update (2016-11-11): the Anniversary Update didn't improve things, but as of Build 14965, the below mentioned getifaddrs preload library is no longer needed. Network interface enumeration now works correctly. If you are having problems (permission denied errors from Python netifaces.interfaces(), see this comment about the Teredo interface.

RQT runs (after export DISPLAY=:0 and installing an X server on Windows). RViz could work, if you have an X server supporting OpenGL.

One remaining issue is that there is still a problem with publishing and subscribing from WSL.

Note that new installations of WSL will install Ubuntu Xenial (16.04), requiring you to install ROS Kinetic. Just follow the Ubuntu ROS Kinetic installation documentation.

tl;dr: you can install ROS Indigo for amd64 from binaries on WSL, but the current state of the network stack is such that it makes any kind of serious use of ROSonWSL impossible (at least as of build 14376 14905).

edit: it could be that things will improve after the Anniversary Update (from Microsoft/BashOnWindows#567):

We are working to enhance the networking/socket level support post Anniversary update release. Stay tuned!

(note: the following text is left here for reference only. Most of the comments about the networking stack don't apply to recent builds any more)

It's perfectly possible to install ROS on WSL as you found out: just follow the Ubuntu Trusty installation tutorial. No need to build from source actually, WSL supports the amd64 architecture, which is well supported by the ROS buildfarm.

The problem is that for ROS to be really useful (other than just using it as a build infrastructure on a Windows10 machine) the networking support in WSL needs to be extended significantly / finished.

One of the major problems is that raw / netlink socket support is absent currently (build 14376 as of writing, see the WSL release notes), which makes getifaddrs(..) not work. That is the cause of the backtrace @Mahmoud Abdul Galil posts in his answer. MS is aware of this (see Microsoft/BashOnWindows#118, Microsoft/BashOnWindows#134 and Microsoft/BashOnWindows#308), and there is a User Voice topic for this, which you can vote on. I'd recommend you do that.

To get around getifaddrs(..) not working, I wrote gavanderhoorn/getifaddrs_preload, which LD_PRELOADs itself and returns the minimal data needed to get netifaces.interfaces() to work. This just always returns 127.0.0.1, and whatever you have ROS_IP set to.

To get roscore to start, do the following (in a WSL Bash terminal):

$ export ROS_IP=<your actual IP>
$ export ROS_MASTER_URI=http://<your actual ip>:11311/
$ source /opt/ros/indigo/setup.bash
$ LD_PRELOAD=/path/to/_getifaddrs.so roscore

This roscore is perfectly usable: other Linux and OSX machines can use it as well, rostopic list, rosservice list etc all work correctly.

But at this point things become less interesting: as @m4k mentions, WSL doesn't have an X server, which means no RViz, no RQT etc. WSL does have an X client though (or more precisely, the Ubuntu root fs that is used does, after you install ROS), so a Windows X-Server (such as the ones @petermitrano suggests) is enough to get basic X working (export DISPLAY=:0 && xcalc fi). At this point, RQT and RViz still crash however. I haven't put any more time in this, but I suspect something is either not implemented in WSL, or it's running into things like what ros-visualization/qt_gui_core#62 was meant to address. I suspect issues with getting OpenGL to work after these are fixed as well.

Ignoring GUI applications, the next limitation is in the socket support: publishing, subscribing and service invocation typically fail with an error such as:

Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received.  Please check sender for additional details.

I've had intermittent success, but things like rostopic pub -r1 /chatter std_msgs/String "data: 'bla'" most of the times result in the error above, and no data being exchanged. Pub or sub from remote machines fail similarly (but that is to be expected).

As to the netlink / raw socket support: there is a (small) chance that it might have gotten more priority for the WSL dev team after Microsoft/BashOnWindows#468 was reported:

This will be required for the new SharePoint Framework update released by Microsoft. Because it use [sic] Yeoman generator to extend SharePoint from Linux, MacOSX as well as Windows.

I have no insight into the WSL development process, but in the past, requirements for internal projects have been known to have influence on the priority of outstanding issues at MS, so who knows ..

At this point I've had to get back to other things, so it is well possible that a few, correctly placed work-arounds like getifaddrs_preload could make things work (although things like Microsoft/BashOnWindows#616 also still exist). I suspect though that without MS getting the network stack working properly, it'll require some effort to get WSL to be a useful deployment target for ROS (even if we can re-use the amd64 binaries directly).