You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #1055 we noticed that our curren structure of dependencies in robot_skills means that all installations of robot_skills have dependencies on functionality from AMIGO, SERGIO en HERO, even if the target does not need all this.
Only the dependencies relevant to the target should be installed, and we should be able to change these depending on the robot we are using.
The text was updated successfully, but these errors were encountered:
Th way this is typically done is by separating interface from implementation.
In such a set-up, robot_smach_states depends only on eg. robot_skill_interfaces while eg. HERO implements those interfaces in a separate package (eg. hero_skills), that depends its specific dependencies.
Then at runtime, a HERO-class is instantiated as we do now.
Yup, and as briefly mentioned you'd need some kind of plugin structure to make sure that the application (main challenge file in this case) knows which robots are available, i.e., 'installed' on the system.
For this aspect, we currently specify the robot's name. Using a path to a file with the class or just a module name+class name could do the trick there.
In #1055 we noticed that our curren structure of dependencies in robot_skills means that all installations of robot_skills have dependencies on functionality from AMIGO, SERGIO en HERO, even if the target does not need all this.
Only the dependencies relevant to the target should be installed, and we should be able to change these depending on the robot we are using.
The text was updated successfully, but these errors were encountered: