Willkommen zum neunten und letzten Blog unserer AMR-Navigations-Spotlight-Reihe, in der wir unseren Prototyp eines Steuerungssystems vorstellen werden. Klicken Sie hier um den vorherigen Blog dieser Serie zu lesen, in dem es um Entscheidungsfindung und Sicherheit geht.
Wenn Sie alle Spotlight-Blogs in dieser Reihe gelesen haben, dann möchten wir Ihnen zunächst einmal danken. Wir hoffen, dass Sie sie nützlich fanden und es Ihnen Spaß gemacht hat, sie zu lesen. Im Laufe der Serie haben wir so ziemlich jeden Aspekt der Navigation und Lokalisierung autonomer mobiler Roboter behandelt. In diesem Blog schließen wir die Serie ab, indem wir einen genaueren Blick auf unseren eigenen AMR-Prototyp werfen.
Warum haben wir unser eigenes AMR-Prototyp-Kontrollsystem entwickelt?
Wie Sie vielleicht schon bemerkt haben, ist OxTS nicht in erster Linie ein Unternehmen, das Roboter baut. Wir sind ein Unternehmen für Trägheitsnavigation, das sich auf die Herstellung von gnss-gestützten Trägheitsnavigationssystemen (INS) für eine breite Palette von Anwendungen spezialisiert hat. Eine dieser Anwendungen ist das Herzstück einer Lokalisierungslösung für autonomen mobilen Robotern.
Vor diesem Hintergrund haben wir beschlossen, uns in die Lage unserer Kunden zu versetzen. Unser Hauptziel war es, herauszufinden, wie sich ein Trägheitsnavigationssystem am besten in den Steuerungsstapel eines AMR integrieren lässt, damit wir unsere Kunden, die dasselbe versuchen, unterstützen können. Auf dem Weg dorthin wollten wir aber auch so viel wie möglich über die Welt der automatisierten Robotik und der Sensorfusion lernen, um die Welt, in der unsere Kunden leben, besser verstehen zu können.
Ein Überblick über den Prototyp
Wie wir bereits in Blog 5 (Jenseits der Lokalisierung)erwähnt haben, befindet sich unser Steuerungssystem auf einem Clearpath Jackal UGV. Zur Hardware gehören ein Jetson Nano, auf dem die Steuerungssoftware läuft, ein Raddrehzahlsensor, zwei Raspberry Pi Kameras und ein OxTS AV200 INS.
Die Software zur Steuerung des Roboters ist modular aufgebaut - jedes Element des Steuerungsstapels ist ein eigenes ROS2-Paket. Wir haben das so gemacht, damit wir in zukünftigen Tests anspruchsvollere Module hinzufügen oder den Roboter leichter an bestimmte Aufgaben anpassen können.
Wir haben uns auch dafür entschieden, unseren Roboter zu einer autonomen Plattform der SAE-Stufe 3 zu machen. Der Roboter folgt einem vorgegebenen Pfad und kann dies nur unter der Aufsicht eines menschlichen Bedieners tun (obwohl der Mensch den Roboter nicht steuert). Wir haben diese Entscheidung aus mehreren Gründen getroffen:
- Wir wollten die Sicherheit unserer Konstruktion maximieren - unser Bediener kann eingreifen und die Kontrolle über den Roboter übernehmen, wenn sein Verhalten von unseren Erwartungen abweicht.
- Wir wollten einen Roboter entwickeln, der dem Grad der Autonomie entspricht, den wir in der realen Welt sehen.
Und schließlich haben wir unser Steuerungssystem so konzipiert, dass es mit jedem OxTS INS - denn natürlich würden wir das tun - und jedem Roboter mit Rädern funktioniert. Wir dachten uns, dass das, was wir aus dem Prototyp gelernt haben, für so viele unserer Kunden und Interessenten wie möglich anwendbar ist.
Die Module in unserem Prototyp
Wir haben bereits einige von ihnen behandelt.
- Das Entscheidungsfindungsmodul, das entscheidet, welche Aktionen der Roboter ausführen soll, wird in Blog 8.
- Die Steuerung, die eine Route in Befehle für den Roboter umwandelt, wird in Blog 7.
- Das Modul zur Objekterkennung, das mit Hilfe von Wahrnehmungssensoren Hindernisse erkennt, wird in Blog 6.
Es gibt noch ein weiteres Modul, das wir in Blog 8 kurz angedeutet haben und auf das wir hier näher eingehen werden: den Systemmonitor.
Der Systemmonitor
Der Systemmonitor ist eine Sammlung von Werkzeugen, mit denen der Status des Roboters aus der Ferne überwacht werden kann und mit denen ein Bediener dem System Befehle erteilen kann. Selbst ein vollautomatischer Roboter benötigt eine Art von Systemmonitor. Die Möglichkeit, dass ein Mensch die Steuerung eines Roboters übernimmt, ist in vielen Anwendungsfällen eine nützliche Ausfallsicherung, und die Statusüberwachung ermöglicht es dem Bediener, Probleme zu erkennen und zu beheben, die den Betrieb des Roboters verhindern. Dies wäre besonders wichtig, wenn Sie eine Flotte von Robotern von einem entfernten Standort aus verwalten würden.
Unser Roboter kommuniziert mit uns über ein WiFi-Modul, das ein lokales Netzwerk aufbaut. Sobald unsere Laptops mit diesem verbunden sind, kann der Roboter ROS2-Nachrichten senden und empfangen.
Hier sehen Sie einen Screenshot unseres Systemmonitors, der auf einem Laptop läuft:
Technisch gesehen gibt es hier zwei Anwendungen. Die erste ist der schwarze Kasten oben links namens "OxTS Full System Monitor". Das ist eine sehr einfache Anwendung, die wir selbst entwickelt haben und die es uns ermöglicht, Befehle an das Entscheidungsfindungsmodul zu geben. Sie können sehen, dass wir die Möglichkeit haben, den Roboter zu starten und zu stoppen, ein Hindernis zu ignorieren und auch das INS zurückzusetzen, was für unsere Testmethodik nützlich war. Außerdem können wir den Status des Roboters und seine Geschwindigkeiten ablesen.
Die größere Anwendung ist RVIZ, ein Visualisierungswerkzeug das mit ROS geliefert wird. Es ermöglicht uns, den Fortschritt des Roboters entlang seines Pfades in einem 3D-Raum zu visualisieren, und gibt uns einen Live-Feed der Kameras, damit wir sehen können, was der Roboter sieht (so entscheiden wir, ob wir die Schaltfläche "Hindernis ignorieren" in unserer Steuerung drücken). Die Pfeile auf dem Bildschirm sind die Wegpunkte auf dem Pfad, wobei der weiße Pfeil der nächste Wegpunkt ist, den der Roboter erreichen muss; wie Sie im GIF sehen können, bringen wir den Roboter in diesem Beispiel nur dazu, vorwärts und rückwärts zu fahren. Das Ding, das wie eine Ansammlung von bunten Strohhalmen aussieht, ist eine Darstellung des INS und ermöglicht uns, seine Position im 3D-Raum zu überwachen (jeder farbige Stab steht für eine Achse).
Natürlich ist unser Systemmonitor nur rudimentär, da wir nur an einem Prototyp arbeiten. Eine professionelle Version davon könnte an einem einzigen Ort die Positionen einer ganzen Flotte von Robotern anzeigen, um zu sehen, was jeder einzelne zu einem bestimmten Zeitpunkt tut, und ihm bei Bedarf individuelle Anweisungen geben.
Einrichten des Testlaufs
Wir beschlossen, unseren Roboter in einer der Scheunen unseres Büros in Oxfordshire zu testen. Wir wollten testen, ob unser Roboter das kann:
- Start in Innenräumen ohne GNSS-Signal
- Navigieren in Innenräumen ohne GNSS-Signal
- Navigieren im Freien nur mit GNSS-Signal
- Navigation mit einer Kombination aus GNSS-Signal und ArUco-Markern zur gleichen Zeit
- Erfolgreiche Übergänge zwischen den verschiedenen Navigationsmodi
Der erste Schritt bestand darin, die visuellen Marker für unsere ArUco-Markerlokalisierungslösung zu kartieren. Da der Roboter die Marker nutzt, um seinen Standort in einem Gebiet ohne GNSS zu bestimmen, mussten wir sicherstellen, dass die Position der Marker selbst mit hoher Genauigkeit bekannt war. Zu diesem Zweck haben wir jeden Punkt mit einer Totalstation vermessen und seine Position in globalen Breiten-, Längen- und Höhenkoordinaten aufgezeichnet.
Danach mussten wir die Route festlegen, der unser Roboter folgen sollte. Dazu fuhren wir den Roboter manuell um die Scheune und nutzten das INS, um Lokalisierungsdaten für jeden Wegpunkt zu sammeln. Das INS nutzte eine Kombination aus ArUco-Markern und GNSS-Signalen, um die Positionen der einzelnen Wegpunkte in denselben globalen Breiten-, Längen- und Höhenkoordinaten aufzuzeichnen, in denen die ArUco-Marker vermessen wurden. Die Wegpunkte wurden dann in einer .csv-Datei gespeichert und an den Roboter übergeben.
Und das war's: Danach haben wir den Roboter in seine Ausgangsposition gebracht, ihm gesagt, dass er sich frei bewegen kann, und los ging's!
Die Ergebnisse des Testlaufs
Hier ist eine Karte, die den Weg des Roboters um die Scheune zeigt. Grün zeigt unsere Zielroute, rot die Route, der der Simulationsroboter folgte, und blau die Route, der der physische Roboter folgte:
Wir erlaubten dem Roboter eine maximale Abweichung von 0,5 m von seiner Zielroute, und die meiste Zeit lag die Abweichung nach unseren visuellen Inspektionen weit unter diesem Wert. Und das Beste ist, dass die Ergebnisse ziemlich reproduzierbar waren. Wir haben einen Vormittag damit verbracht, zur Unterhaltung der anderen Kollegen auf OxTS Runden um unsere Scheune zu drehen, und jedes Mal war die Route sehr ähnlich. Angesichts der Bedeutung der Wiederholbarkeit bei der autonomen Navigation war dies ein großes Plus.
War es perfekt? Ganz und gar nicht. Dies war unser erster Versuch, ein eigenes Steuersystem zu entwickeln, das ein OxTS INS für die Lokalisierung verwendet, daher gibt es viele Dinge, die wir beim nächsten Mal anders machen könnten - und würden.
Mit der Zeit wäre es toll, weitere Module hinzuzufügen, um einen anspruchsvolleren Roboter zu schaffen. Zum Beispiel ein Modul zur Hindernisvermeidung, eine intelligente Pfadplanung und ein Modul, mit dem der Roboter als Teil einer Gruppe (oder eines Schwarms, um den viel cooleren und genaueren Begriff zu verwenden) von AMRs arbeiten kann. Aber im Moment sind wir wirklich zufrieden mit dem, was wir erreicht haben. Wir haben uns selbst bewiesen, dass die Technologie von OxTS erfolgreich in einen funktionalen AMR-Steuerungsstapel integriert werden kann, der es dem Roboter ermöglicht, in Innenräumen, im Freien und zwischen beiden Umgebungen zu navigieren.
Vor allem aber hat es unseren Ingenieuren und unseren Forschungs- und Entwicklungsteams die Augen für die weite Welt der Robotik geöffnet. Das hat uns nicht nur großartige Ideen für neue Produkte in der Zukunft gegeben, sondern auch ein neues Verständnis für die Welt, in der unsere Kunden leben. Und wir hoffen, dass all das zusammenkommt, um unseren Kunden zu helfen, in Zukunft mit AMRs großartige Dinge zu tun.
Autonome Roboternavigation - Kurzbeschreibung
AMRs benötigen eine robuste Lösung zur Lokalisierung von Robotern; ein Werkzeug, das nicht nur die Position und Orientierung des Roboters erfasst, sondern auch in Innenräumen und im Freien funktioniert.
In dieser Lösungsübersicht gehen wir auf die Aspekte ein, die wir unseren Kunden empfehlen, wenn sie sich für eine Lokalisierungsquelle für ihre autonomen mobilen Roboter entscheiden.
Lesen Sie die Lösungsbeschreibung um zu erfahren, wie die richtige Roboterlokalisierungslösung Ihr AMR-Projekt unterstützen kann, einschließlich der wichtigsten Fragen, die Sie sich stellen müssen, bevor Sie ein Projekt in Angriff nehmen.
Wir hoffen, dass Ihnen diese Blogserie gefallen hat und dass sie Ihnen geholfen hat, wenn Sie gerade erst mit der AMR-Reise beginnen.
Wenn Sie mehr darüber erfahren möchten, was wir derzeit für AMR-Ingenieure tun können, besuchen Sie unsere Bewerbungsseite.
Wenn Sie ein bestimmtes Projekt haben, über das Sie mit uns sprechen möchten, können Sie uns auch über das unten stehende Formular kontaktieren. Wir freuen uns immer darauf, die neuesten und besten Robotikprojekte zu besprechen.
