Announcing the Hardware Robot Information Model (HRIM)

General
1

Hello everyone,

It’s a pleasure for me to announce the release of the 0.1.0 version of the Hardware Robot Information Model (HRIM) available at GitHub - AcutronicRobotics/HRIM: An information model for robot hardware. Facilitates interoperability across modules from different robot manufacturers. Built around ROS 2.0.

Briefly,
HRIM is a common interface that facilitates interoperability among different vendors of robot hardware components with the purpose of building robot modules and thereby, modular robots. HRIM focuses on the standardization of the logical interfaces between robot modules, designing a set of rules that each device has to meet in order to achieve interoperability. It tackles the problem of incompatibility between robot components that hinder the reconfigurability and flexibility demanded by the robotics industry. In a nutshell, HRIM presents a model to create plug-and-play robot hardware components. HRIM builds upon the ROS component model and although we envision its expansion to support other framework alternatives, currently a ROS 2.0 implementation is available at GitHub - AcutronicRobotics/HRIM: An information model for robot hardware. Facilitates interoperability across modules from different robot manufacturers. Built around ROS 2.0.

In short, the robot modules have been classified in 6 (actually, there’s a seventh, composites that is a work in progress) types of modules which correspond to the task they can perform: sensing, actuation, communication, cognition, user interfaces or power. Each type is composed by sub-types or devices, related to the functionality of the component. For example, a camera is a sub-type of the sensor type. The following image pictures the HRIM component model for each device (or sub-type):

1*t95rSkuCEWBBNEM4J-O_6A.jpeg1000×379 40.2 KB

HRIM has been presented to national experts at the International Standardization Organization (ISO) within the scope of the standardization in the field of robotics, excluding toys and military applications (ISO/TC 299). Particularly, it has been introduced within the ongoing standard ISO/CD 22166–1 which treats modularity for service robots.

HRIM also conforms with the following pre-existing international standards:
HAL4RT
OpenEL 3.0

In addition, Fraunhofer IPA — the largest research organization for applied research in Europe — is currently looking at HRIM to adopt it and extend it for several projects. Mirko Bordignon, group manager at Fraunhofer IPA said:

After years of experience designing, developing, and deploying software on robotic systems, we fully subscribe to the objectives stated in the HRIM manifesto: working towards true “plug and play” hardware modules through a standardized information model, which merges the inputs and feedback gathered from open-source communities with the stability and platform-independence required by standardization bodies. We look forward to contribute our experience to further advancing HRIM towards this goal!

Similarly, HRIM picked the interest of the ROS-Industrial (ROS-I) Europe consortium during the last ROS-I conference where HRIM was introduced.

Feedback, criticism and contributions are more than welcome. A complete writeup and description of the release is available at Introducing the Hardware Robot Information Model (HRIM) | HackerNoon.

Regards,

5 Likes
2

Great work, Victor and everyone working with you! I hope this is adopted widely!

I have some questions about your relationship with standards.

  • How exactly are you compatible with the (draft) ISO 22166-1?
  • How are you compatible with HAL4RT? There are two versions of that specification proposed; the first has died and the second was rejected because it doesn’t contain anything of use to robotics. The proposed APIs are also not compatible with ROS.
  • How do you support OpenEL 3.0, which is a private commercial project (not an international standard)? Do you provide an implementation of its APIs? They don’t seem compatible with ROS, to me.
1 Like
3

Hello @gbiggs!

How exactly are you compatible with the (draft) ISO 22166-1?

I/we don’t claim that HRIM is compatible with the draft of ISO 22166-1. Doing so would be incorrect as the ongoing standard covers (or that’s my hope for its final shape) much, much more than a model. As far as I know, the existing draft does not even propose a model and the closest thing included is a pointer to HAL4RT (more about this below).

What we claim is that HRIM has been presented and introduced to the experts pushing the ongoing standard. We received feedback already from several of those experts and our hope is that we can inspire some additional content on the working document which currently, IMHO, lacks of software abstractions that facilitate interoperability.

Although what you say is right and HAL4RT 2.0 isn’t still official (AFAIK JASA will revise and submit the new version to OMG in June this year but you probably know it better than I do), we based ourselves on the latest draft of HAL4RT 2.0 available (verified just a few days ago with Kenichi Nakamura when he facilitated the last version after I introduced HRIM to him (leading HAL4RT)). We claim we conform with the statements indicated in this last draft and which refer to specific sections within HAL4RT 2.0 document. The conformance of each one of this sections is discussed in Appendix I at https://arxiv.org/pdf/1802.01459.pdf.

Taking into account these aspects, we believe that claiming conformance is valid but probably, stating that we’re on the path to conform (formally) with HAL4RT 2.0 is more correct since as you point out, (HAL4RT 2.0) isn’t official yet.

I’m not really sure we agree on this. Could you mention which sections make you think this way?

This is likely the claim I can defend the least since most of the information we found is in Japanese and it was a tremendously hard task to understand it right. In fact, although we looked into it, we were not going to mention anything about it however, a few days ago I got the following from Kenichi:

At this time, OpenEL 3.0 and HAL4RT 2.0 are almost the same.
So there is no document for OpenEL 3.0 in English now.

Everything we saw (and understood), make us think this way as well so on this basis, we included that sentence.

1 Like
4

Sorry, I misread your post.

Unfortunately, based on this week I don’t think that 22166-1 is going to go in the direction you and I desire.

OK, after reading that document I understand how you are looking at HAL4RT. I looked at the interfaces you have and I do not think you are correct to claim conformance with HAL4RT 2.0. You can claim that you correlate on capabilities with HAL4RT 2.0, but to conform you would need to have identical interfaces, which you do not. You have similar capabilities (as well as significantly extended capabilities) but you do not match the model defined by HAL4RT 2.0. Which I think is a good thing because your model is significantly better for our needs, in my opinion.

OK, on that basis if you feel confident then you could claim correlation with OpenEL 3.0 (I wouldn’t claim compliance with something I hadn’t seen; “almost the same” is not the same as “identical”). I wouldn’t claim it’s an international standard, though.

If you want help with the Japanese, feel free to ask. :slight_smile:

1 Like
5

For completeness, I’m leaving here a short comment about our updates:

although we will keep in touch with the groups behind HAL4RT and OpenEL efforts, after an offline discussion, Iweve made an update to the original announcement and crossed over the HAL4RT and OpenEL claims until we clarify exactly the status of those documents/efforts.

A new version of the paper has been submitted to arXiv and should be available tomorrow. Thanks @gbiggs for the support.

Needless to say, HRIM will keep growing as we get more and more contributors, supporters and (hardware) devices captured in the model.