ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Reliability, safety, security, maintenance and support in ROS

In the last edition of Microniek there is an article (1.3 MB) with the title More than ROS on ROS and especially on the differences between the “ROS approach” and “existing robot manufacturers approach”. The article is written by Henk Kiela, professor in Mechatronics and Robotics. He raises some interesting points and gives advice for both ROS developers as “non-ROS developers”. I am very interested in your opinions on this article.


It is an interesting article.

The main takeaway for me is that ROS community prefer to go broad (the more, the better) whilst a typical robotic product need to do deeper.

In the specific context of mobile robot navigation, it is not surprising that some commercially available solutions are better, since they could focus full time on a single use case.

Additionally, I believe that ROS was designed from the ground up as a easy-to-learn framework for non experts; this is, at the same time, its biggest strength and weakness, since the openesses of the system also makes very hard to deal with safety.

About the comparison table: I do not agree with a few points and it feels a little bit biased, even if I agree on most of the items (80% maube?)
There is one in particular that I consider very interesting:

COST -> ROS (Weak)

Open source is ‘free’; the effort to make it a reliable and safe system is unpredictable.

This is unfortunately true; I have multiple examples of situations in which I could have been better served, in the long term, by an expensive COTS solution rather than the open-source “free” one.

I have been complaining a lot about the open source model and the issue of sustainability. I like open source software (hey, I have my own OSS projects!), but it is naive to expect that:

  1. The quality of an horizontal OSS software match the quality of a vertical and commercial one.
  2. That it is possible to create high quality software without a sustainable way to pay full-time, highly-skilled developers.

Thanks for sharing the article.




In my humble opinion, I do not agree with the focus of the article. I think you can not compare a final product of two companies with ROS, even if we limit it to their navigation capabilities. ROS provides a base where to build concrete applications, and it is the responsibility of the person who develops a final application to complete the generalities of ROS to adapt it to a final solution.

There are many robot companies that have robots navigating reliably and safely in real environments using ROS. We have a Pepper navigating 24x7 in a real office environment ( in which, of course, there was a lot of work of adjusting parameters.

Of course, this requires a lot of work to adjust parameters, but no more than those that would have to be adjusted in any other navigation system, with the advantage that in ROS there is a community that develops and tests software that you do not have to implement from scratch .

Anyway, thanks for sharing,


Thanks for sharing, it’s an interesting article.

I have to grudgingly agree with most of the points he makes. Right now it’s very difficult to integrate ROS safely in an industrial grade robot, having either to encapsulate the cell in a parallel, isolated safety system or making ROS act as a kind of supervisor, encapsulating more low level and safety critical systems.

I see the value of focusing ROS on scientific research and foregoing more mundane features such as these, but support from industrial manufacturers could really ensure the longevity of the project.

@Wilco great that you brought this up for discussion and thanks!

A few thoughts from my side: Henk summarized pretty nicely the relevance of ROS and some of the issues related to building robots from ground up. One must note that Prof. Kiela has several decades of experience in this area and a deep industrial insight. However, to the best of my knowledge, he’s not very actively involved in the ROS community (at least it didn’t feel that way last time we spoke!).

He presents ROS 2.0 as

a project was started recently, incorporating the new
requirement for mission-critical functionality and indeed safety

Arguably, some members of the community will object since ROS 2.0 started quite a few years ago (e.g. see Nevertheless, ROS 2.0 has indeed become official within the last year. Much has happened since though!

In addition and as pointed by @facontidavide, I disagree with several aspects exposed in the comparison made in table 1. E.g., ROS is indeed being used in safe environments and just recently, at ROS-Industrial Conference, a speaker shared quite a few details about their safe setup while using ROS (1) and how they did it (they followed an isolated safety system-approach making the ROS setup as a behavior coordinator, as mentioned by @GuillermoUrcera above).

Of course, this doesn’t mean they “certified ROS” (completely) and one should questions whether this makes sense at all. Selecting, however, individual ROS packages (or stacks) and adapting them for complying with a particular set of guidelines is something that several companies are already doing.

A store of ROS-certified modules could provide a similar
function to the user community. The certification should
provide minimum qualifications for the performance,
safety, security and maintainability of a module. Such a
scheme could be adopted for ROS 2.0 in the future, but this
should also be done right away for ROS Industrial.

I think it’s relevant to note here that by modules, Henk here refers to both software and/or hardware modules. Certification of such is an ongoing discussion and new standards like ISO 22166, hopefully, will provide some answers. A pre-requisite and one of the aspects required for modularity (and hardware reconfiguration) is interoperability. In the article, it’s claimed that “quality and ease of reconfiguration is not as good” in ROS. I also disagree with this. Furthermore, there exists new projects like HRIM that aim to facilitate interoperability by defining a common information model that generates artifacts in an MDE fashion (while offering a structure that allows for its extension in other robotic frameworks).

1 Like

I find this statement pretty interesting @fmrico and while I don’t fully disagree when it comes to “a final product” , I actually have a pretty strong opinion about the usefulness of ROS (ROS 2 in particular) to compare different individual components. Our team, often, finds that comparing two different pieces of hardware of the same kind (e.g. two cameras or two actuators aimed for a similar task) is actually pretty hard. Specially because things like communication interfaces and APIs differ substantially (which makes system integration a complete hell most of the time).

Our approach for the last years has been to “find common ground” to attack these comparisons. Typically, assuming you have component A (C_A) and component B (C_B) with their respective interfaces, let’s say I_A and I_B, to compare them. Often, you’d go ahead and create an abstraction layer on top of I_A and I_B called AL that allows you to speak to both components and effectively make the comparisons. This way, you can inspect which component C_A or C_B actually performs better for your needs.

To us, AL=ROS. I think this is one of the core principles of ROS and also, the reason why we selected it when we started building H-ROS years ago covering not only logical and electrical interfaces but a wide variety of aspects required to go from a component to a module (note that modules imply certain characteristics including interoperability).

Now, back to your statement, I believe it depends very much on the “final product” (assuming we’re speaking of robots, final robots) itself. E.g., we started a while defining models for a composite set of robot modules. While this is still a work in progress, we managed to interface with several 6DoF arms (model proposed) and that provided quite a bit of insight that we later used in the development of our latest robots so I’d argue that you can actually compare certain final products with ROS.

@fmrico I’m very interested to hear what’s your reaction to this since as I said, we’re still exploring this path and we certainly could use additional insight.


@vmayoral Is there a recording of this talk?

1 Like

there is an inofficial bootleg video of the talk … and there will be a publication of the talk via the official ROS-Industrial YouTube channel with dedicated playlists for each day of the conference … I will keep you posted…


I think @vmayoral means the talk from Georg Heppner and Fabian Fuerst (Flexible Automotive Assembly with Industrial Co-workers).


that was on Day 3, the playlist for Day 3 is not yet finished. Sorry, it looks like you will have to wait until January 2019…

@ThiloZimmermann That is great to hear. Thanks for making it available.

Hey there, happy new year.

As @Wilco said, it’s the talk about Flexible Assembly. AFAIK it’s not ready just yet. Let’s wait until @ThiloZimmermann and his colleagues publish it.

Would be happy to keep discussing it then.


1 Like

Here is the blog post on Day 3 of ROS-Industrial Conference 2018 in Stuttgart, Germany.

The talk on Flexible Automotive Assembly with Industrial Co-workers
by Fabian Fuerst, Opel, and Georg Heppner, FZI
can be watched on YouTube.