Proposal

• Proposer: Daniel Stonier/김형률/Mirza Shah

• Deadline: xxx 2013

• Interested Parties:

  • ...
  • ...

We'll call a live meeting if there is sufficient need for it, otherwise conclusions from the dialogue below will do.

Agenda

Clearly outline short term direction to providing a relatively mature (and more importantly, finally stable) package for the core subset of ros on windows.

The current status.

Design

Goals

• G01 - easy installation
• G02 - support a core subset of ros
• G03 - support native compilation for windows users with msvc
• G04 - support cross compilation for linux users with mingw
• G05 - support python development on windows
• G06 - fully featured runtime environment (roscore, roslaunch, rostopic etc).
• G07 - support at least one gui framework
• G08 - automated builds on the build farm
• G09 - testing infrastructure
• G10 - multiple ROS distro side-by-side installation on single machine

Implementation Decisions

n/s : no solution as yet

• D01 - n/s
• D02 - all of ros comms, rosbag, tf, diagnostics and rqt
• D03a - baseline support for Windows7
• D03b - support 32bit (currently) and 64bit (needs a bit of work)
• D03c - windows sdk is a good choice (it's free and fully functional)
• D03d - allow windows users to build from either catkin or use the sdk as a library

• D04 - use mingw_cross, needs some work for mingw_cross itself to be stable.

• D05 - this is already mostly there, 64 bit support and python 3 might be headachish though.
• D06 - also mostly there, just minor things to patch (ahem roslaunch).
• D07 - build on top of the rqt framework
• D08 - easy to set up with a slave to osrf's jenkins.
• D09 - support c++ gtests and python nosetests, support others as needed.
• D10 - n/s

Issues

Installers [Daniel Stonier]

Life is tough without emerge, apt-get or similar. Some open questions I have about installation.

• Many installers or just one big installer?
• If we have many installers, how do we replace rosdep/apt-get for management?
• Be careful with the choice of installers - good to pick one that has scriptable uninstall hooks (some dont). The .msi installers work.
• Create a backend for bloom to do .msi generation like it does debs?

Msvc Code Generation [Daniel Stonier]

Currently things are done with the windows sdk and nmake. This is very compatible with the existing ros build environment. Moving to visual ide generation is a huge headache since it places everything in directories very very alien to catkin. Alot of windows users simply won't build stuff outside of the ide - they are currently free to do so if they use the provided sdk like a bunch of libraries and headers, but they can't actually develop win_ros like that.

Kinect Support [Daniel Stonier]

There is some interest for this (alot of windows pcl/kinect developers out there). I daresay, openni_launch is probably way beyond an easy port, and it currently doesn't support the newer kinects anyway. It would be good though to allow people to work with ros and the kinect somehow though.

Plugins/Nodelets [Daniel Stonier]

How urgent is this?

Next Gen Comms [Daniel Stonier]

How soon are we likely to have to deal with movement in this direction?

C# Support [Daniel Stonier]

I known there's a few people with interest in this, but we'd need someone well versed in windows to come in with recommendations. I don't know if it would be possible for C# to make use of the ros comms dll's or whether C# would have to write a full implementation of whatever comms there currently is (probably unfeasible without the critical mass to support it).