Herr Reiser, wo liegen die Ursprünge von ROS?
Das Robot Operating System, kurz ROS, hat seine Ursprünge an der Stanford University in den USA und wurde ab 2007 von einer Firma namens Willow Garage professionell als Software-Framework entwickelt. Die Zielsetzung bestand im Wesentlichen darin, wieder verwendbare Software für die Robotikforschung bereitzustellen und damit den Aufwand der Universitäten zu reduzieren. Zudem behinderte die immer wieder erneute Entwicklung von Basisfunktionalitäten für Robotersysteme den wissenschaftlichen Fortschritt enorm. Durch den Open-Source-Charakter von ROS waren innerhalb kürzester Zeit weltweit mehr als 3.000 Softwarepakete verfügbar.

Im März 2013 wurde in den USA die ROS-Industrial-Initiative ins Leben gerufen. Was gab den Ausschlag hierfür?
Die Qualität und Ausgereiftheit der einzelnen ROS-Komponenten ist naturgemäß sehr unterschiedlich. Die Bandbreite reicht von den professionell entwickelten Kernpaketen und sehr reifen, jahrelang entwickelten Software-Bibliotheken bis hin zur schnellen Proof-of-Concept-Implementierung einer Bachelor-Arbeit. Weiterhin standen bei der Entwicklung von ROS weder die Unterstützung von industriell eingesetzten Komponenten noch nicht-funktionale Eigenschaften wie Echtzeit-Fähigkeit, Zuverlässigkeit und Sicherheit im Fokus. Nicht zuletzt sind Unternehmen, die Open-Source-Software einsetzen wollen, auf zuverlässigen Support und langjährige Schnittstellen-Stabilität angewiesen.

Wesentliche Zielsetzung des Konsortiums ist es daher, die Anforderungen aus der Industrie in die ROS-Entwicklergemeinschaft zu tragen. Zudem entwickelt und pflegt es das ROS-Industrial-Software-Verzeichnis, das spezielle Treiber für Industriekomponenten und auf industrielle Anforderungen getestete ROS-Komponenten enthält, und gewährleistet dafür einen verbindlichen Support und professionelles Training.

Im Juni 2014 erfolgte das Kick-off des europäischen ROS-Konsortiums. Vor welchem Hintergrund?
Reiser: Bereits im Sommer 2012 erreichte uns vom ­texanischen Southwest Research Institute – dem Gründer des amerikanischen ROS-Industrial-Konsortiums – eine Einladung zur Teilnahme an der Initiative. In der Diskussion zur Gewinnung weiterer europäischer Mitglieder wurde schließlich die Idee ­geboren, ein europäisches Geschwisterkonsortium unter ­Leitung des Fraunhofer IPA zu gründen. Dies ermöglicht eine ­eigenständige Priorisierung der Entwicklungsziele auf der ­technischen Roadmap. So sind zum Beispiel die Themen ­Sicherheit, Zertifizierung und standardisierte Entwicklungsprozesse in Europa sehr viel mehr im Vordergrund als in den USA.

Welche konkreten Projekte verfolgt das Konsortium?
Zum einen werden in fokussierten technischen Projekten Lösungen für konkrete Problemstellungen erarbeitet, die ­mehrere Mitglieder gemeinsam haben, die aber nicht in deren Kernkompetenz liegen beziehungsweise keinen strategischen Wettbewerbsvorteil bedeuten. So führt beispielsweise Siemens ein Projekt für das Fräsen mit einem mobilen Roboter.

Zum anderen gibt es im europäischen Konsortium zusätzlich strategische Projekte, in denen anwendungsunabhängige Anforderungen der Industrie an ROS umgesetzt werden sollen. Bosch arbeitet etwa mit dem Fraunhofer IPA an einem Projekt für modellgetriebene Entwicklungswerkzeuge, die die Modellierung von Echtzeit-Anforderungen von ROS-Komponenten erlauben. Themen für weitere strategische Projekte sind unter anderem Windows-Unterstützung und Erweiterung des ROS-Industrial-Schnittstellenstandards für generische IO-Eingänge.

Inwiefern findet das Thema Unterstützung bei den Roboterherstellern – diese haben doch in der Regel eigene Tool-Plattformen?
Die Unterstützung der Roboterhersteller fällt sehr ­unterschiedlich aus. Einige – zum Beispiel Yaskawa oder Comau – sind von Beginn an sehr stark engagiert, da die Nachfrage für  ROS-Schnittstellen seitens der Anwender stetig zunimmt. Diese Her­steller sehen die Vorteile vor allem in der verbesserten Integrierbarkeit ihrer Komponenten. Andere haben noch Bedenken, mit der Unterstützung von ROS-Industrial ihre eigenen Ent­wicklungen von höherwertigen Schnittstellen und Funktionen zu torpedieren.