Projekt 70a:Bau eines Labyrinths für EV3-Roboter

Ev3 im Labyrinth

Autoren: Michael Menke und Sebastian Trybel

Betreuer: Prof. Dr.-Ing. Schneider

Einleitung

In diesem Artikel wird das Projekt 70a: Bau eines Labyrinths für EV3-Roboter erklärt. Dieses Projekt soll ein EV3 Roboter den Ausgang aus einem Labyrinth finden und dabei den Weg aufzeichnen. Erarbeitet wurde dieses Projekt von Michael Menke und Sebastian Trybel im Rahmen des Elektrotechnik Fachpraktikums im Wintersemester 2017/18. Ziel des Beitrags ist es, eine nachhaltige Dokumentation zu schaffen, welche die Ergebnisse festhält und das weitere Arbeiten am Projekt ermöglicht. Aus diesem Grund befinden sich weitere Dateien, wie die Bauanleitung für den Roboter, die technische Zeichnungen für das Labyrinth, die Flussdiagramme und ein Programmcode in Subversion(SVN). Der Link für die Unterlagen befindet sich unter der Überschrift Projektunterlagen. Für eine kurze Präsentation des Projekts wurde ein Youtube-Video erstellt.

Aufgabe

Ein EV3 Roboter soll den Ausgang aus einem Labyrinth finden und dabei einen SLAM-Algorithmus anwenden.

Das SLAM-Verfahren (englisch Simultaneous Localization and Mapping; Deutsch: Simultane Lokalisierung und Kartenerstellung) ist eine Methode, mit der ein mobiler Roboter gleichzeitig eine Karte seiner Umgebung erstellen und seine Position innerhalb dieser Karte schätzen kann.

Eine der grundlegenden Fähigkeiten eines mobilen Roboters besteht darin, zu wissen, wie seine Umgebung aussieht und wo er sich befindet. Ist eine Karte der Umgebung vorhanden, kann sich ein Roboter mit Hilfe seiner Sensoren, wie Ultraschall oder Lidar darin positionieren. Ist die absolute Position des Roboters bekannt, kann eine Karte aufgebaut werden. Dabei misst der Roboter die relative Position möglicher Hindernisse zu ihm und kann mit seiner bekannten Position dann die absolute Position der Hindernisse bestimmen. Diese werden dann in die Karte eingetragen.

SLAM ist somit ein Henne-Ei-Problem, da weder die Karte noch die Position bekannt ist und daher geschätzt werden muss.

Erwartungen an die Projektlösung

• Aufbau und Planung eines flexiblen Labyrinths (z.B. Styrodur)
• Robotervorschlag existiert bereits
• Recherche SLAM
• SLAM Ortung und Navigation via US oder IR Sensor(en)
• Inbetriebnahme mit Matlab/Simulink
• Realisierung der Flucht aus dem Labyrinth durch SLAM.
• Machen Sie spektakuläre Videos, welche die Funktion visualisieren.
• Test und wissenschaftliche Dokumentation
• Live Vorführung während der Abschlusspräsentation

Stimmen Sie sich mit Projekt 70b bezüglich Roboterdesign und Labyrinth ab, so dass die Labyrinthteile kompatibel sind.

Schwierigkeitsgrad

Mittel (***)

Verwendete Materialien und Werkzeuge

Planung

Von der Themenauswahl bis hin zur Abschlusspräsentation umfasst das Projekt rund vier Monate. Zunächst wurde eine zeitliche Gliederung für das Projekt erarbeitet. Anschließend folgte die Konstruktion des Labyrinths und des Roboters, damit die Bestellungsliste bis zum 22.10.2017 fertiggestellt werden konnte.

Konstruktionsphase

Labyrinth

Da das Labyrinth variabel sein soll, wurde eine Rasterung für die Grundplatte entwickelt, die es ermöglicht das Labyrinth auf einem 4x4 Feld flexibel aufzubauen. Dabei ist jedes Feld 300x300 mm groß. Die Wahl für die Wände und Eckverbinder ist auf Styruoduo gefallen, da dieses Material nicht so schwer wie Holz ist, es sich leicht verarbeiten lässt und auch kostenmäßig sparsam ist. Für die Grundplatte wurde eine Holzplatte benutzt, damit die Konstruktion auch eine gewisse Stabilität besitzt und Transporte übersteht. Zur Verbindung der Wände mit der Holzplatte wurden Holzdübel verwendet. Diese Art der Verbindung ist deutlich kostengünstiger und im Vergleich zum verschrauben, eine zeitliche Ersparnis bei dem individuellen Umbauen des Labyrinths. Dadurch, dass der finanzielle Rahmen von 20 € nicht überschritten werden sollte, wurde nicht allzu hohes Styruoduo verwendet um die Kosten niedrig zu halten. Daher war die Konstruktion des Roboters eingeschränkt. Dementsprechend durfte der Sensor zur Überprüfung des Daseins der Wand nicht höher als 150mm vom Boden entfernt sein.

Roboter

Der Roboter musste aus Kostengründen und nach Absprache mit den Studenten aus dem Masterstudiengang BSE (Business and Systems Engineering) umgebaut werden. Des Weiteren mussten Entscheidungen über die Arten der Sensoren getroffen werden.

Auswahl der Sensoren Zunächst findet eine Recherche über den Ultraschall- und Infrarotsensor statt, da einer dieser Sensorarten zur Überprüfung der Wände genutzt werden soll. Die Sensorfunktionen werden kurz und allgemein erläutert, um daraufhin die Vor- und Nachteile der beiden Sensorarten in tabellen Form darzustellen. Zusätzlich wurde eine Messreihe mit den beiden Varianten der Sensoren durchgeführt.

EV3 Ultraschallsensor

Der Ultraschallsensor erzeugt Schallwellen, entdeckt darüber Objekte und ermittelt zusätzlich die entsprechende Entfernung in cm. Das Prinzip kommt aus dem Tierreich und bezieht sich auf der Orientierung der Fledermäuse. Die Entfernungsmessung beruht auf der Messung der Zeit, die ein für den Menschen unhörbare Schallwelle vom Senden bis zum Empfangen benötigt ..

EV3 Infrarotdetektor

Der EV3 Infrarotdetektor detektiert Infrarotlicht (IR). Diese Signale können durch Sonnenlicht oder IR-Licht beispielsweise aus TV-Fernbedienungen erzeugt werden, aber auch den Infrarot-Ball der im Informatikpraktikum für das RoboSoccer-Tunier als Fußball verwendet wird, wird erkannt. Dabei erkennt er die Richtung und den Abstand der Signalquelle .

Für die Messreihe wurden verschiedene Abstände eingestellt und durch die beiden Sensoren ermittelt. Die Tabelle besteht aus dem eingestellten Abstand, dem ermittelten Abstand durch den Ultraschallsensor und den Infrarotdetektor, sowie die resultierende Abweichung vom Ist- zum Sollwert. Die Tabelle ist hier hinterlegt.

Versuchsaufbau der Messreihe

Unsere Wahl ist durch die Messreihe auf den Ultraschallsensor gefallen. Durch diese wird deutlich, dass die Abweichung des Ultraschallsensors bei geringen und größeren Abständen im Vergleich zum Infrarotdetektor exakter ist.

EV3 Gyro-Sensor

Um die Drehbewegung festzustellen wurde noch ein Gyro-Sensor montiert. Dieser reagiert auf die geringsten Beschleunigungen, Drehbewegungen oder Lageänderungen. Sobald der Roboter während der Fahrt lenkt, erfasst der Sensor dieses und liefert ein Signal, welches eine Spannungsänderung bezogen auf die Drehgeschwindigkeit an den EV3 liefert ..

• Genauigkeit der Winkelmessung: +/- 3 Grad
• Maximale Ausgabe: 440 Grad/Sekunde
• Anzahl der Messzeiten: 1000-mal / Sekunde

Parallel zu den Konstruktionsaufgaben, wurden die Flussdiagramme und somit die ersten Ideen zur späteren Programmierung festgehalten. Diese befinden sich ebenfalls im SVN.

Bauphase

Durch die Lieferzeiten für die Bauelemente, die für die Herstellung des Labyrinthes benötigt werden, beginnt die Bauphase in dem Projekt mit dem Bau des Roboters. Hierzu befindet sich die Bauanleitung im SVN.

EV3-Roboter

Beispiel Labyrinth von oben

Nach der Lieferung der Bauelemente beginnt der Bau des Labyrinths. Die technischen Zeichnungen für den Aufbau des Labyrinths befinden sich im SVN. Dazu gehören die Zeichnungen für die Wände, die Eckverbinder und die Grundplatte. Zunächst werden die Bohrungen nach diesen Zeichnungen auf der Grundplatte angezeichnet und anschließend mit der Bohrmaschine und dem Bohrer angefertigt. Ebenso werden die Bohrungen in den Styrodurplatten hergestellt. Diese müssen jedoch vorher auf die gewünschten Maße zugeschnitten werden. Insgesamt müssen bei einer Grundplattengröße von 1,3 m x 1,3 m 25 Eckverbinder und 42 Wände hergestellt werden, um alle vorhandenen Bohrungen abzudecken.

Programmcode

Der Programmcode wurde in Simulink nach dem Muster der folgenden Programmablaufpläne erstellt. Durch technische Probleme, welche in dem Unterpunkt "Schwierigkeiten" erläutert werden, ist der Programmcode nur begrenzt getestet worden und ist somit auch nicht vollständig lauffähig.

Die Programmablaufspläne wurden in Simulink weites gehend umgesetzt. Es fehlt ein Modul zur Überprüfung ob das Labyrinth verlassen wurde. Dieses könnte in der Theorie so Umgesetzt werden das ein Scan durchgeführt wird bei dem nicht nur die drei Richtungen abgefragt werden sondern umfangreicher gescant wird.

• 

  Flussdiagramm Hauptprogramm

• 

  Flussdiagramm Scannen

• 

  Flussdiagramm Fahren

• 

  Flussdiagramm Karte erfassen

Programm Module

Die Programmlösung für das Projekt ist in mehrere Module aufgeteilt. Diese Module erfüllen kleine Teilaufgaben.

Name	Funktion
MoveDrive	Bewegt den EV3 nach vorne oder hinten
MoveTurn	Dreht den EV3 um 90° nach links oder rechts
Scan3Way	Führt eine Messung in drei Richtungen durch und gibt aus ob diese Richtung frei oder blockiert ist
ScanRead	Nimmt einen Ultraschallwert auf und vergleicht diesen mit einem Input
ScanTurn	Dreht den Ultraschall Sensor um 90° nach links oder rechts

MoveDrive

Input:

Geschwindigkeit: Ganzzahlwert von 0 bis 100. Gibt die Geschwindigkeit des Motors an.

Richtung: 1 oder -1. Gibt die Richtung an. 1 Nach Vorne und -1 nach Hinten.

Strecke: Positiver Wert. Gibt die Strecke die gefahren werden soll.

Radius: Positiver Wert. Gibt den Radradius an.

Start: Dieses Modell startet nur wenn 1 übergeben wird.

Output:

Stop: Gibt 0 aus, wenn die Strecke gefahren wurde.

Port B & C: Motor Ports. Übergibt die Geschwindigkeit an die Ports der Motoren.

MoveTurn

Input:

Geschwindigkeit: Ganzzahlwert von 0 bis 100. Gibt die Geschwindigkeit des Motors an.

Richtung: 1 oder -1. Gibt die Richtung an. 1 Nach Links und -1 nach Rechts.

Start: Dieses Modell startet nur, wenn 1 übergeben wird.

Output:

Stop: Gibt 0 aus, wenn die Drehung abgeschlossen ist.

Port B & C: Motor Ports. Übergibt die Geschwindigkeit an die Motoren.

Scan3Way

Anmerkung: Diese Funktion ist nicht lauffähig, da das Unterprogramm ScanRead nur einmal pro Modell aufgerufen werden kann.

Input:

Geschwindigkeit: Ganzzahlwert von 0 bis 100. Gibt die Geschwindigkeit der Motoren an.

Abstand: Gibt die Entfernung an, welche benötigt wird damit eine Richtung als "frei" erkannt wird.

Start: Dieses Modell startet nur wenn 0 übergeben wird.

Output:

Links: Bool. 1 Richtung ist Frei, 0 Richtung ist blockiert.

Vorne: Bool. 1 Richtung ist Frei, 0 Richtung ist blockiert.

Rechts: Bool. 1 Richtung ist Frei, 0 Richtung ist blockiert.

Stop: Gibt 1 aus, wenn die Messung abgeschlossen wurde.

ScanRead

Input:

Start: Dieses Modell startet nur, wenn 1 übergeben wird.

Output:

Frei: Bool. 1 Abstand ist groß genug, 0 Abstand ist zu klein.

ScanTurn

Input:

Geschwindigkeit: Drehgeschwindigkeit.

Richtung: 1 eine Drehung nach Links und 0 nach Rechts.

Start: Dieses Modell startet nur, wenn 1 übergeben wird.

Output:

Stop: Gibt 0 aus, wenn der Sensor gedreht wurde.

Schwierigkeiten

In diesem Projekt gab es Schwierigkeiten hinsichtlich der Programmierung. Durch den wenigen Kontakt mit der Simulink-Software waren wichtige Programmierfähigkeiten in der Software nicht vorhanden. Diese mussten zunächst angelernt werden. Dadurch wurden am Anfang viele Tests und Versuche durchgeführt. Diese haben viel Zeit gekostet. Zusätzlich waren Softwarefehler vorhanden, welche auch nicht nach längeren Recherchen nicht gelöst werden konnten.

Bei Versuchen die Software auf die Hardware zu übertragen, entstand beim kompilieren ein Fehler. Die Ursache der Fehler konnte auch nicht durch Kontakt mit dem Mathworks Support rechtzeitig gelöst werden. Sobald eine Lösung gefunden wird, wird diese nachgereicht. Dieser Fehler brachte das Projekt zum Erliegen, da die erstellten Modelle nicht mehr ausreichend getestet werden konnten.

Error Log

   ### Starting build procedure for model: Test
   ### Generating code and artifacts to 'Model specific' folder structure
   ### Generating code into build folder: C:\Users\Michael Menke\OneDrive\Studium\SVN\Elektrotechnik Fachpraktikum\Projekte\70_LabyrinthMitEv3\Gruppe_MTR\SimulinkProjekt70\Test_ert_rtw
   ### Invoking Target Language Compiler on Test.rtw
   ### Using System Target File: C:\Program Files\MATLAB\R2017b\rtw\c\ert\ert.tlc
   ### Loading TLC function libraries
   ### Initial pass through model to cache user defined code
   .
   ### Caching model source code
   ### Writing header file Test_types.h
   .
   ### Writing header file Test.h
   ### Writing header file rtwtypes.h
   ### Writing source file Test.c
   ### Writing header file Test_private.h
   ### Writing source file Test_data.c
   ### Writing header file rtmodel.h
   .
   ### Writing source file ert_main.c
   ### TLC code generation complete.
   ### Evaluating PostCodeGenCommand specified in the model
   ### Using toolchain: Sourcery G++ Lite v2009q3 v4.7 | gmake (64-bit Windows)
   ### 'C:\Users\Michael Menke\OneDrive\Studium\SVN\Elektrotechnik Fachpraktikum\Projekte\70_LabyrinthMitEv3\Gruppe_MTR\SimulinkProjekt70\Test_ert_rtw\Test.mk' is up to date
   ### Building 'Test': "C:\PROGRA~1\MATLAB\R2017b\bin\win64\gmake"  -f Test.mk all
   C:\ProgramData\MATLAB\SupportPackages\R2017b\ [...] -o Test.o Test.c
   In file included from Test.h:27,
                    from Test.c:20:
   C:/PROGRA~1/MATLAB/R2017b/simulink/include/rtw_continuous.h:17: fatal error: rtwtypes.h: No such file or directory
   compilation terminated.
   arm-none-linux-gnueabi-gcc: Menke/OneDrive/Studium/SVN/ELEKTR~1/Projekte/70_LAB~1/GRUPPE~1/SimulinkProjekt70: No such file or directory
   arm-none-linux-gnueabi-gcc: Menke/OneDrive/Studium/SVN/ELEKTR~1/Projekte/70_LAB~1/GRUPPE~1/SimulinkProjekt70/Test_ert_rtw: No such file or directory
   arm-none-linux-gnueabi-gcc: Menke/OneDrive/Studium/SVN/ELEKTR~1/Projekte/70_LAB~1/GRUPPE~1/SimulinkProjekt70/Programme: No such file or directory
   gmake: *** [Test.o] Error 1
   ### Creating HTML report file Test_codegen_rpt.html
   ### Build procedure for model: 'Test' aborted due to an error.
   Error:Error(s) encountered while building "Test":
   ### Failed to generate all binary outputs.

SLAM - Simultaneous Localization and Mapping

Bei SLAM geht es um einen selbstständig agierenden Roboter, welcher sich in einer für ihn unbekannten Umgebung befindet und sich in dieser selbstständig navigiert. Bei dieser Navigation werden externe und interne Messwerte Roboter erfasst. Die externen Werte werden durch Messungen von Sensoren ermittelt. Die internen Werte beschreiben die Drehwinkel der Motoren und die Ausrichtung anderer Aktoren. Durch diese Werte kann dann eine Karte sowie ein Fahrplan erstellt werden. Zur Lösung des SLAM-Problems gibt es verschiedene Verfahren. In Zusammenhang mit der Aufgabenstellung würde sich die Verwendung von einem Grid-basierten SLAM Verfahren anbieten, da das Labyrinth wie ein Raster („Grid“) aufgebaut ist. Selbstverständlich besteht auch die Möglichkeit andere meist aufwändigere SLAM-Verfahren anzuwenden.

OpenSLAM.org

Die Umsetzung eines Grid SLAM-Verfahrens könnte man vereinfachen, indem man eine bereits existierende Implementierung von Openslam.org verwendet. OpenSLAM.org ist eine Plattform, auf der verschiedene SLAM Verfahren fertig implementiert angeboten werden. Diese Implementierungen liegen in verschiedenen Programmsprachen vor. Sie können dann teilweise als S-Function in Simulink eingebunden werden. Um diese anzuwenden muss man jedoch eine Schnittstelle entwickeln. Die Schnittstelle besteht daraus, dass die EV3 Daten (Ultraschallsensor Messungen, Motordrehwinkel, usw.) an die SLAM Implementierung übergeben werden. Je nachdem, für welche Implementierung man sich entscheidet, kann man dann entweder den berechneten Kurs an den EV3 übergeben oder diesen anders weiterverarbeiten.

Ohne Navigation

Man kann SLAM auch zur Anlegung einer Karte anwenden. Dafür agiert die Navigation des EV3 allein auf der Basis von „Lösungsalgorithmen für Irrgärten“. Zur Umsetzung einer reinen Kartenerstellung gibt es zwei Lösungsansätze. Ein Lösungsansatz ist es, die Messwerte auf dem EV3 zu speichern und diese dann später auszuwerten. Der alternative Lösungsweg ist es die Messdaten über eine drahtlose Verbindung wie Bluetooth oder WLAN zu übertragen und anschließend direkt auszuwerten. Bei diesem Lösungsansatz kann das Programm später so erweitern werden, dass der EV3 von dem Computer Anweisungen bekommt.

Fazit

Es war ein hochinteressantes Projekt, in dem verschiedene erlernte Fähigkeiten aus vorherigen Vorlesungen und Übungen verwendet werden konnten. Für die Planung und die Einteilung der Aufgaben sind die Fähigkeiten aus dem Fach „Projektmanagement und Teamarbeit“ verwendet worden. Für die technischen Zeichnungen und für das Labyrinth sind die Kontakte mit der SolidWorks-Software aus dem „CAD-Praktikum“ des 1. Semesters sehr hilfreich gewesen. Für die eigentliche Kernaufgabe des Projektes, das Programmieren des Lego Mindstorms EV3 waren die Vorlesungen und die dazugehörigen Praktika aus der „Informatik I“ und „Informatik II“, sowie die Vorlesungen aus der „Mess- und Regelungstechnik“ hilfreich. Zusätzlich mussten für das Projekt eigenständig Informationen gesammelt werden, um das gewünschte Ergebnis zu erreichen. Dazu gehörte das auseinandersetzten mit der SLAM-Darstellung und mit der Simulink-Software. Bei der Programmierung sind viele Erkenntnisse im Bereich von Matlab und Simulink entstanden, die im weiteren Studiumverlauf hilfreich sein können. Jedoch konnte die Komplexität der Aufgabe nicht durch das reine Wissen aus vorherigen Vorlesungen und Übungen kompensiert werden und aufgrund technischer Probleme mit der Simulink-Software nicht beendet werden.

Projektunterlagen

Die gewünschten Projektunterlagen befinden sich im SVN. Diese sind unter diesem Link erreichbar: LINK

Ausblick

Durch die technischen Probleme mit der Simulink-Software konnten die vorhandenen Programme simuliert, aber nicht auf den Roboter übertragen werden. Die Hardware wurde für das Projekt komplett angefertigt. Somit wäre eine erneute Aufnahme des Projektes mit anschließender fehlerfreien Übertragung der Software auf die Hardware eine Möglichkeit. Des Weiteren können auch andere Varianten eines SLAM-Algorithmus in dem Labyrinth entwickelt und ausprobiert werden.

Die Rahmenbedinungen zur Fertigstellung des Projektes sind nun geben. Als Ansatz für die Weiterführung dieses Projektes kann man die Umsetzung einer Schnittstelle verwenden. Dieses ermöglicht es für zukunftige Gruppen, sich alleine auf die Entwicklung eines SLAM-Verfahrens zu konzentieren.

Literatur

• Monjazeb, A.: Autonomous Robot Navigation Based on Simultaneous Localization and Mapping. Carleton University (Canada), 2008. ISBN 978-049-4368-29-9
• Nüchter, A.: 3D Robotic Mapping: The Simultaneous Localization and Mapping Problem. Heidelberg: Springer, 2009. ISBN 978-354-0898-83-2
• Stachniss, C.: Robot Mapping. Uni Freiburg: Vorlesung, WS 13/14. URL: http://www2.informatik.uni-freiburg.de/~stachnis/. Stand: 01.01.15
• Thrun, S.; u.A.: Probabilistic Robotics. Cambridge: MIT Press, 2005. ISBN 978-026-2201-62-9.
• Thrun, S.; u.A.: FastSLAM: A Scalable Method for the Simultaneous Localization and Mapping Problem in Robotics. New York: Springer, 2007. ISBN 978-354-0463-99-3
• Wang, Z. u.A.: Simultaneous Localization and Mapping: Exactly Sparse Information Filters. Singapore: 2011. ISBN 978-981-4350-31-0

Weblinks

• Martin Berysztak: Self Localization and Mapping mit Lidar- oder Kamera
• Wiki: Simultaneous Localization and Mapping
• CeBIT 2012: Roboter erkundet neues Terrain
• TU-Chemnitz: Kartenerstellung - Umgebungsmodellierung
• TU Dortmund: Simultane Lokalisierung und Kartenerstellung eines autonomen Roboters in einer dynamischen Umgebung bei Anwesenheit von Personen
• TU Dortmund: Simultane Lokalisierung und Kartierung spurgeführter Systeme
• EV3 SLAM
• LEGO MINDSTORMS EV3 Programming Using Simulink
• Obstacle Avoidance using LEGO Mindstorms EV3 and Simulink
• EKF SLAM using LIDAR sensor and Corner Extraction
• ATLAS: SLAM with Lego Mindstorms NXT
• Autonomous Arduino Car Maze Solving with 3 Ultrasonic Sensors
• Maze solving robot Lego Mindstorms
• Particle Filter based SLAM
• NXT Maze Solver that Remembers the Shortest Path
• Monte Carlo Localization with LEGO NXT & MATLAB

Einzelnachweise

Bilder und Diagramme wurden eigenständig erarbeitet

YouTube Video

Projekt 70a:Bau eines Labyrinths für EV3-Roboter

---

→ zurück zum Hauptartikel: WS 17/18: Fachpraktikum Elektrotechnik (MTR) und Angewandte Elektrotechnik (BSE)