HRIM Introduction

HRIM, is a modular common interface for robot modules presented as a model. It is focused on hardware and, if adopted, facilitates interoperability among different vendors of robot hardware components. In other words, it's hardware oriented and defines a set of rules that each device has to meet in order to achieve interoperability.

An information model is typically understood as an abstraction and a representation of the entities in an environment including their properties, attributes and operations. An information model also describes the way those entities (modules in this particular case) relate to each other. An information model is typically independent of any specific repository, software usage, protocol, or platform. As such it can be used to define the semantics for the interactions between modules, making all of these interoperable.

Robot technologies have advanced exponentially in the last decade but integrators, robot developers and users keep facing the same big hurdle: the integration effort, in other words, the incompatibility between robot components.

The fact that robot manufacturers are using different interfaces hampers the communication between distinct components, between components and robots and even the interaction among robots and humans.

Typically, robot hardware needs to send or receive orders (or requests) to operate. A servomotor, for example, waits for movement orders. In a similar manner, a camera sends pictures in a specific format either proactively or from external requests. In robotics, the way this interaction is made, the content of it, does still lack a standard, leading to consequences such as, for example, the following:

  • Slowdown of the robot building process: Anyone wanting to innovate when building a robot may need to create new abstractions for any new hardware device used, since there is no standard nor component interface agreement in place.

  • Time and effort consuming programming process: As each component typically uses a different abstract interface for communication (for example, two cameras, from different manufacturers, most likely will send incompatible formats, even when being ROS compliant and supporting the ROS Image message) the programmer has to understand the hardware and may also have to adjust the rest of the software correspondingly.

  • Difficulties to compare components of the same type: Assuming the ROS communication paradigm, given the fact that most robot components of the same type (for example, two servo-motors) will produce or receive different and incompatible (from an interoperability perspective) abstractions, it becomes especially challenging to compare two components of the same type for a given task.

  • Lack of formal compliance and quality assurance processes: Current ROS and ROS-In initiatives impose no restrictions on how robot components (mostly hardware although it also applies to software) use the de facto messages for a given type which leads to an heterogeneous landscape of non-interoperable devices that should perform similar tasks. There is no joint agreement among manufacturers.

  • Impossibility to exchange and replace components seamlessly: Even when two components speak the same language –in ROS terminology, use ROS messages, services, etc.– the dialect is different. In other words, the selection of the ROS abstractions (msgs, srvs, etc.) for a given robot component (e.g. a rangefinder) is commonly different leading to hardware components that do not interoperate. Thereby, even though the components might be meant to execute the exact same function (e.g. measure distance using a laser), such components won’t be exchangeable. Not without a modification of the underlying software infrastructure.

For all these reasons, robot component manufacturers are in the need of a shared set of principles to follow when designing the interfaces of their hardware devices. With HRIM we propose a modular common interface focused on hardware which if adopted, facilitates interoperability among different vendors of robot hardware components.

The interoperability and the reuse of software in robotics is a common topic that several groups have worked on. According to literature, making use of Model Driven Engineering (MDE) techniques, it is possible to describe software development approaches in which abstract models of software systems are created and systematically transformed to concrete implementations. Basically a set of transformations between models, meta-models to models, etc. The following figure describes this process:

MDE approach

The figure above provides insight about the flow that MDE techniques follow when designing an application. Initially, a meta-model makes statements about what can be expressed in the context of a certain modelling language. These statements are then translated to a Platform Independent Model (PIM), which is a representation of a reality intended for some purpose. Independence comes from the fact that the generated models are still abstract and not specific to any platform itself. Platform Specific Models (PSMs) provide insight about representations for an specific platform, for example, for the ROS platform. Having defined a platform, PSMs are then translated to Platform Specific Implementations (PSIs). In the context of ROS, these PSIs would be the “.msg”, “.srv” or “.action” files that capture the original application.

Several groups have studied a unified way of representing knowledge and provided a common set of terms and definitions to facilitate interoperability in the robotics domain, using models. They are mentionable: RobMoSys, The Robot Technology Component (RTC), ReApp and SmartSoft.

From this analysis we can conclude that:

  • None of the previously developed projects have a clear hardware focus.
  • Most of them are focused on reusing code for applications, defining how the models have to be designed and the methodology to implement correctly MDE techniques. To the best of our knowledge, very few of them touch into the topic of hardware quality assurance or compliance with regard defined models.
  • Previous work has mainly been executed as research actions and no clear market impact can be deduced from existing results.

HRIM MDE approach

HRIM was created to fulfill the needs identified by our team while working in modular robot components as part of the H-ROS effort. Because of this, HRIM originally focused on defining Platform Specific Implementations for the ROS middleware through conversations with manufacturers. We worked on this implementation taking into account the modularity guidelines defined in the (still in development) International Organization for Standardization. Robotics — Modularity for service robots — Part 1: General requirements (ISO Standard No. 22166).

Parting from that ROS 2 implementation we developed the current models and tooling. We decided on XML for a machine-readable way of representing the models because of it being extremely widespread and supporting our needs. The python tool and its interface allows for a way to compose the existing models into a user-specific "schema" that can then get compiled into a platform specific implementation, for example ROS 2's .msg and .srv files. For more information on this refer to the Information Model section.

Our main objective is to simplify the process of building robots. Particularly, with the Hardware Robot Information Model (HRIM), we focus on manufacturers and aim to facilitate a common interface to create interoperable robot hardware components which will lead to a plug-and-play scenario of robot devices.

Nowadays, industrial robots lack of flexibility. The robot industry is configured in a vertical structure, single vendors develop the final product leading to slow development progress, expensive products and customer lock-in. Our vision is that, opposite to this, horizontal integration would result in a rapid development of cost effective mass-market products with an additional consumer empowerment. HRIM is proposed as a tool to facilitate this transition from the current vertical structure and towards an horizontal one, as it happen in other areas in the past.

In summary, HRIM tackles the incompatibility between robot devices that hinders the reconfigurability and flexibility demanded by the robotics industry.

A few milestones of the project so far:

  • HRIM is hardware oriented and has been built in collaboration with robot hardware manufacturers. HRIM is already being adopted and reused in projects such as SeRoNet in Germany and considered as a key element of inspiration in ongoing standards like ISO/CD 22166-1 and other norms within the ISO Technical Committee 299, dedicated to Robotics.
  • Although HRIM has conceptually been designed to support other robot middlewares in the future, its development is centered around ROS 2.0.

  • Make HRIM a formal common interface (involving models and meta-models) for robot components with a clear, hardware perspective and implemented for the Robot Operating System 2 (ROS 2.0).
  • Such interface will be designed in collaboration with a) manufacturers, b) researchers c) integrators and d) end-users.
  • Provide means for Quality Assurance (QA) and compliance.
  • Steer HRIM towards existing standardization initiatives. In particular, within ISO and OMG organizations.
  • Favor the adoption of a common datasheet-like specifications document for robot components.
  • Use MDE approach where the meta-model will produce for each component type, a robot component model (the models), that could later be translated to the specific ROS ecosystem through the corresponding messages, services, etc. (implementation).
  • Make HRIM a common interface for building any robot, for that we have taking into account all module types that make up a robot.
  • Create a relevant and simple guide which details the interface that each module have to contain.
  • Build it as modular as possible to be used by the majority of devices: Instead of creating heavy and large messages with which you can control many things, they are designed to perform specific actions.
  • Analyze all types of devices, from the most basic to the most complicated in order to reach the majority of the robot modules.
  • Dynamic platform that changes as the technology advances.

The best way to create a common interface is to build it collaboratively. For us it is very important to count with the opinion of the ROS community (considering that the first iteration of the information model is written using ROS messages syntax), robotics experts (the information model being an implementation for different middlewares) and device manufacturers (since they are the ones who know the most about all the characteristics and the possibilities of each component), among others (all constructive opinions are welcome).

The more collaborative the more solid will the information model be, and more useful for all who want to benefit from the work done. That is why we wanted to share it in it's state of development. From our side, we will continue adding more components (giving priority to the most used in robotics), while improving the existing with received feedback.

HRIM was created through a need found during the development of H-ROS, where the need of reusability and interoperability in robotics is solved by plug-and-play hardware components. For that, a common communication between components is needed. So, HRIM is the part in charge of providing a common interface.

However we wanted to make HRIM an independent standard interface for robot modules which contains rules/specifications that standardize interactions between different robot components. This way, we apport a solution that everyone can benefit from to the robotics community, instead of spending resources for its development.

H-ROS, the Hardware Robot Operating System, delivers a solution for companies manufacturing sensors, actuators etc. to create modular robot components that interoperate and can be easily reused; even from different manufacturers, you would only have to connect them together. With H-ROS you can create plug and play devices simplifying the robot building process.

Nowadays the incompatibility in terms of communication between components is one of the biggest problem in robotics. An expert is required to spend almost over 70% of the total robot-building process working to achieve communication between components. H-ROS eliminates this problem thanks to all its infrastructure, and the information model is part of it, "standardizing" the content that all the modules must include to be sure that all of them speak the same language at all levels.

H-ROS is an infrastructure that works on top of ROS 2, which has lead us to create an Information Model which standarized modules using ROS messages syntax. But we want to do it more generic, adapting the information model for different implementations. That is to say, the information model is created specifically for H-ROS, but we are taking care of making it as modular as possible, so that many can take advantage of it.

The information model will solve one of the biggest problem of robotics: the incompatibility in terms of communication between components. It's focused on creating common software content that each device has to contain to enable interoperability. As mentioned before, H-ROS uses ROS 2 infrastructure, that is why we have worked focused on it.