Robotik WS1415 - Roomba - Kinect

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche
Roomba mit Kinect und BeagleBone

Ziel dieses Projektes ist es, einen autonomen mobilen Roboter in einer unbekannten Umgebung steuern zu können. Dazu soll der Roboter zusätzlich zu den internen Sensoren noch mit einer Kinect ausgestattet werden. Es wird auf einer Grundlage aufgebaut, die im Rahmen zweier Projekt[1] [2] der Veranstaltung Embedded Systems erarbeitet wurde.

Einleitung

Der autonome mobile Roboter Roomba 780 der Firma iRobot soll mit einer Microsoft Kinect ausgestattet werden. Ziel ist es, den Roboter in einer unbekannten Umgebung zu steuern. Dazu soll mithilfe der Kinect und der internen Sensoren des Roboters eine Karte der Umgebung erstellt werden, während anhand dieser Umgebungskarte einen Pfad zum Zielpunkt berechnet wird und der Roboter diesen Pfad abfährt. Soft- und Hardware sollen so ausgelegt sein, dass der Roboter komplett autonom fahren kann.

Roomba 780

Der Roomba 780 ist ein kommerzieller Staubsaugrobotor der Firma iRobot. Dieser besitzt eine serielle Schnittstelle mit dem er Befehle von einem externe Knoten etgegennemen kann. Weiter ist über diese Schnittstelle der Empfang der zahlreichen internere Sensoren des Rooombas möglich. Der Roomba verfügt über folgende Sensoren:

  • vier Drucksensoren im vorderen Bereich verbunden mit einem 180° Bumper
  • sechs IR Abstands Sensoren vorne um eine Annäherung eines Objektes zu erkenne.
  • sechs Cliff Sensoren die den Abstand zum Boden messen
  • Radsensoren zur Erkennung von Bodenkontaktverlust
  • Odometriesensoren an den Antriebsrädern
  • Bodenschmutzsensor
  • ungerichteter Infrarotsensor zum Empfang von Befehlen oder Landmarken(Ladestation, IR Türme und IR Fernbedienung)

Mircosoft Kinect

Die Mircosoft Kinect ist ein Hardware zur Steuerung der Spielkonsole XBox 360. Die Kinect soll die Umgebung und Bewegungen mithilfe einer IR Kamera und einer IR Laserwolke erkennen und ein räumliches Bild der Umgebung an die Software weitergeben. Sie liefert also zu jedem Bildpunkt auch eine Tiefeninformation. Weiter besitzt die Kinect eine RGB Kamera die ein Farbbild der Umgebung aufzeichnet.

Hardware

Als Grundlage für die Ansteuerungshardware dient die Hardware des Embedded Projektes der Hochschule RheinMain aus dem Sommersemester 2013 (EM2013SSP07_-_Staubsaugroboter_-_Sensornetzanbindung).

Hardware Analyse

Im Embedded Systems Projekt bestand die Hardware aus drei Teilen:

  • Stromversorgung und TTL Wandler für UART Signale des Roomba
  • ATmega128RFA1 mit IEEE 802.15.4 Transceiver
  • PC + IEEE 802.15.4 Empfänger zur Steuerung

Hardware Voraussetzungen

Da in diesem Projekt eine Microsoft Kinect verwendet wird, musste die Rechenleistung am Roomba deutlich erhöht werden. Die Kinect transportiert ihre Daten über USB 2.0, hierbei werden Sensordaten sowie zwei Kamerabilder(RGB und IR) und eine Entfernungsbild(Depth Stream) übertragen. [3] Da der im Embedded Systems Projekt verwendete Prozessor weder über die passende Rechenleistung verfügt noch ein USB 2.0 Host controller besitzt, musste für dieses Projekt ein leistungsstärkerer Prozessor gefunden werden. Weiter wurde der Stromverbrauch der Kinect ermittelt um ein geeignetes Netzteil auswählen zu können. Die Kinect wird neben USB noch über ein separates 12 V Netzteil mit Strom versorgt. Das original Netzteil ist hierbei auf einen Maximalstrom von 1 A ausgelegt. Die Messungen ergeben, dass die Kinect ca 600 mA verbraucht.

Roomba Stromversorgung

Wie in der Roomba Schnittstellenbeschreibung beschrieben [4] ist über die Schnittstelle eine "unregulated" Stromversorgung herausgeführt. In der Dokumentation ist nicht zu entnehmen, welche Spannungen oder Belastbarkeit hier möglich ist. Messungen haben ergeben, dass diese sich zwischen 14 V und 11 V bewegen.

Auswahl des Prozessors

Für die Verarbeitung am Roomba kommen verschiedene Boards in Frage:

  • Raspberry PI
  • Beaglebone Black
  • Colibri iMX6

Der Raspberry Pi wurde wegen der veralteten Architektur(ARM11) und der Prozessorgeschwindigkeit abgelehnt. Das Colibri Board der Firma Toradex besitzt von den hier angeben Boards am meisten Leistung aber da es in der Hochschule nicht verfügbar war, wurde es ebenfalls abgelehnt. Das Beaglebone Black besitzt ein 1 Ghz ARMv7 Prozessor und ist in der Hochschule verfügbar.

Auswahl der Stromversorgung

Für das Projekt werden zwei Stromversorgungen benötigt. Eine für das Beagebone Black und eine für die Kinect. Neben der Kinect ist an dem Beaglebone noch ein WLAN Transceiver angeschlossen. Dieser soll für Debugzweke einen Hotspot öffnen, sodass das Beaglebone ohne Kabel gedebugt werden kann. Das Beglebone Black verbraucht ohne angeschlossene Geräte ca 150 mA. Zusammen mit Kinect und dem WLAN Transceiver muss mit einem Stromverbrauch von mindestens 650 mA gerechnet werden. Zusammen mit der Kinect liegt der gesamte Strombedarf somit bei 1250 mA. Das Beglebone Black braucht eine 5 V Stromversorgung.

Die Stromversorgung des Embedded Projektes besteht aus einem DCDC Wandler der von 4.7V bis 28 V auf 3.3V max 0.5 A umwandelt und einem Linearregler der auf 5 V regelt. Durch den hohen Spannungsabfall wird der Linearregler bereits stark belastet. Da beide Stromversorgungen nicht ausreichend sind um das Beaglebone Black zu versorgen, musste im Rahmen dieses Projektes eine neue Stromversorgung entwickelt werden.

Die Stromversorgung wurde mithilfe von Gleichstromwandlern(DCDC) der Firma Ti entwickelt. Hierfür wurden Samples von drei Modulen bestellt. Um eine stabile 12 V Stromversorgung für die Kinect zu gewährleisten, muss ein weiteres Problem gelöst werden. Die Eingangsspannung vom Roomba ist 11 - 14 V. Die meisten DCDC sind sogenannte Step Up oder Step Down also wandeln sie entweder die Spannung nach oben oder nach unten. Diese können häufig nur Spannungen von +/- 2 V über oder unter der Ausgabespannung entgegennehmen. Also bei 12 V bei einem Step Down Wandler 14 V bei einem Step Up Wanlder 10 V. Es existieren zwar auch Step Up/Down Wandler die in beide Richtungen wandeln können aber diese sind extrem teuer. Deswegen wurde in diesem Projekt die Stromversorgung der Kinect aus zwei DCDC hergestellt. Ein Step-Down Wandler der auf 5 V wandelt und danach ein Step - Up Wandler der auf 12 V wandelt. Somit kann eine Stromversorgung von 7 V bis 36 V in 12 V umgewandelt werden. Nachteil dieser Methode ist, dass bei einer Entnahme von 1 A bei 12 V der Step-Down Wandler bei 5 V mit 2,4 A belastet wird.

Verwendet werden drei Ti DCDC Module:

  • PTN04050C: 12 W Step-Up Wandler (2.95 V bis 5.5 V Eingangsspannung auf 5 - 15 V Ausgangsspannung)[5]
  • PTN78060W: 3 A Step-Down Wandler (7 V bis 36 V Eingangsspannung auf 2,5 V - 12,6 V Ausgangsspannung)[6]
  • PTN78000W: 1 A Step-Down Wandler (7 V bis 26 V Eingangsspannung auf 2,5 V - 12,6 V Ausgangsspannung)[7]

Das dritte Module ist für das Beaglebone gedacht. Ein Schaltplan der Netzteil Schaltung ist in Abbildung zu erkennen. Eingestellt werden die Module über Widerstände. Wie groß die Widerstände sind um eine bestimmte Ausgangsspannung zu erreichen, ist im Datenblatt des Modules zu entnehmen und wird in dieser Dokumentation nicht weiter ausgeführt. Für die spätere TTL Wandlung wird über ein Spannungsteiler aus den 5 V 3.3V generiert.

Robotik-WS1415-Schaltplan - Netzteil.png

Schnittellen Adapter für den Roomba

Die Roomba Schnittstelle arbeitet über UART(0 - 5V TTL Signale) da das Beaglebone Black nur singale von 0 - 3,3 V verarbeiten kann, muss ensprechent wie im dem Embedded System Projekt die Signale von 0 - 5 V auf 0 - 3,3 V umgewandelt werden. Hierfür wurde ein Hex Inverter verwendet. Dies ist eine Komponente, die ein eingehendes Signal invertiert und über eine Open Colector Schaltung ausgeben und angepasst werden kann. Das heißt die Ausgangsspannung kann mithilfe eines Pull Up Widerstandes auf die gewünschte Spannung gebracht werden. Da das Invertieren des Signales in diesem Anwendungsfeld nicht erwünscht ist, wird das Signal erneut in den Hex Inverter geleitet und somit wieder invertiert. In der Abbildung ist der Schaltplan für RX und TX zu erkennen. In dem Schaltplan ist mit RXR der Signal Eingang und TXR der Signal Ausgang des Roomba bezeichnet ist.

Robotik-WS1415-Schaltplan - Roomba.png

Beschaltung Beaglebone Black

Am Beglebone werde neben der Stromversorgung nur der UART 4 Benötigt. Der Schaltplan ist in dieser Abbildung zu erkennen

Robotik-WS1415-Schaltplan - Beaglebone.png

Prototype auf Lochraster

So wie im Embedded Systems Projekt von 2013 wurde die Stromversorgungsplatine auf Lochraster aufgebaut. In dieser Abbildung ist die Platine aus dem Embedded Systems Projekt zu erkennen. Die Unterschiede zu dem oben gezeigten Schaltplan besteht darin, dass diese Platine selbstversorgt ist.

Robotik-WS1415-Roomba-Connector.jpg

In dieser Abbildung ist die Stromversorgungsplatine zu erkennen.

Robotik-WS1415-stromversorgung.jpg

Schaltung auf Platine

Weiter wurde eine Platine in Eagle erstellt, die die zwei Platinen vollständig ersetzen kann. Die Platine wurde so erstellt das sie ein Beglebone aufnehmen kann. Bei der Erstellung wurde besonderes darauf geachtet, dass nicht leitende Flächen vermieden werden, da die Platine später gefräst werden soll. Zusätzlich war es wichtig, dass der Abstand zwischen allen Leitungen etwa gleich war. Dies vereinfacht das Fräsen deutlich. Bei den Netzteilen musste darauf geachtet werden, dass die Leiterbahnen den zu führenden Strom leiten können(max 2.5 A). Um so große Erhitzungen zu vermeiden wurden hier Flächen verwendet.

Das gesamte Layout ist in dieser Abbildung zu erkennen: Robotik-WS1415-Layout.png

Stomversorgungsproblem

Spannungsabfall der Stromversogung

Nach erfolgreicher Herstellung der Prototypenplatinen wurde ein Test mit allen Komponenten gemacht. Beim Einschalten des Beaglebone, WLAN und Kinect ist dann aufgefallen, dass eine nicht dokumentierte Strombegrenzung seitens des Roomba existiert. Nach einigen Tests konnte die Strombegrenzung auf ca. 500 mA geschätzt werden. In der Abbildung ist der Stromverlust zu erkennen, der beim Start aller Komponenten auftritt. Deutlich ist ein Spannungsabfall auf 5V zu erkennen.

Um dieses Problem zu lösen gab es zwei Lösungsansätze. Einmal die Verwendung von einer extra Batterie und die direkte Anzapfung der NiMh Akkus des Roomba. Da eine extra Batterie weitere Nachteile mit sich bringt wurde die direkte Anzapfung durchgeführt. Hiefür wurde auf die Steuerungsplatine des Roomba ein Kabel an die Plus und Minus Kontakte gelötet und nach außen geführt.

BeagleBone Betriebssystem

Auf dem Beglebone Black läuft ein Linux. Dieses wurde mithilfe der Ångström Distribution erstellt. Diese basiert auf Open Embedded und yocto. Die Grundidee von yocto und Open Embedded ist es, keine Binarys zu Verfügung zu stellen wie herkömmliche Distribution, sondern ein Buildsystem für Distribution zur Verfügung zu stellen. Wenn mit yocto gebaut wird ist das Reslutat ein Image für die Zielplattform das ein vollständiges Linux enthält und alle Dateien die zum Booten benötigt werden. Weiter wird ein Software Developer Kit erstellt, mithilfe dessen Programme für die Zielplattform erstellt werden können.

Erstellung eines Yocto Image

Um ein Yocto Image zu erzeugen, wird einerseits Yocto benötigt und eine Maschinenbeschreibung, die das Zielsystem beschreibt. Yocto besteht aus verschiedenen Scripten die das Ziel haben, ein komplettes Linux System zu erzeugen. Hiebei werden alle Komponenten eines System erzeugt(RootFS, Bootloader und Kernel). Alle Scripte sind in einer yocto eigenen Metasprache definiert. Die eigentliche Scriptsprache kann nach Belieben ausgewählt werden(Phyton, Perl, Bash und viele weitere sind möglich). In Ycoto und Open Embedded sind alle grundlegenden Scripte für die Erzeugung eines Image enthalten. Open Embedded unterteilt sich in zwei Ebenen: Die Layer Ebene und die recipes Ebene(Rezepte). Yocto und Open Embedded selbst fallen unter die Layer Ebene. Sie beschreibt eine Sammlung von Rezepten, um ein Image zu bauen.

Erstellung eines eigenen Layer

Um eine neue Maschinenbeschreibung zu erstellen muss folge Ordner Struktur erstellt werden:

<layer name>
├── conf
│   ├── layer.conf
│   └── machine
│       └── beaglebone-rob.conf
└── recipes-kernel
    └── linux
        ├── linux-yocto-custom-rob
        │   └── defconfig
        └── linux-yocto-custom-rob.bb

Die Datei layer.conf beschreibt den Namen des Layer etc. Im Verzeichnis machine wird die Maschinenbeschreibung abgelegt. Unter recipes-kernel werden die Linux Kernel Settings mit Patches abgelegt. In sogenannten bb Files werden dann die einzeln Teile des Betriebssystems beschrieben. Auf den genauen Inhalt der einzeln Dateien wird in dieser Dokumentation nicht weiter eingegangen, da sie auf der Yocto Seite genauer beschrieben sind.

Änderung am Muxing des AM335x im Linux Kernel

Um den UART 4 benutzen zu können, musste das sogenannte Muxing des Prozessors geändert werden. Das Muxing des AM335x wird im Linux Kernel über sogenannte Device Tree Dateien eingestellt. Herfür muss ein neuer Muxing-Eintrag erstellt werden und der UART 4 Contoller aktiviert werden.

/dts-v1/;

#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
...
&am33xx_pinmux {
       nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
               ...
       };
       /* Pinuxing */
       uart4_pins: pinmux_uart4_pins {
                pinctrl-single,pins = <
                        0x70 (PIN_INPUT_PULLUP | MUX_MODE6) /* conf_gpmc_wait0 (P9: 11 UART4_RXD) */
                        0x74 (PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* conf_gpmc_wpn (P9: 13 UART4_TXD) */
                >;
       };
}
/* Aktivieren des UART 4 Kontrollers*/
&uart4 {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&uart4_pins>;
};

USB Probleme des Beaglebone Black

Bei den ersten Tests mit dem Beaglebone Black zusammen mit der Kinect stellten sich schnell extreme Problem mit dem USB Port heraus. Als Basis wird die Freenect Library verwendet, die eine offene Ansteuerungsbibliothek für die Kinect ist. Diese wurden mithilfe von Yocto und Open Embedded für das Beglebone Balck gebaut und installiert. Mithilfe der Demo Applikationen der freenect Library konnten erste Tests durchgeführt werden. Es stellte sich heraus, dass der auf dem Beaglebone Black installierte Prozessor(XAM3359 / AM3358) Probleme mit USB hat. Laut Beschreibung in mehreren Commits im Linux Kernel kommt es bei großen Paketen die per USB übertragen werden zu Problemen.[8][9] Alle Pakete werden über eine Methode übertragen die Direct Memory Access (DMA) heißt. Hierbei holt sich der passende Kontroller ohne Prozessorinteraktion automatisch die zu übertragenden Daten aus dem RAM. Umgekehrt legt er einkommende Daten im RAM ab und benachrichtigt den Prozessor, dass Informationen bereitgestellt worden sind. Hierbei tritt dann der Fehler auf: Der USB Kontroller benachrichtigt den Prozessor bei großen Datenpacketen zu früh. Hiefür wurde in der Vergangenheit ein Workaround in den Linux Kernel eingebaut um große USB Pakete empfangen zu können. Leider wurden der Workaround erst mit der Kernel Version 3.17 vollständig korrekt eingebaut. Das Beglebone verwendet aber noch 3.8. Somit musste über Yocto ein neues Image erzeugt werden das den Kernel 3.17 verwendet um die Kinect am Beaglebone nutzbar zu machen.

Roomba Bibliothek

Alte Software Architektur
Neue Software Architektur

Wie bereits erwähnt basiert dieses Projekt auf zwei Embedded Systems Projekten von 2013. Neben der Schaltung wurde auch die dort entwickelte Bibliothek übernommen. In diesem Kapitel werden die Änderungen an der Architektur genauer beschrieben. Die größte Änderung an der Architektur bestand darin, dass die SDDs Kommunikation abgeschafft worden ist, da die Anwendung vollständig auf dem Beglebone lauffähig ist. Die komplette Steuerung läuft jetzt auf dem Beglebone und als Kommunikation nach außen wird WLAN verwendet. Als Anzeige Framework wird das X Protokoll verwendet um Oberflächen / Bilder an einen PC zu übertragen. Die Arbeit die vorher der Sensorknoten übernommen hat wird jetzt von einem Linux Thread übernommen der über die TTY Schnittstelle des Linux Betriebssystems die UART Schnittstelle abruft. Weiter wurde über die libFreenect die Kinect angebunden.

Steuerung

Aufgabe der Steuerung ist es, die Umgebung wahrzunehmen, um Hindernisse zu erkennen, einen Pfad um diese Hindernisse herum zum Ziel zu finden und sicher entland des Pfades zum Ziel zu navigieren. Zu beachten ist, dass der Roboter in einer komplett unbekannten Umgebung startet. Während der Roboter seinen Pfad verfolg, wird die Umgebung erkundet. Wird ein Hinderniss erkannt, das den aktuellen Pfad versperrt, muss ein neuer Pfad gesucht werden.

Lokalisierung

Es wurde sich dazu entschieden, die Lokalisierung des Roboters ausschließlich über den Odometriesensor der Beiden Antriebsräder durchzuführen. Auf eine Verfeinerung der berechneten Pose anhand der kartierten Umgebung wurde verzichtet.Die verbauten Odometriesensoren erlauben es theoretisch --in einem Perfekten System ohne Schlupf und andere Fehlerquellen -- die zurückgelegte Strecke auf 0,5mm genau zu bestimmen.

Kartierung

Die Kartierung der Umgebung wird zum einem durch die Daten des Bumpers am Roboter, zum anderen durch die Daten der Kinect realisiert. Die gesamelten Daten werden in eine gemeinsame Karte eingetragen, auf basis derer ein Pfad zum Ziel gesucht wird.

Bumper

Fährt der Roboter gegen ein Hindernis, wird der Bumper betätigt, woraufhin der Roboter gestoppt wird. Ist der Bumper betätigt worden, wird der Knoten, der unmittelbar erreicht werden sollte, als nicht passierbar in die Karte eingetragen und der Roboter fährt zum vorigen Knoten zurück, um von dort über einen anderen Pfad das Ziel zu erreichen.

Kinect

Die Sensorleiste von Microsoft Kinect ist in der Lage, sowohl die Farbinformationen einer üblichen Kamera, als auch Tiefeninformaitonen zu jedem Pixel zu liefern. Mithilfe dieser Tiefeninformation können Hindernisse bis zu einer Entfernung von ca. 4m zuverlässig erkannt werden. Um eine Korrekte Karte der relevanten Hindernisse zu erstellen, sollen Pixel, die ein Hinderniss indizieren, das für den Roboter irrelevant ist, nicht beachtet werden. Befindet sich zum Beispiel ein Tisch im Blickfeld der Kamera, so soll die Tischplatte nicht als Hindernis erkannt werden, falls der Roboter darunter hindurchfahren kann ohne zu kolidieren. Die Tischbeine hingegen sollen als Hinderniss erkannt und in die Karte eingetragen werden.

Hinderniserkennung

Zudem soll die Neigung der Kinect keine Auswirkung auf das Durchfahrtsvolumen haben. Das wird erreicht, indem anhand der Daten der Beschleunigungssensoren der Kinect der Horizont berechnet wird. Die die Daten der Beschleunigungssensoren stark rauschen, wurde ein gleitender Mittelwert Filter implementiert, sodass man einen geglätteten Horizont erhalt..Aus der geglätteten Beschleunigung in z-Richtung Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle a_z} lasst sich der Neigungswinkel der Kamera Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \alpha} um deren x-Achse folgendermaßen bestimmen:

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \alpha=acos(a_z/g - \pi/2).}
Horizont

Analog dazu erhält man mit folgender Formel den Winkel Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \beta} der Kamera um die z-Achse:

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \beta=-acos(a_x/g)+\pi/2 .}

Anhand der bekannten Gesamthöhe des Roboter und der Höhe des Kameraauges lässt sich mithilfe des Horizontes das Durchfahrtvolumen bestimmen. Es werden nur Hindernisse in die Karte eingetragen, die sich in diesem Volumen befinden. Die Höhe eines Objektpunktes lässt sich mit den Pixel- und Tiefeninformationen unter zuhilfenahme der intrinsischen Kameraparameter berechnen.

Kameraansicht mit Horizont

Das nebenstehende Bild entstand aus einer doppelt geneigten Kinect. Man sieht, dass die Hindernisse entsprechend dem berechneten Horizont im Durchfahrtsvolumen farbig gekennzeichnet sind. Die Einfärbung der Hindernisse kodiert die jeweilige Tiefe. Da ein Bild der Kamera durch perspektivische Projektion entsteht, sind entfernte Objekte kleiner dargestellt als nahe Objekte. Dadurch ist die Ausdehnung der Einfärbung orthogonal zum Horizont bei nahen Objekten (grün) größer, als bei entfernteren Objekten (rot).

Wurde eine Karte der aktuellen Umgebung aus Sicht der Kinect erstellt, müssen die Punkte mithilfe der Pose des Roboters per Koordinatentransformation in das Weltkoordinatensystem überführt werden, woraufhin sie der Umgebungskarte hinzugefügt werden können. Zur Koordinatentransformation muss der gegebene Punkt Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \vec p} zunächste rotiert werden. Die rotierten Koordinaten im zweidimensionalen Raum erhält man durch Anwendung folgender Matrix:

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle R_\alpha = \begin{pmatrix} \cos\alpha & -\sin\alpha \\ \sin\alpha & \cos\alpha\end{pmatrix}}

Da die Ausrichtung des Roboters als Einheitsvektor hinterlegt ist gilt für gegebenen Richtungsvektor Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \vec a} :

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \vec a = \begin{pmatrix} a_x \\ a_y\end{pmatrix} = \begin{pmatrix} cos(\alpha) \\ sin(\alpha)\end{pmatrix}}

somit gilt:

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle R_\alpha = \begin{pmatrix} a_x & -a_y \\ a_y & a_x\end{pmatrix}} .

Addiert man nun noch den gegebenen Positionsvektor Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \vec l} des Roboters, so erhält man den Punkt in Weltkoordinaten.

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \vec p_{welt} = \begin{pmatrix} a_x * p_x - a_y * p_y + l_x\\ a_y * p_x + a_x * p_y + l_y\end{pmatrix}} .

Dieser Punkt lässt sich nun in die Weltkarte eintragen. Um eine Kollision zu vermeiden, wird jedes Hindernis mit dem Roboterradius dilatiert in die Karte eingetragen.

Kartierung der Umgebung während der Fahrt

In der Nebenstehenden Abbildung der Weltkarte ist zu erkennen, dass der Roboter nicht den optimalen Pfad gefahren ist. Das liegt daran, dass die Karte erst während der Fahrt nach und nach erstellt wird. Wird ein neues Hindernis erkannt, wird der Pfad neu berechnet.

Architektur

Architektur der Steuerung

Die Grundarchitektur der Steuerung ist bezüglich des vorrausgegangenen Projektes nicht stark verändert worden. Nach wie vor liest der Data Manager dauerhaft in einem nebenläufigen Thread die Sensordaten des Roomba aus und hinterlegt sie in einem zentralen Datenstruct. Der Pathfinder unterhält eine Karte der Umgebung auf basis derer er einen Pfad sucht. Der Pfadfinder erteilt daraufhin dem Navigator Befehle, in welche Richtung er fahren soll. Dieser wiederum setzt die Befehle in Sequenzen von Befehlen für den Roomba um. Dieser schickt daraufhin die nötigen Steuerkomandos ans den Roomba. Nähere Informationen hierzu finden sich in der Dokumentation des Vorgängerprojektes[10]. Im Rahmen dieses Projektes wurde ein dritter Thread hinzugefügt, der aus jedem Frame der Kinect die Hindernisse extrahiert. Der Pfadfinder kann immer auf die aktuellste Hinderniskarte dieses Threads zugreifen. Die Hindernisse sind dort im Koordinatensystem der Kinect hinterlegt. Befor der Pfadfinder die Hindernisse in die Karte einfügt, muss er erst eine Koordinatentransformation in das Weltkoordinatensystem durchführen. Der zusätzliche Thread überschreibt solange die Hintergrundkarte, bis der Pfadfinder eine neue anfordert. Dann tauscht der Mapper Vorder- und Hintergrundkarte aus.

Implementierung

Die Steuerung wurde in der Sprach C++ implementiert. Zur Ansteuerung der Kinect wurde die offene Bibliothek libfreenect[11] verwendet. Die Darstellung der Karte erfolgt mithilfe von OpenGL. Die Steuerung baut auf die bereits in einem anderen Projekt entwickelte Steuerung[12] auf.

Fazit

Da sich dafür entschieden wurde, die Lokalisierung des Roboters ausschließlich auf Grundlage der Odometriesensoren an den Antriebsrädern durchzuführen, ist die berechnete Pose des Roboters immer ungenau. Diese Ungenauigkeit wird mit der zurückgelegten Strecke größer. Vor allem die Ungenauigkeit in der Orientierung des Roboters ist kritisch, Die Ungenauigkeit der Orientierung ist stark abhängig von der Anzahl an Punktdrehungen, die der Roboter während eines Durchlaufs zurücklegt. Diese Ungenauigkeit der Pose führt dazu, dass die erzeugte Umgebungskarte ungenau wird. Um dies zu verbessern, wäre denkbar, die Pose anhand der Umgebungskarte und der momentanen Karte aus Sicht der Kinect zu verfeinern.

Quellen

  1. https://wwwvs.cs.hs-rm.de/vs-wiki/index.php/EM2013SSP07
  2. https://wwwvs.cs.hs-rm.de/vs-wiki/index.php/EM2013SSP08
  3. http://openkinect.org/wiki/Protocol_Documentation
  4. http://www.irobot.lv/uploaded_files/File/iRobot_Roomba_500_Open_Interface_Spec.pdf
  5. http://www.ti.com/product/ptn04050c
  6. http://www.ti.com/product/ptn78060w
  7. http://www.ti.com/product/ptn78000w
  8. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=a655f481d83d6d37bec0a2ddfdd24c30ff8f541f
  9. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=50aea6fca771d6daf3ec24f771da866f7fd836e4
  10. https://wwwvs.cs.hs-rm.de/vs-wiki/index.php/EM2013SSP08
  11. https://github.com/OpenKinect/libfreenect
  12. https://wwwvs.cs.hs-rm.de/vs-wiki/index.php/EM2013SSP08