The latest and second release of HRIM, Beriain, was announced some weeks ago. In this article, we take a closer look on HRIM's novelties.

The main characteristic in Beriain that differentiate it from Anboto, the first version of the Hardware Robot Information Model, is that HRIM is now no longer a platform specific information model, but a platform independent representation of that information model. Meaning the model can now be implemented in many different platforms.

Summing up, there are three novelties in Beriain:

  1. The switch to XML models.
  2. The ROS 2.0 package dependency removal.
  3. The meta-model composition (in development).

1. Switch to XML models

HRIM has officially taken a very important step towards platform independence on Beriain. We make use of our own xml notation to represent our communication artifacts (.msgs, .srvs...), to then generate said artifacts via our command line tooling.

This command line tool enables the user to interact with HRIM's XML models; to generate the (for now only) ROS 2.0 implementation of different components, visualize the contents of the models, list existing models, etc.

2. ROS package dependency removal

In the previous release, Anboto, HRIM made use of ROS's base communication packages (namely std_msgs and geometry_msgs), depending on packages not necessarily contemplated on other platforms. Now, in Beriain, this dependency has been removed by translating the necessary data structures to our XML representation, therefore depending on nothing but the basic structures provided by ROS 2.0. This paves the way for implementations of HRIM on other future platforms.

3. Meta-model composition (in development)

Strictly speaking, the meta-model composition is not part of the Beriain release, and is still in development. However, the meta-model is a core concept in our vision for HRIM, and we are finally able to start it's development because of the jump to XML models.

Also, we are quite excited to speak about it, to be honest.

Do have in mind this is a possible approach for this, and the one we are starting with. Meaning, the exact process described here is subject to changes, but the thought process behind it is what we are going for. Anyone interested can read further at our docs, specifically the model composition section.

Basically, the current HRIM models define what a module of those types might be able to do, but a specific product might not have all those capabilities.

Additionally, a module's capabilities might be composed of multiple models, e.g. a robotic arm with an integrated camera at the end. These wouldn't be two separated modules, but a single one with multiple capabilities, as the camera would be integrated. For this, you'd use the model composition.

First, you'd indicate to the tool that you want to generate a composition of models followed by it's parts. Following the example above of an arm with an integrated camera:

python compose composite/arm sensor/camera
python compose composite/arm/arm sensor/camera/camera

The passed argument basically represents the pathing from the models folder to the desired XML model. The three part identifier is usable by all models, simply necessary for the current 3dcamera implementation (i.e. sensor/3dcamera/3dcamera_tof).

The resulting file from executing the compose command is a model.xml file at the repository's root that looks like this (click on the dropdown to view file contents):

model.xml <composition name="defaultName"> <model type="composite" subtype="arm" path="models/composite/arm/arm.xml"> <topic name="rc"/> <topic name="reconfiguration"/> <param name="rc_max_velocity"/> <param name="rc_max_yaw"/> </model> <model type="sensor" subtype="camera" path="models/sensor/camera/camera.xml"> <topic name="audio_raw"/> <topic name="compressed"/> <topic name="image_camera_info"/> <topic name="image_color"/> <topic name="image_mono"/> <topic name="image_rect"/> <topic name="image_rect_color"/> <topic name="ptz"/> <topic name="reconfiguration"/> <topic name="set_camera_info"/> <param name="auto_binning"/> <param name="auto_brightness"/> <param name="auto_contrast"/> <param name="auto_exposure"/> <param name="auto_focus"/> <param name="auto_gain"/> <param name="auto_gamma"/> <param name="auto_hue"/> <param name="auto_iris"/> <param name="auto_iso"/> <param name="auto_saturation"/> <param name="auto_sharpness"/> <param name="auto_shutter"/> <param name="auto_white_balance"/> <param name="auto_zoom"/> <param name="binning_x"/> <param name="binning_y"/> <param name="brightness"/> <param name="contrast"/> <param name="exposure"/> <param name="focus"/> <param name="frecuency_rate"/> <param name="gain"/> <param name="gain_blue"/> <param name="gain_green"/> <param name="gain_red"/> <param name="gamma"/> <param name="hue"/> <param name="iris"/> <param name="iso"/> <param name="pan_angle_end"/> <param name="pan_angle_start"/> <param name="pan_speed"/> <param name="password"/> <param name="saturation"/> <param name="sharpness "/> <param name="shutter"/> <param name="tild_angle_end"/> <param name="tild_angle_start"/> <param name="tild_speed"/> <param name="username"/> <param name="white_balance_blue"/> <param name="white_balance_red"/> </model> </composition>

The type and subtype of the model tags are more descriptive than anything, as the path attribute is the one used to point to the used XML model.

The composition tag contains a model tag for each indicated model, and each of these contains a tag for each optional topic and/or parameter that model contains (the mandatory ones are, well, mandatory, so the tool won't let you choose between those). The idea is for the user to remove the ones their module isn't capable of. Said user might en up with something like:

model.xml <composition name="myComponent"> <model type="composite" subtype="arm" path="models/composite/arm/arm.xml"> <topic name="reconfiguration"/> </model> <model type="sensor" subtype="camera" path="models/sensor/camera/camera.xml"> <topic name="ptz"/> <topic name="reconfiguration"/> <topic name="set_camera_info"/> <param name="auto_binning"/> </model> </composition>

Lastly, you'd compile the implementation from the composition, indicating it's platform (for now only ROS 2.0):

python compile model.xml

Which will yield you the following file tree under your repository's root:

└── myComponent
    ├── hrim_composite_arm_msgs
    │   ├── CMakeLists.txt
    │   ├── msg
    │   │   ├── JointStates.msg
    │   │   ├── JointTrajectoryPoint.msg
    │   │   ├── Reconfiguration.msg
    │   │   └── SpecsArm.msg
    │   └── package.xml
    ├── hrim_composite_arm_srvs
    │   ├── CMakeLists.txt
    │   ├── package.xml
    │   └── srv
    │       ├── GoalEndPosition.srv
    │       ├── GoalJointMovement.srv
    │       └── GoalJointTrajectory.srv
    ├── hrim_generic_msgs
    │   ├── CMakeLists.txt
    │   ├── msg
    │   │   ├── Header.msg
    │   │   ├── ID.msg
    │   │   ├── Power.msg
    │   │   ├── ...
    │   └── package.xml
    ├── hrim_geometry_msgs
    │   ├── CMakeLists.txt
    │   ├── msg
    │   │   ├── Accel.msg
    │   │   ├── AccelStamped.msg
    │   │   ├── ...
    │   └── package.xml
    ├── hrim_sensor_camera_msgs
    │   ├── CMakeLists.txt
    │   ├── msg
    │   │   ├── CameraInfo.msg
    │   │   ├── Image.msg
    │   │   ├── PTZ.msg
    │   │   ├── Reconfiguration.msg
    │   │   └── SpecsCamera.msg
    │   └── package.xml
    ├── hrim_sensor_camera_srvs
    │   ├── CMakeLists.txt
    │   ├── package.xml
    │   └── srv
    │       └── SetCameraInfo.srv
    ├── mandatory_parameters.yaml
    ├── model.xml
    └── optional_parameters.yaml

Users that know our model may notice the lack of RC.msg and Audio.msg (amongst others) in the arm and camera's packages, respectively, because of their topic's removal from the composition. The used model.xml composition file is also copied to said folder.