We initially discussed doing it like this but discarded the idea in favour of the current setup. We raised this a long time ago on the turtlebot issues, but I guess now people are starting to focus on it. This was our thinking: - Requiring all software installed isn't really a runtime issue (think ubuntu kernel modules for which you don't have hardware). It just uses some extra disk space which is plentiful. It does become a problem if it can't be maintained easily, at which point unmaintainable dependencies should be removed. So we discarded idea this as simply a human thinking convenience and concentrated on the real issues. - What is turtlebot 2 exactly? - Mostly it's the software, with some hardware variation underneath (currently base, stacks, 3d sensor), in the future possibly more.
We think it's easier to move the software to version 2.0 and configure the setup via other means, such as the currently used environment variables with a gui helper in future, than via ros stacks. It also becomes easy to extend this concept to include additional hardware variations and extras.
Also, it's easy to provide launchers (minimal-create.launch) which would also remove the need for a user to worry about setting up a couple of environment variables.
Advantages for separate stacks - simplification in launch files is the only one that strikes me as a real benefit. Is that significant for users? Disadvantages - 1. If you do it via stacks for t1/t2, then you still have to configure variations in hardware such as the 3d sensor. There are also some people are running hexagon stacks on creates, though that's simply a visualisation issue. 2. stack separation might run into turtlebot_viz and turtlebot_apps as well. For example, we'd like to load nodelets into kobuki core for some of the applications based on hardware variable configuration (e.g. safety controller for the bump sensor), but we don't wish to force users to use that particular nodelet controller via minimal.launch. i.e. they may wish to write their own safety controller specifically suited to their task/app. 3. versioning would get confusing, turtlebot stack software would be v1.0? The same user would be installing v2.0 turtlebot_apps?
What are others' thoughts? It's not an issue that I think is terribly important (a big bacon and eggs breakfast is doing a better job of distracting me right now), but I do think it could use some shared discussion/thinking on it.