ROS Enterprise meeting at ROSCon

[David Vickers]

ROS Enterprise meeting at ROSCon:

We had a BOF meeting at ROSCon for Enterprise ROS. It was reasonably
well attended, if a little chaotic (since it coincided and was co-
located with the reception). The following are my remembrances/
reflections on the discussion. Additions and corrections from others
are welcome, as well as feedback and additional discussion. If we need
to break this down into more discussions we can.

There is definitely beginning to be a desire for a path from research
based on ROS to a “Product” or a “Deliverable” that has some level of
assurance that it can be used in a critical environment. Some of the
applications people were involved in include: Semi-autonomous
wheelchairs, autonomous vehicles, and robots operating side-by-side
with humans.

There seem to be a couple of possible paths: 1. Do the “research” in
ROS, but either do the critical portion in another RTOS or migrate to
some other RTOS for the critical portions of the code. 2. Do some work
on portions of ROS to make it more feasible to use ROS as the basis of
critical software.

For the other RTOS, there were a couple of possibilities mentioned.
OROCOS was mentioned both as a lower level RTOS used in systems using
ROS at higher levels and as the possible “safer”, more robust basis
for operation of the safety-critical portion of the code. More
standard RTOSs traditionally used in safety-critical/related areas
include VsWorks. The biggest issue with transitioning to a different
RTOS for “productizing” something is the loss of the good development
environment offered by the ROS environment. That loss will be
especially difficult to deal with if many of the higher level
functions end up being defined as safety/security related.

There also seems to be a fairly wide spectrum of “rules” that might
need to be satisfied for various areas. The US agencies that might
need to be satisfied include the FDA, the DoD and others. There are
agencies in other governments as well. There are also international
standards such as IEC 61508 and derivative standards for specific
areas. Some of the oversight or procuring agencies will have stringent
less rules and therefore require less effort than others. However, for
many of the standards, the level of effort required for a specific
product to be certified for use in a safety-critical/related area are
significant. The level of effort for certifying a different product,
even one with minimal changes is also significant. While there may be
some re-use in the effort required to certify a product, there will
still be significant effort to analyze the possible impact of the
change, even if the change is relatively minor.

There did seem to be a desire for some effort to be expended as a part
of ROS maintenance to decrease the project-specific effort required to
use ROS-based systems in safety-critical/related areas. Some of the
possible efforts we talked about included the essential core
functionality of ROS (messaging for sure, others like services and
Master functionality would be likely candidates). Two D navigation was
mentioned. I would expect that tf might be another candidate. There
have been discussions about dealing with security in ROS, but it is
possible that for many cases an argument can be made that there will
be no external access to ROS functionality of the “product”. However,
if there is external access, especially, plug-in hardware access, the
security of the messaging system and the services would need to be
dealt with to be able to use ROS. Precisely what we would focus on, in
terms of such an effort is still unclear.

The idea of a long-term-support (LTS) version definitely seems to have
merit since whatever safety arguments are made for a specific version
would seem to be much more re-usable if they are applied to other
products using the same version. It could be that an LTS version would
need to be the basis for whatever else we do. I think we would need to
address whether that version would be Fuerte, Groovy or something
later. Fuerte exists and we could start with it, but if we do anything
to ROS to try to make the safety arguments easier to write, they
couldn’t be in an earlier version than Groovy. If we are doing very
much, it could be hard to make a Groovy version.

We talked some about funding. Some of us will look into some
possibilities, but if anyone else has any ideas, let us know.

[Joe Tojek]

There are many important but difficult issues around this topic. I would like to ask if anyone is aware of this effort moving forward outside of this group? 

In the Education SIG we discussed leveraging a ROS Enterprise image as the Education image used to create boot-able USB keys for lab use.

As we are shooting for Groovy, do you think that ROS Enterprise will be working towards Groovy as well, or targeting a post-Groovy release?

[Shaun Edwards]

Joe,

I cannot speak to the timeline for ROS Enterprise, but I think I Heart Engineering may have a solution for you ( http://store.iheartengineering.com/Software-Robots/b/4601921011?ie=UTF8&title=Software ).  They have several options for installing ROS.  They are also developing some GUI like executables for some of the command line tools (like rosbag, rostopic, etc...).  I bet if you spoke to them, they might create a product that you could buy.

Shaun