Cleanup

[ibaiape]

• Removal of Header, Time and Duration from hrim_generic_msgs. All packages now depend on std_msgs for the header and the ones making use of Time and Duration take it from builtin_interfaces.
• Removal of hrim_geometry_msgs, all dependencies to it now point to geometry_msgs.
• Removal of the models & related code for moveit_msgs, octomap_msgs, shape_msgs, object_recognition_msgs and control_msgs. All but control_msgs (will be done shortly) have their repositories in AcutronicRobotics with a clean ROS2 migration.

Code changes have been applied to hrim.py (for the generation shorthands and their inclusion in the generate all command) and a couple of small changes to scripts/compiling.py for proper checks on the package origin.

[ahcorde]

I know that we can generate sensors and actuators independently. Can we add this to the help message?

[ibaiape]

True, on it.

Will review I'm not missing anything else.

[ahcorde]

I don't fully understand this

                        compose:
                            generate a composition of modules.
                        compile:
                            generate the platform-specific implementation of the passed composition.

Why we don't make it in one step?

why we want to modify a model? doing so, we are breaking the compatibility right?

[ibaiape]

Process is explained step-by-step in our docs.

As a sum-up:

• You generate an initial model composition of multiple models (i.e. python3 hrim.py compose composite/arm sensor/camera). This results in an xml composition with a list of each of the passed modules' optional topics&parameters.
• You manually (prepared to be manipulated programatically through a GUI) remove the optional capabilities your component doesn't support (i.e. as my arm doesn't support control by joystick you remove the RC topic).
• You "compose" the composition by running it's command and passing the xml composition you passed above, by default model.xml (i.e. python3 hrim.py compose model.xml). This generates a structure of folders containing the necessary packages for your defined module to work, with the minimum amount of interfaces (.msg&.srv files) and the node parameters of your composition (following the example above, without an RC.msg interface). This structure also contains the composition xml model.

So you wouldn't be modifying a model as much as you'd be picking the parts you'd need. It is true that your resulting packages (apart of possibly having duplicated package definitions in your HRIM folder structure if you either have multiple compositions or the results of running generate all) aren't the same as the full models (contain less interfaces).

I do feel, however, that this process could be of a lot more value later on if it the process didn't only imply interfaces & parameters. I could see this same process making much more sense if the tooling, for example, also generated some basic drivers. The best example I can get off the top of my head would be some basic "getter"/"setter" functions (taking care of the publisher&subscribers / some basic ROS plumbing).

I still can't see any way of model composition without modifying package definition, be it modifying the interfaces themselves (which completely breaks compatibility) or the current way (which could easily result in missing some interfaces).

Your thoughts on this @vmayoral?