tue_robocup
tue_robocup copied to clipboard
tue-robotics
Break bringup repo into sub-packages
To define the execution dependencies better (for all of our launch files).
After having a small chat with @jlunenburg and @LoyVanBeek I got this idea of having a meta-package for the bringup repo and sub-packages that have complete package dependencies.
Hmm, so a hero_bringup_restaurant & hero_bringup_receptionist for example?
Then I wonder: why not put these into a launch subdir of the challenge package? There is probably a good reason for this, but I'm not sure what it would be. @jlunenburg, @reinzor ?
why not put these into a launch subdir of the challenge package?
One reason is that then a challenge is not robot-independent anymore: it known on which robots it can run. In the proposed case (challenges not having launch files), there is no direct coupling between challenge and robot which is desirable.
It's then possible to add a new _bringup package and when the API matches have that new robot run a new challenge.
So splitting into hero_bringup_restaurant & hero_bringup_receptionist etc sounds like a good idea.
Not just the challenges. We also have other dependencies in free-mode, start that are not in the package.xml.
Although I like your idea @LoyVanBeek of having a launch sub-dir in each challenge because that's one of the best practices of creating a ROS package, but why do you say that the challenges are not robot-independent anymore? They are just smach states which IDEALLY do not call the robot api directly.
My main concern here is that the bringup repos are happily married with tue-env when in fact they should not even have any kind of brewing relationship.
but why do you say that the challenges are not robot-independent anymore?
Currently, a challenge doesn't even know which robots we have. If a challenge has robot-specific launch files, they'll at least need one launch file per robot and thus introducing some coupling in that regard.
Shouldn't a robot itself figure out how to run a challenge? That is, have 1 launch file, and then the challenge itself queries the robot for things it needs, and adapts itself such that the challenge can be performed.
Obviously, bailing out when needed requirements and robot capabilities don't fit is always an option. However that is then due to some mismatch between robot and challenge found in the negotiation process.
