weixin_39549899
weixin_39549899
2020-12-01 13:34

The should not depend on any turtlebot2 software.

I have broken out all of the common components into a new stack calledturtlebot_common and turtlebot2. This way one can install either turtlebot or turtlebot2 without requiring all of the software from the other. This also simplifies bringup somewhat as the setup_t1.sh and setup_t2.sh are no longer necessay, you may now simply call the roslaunch file for the specific robot.

该提问来源于开源项目:turtlebot/turtlebot

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

5条回答

  • weixin_39926588 weixin_39926588 5月前

    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.

    点赞 评论 复制链接分享
  • weixin_39612023 weixin_39612023 5月前

    mmmmmmm, bacon and eggs........

    点赞 评论 复制链接分享
  • weixin_39549899 weixin_39549899 5月前

    I have to disagree with you slightly: - While disk space may not be an issue, the overriding problem here is that it is incorrect to have to install both turtlebot and turtlebot2 software. This becomes a large inconvenience if there are any issues with building either the kobuki or create specific software, in which case both won't build. The two pieces of software are entirely unrelated and thus nothing required to run turtlebot1 should be dependent on software for turtlebot2 and vice versa.

    While I don't disagree that it is possible to handle the setup via separate launch scripts and environment variables I believe it is more useful to have separate stacks: - The configuration variations are not an issue, all of the common components, like urdfs for the stacks and sensors are in common, and I am already working on a configuration script that allows you to select theses components and generates a URDF. The user then simply has to install the either turtlebot/turtlebot2 software depending on which base they have - You might run into problems with apps and viz that is true but as I said I believe the separation is important, so we may need to have turtlebot1 viz and turtlebot2 viz. While this does create more stacks, in the end it will be easier to maintain, and any components that are used by both should just go in common. - As far as versioning goes users are simply going to check out the stack or install the debs. I believe putting it in the name makes it far clearer that the user is getting software for either the turtlebot or turtlebot2.

    点赞 评论 复制链接分享
  • weixin_39926588 weixin_39926588 5月前

    I don't know that I would call it incorrect. A single ubuntu release with a wide set of kernel modules, an image capture program with common camera software driver dependencies, or even openni supporting multiple hardware configurations out of the box represent similar situations. - Perceived problem : depending on kobuki/create software representing a maintenance issue.

    The short of it - if there is this perception I'm fine with finding a way to fix this. It wouldn't be surprising that people have feel like this after having seen the long process that has been the groovy release. Issues that I have with the proposed solution: - The turtlebot/turtlebot2 naming. It goes against the spirit of a turtlebot-compatible platform that REP119 is trying to define. A turtlebot with a create base and a turtlebot with a kobuki base are just variations on the rep definition. They also use the same 2.0 software on top, which would get confused with thinking that the turtlebot1 stack might need the old 1.0 software. - Bigger view. Key issues are how to handle hardware variation and optional dependencies, i.e. 1) how to install stuff and 2) how to launch stuff. Ros just doesn't do this very well right now. Sure, for one or two variations, you can do the stack and multiple launchers thing, but permutations stop you from scaling up very far. Keep in mind that distributors would like to do more with the turtlebot platform - it's a very fixed beast right now.

    I think turtlebot is potentially a good platform for experimenting with solutions to these issues because it is intended as a variable platform for which the turtlebot framework provides some structure. I was envisioning starting turtlebot with a script instead of minimal.launch. One that checks for configuration, validates, and then either launches into a configuration gui or a launcher depending in whether the validation fails or not. Bill I believe was playing around with these issues with his 'meta-launcher' and 'urdf stitcher'. We should listen to him and the distributors more - he has requirements for his business that ros developers/labs just don' t have and such tools would make useful additions to the ros framework in any case.

    Really Important

    I'd really like to avoid late fragmentation, retesting and re-releasing of everything for something that isn't a critical requirement, nor a fully workable solution. We were quite close to get a first set of mostly functional debs out to the distributors, and this is the absolute priority at this stage. This input would have been appropriate two-three months ago, but right now, getting it out for the distributors is the priority - they've already been too far delayed by both kobuki and groovy.

    New stacks as proposed, would require testing and re-releasing after rethinking and possibly splitting everything, through to turtlebot_apps, turtlebot_viz and turtlebot_simulator as well. The current design was meant as a temporary solution to get us through launch. Catkinization will make it easier to break down dependencies via metapackages without the extra stack infrastructure. At that point I think it would be a good time to revisit the problem. If there is an absolute need to remove the dependencies, a simple bootstrap script/configuration program could fix this with the current design.

    We can design and implement upgraded solutions for various things (minimal bootstrap, app manager, android) with the intent of landing it in hydra.

    点赞 评论 复制链接分享
  • weixin_39926588 weixin_39926588 5月前

    Cancelling for now - revisit hardware variation going on to hydro.

    点赞 评论 复制链接分享