Der Markt für autonome mobile Roboter – kurz AMR – boomt. Im Jahr 2020 bezifferte sich die Marktgröße auf 356 Mio. US-Dollar – und MarketWatch prognostiziert bis 2026 ein Wachstum auf 1011 Mio. US-Dollar bei einer durchschnittlichen jährlichen Wachstumsrate (CAGR) von 15,9 %.

Bis vor kurzem waren FTF mit ihren Fähigkeiten, Rohstoffe und unfertige sowie fertige Erzeugnisse zu Produktionslinien zu transportieren oder Waren in Lagerhallen und Logistikzentren zu lagern und dort zu entnehmen, die Vertreter neuester Technologie. FTF nutzen eine Kombination aus Software und sensorbasierten Leitsystemen zur Steuerung ihrer Bewegungen. Sie verrichten sichere und zuverlässige Arbeit bei der Bewegung von Lasten, da sie auf einer fixen Trasse arbeiten und über eine präzise gesteuerte Beschleunigung und Verlangsamung sowie eine Hinderniserkennung verfügen.

Allerdings mangelt es FTF an Flexibilität. Ändert sich beispielsweise das Layout einer Produktionslinie, muss die Spurführung entsprechend angepasst werden, was in der Regel mit Zeit- und Kostenaufwand verbunden ist. Erkennt ein FTF ein Hindernis, stoppt es, bis jemand den Gegenstand entfernt. Darüber hinaus können FTF nicht mit Menschen interagieren, da das Flottenmanagementsystem zentralisiert ist und ohne Peer-to-Peer-Kommunikation arbeitet.

AMR sind weitaus flexibler: Ändert sich ein Betriebslayout, ermöglicht die simultane Lokalisierung und Kartierung (SLAM) dem Roboter, den noch unbekannten Raum zu erkunden, um ohne zusätzlichen Aufwand oder Kosten für den Unternehmer automatisch eine Karte zu erstellen. AMR nutzen eine Reihe von Sensortechnologien sowie eine Kombination aus Kamera-Erkennung und Echtzeit-Kommunikationstechnologien, um Hindernisse einschließlich Personen dynamisch zu erkennen und zu vermeiden.

Eine neue Richtung

Das Robotic Operating System (ROS) ist ein Open-Source-Framework für die Entwicklung von Robotersoftware, also weder Roboter noch Betriebssystem. ROS wurde 2007 von den beiden Stanford-Doktoranden Eric Berger und Keenan Wyrobek mit dem Ziel entwickelt, Software-Entwicklern mit minimalen Kenntnissen über Robotik-Hardware zu ermöglichen, Software für Roboter zu schreiben.

Heute bietet ROS Classic (ROS 1) zahlreiche stabile Pakete, Tools und Tutorials, die die Hardware für die Entwicklung verschiedener Roboteranwendungen einschließen. ROS-Bausteine umfassen Sensorfusion, Navigation, Visualisierung und Bewegungsplanung.

Ursprünglich für den akademischen Einsatz entwickelt, setzt ROS 1 eine perfekte Kommunikation voraus. In der Praxis ist diese jedoch alles andere als perfekt, insbesondere im Industriesektor. Variable Faktoren wie Bandbreite, Vernetzungsmöglichkeiten, Kommunikationsreichweiten sowie der Transceiver-Stromverbrauch akkubetriebener mobiler Roboter erschweren zusätzlich optimale Lösungen. Darüber hinaus war ROS 1 nur für den Einsatz mit einem einzigen Roboter vorgesehen. Um die Funktionsweise von Fabriken mit mehreren Robotern intelligenter zu machen, sind Fähigkeiten der Zusammenarbeit gefragt. Hier kommt ROS 2 ins Spiel, das basierend auf dem DDS-Kommunikations-Framework das Flottenmanagementsystem dezentralisiert, indem es AMR die Echtzeit-Peer-to-Peer-Kommunikation – die sogenannte Schwarmautonomie – ermöglicht.

Die Migration von ROS 1 zu ROS 2 ermöglicht Schwarmrobotik-Autonomie.

© Adlink

Ein Schwarm autonomer mobiler Roboter kann seine Aufgaben mit wenig oder gänzlich ohne Aufsicht durch menschliche Bedienpersonen ausführen. Die Branche wird jedoch zur Realisierung dieses Ziels von ROS 1 zu ROS 2 wechseln müssen. Diese Migration ist eine Herausforderung.

Für Entwickler, die bereits ROS 1 verwenden, gibt es drei prinzipielle Herausforderungen: Komplexität, Skalierbarkeit und Upgrade-Fähigkeit. Das AMR-Design ist komplex. Für den Bau eines Robotiksystems müssen Anwender von Computerplattformen bis zu Sensoren, Bewegungssteuerungen und mechanischem Design die Hardware auswählen und kaufen sowie die Software (das Betriebssystem (OS), Treiber und Pakete) installieren. Sind sie mit einem System nicht vertraut, kann es bis zu einem Monat dauern, bis die Systemintegration abgeschlossen ist. Sind erweiterte Funktionalitäten wie Echtzeitfähigkeit oder dedizierte Quality of Service (QoS) gefragt, muss der Entwickler den Code selbst verfassen. Wird ein Roboter als Machbarkeitsstudie gebaut, stellen die Themen Skalierbarkeit und Bereitstellung größere Probleme dar.

ROS 1 dient vom Konzept her nicht der Kommunikation über mehrere AMR hinweg. In solchen Fällen bestünde das Risiko von Genauigkeitsproblemen, Ausfällen oder Schäden am Flottensystem. Zudem erreicht die ROS 1-Unterstützung bis 2025 das Ende des Lebenszyklus (EOL); betroffene Unternehmen müssen entscheiden, wie sie die Migration von ROS 1 auf ROS 2 bewerkstelligen wollen.

ROS 2 ist das Update, das ROS 1 aus der akademischen Welt in den industriellen Bereich überführt. ROS 2 ermöglicht den industriellen Einsatz mit mehreren zur Zusammenarbeit fähigen Robotern und einer zuverlässigen, fehlertoleranten Echtzeitkommunikation. Mit DDS als Backbone bietet ROS 2 eine einheitliche Datenaustausch-Umgebung (wie zum Beispiel einen Datenfluss), die einem AMR-Schwarm die Kommunikation ermöglicht. Auch zusätzliche Geräte mit Distributed-Data-Service (DDS) -Technologie können den Datenfluss zum gemeinsamen Datenaustausch nutzen.

DDS ist eine Schlüsselkomponente von ROS 2. Kern der Technologie ist der Data-Centric Publish-Subscribe (DCPS) -Standard, der einen globalen Datenraum bereitstellt, auf den alle unabhängigen Anwendungen zugreifen können. Die United States Navy nutzte ROS 2, um die im Zuge umfangreicher Software-Upgrades entstehenden Kompatibilitätsprobleme in der komplexen Netzwerkumgebung von Schiffen zu lösen. Seit der Veröffentlichung durch die Object Management Group (OMG) im Jahr 2004 hat sich DDS als Standardlösung für das Data-Publish-Subscribe-Pattern für die verteilte Echtzeitkommunikation in autonomen und anspruchsvollen Systemen weit verbreitet.

Die passende AMR-Lösung

Bei der Suche nach der richtigen ROS 2-basierten AMR-Lösung gibt es mehrere Aspekte zu berücksichtigen.

Unternehmen müssen erst ermitteln, ob die Systeme für eine AMR-Navigation optimiert sind, inkl. der Hard- und Software-Integration, um zeitraubende Abhängigkeiten, Versionsprobleme und Kompilierungsfehler zu vermeiden.

 Um eine hohe Genauigkeit bei der Sensorfusion zu erreichen, ist die Zeitsynchronisation von mehreren integrierten Sensoren, zum Beispiel GMSL-Bildern (Gigabit Multimedia Serial Link) und Inertial Measurement Unit (IMU) unerlässlich.

 Damit die interne Datenverarbeitung optimiert werden kann, sollte das System über einen Shared-Memory-Mechanismus verfügen. Bei herkömmlichen Implementierungen müssen Prozesse im System Nachrichten über die Netzwerkebene des Betriebssystems weiterleiten, was zu Latenzen führt. Der Zugriff auf gemeinsam genutzte Speicher und eine direkte Übertragung stellen optimierte Ansätze dar, die Latenzen erheblich verringern.

Die erarbeitete Lösung sollte eine dezentrale Kommunikation ermöglichen, die Autonomie des Schwarms unterstützen und gleichzeitig Fehlertoleranz und Redundanz gewährleisten.