Vereinfachte AMR- und AGV-Integration mit ROS-2-Komponenten

Autonome mobile Roboter (AMRs) und fahrerlose Transportsysteme (AGVs) erfordern eine enge Koordinierung mehrerer Teilsysteme, darunter Sensoren, Motoren, Navigation und auf künstlicher Intelligenz (KI) basierende Entscheidungen. Die Integration all dieser Teilsysteme ist eine Herausforderung für die Entwickler.

Das Robot Operating System (ROS) bietet einen Weg durch diese Komplexität. ROS ist eine Open-Source-Robotik-Middleware, die standardisierte Kommunikationsrahmen und ein großes Ökosystem wiederverwendbarer Pakete bietet. Durch die Auswahl von Komponenten mit nativer ROS-Unterstützung können Entwickler vorgefertigte Hardwaremodule mit softwareadressierbarer Funktionalität verwenden, was die Einführungszeit verkürzt und die Interoperabilität verbessert.

Dieser Artikel gibt einen kurzen Überblick über die Herausforderungen, mit denen Entwickler von AMRs und AGVs konfrontiert sind und wie ROS dabei helfen kann. Anschließend wird ROS-kompatible Hardware von Analog Devices (ADI) vorgestellt, darunter Motorsteuerungen, Trägheitsmesseinheiten (IMUs) und Laufzeitsensoren (ToF), und es wird erläutert, wie diese Komponenten in den ROS-Software-Stack integriert werden, um die Produktentwicklung zu beschleunigen.

Die Herausforderung der Integration von AMRs und AGVs

Die Integrationsarbeit kann den frühen Zeitplan eines AMR- oder AGV-Konzepts dominieren. Auf der Hardwareebene müssen die Teams Komponenten auswählen, Schnittstellen entwerfen und die Signalintegrität und das Timing validieren. Auf der Softwareebene müssen sie Treiber laden, Datenflüsse definieren und sicherstellen, dass sich das System unter realen Bedingungen vorhersehbar verhält.

Talentierte Teams können diese Ziele mit eigenen Entwürfen erreichen, aber das bedeutet oft, dass sie bereits verfügbare Standardfunktionen neu entwickeln müssen. Dieser Aufwand kann schwer zu rechtfertigen sein, vor allem wenn herkömmliche Ansätze die Teams an proprietäre Schnittstellen binden können. Wenn sich die Anforderungen ändern, kann der Austausch einer Komponente die Überarbeitung wesentlicher Teile des Software-Stacks erforderlich machen.

Wie ROS die Herausforderungen der Integration angeht

ROS wurde geschaffen, um diese Probleme zu lösen. Trotz seines Namens ist ROS kein Betriebssystem im klassischen Sinne. Stattdessen handelt es sich um ein Open-Source-Framework, das eine breite Palette von Tools, Bibliotheken und Konventionen bietet.

Das Schlüsselkonzept von ROS ist die Strukturierung komplexer Robotikanwendungen in modulare Knotenpunkte (Abbildung 1). Diese mundgerechten Prozesse führen bestimmte Aufgaben aus, z. B. das Lesen von Sensordaten oder die Steuerung der Motordrehzahl.

Abbildung 1: Zu den grundlegenden Bausteinen von ROS gehören Pakete, Knoten, Nachrichten und Dienste. (Bildquelle: Analog Devices, geändert von Kenton Williston)

Die Kommunikation zwischen den Knoten erfolgt über zwei Hauptmechanismen:

• Topics: Ein Publisher-Subscriber-Modell, das sich für kontinuierliche Datenströme, wie z. B. Sensor-Feeds, eignet
• Services: Ein Anfrage-Antwort-Modell, am besten geeignet für seltene Aktionen wie Gerätekonfiguration und Initialisierung

Mehrere Knoten und ihre Abhängigkeiten (einschließlich zugehöriger Topics und Services) können zu einem Paket zusammengefasst werden, um eine umfassendere Funktionalität zu bieten. Analog Devices hat zum Beispiel ROS-Treiberpakete für seine Sensor- und Aktuatormodule für AGVs und AMRs entwickelt. Diese Pakete kapseln die Knoten, Nachrichten-Definitionen und Konfigurationsdateien, die für die Integration der Hardware in ein ROS-basiertes System benötigt werden.

Wie ROS die AMR- und AGV-Konstruktion optimiert

Diese modulare Architektur ermöglicht Interoperabilität und beschleunigt die Entwicklung. Auf der Hardware-Ebene bietet ROS standardisierte Schnittstellen für Komponenten wie Kameras und Motorsteuerungen. Dies beschleunigt die Integration und befreit die Designer von Herstellerbindung und Lizenzgebühren.

Auf der Softwareebene bietet ROS Tools und Middleware, die den Entwicklern helfen, komplexe Roboter zu entwickeln, zu testen, einzusetzen und zu warten. Die aktuelle Version des Frameworks, ROS 2, bietet Funktionen, die besonders für AMRs und AGVs nützlich sind. Dazu gehören:

• Das Nav2-Navigationspaket, das Verhaltensbäume, Sperrzonen, Geschwindigkeitsbegrenzungen und mehr unterstützt
• Ausgefeilte Positionierungsalgorithmen, einschließlich Tools für Kartierung und Ortung, die es AMRs und AGVs ermöglichen, ihre Umgebung zu verstehen
• Integration mit Simulations-, Visualisierungs- und Protokollierungstools, die sowohl die Entwicklung als auch die Diagnose unterstützen

ROS 2 läuft normalerweise auf einem Linux-basierten Computer, obwohl auch andere Betriebssysteme unterstützt werden. ROS 2 unterstützt auch micro-ROS, eine Variante, die nativ auf Mikrocontrollereinheiten (MCUs) mit Echtzeitbetriebssystemen (RTOSs) wie Zephyr und FreeRTOS läuft.

Motorsteuerung mit ROS-2-Integration

Um das Potenzial von ROS 2 zu veranschaulichen, betrachten wir die Komplexität der Antriebssteuerung. Die meisten AMRs und AGVs verwenden einen Differentialantrieb, bei dem zwei unabhängig voneinander gesteuerte Radsätze sowohl die Vorwärtsbewegung als auch das Wenden ermöglichen. Diese Architektur erfordert eine Motorsteuerung, die in der Lage ist, beide Räder gleichzeitig anzutreiben und gleichzeitig koordinierte Befehle des Navigationssystems zu akzeptieren.

Der TMCM-2611-AGV von ADI (Abbildung 2) geht direkt auf diesen Bedarf ein. Als Teil der Familie TMCM (Trinamic Motor Controller Module) ist dieses Board eine Zwei-Achsen-Servoantriebsplattform für dreiphasige bürstenlose Gleichstrommotoren (BLDC), die für AGV- und AMR-Traktionsanwendungen entwickelt wurde. Jede Achse kann Motoren mit bis zu 14 Ampere (A) effektiv bei 48 Volt antreiben, mit Positionsrückmeldung über inkrementale Quadratur-Encoder oder digitale Hall-Effekt-Sensoren.

Abbildung 2: Der TMCM-2611-AGV ist ein zweiachsiger Controller/Treiber für dreiphasige BLDC-Motoren. (Bildquelle: Analog Devices)

Der ROS-2-Treiber adi_tmcl verbindet diese Hardware mit dem ROS-2-Ökosystem hauptsächlich über Topics (Abbildung 3). Ein Navigations-Stack kann beispielsweise Geschwindigkeitsbefehle für jeden Satz von Rädern über die Topics /cmd_vel_X veröffentlichen. Der Treiber adi_tmcl abonniert diese Topics, übersetzt die Befehle in TMCL-Frames (Trinamic Motion Control Language) und sendet sie über den CAN-Bus über die Linux-eigene SocketCAN-Schnittstelle.

Abbildung 3: Das TMCL-ROS2-Treiberpaket enthält eine Reihe robuster Schnittstellen. (Bildquelle: Analog Devices)

In der anderen Richtung veröffentlicht der Treiber adi_tmcl das Motorfeedback in den Topics /tmc_info_X, die Informationen zu Geschwindigkeit, Position, Drehmoment und Status liefern. Andere Knoten können diese Daten für die Odometrieberechnung, die Diagnose oder die Regelung auf Anwendungsebene abonnieren.

Dieser bidirektionale Fluss veranschaulicht, wie ROS 2 den modularen Aufbau von Systemen ermöglicht. Der Navigationsalgorithmus muss nichts über TMCL oder CAN-Bus wissen; er veröffentlicht einfach Standard-Geschwindigkeitsnachrichten und erhält Rückmeldungen.

Der Treiber adi_tmcl verwendet auch Services für Aufgaben wie Initialisierung und Parameterzugriff. Zum Beispiel ruft /tmcl_gap_all alle Achsenparameterwerte und /tmcl_ggp_all alle globalen Parameterwerte für das Controller-Board ab.

Trägheitsmessung zur Positionsbestimmung

Obwohl Raddrehgeber es einem System ermöglichen, die Position auf der Grundlage des Radwegs abzuschätzen, ist die Rad-Odometrie allein oft nicht ausreichend für eine genaue Positionsbestimmung. Radschlupf und unebene Oberflächen können im Laufe der Zeit erhebliche Fehler verursachen. Dies ist vor allem in den vielen Innenräumen problematisch, wo GPS-Signale unzuverlässig sind und keine kontinuierlichen Korrekturen liefern können.

IMUs bieten eine unabhängige Bewegungsreferenz, die AMRs und AGVs nutzen können, um die Dead-Reckoning-Genauigkeit zu verbessern. Ein Paradebeispiel ist die Familie ADIS16500/05/07, die über triaxiale Gyroskope und triaxiale Beschleunigungssensoren sechs Freiheitsgrade an Präzisions-Trägheitssensoren in einem 15 × 15 × 5 Millimeter (mm) großen BGA-Gehäuse bietet. Die werkseitige Kalibrierung charakterisiert jeden Sensor hinsichtlich Empfindlichkeit, Vorspannung, Ausrichtung und Temperaturkompensation und reduziert so den Integrationsaufwand für Systementwickler.

Ein repräsentatives Beispiel ist der ADIS16500AMLZ (Abbildung 4). Dieses Bauteil hat einen Kreiselbereich von ±2000° pro Sekunde (˚/s), eine Kreiselvorspannungsstabilität von 8,1° pro Stunde (˚/hr) und eine zufällige Winkeländerung von 0,29° pro Wurzel-Stunde (°/√hr). Diese Spezifikationen tragen dazu bei, die Drift im Laufe der Zeit zu verringern und die Dead-Reckoning-Performance zwischen externen Korrekturen zu verbessern.

Abbildung 4: Der ADIS16500AMLZ ist einr präzise MEMS-Trägheitsmesseinheit in einem kompakten BGA-Gehäuse. (Bildquelle: Analog Devices)

Für die ROS-2-Integration wird die Familie ADIS16500/05/07 durch den Treiber imu_ros2 unterstützt. Der Treiber nutzt das „Linux Industrial I/O“-Subsystem über LibIIO. Seine Ausgabe ist kompatibel mit gängigen ROS-2-Sensorfusionspaketen wie robot_localization, die erweiterte Kalman-Filter zur Kombination von IMU- und Odometriedaten einsetzen.

Entwickler, die mit der Trägheitsmesseinheit experimentieren möchten, können mit dem Evaluierungsboard ADIS16500/PCBZ beginnen (Abbildung 5). Diese Karte stellt die SPI-Schnittstelle der Trägheitsmesseinheit über eine 16-polige Stiftleiste zur Verfügung, die mit Standard-Flachbandkabeln mit 2 mm Abstand kompatibel ist.

Abbildung 5: Das Evaluierungsboard ADIS16500/PCBZ stellt die SPI-Schnittstelle über eine 16-polige Stiftleiste zur Verfügung. (Bildquelle: Analog Devices)

Tiefenabtastung zur Hinderniserkennung

Die Hinderniserkennung ist eine weitere Standardfunktion von AMR/AGV. LiDAR eignet sich zwar hervorragend für die Erkennung von Hindernissen in größeren Entfernungen, doch viele Anwendungen erfordern auch eine Nahfelderfassung, um tief liegende Hindernisse, Bodenunterbrechungen oder Objekte, die außerhalb der LiDAR-Scanebene liegen, zu erkennen. ToF-Tiefenkameras schließen diese Lücke, indem sie dichte Tiefenbilder über ein breites Sichtfeld liefern.

Das ToF-Modul ADTF3175BMLZ (Abbildung 6) eignet sich hervorragend für diese Anforderungen. Durch die Kombination eines CMOS-Tiefensensors mit einer Beleuchtungsoptik erfasst das Modul Tiefenbilder und Bilder mit aktiver Helligkeit (AB) mit einer Auflösung von bis zu 1024 × 1024 und einem Sichtfeld von 75˚ × 75°. Dank dieser Kombination aus Auflösung und Reichweite eignet sich das System hervorragend für die Überwachung von Sicherheitszonen und die Bodenerkennung in Lager- und Produktionsumgebungen, in denen Hindernisse in unterschiedlichen Höhen auftreten können.

Abbildung 6: Das ToF-Modul ADTF3175BMLZ integriert einen CMOS-Tiefensensor mit Beleuchtungsoptik. (Bildquelle: Analog Devices)

Der Treiber adi_3dtof_adtf31xx erleichtert den Zugriff auf die Kameradaten, indem er Tiefen- und AB-Frames in den Standard-ROS-2-Nachrichtenformaten veröffentlicht. Diese Ausgänge lassen sich direkt in gängige Wahrnehmungspakete für Aufgaben wie die Erstellung von Punktwolken, die Bodenerkennung und die Überwachung von Sicherheitsblasen integrieren. Der Treiber unterstützt auch einen Dateiwiedergabemodus, der die Entwicklung und das Testen von Algorithmen ohne eine physische Hardwareverbindung ermöglicht.

Für die Entwicklung und das Prototyping bietet das Kit EVAL-ADTF3175D-NXZ (Abbildung 7) eine komplette Sensorplattform. Das bemerkenswerteste Merkmal des Kits ist ein Arm®-basiertes Board, auf dem Linux läuft und das direkt den ROS-2-Knoten hosten kann. Alternativ kann der Sensor Tiefendaten über Ethernet an einen separaten ROS-2-Host übertragen, was Flexibilität für unterschiedliche Systemarchitekturen bietet.

Abbildung 7: Das Evaluierungskit EVAL-ADTF3175D-NXZ enthält einen Arm-basierten Linux-Host. (Bildquelle: Analog Devices)

Die Referenzplattform Autonomous Mobot (ADAM) von Analog Devices zeigt, wie diese ROS-kompatiblen Komponenten mit zusätzlichen Lösungen für Batteriemanagement, Energieumwandlung und Kommunikation zu einem kompletten AMR-System integriert werden können.

Fazit

Die Komplexität von AMR- und AGV-Konstruktion und -Entwicklung kann durch die Auswahl von ROS-kompatiblen Komponenten erheblich reduziert werden. Die Verwendung einer bewährten Komponentenquelle wie ADI, die ROS-2-Treiber für eine breite Palette von Sensoren und Aktoren bereitstellt, kann ein wertvoller Partner sein.