Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Break bringup repo into sub-packages #878

Open
ar13pit opened this issue Jul 11, 2019 · 5 comments
Open

Break bringup repo into sub-packages #878

ar13pit opened this issue Jul 11, 2019 · 5 comments

Comments

@ar13pit
Copy link
Contributor

ar13pit commented Jul 11, 2019

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.

@LoyVanBeek
Copy link
Member

LoyVanBeek commented Jul 11, 2019

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 ?

@LoyVanBeek
Copy link
Member

LoyVanBeek commented Jul 11, 2019

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.

@ar13pit
Copy link
Contributor Author

ar13pit commented Jul 11, 2019

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.

@LoyVanBeek
Copy link
Member

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.

@alberth
Copy link
Contributor

alberth commented Jul 15, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants