Autonomes Fahren im Maßstab 1:10: Unterschied zwischen den Versionen
(22 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 57: | Zeile 57: | ||
* Lastenheft und [[Projekt_27:_Carolo-Cup|Projektdaten der Vorgängen]] in [https://svn.hshl.de/svn/Elektrotechnik_Fachpraktikum/trunk/Projekte/27_Carolo-Cup/ SVN] | * Lastenheft und [[Projekt_27:_Carolo-Cup|Projektdaten der Vorgängen]] in [https://svn.hshl.de/svn/Elektrotechnik_Fachpraktikum/trunk/Projekte/27_Carolo-Cup/ SVN] | ||
== | == Datenablage und Dokumentation == | ||
Als Dokumentationsgrundlage dient dieser Wiki Artikel im HSHL Wiki. | |||
Zur Datenablage wird das Hochschul SVN verwendet: | |||
[https://svn.hshl.de/svn/Studentische_Arbeiten/trunk/Christian_Sievers/] | |||
Sollte Zugriff auf den Ordner benötigt werden, kann dies gerne mit Prof. Schneider abgesprochen werden. | |||
Die Ordnerstruktur ist folgendermaßen gegliedert: | |||
'''10_Projektmanagement:''' Unterlagen zur Projektpresentation und Terminplänen sowie Beschaffung von Einzelteilen. | |||
'''20_System:''' Lastenheft und Pflichtenheft, System Reviews und Dokumentation von Unterlagen und Bildern. | |||
'''30_Hardware:''' Unterlagen zu elektronischen Komponenten, Leiterplatten sowie Einzelteilen. Beinhaltet auch Schaltpläne und Konfigurationen. | |||
'''40_Mechanical Design:''' Unterlagen zum mechanischen Aufbau, sowie Einzelteilen und Zusammenbauanleitungen. | |||
'''50_Software:''' Datenpakete für das Python A-Muster sowie Matlab Software für B- und C-Muster. Zusätzlich Testsoftware für Simulink Module. | |||
'''60_Purchasing:''' Unterlagen zur Beschaffung der benötigten EInzelteile. | |||
'''90_Correspondance:''' Externe Unterlagen vom Carolo Cup und Sunfounder Pi-Car-V. | |||
== Bausatz == | == Bausatz == | ||
Zeile 116: | Zeile 120: | ||
[[Datei:Warnhinweis.JPG]] | [[Datei:Warnhinweis.JPG]] | ||
Wichtig! Von LiPo Akkus geht bei Defekt immer eine Brand- und Explosionsgefahr aus! | <span style="color:#C00000"> '''Wichtig! Von LiPo Akkus geht bei Defekt immer eine Brand- und Explosionsgefahr aus! '''</span> | ||
Die Akkus immer bei Nichtverwendung im Lagerbeutel aufbewahren. | Die Akkus immer bei Nichtverwendung im Lagerbeutel aufbewahren. | ||
Zeile 257: | Zeile 263: | ||
Die Funktion hat in der Simulationsumgebung von Simulink sehr gut funktioniert. Getestet wurde dies über den Source Block Pulse Generator. Nach kurzer Einschwingzeit hat das System erfolgreich den Duty Cicle vom PWM Signal berechnet. Leider funktioniert dies nicht auf dem Raspberry Pi. Da die Systemzeit der Simulation verwendet werden muss, und das Signal erst über das W-Lan Signal zum Raspberry Pi gelangt viel zu hoch und ungbeständig ist, kann der Duty Cicle nicht erfolgreich gemessen und ausgewertet werden. Lösen würde man das Problem, indem man den Prozessor anweist, den Port zu überwachen, wenn es eine Änderung zwischen LOW und HIGH oder HIGH und LOW gibt und nur dann zu reagieren, auch bekannt als Interupt Service Routine. Diese Interupt Service Routine ist allerdings leider nur möglich, wenn der Code, der verwendet wird in C/C++ oder Python geschrieben ist. Dem Simulink Raspberry Pi Modul fehlt an dieser Stelle leider die Echtzeitfähigkeit und Flexibilität. | Die Funktion hat in der Simulationsumgebung von Simulink sehr gut funktioniert. Getestet wurde dies über den Source Block Pulse Generator. Nach kurzer Einschwingzeit hat das System erfolgreich den Duty Cicle vom PWM Signal berechnet. Leider funktioniert dies nicht auf dem Raspberry Pi. Da die Systemzeit der Simulation verwendet werden muss, und das Signal erst über das W-Lan Signal zum Raspberry Pi gelangt viel zu hoch und ungbeständig ist, kann der Duty Cicle nicht erfolgreich gemessen und ausgewertet werden. Lösen würde man das Problem, indem man den Prozessor anweist, den Port zu überwachen, wenn es eine Änderung zwischen LOW und HIGH oder HIGH und LOW gibt und nur dann zu reagieren, auch bekannt als Interupt Service Routine. Diese Interupt Service Routine ist allerdings leider nur möglich, wenn der Code, der verwendet wird in C/C++ oder Python geschrieben ist. Dem Simulink Raspberry Pi Modul fehlt an dieser Stelle leider die Echtzeitfähigkeit und Flexibilität. | ||
== Installation Software== | == Installation Software beim A-Muster mit Phyton== | ||
Die Schritte die notwendig sind, um das Fahrzeug mit der von Sunfounder zur Verfügung gestellten Software zu flashen, sind alle sehr detailliert in der Beschreibung (PDF Sunfounder Pi Smart Video Car V2.0) beschrieben. Um einen Überblick zu gewinnen, sind die einzelnen Schritte hier kurz beschrieben. | Die Schritte die notwendig sind, um das Fahrzeug mit der von Sunfounder zur Verfügung gestellten Software zu flashen, sind alle sehr detailliert in der Beschreibung (PDF Sunfounder Pi Smart Video Car V2.0) beschrieben. Um einen Überblick zu gewinnen, sind die einzelnen Schritte hier kurz beschrieben. | ||
Zeile 296: | Zeile 302: | ||
Dies startet die Installation der Software vom Github Server. | Dies startet die Installation der Software vom Github Server. | ||
==Get on the Road beim A-Muster== | |||
==Get on the Road== | |||
===1. Run the Server - Den Server auf dem Fahrzeug starten=== | ===1. Run the Server - Den Server auf dem Fahrzeug starten=== | ||
Notwendige Schritte: | Notwendige Schritte: | ||
Zeile 392: | Zeile 397: | ||
[x;y;-34] | [x;y;-34] | ||
== Testing == | == Testing A-Muster == | ||
Für das abtesten der A-Muster Anforderungen in Lastenheft und Pflichtenheft, wurde ein Testplan erstellt der systematisch abgearbeitet wurde. Der Testplan ist unter folgendem Pfad im SVN zu finden: | Für das abtesten der A-Muster Anforderungen in Lastenheft und Pflichtenheft, wurde ein Testplan erstellt der systematisch abgearbeitet wurde. Der Testplan ist unter folgendem Pfad im SVN zu finden: | ||
Zeile 445: | Zeile 450: | ||
Auflösung: | Auflösung: | ||
Sollte eine andere Kamera verwendet werden, müssen diese Parameter unbedingt angepasst werden, da es sonst zu Fehlverhalten führen kann! | <span style="color:#C00000"> '''Sollte eine andere Kamera verwendet werden, müssen diese Parameter unbedingt angepasst werden, da es sonst zu Fehlverhalten führen kann! '''</span> | ||
[[Datei:Matlab_Kamera.JPG]] | [[Datei:Matlab_Kamera.JPG]] | ||
Zeile 491: | Zeile 497: | ||
==== Fahrzeug Modul ==== | ==== Fahrzeug Modul ==== | ||
Im Fahrzeugmodul werden die einzelnen Systeme angesteuert. Momentan verfügt das Fahrzeug über Blinker, Lenkung und Antrieb. Weitere Systeme sind prinzipiell möglich und können in das System eingefügt werden. | |||
[[Datei:Matlab Fahrzeugmodul.JPG]] | [[Datei:Matlab Fahrzeugmodul.JPG]] | ||
===== Blinkerausgabe ===== | ===== Blinkerausgabe ===== | ||
Die Blinkerausgabe nutzt die GPIO Ports des Raspberry Pi und steuert die LED's direkt an. Die Blinker sind folgendermaßen verbunden: | |||
GPIO Port 16 -> Blinker Links Vorne und Blinker Links hinten (blau)-> 100 Ohm Vorwiderstand -> Masse | |||
GPIO Port 20 -> Blinker Rechts Vorne und Rechts Links hinten (rot)-> 100 Ohm Vorwiderstand -> Masse | |||
GPIO Port 12 -> Signallampe (weiß) -> 100 Ohm Vorwiderstand -> Masse | |||
[[Datei:Matlab_Blinkerausgabe.JPG]] | [[Datei:Matlab_Blinkerausgabe.JPG]] | ||
===== Lenkung ===== | ===== Lenkung ===== | ||
Der gewünschte Lenkwinkel kommt als Signal zwischen -1 und +1 im Modul an. Der verwendete Servo benötigt ein PWM Signal zwischen -100 und +100. Um den Lenkwinkel nicht voll auszunutzen, habe ich eine Umwandlung auf -90 bis +90 angelegt. | |||
<span style="color:#C00000"> '''Vorsicht! Sollte der Servo ausgetauscht werden, muss unbedingt an dieser Stelle angepasst werden! Die Daten befinden sich dazu im Datenblatt vom Servo. Sollte dies nicht beachtet werden kann dies zum defekt des Servos führen!'''</span> | |||
[[Datei:Matlab_Lenkung.JPG]] | [[Datei:Matlab_Lenkung.JPG]] | ||
===== Antrieb ===== | |||
== Testing B und C-Muster == | |||
Im B und C-Muster sollen sowohl Systemtests als auch Integrationstests durchgeführt werden. | |||
===Systemtests B-Muster=== | |||
Im B-Muster soll die Ansteuerung der drei Module Blinker, Kamera Antrieb und Lenkung einzeln getestet werden. | |||
'''Blinker:''' Über das Simulink Modell werden die Blinker einzeln über ein simulierten Input getestet. Dabei wird geprüft ob die Lampe angeht und ob die Blinkfrequenz stimmt. | |||
Ergebnis: Die Blinker werden richtig angesteuert und die Blinkfrequenz passt zum Lastenhefteintrag. | |||
'''Kamera:''' Das Kamerabild das der Sensor ermittelt wird im Logikmodul erfasst, analysiert und ausgegeben. Im Test ist zu überprüfen, ob ein grünes Objekt richtig erfasst wird. | |||
Ergebnis: Die Kamera kann zuverlässig grüne Objekte im Sichtbereich erkennen. | |||
'''Antrieb:''' Der Antrieb wird über einen simulierten Input von langsam bis schnell durchgefahren. Dabei soll das Fahrzeug ohne Unterbrechung und gleichmäßig fahren. | |||
Ergebnis: Das Fahrzeug bewegt sich ohne Verzögerung oder Aussetzer mit dem vorher eingestelltem Wert. | |||
'''Lenkung:''' wird über einen simulierten Input von links bis rechts durchgefahren. Dabei soll der Lenkwinkel verzögerungsfrei eingestellt werden. | |||
Ergebnis: Das Fahrzeug lenkt ohne Verzögerung oder Aussetzer mit dem vorher eingestelltem Wert. | |||
===Integrationstests C-Muster=== | |||
Im Integrationstest sollen alle Module ineinander greifen und eine gemeinsame Funktion abbilden. | |||
Der Testaufbau sieht dabei vor das das Fahrzeug ein grünes Objekt erkennt und auf dieses zufährt. Dabei soll das Fahrzeug möglichst nah an das Objekt fahren, ohne mit dem Objekt zu kollidieren. | |||
Als Parameter für das optimierte Verhalten dienen dabei: | |||
'''- Der Treshold des Kameramoduls im Logikmodul: Ermitteltes Optimum = 50''' | |||
'''- Die Lookuptable für das Geschwindigkeitsverhalten des Antribs''' | |||
'''- Die Anzahl der Werte, die in den gleitenden Mittelwertfilter des Antriebs eingerechnet werden.''' | |||
'''- Die Anzahl der Werte, die in den gleitenden Mittelwertfilter der Lenkung eingerechnet werden.''' | |||
'''- Die Anzahl der Werte, die in den gleitenden Mittelwertfilter der Posx Ermittlung eingerechnet werden.''' | |||
Wichtig ist dabei, das durch veränderte Umweltbedingungen wie Sonneneinstrahlung, störende Strukturen oder Farben die Parameter unter umständen angepasst werden müssen. | |||
'''Ergebnis:''' Nach Anpassung der erforderlichen Parameter kann das Fahrzeug erfolgreich eine grüße Kunststoffkiste finden und direkt vor dieser zum stehen kommen. Auch wenn die Kiste in einiger Entfernung zum Fahrzeug positioniert wird, erkennt das Fahrzeug die Kiste und fährt zielgerichtet auf sie zu. Bei großen Lenkwinkeln reagiert der Blinker ohne Verzögerung und eine Detektion wird sicher durch die Signallampe signalisiert. | |||
== Kurzzusammenfassung und Ausblick == | == Kurzzusammenfassung und Ausblick == | ||
Zeile 504: | Zeile 574: | ||
Alles in allem habe ich einen guten Stand, um das Projekt im nächsten Semester mit Matlab Simulink zu verbinden und steuern zu können. Eine Große Herausforderung wird es sein zu erkennen, wie Sunfounder die einzelnen Motoren antreibt, da die Steuerplatine, die auf dem Raspberry Pi sitzt, nicht mit Schaltplänen etc. dokumentiert ist. Hier wird man wahrscheinlich eher durch ausprobieren an die richtigen Steuerbefehle kommen. Parallel sind diese Unterlagen bereits bei Sunfounder angefragt. | Alles in allem habe ich einen guten Stand, um das Projekt im nächsten Semester mit Matlab Simulink zu verbinden und steuern zu können. Eine Große Herausforderung wird es sein zu erkennen, wie Sunfounder die einzelnen Motoren antreibt, da die Steuerplatine, die auf dem Raspberry Pi sitzt, nicht mit Schaltplänen etc. dokumentiert ist. Hier wird man wahrscheinlich eher durch ausprobieren an die richtigen Steuerbefehle kommen. Parallel sind diese Unterlagen bereits bei Sunfounder angefragt. | ||
=== 2. Semester === | |||
Die Überführung des Fahrzeugs vom fertigem Bausatz mit lauffähiger Software zum Matlab Simulink Modell hat mir ein sehr tiefes Verständnis für den Systemaufbau vermittelt. Da ein Großteil der verwendeten Komponenten und Ansteuerungsstrategie nicht offen gelegt wurde, musste ich viel Recherchieren und Backward Engineering betreiben. Sehr hilfreich war das überwachen der Bussignale, die im Betrieb des Python Codes verwendet werden. | |||
Die größte Hürde war das verwenden der Fernsteuerung. Durch die sehr hohe Auslastung des Raspberry Pi zum Auslesen der LIN Signale hat dieses Modul leider nicht zum Erfolgt geführt. Hier kann sicherlich das Projekt gut aufgegriffen und optimiert werden. | |||
Rückblickend hat das Projekt eine sehr gute Brücke über alle Disziplinen des Masterstudiengangs BSE geschlagen und praktisch abgerundet. | |||
== Vorschläge für Fortsetzung des Projekts == | |||
- Modul Fernsteuerung betriebsbereit bringen | |||
- Software für Kameratracking mit Fahrspurerkennung erweitern | |||
- Anschluss von Ultraschall, Lidar oder Radar mit dem Sensor und Auswertung der Daten. | |||
- Optimierung der Detektion durch das Kameramodul mit Partikelfilter oder Kalmanfilter, sowie dynamischen Korrekturfaktoren. | |||
- Verbesserung des Logikmoduls auf neue Funktionen wie Labyrinth verlassen, Ball suchen, etc. | |||
- Verwenden der I2C Platine zum sparen von Raspberry Pi Anschlusspins. | |||
== Weblinks == | == Weblinks == |
Aktuelle Version vom 29. Februar 2020, 21:35 Uhr
Autor: Christian Sievers
Betreuer: Prof. Schneider
Art: Projekt
Kurzbeschreibung: Der Artikel beschreibt den Zusammenbau und die Verwendung eines von der Firma Sunfounder hergestellten Bausatz für ein autonomes Fahrzeug auf der Basis des Raspberry Pi 3.
Thema
Autonomes Fahren ist ein wichtiges Ziel auf der Agenda der Automotive OEMs für die kommenden Jahre. Für das Praktikum SDE ist ein Mikrocontroller-gesteuertes Fahrzeug im Maßstab 1:10 zu entwickeln.
Ziel
Entwickeln Sie autonomes Modellfahrzeug, welches in der Zukunft im Praktikum SDE im Studiengang Mechatronik eingesetzt werden kann.
Umfang
Die Praktika habe laut Modulhandbuch folgenden Umfang
- Systementwurf Workload: 108h (45h Präsenz + 63h Selbststudium)
- Systemintegration Workload: 150h (60h Präsenz + 90h Selbststudium)
Der Umfang entspricht 258h. Bei einer 40 Stunden Woche entspricht dies ca. 7 Wochen.
Aufgabenstellung
Systementwurf
- Projektplanung und Zeit-Management*
- Entwickeln Sie konsequent nach dem V-Modell.
- Aufstellung der Anforderungen (Lastenheft)*
- Raspberry Pi für die LiDAR und Videoverarbeitung
- Optional Berücksichtigung von 3D-ToF-Sensorik
- Arduino zur Auswertung einfacher Sensorik und Ansteuerung der Aktoren
- Längs- und Querregleregler
- WLAN Kommunikation mit einem Diagnose-PC
- Display ansteuern
- Umsetzung der Anforderungen in ein Pflichtenheft*
- Planung der Hardware*
- Konstruktion und 3D-Druck des mechanischen Aufbaus des Fahrzeugs*
- QV-Antrag und Beschaffung der Bauteile
Systemimplementierung
- Modellbasierte Programmierung mit Simulink aufbauend auf der bestehenden Online/Offline-Software*
- Inbetrieb des Systems*
- Test der Anforderungen entsprechend der Methoden der Vorlesung Reliability Engineering (statische und dynamische Code-Tests, Modul- und Systemtests)
- Testdokumentation*
- Dokumentation nach wissenschaftlichem Stand*
* Diese Meilensteine müssen mit Prof. Schneider in einem persönlichen Gespräch abgestimmt und dokumentiert werden.
Anforderung
- Wissenschaftliche Vorgehensweise (Requirements, Projektplan, etc.)
- Wöchentliche Fortschrittsberichte
- Regelmeeting
- Projektvorstellung im Wiki
- ggf. Literaturrecherche mit Citavi
- Softwareentwicklung nach HSHL Standard, tägliche Datensicherung in SVN
Getting Started
- Nutzen Sie die Matlab Academy, um sich in Matlab Simulink einzuarbeiten.
- Studieren Sie das Carolo Cup Regelwerk zur Erstellung der Anforderungen.
- Erstellen Sie ein Lastenheft.
- Für die Entwicklung steht ein Bausatz "SunFounder Raspberry Pi Smart Video Car Kit V2.0" zur Verfügung.
- Lastenheft und Projektdaten der Vorgängen in SVN
Datenablage und Dokumentation
Als Dokumentationsgrundlage dient dieser Wiki Artikel im HSHL Wiki. Zur Datenablage wird das Hochschul SVN verwendet: [1] Sollte Zugriff auf den Ordner benötigt werden, kann dies gerne mit Prof. Schneider abgesprochen werden. Die Ordnerstruktur ist folgendermaßen gegliedert:
10_Projektmanagement: Unterlagen zur Projektpresentation und Terminplänen sowie Beschaffung von Einzelteilen.
20_System: Lastenheft und Pflichtenheft, System Reviews und Dokumentation von Unterlagen und Bildern.
30_Hardware: Unterlagen zu elektronischen Komponenten, Leiterplatten sowie Einzelteilen. Beinhaltet auch Schaltpläne und Konfigurationen.
40_Mechanical Design: Unterlagen zum mechanischen Aufbau, sowie Einzelteilen und Zusammenbauanleitungen.
50_Software: Datenpakete für das Python A-Muster sowie Matlab Software für B- und C-Muster. Zusätzlich Testsoftware für Simulink Module.
60_Purchasing: Unterlagen zur Beschaffung der benötigten EInzelteile.
90_Correspondance: Externe Unterlagen vom Carolo Cup und Sunfounder Pi-Car-V.
Bausatz
Der Zusammenbau ist in der Dokumentation von Sunfounder sehr ausführlich beschrieben. Falls Fragen aufkommen kann auch das von mir erstellte Video verwendet werden:
Zusammenbauanleitung auf Youtube
Beschaffung
Zur Inbetriebnahme sind folgende Komponenten beschafft worden:
Bausatz Sunfounder Smart Video Car Kit V2.0
Der Bausatz wurde zu Beginn des Projekts bereits durch Prof. Schneider zur Verfügung gestellt.
Preis (08.06.2019) US$115.00
Link zum Onlineshop von Sunfounder
Batterien
Industriezelle, Li-Ion, 18650, 3,7 V, 3200 mAh, Button Top
Preis (08.06.2019) 15,59 €
Benötigt werden 2 Stück für das Fahrzeug. Beschafft wurden 4 Stück.
Batterie Ladegerät
XTAR D2 :: AC Ladegerät, 2 A, 2 slot
Das Ladegerät ist geeignet für diverse Modellbauakkus, unter anderem auch für die verwendeten 18650 LiPo.
Preis (08.06.2019) 14,20 €
Batterie Lagerbeutel
brandschutzbeutel-fuer-li-polymer-akkus-lipo-guard
Preis (08.06.2019) 8,24 €
Wichtig! Von LiPo Akkus geht bei Defekt immer eine Brand- und Explosionsgefahr aus!
Die Akkus immer bei Nichtverwendung im Lagerbeutel aufbewahren.
Akkus ohne Lagerbeutel nicht unbeaufsichtigt lassen, nicht Wärmequellen und mechanischer Belastung aussetzen.
Zusammenbau
Der Zusammenbau erfolgte mit Hilfe der dem Bausatz beigefügtem Bausatz. Der Bausatz ist gut bebildert und hilft, die einzelnen Schritte zu verstehen. Zusätzlich ist ein Video erstellt worden, in dem der gesamte Zusammenbau des Modells dokumentiert wurde. Hier kann sich jeder einzelne Schritt des mechanischen Zusammenbaus angeschaut werden, falls Fragen zum Aufbau aufkommen. Die Schritte des Aufbaus sind dabei identisch zur PDF vom Hersteller gewählt, damit man sich schnell orientieren und zum momentanen Schritt zu springen.
Das Video ist momentan im SVN vorhanden und wird, da Grafiken vom Hersteller Sunfounder vernwedet werden, erst online gestellt, wenn die Freigabe erfolgt ist. Dann wird es auf Youtube frei verfügbar sein.
Verkabelung der Platinen
Komponenten
Grundplatten
Die Grundplatten bestehen auf einem Plexiglas. Alle Teile sind bereits fertig zugeschnitten und müssen nicht mechanisch nachbearbeitet werden. Die Teile sind beidseitig mit einer Schutzfolie versehen, die vorab entfernt werden muss.
Servos
Kupplungsgetriebe-Digitalservo mit eingebautem Gleichstrommotor Nach einer bestimmten Belastung kuppelt und schützt das Lenkgetriebe das Produkt automatisch vor Beschädigung.
Elektrische Eigenschaften:
Motoren
Die Beigefügten Motoren sind Gleichstrommotoren mit drehzahlreduzierendem Getriebe.
Elektrische Eigenschaften:
Platinen
TB6612_Motor_driver
Das TB6612 Motortreibermodul ist geeignet für Motoren mit geringer Wärmeentwicklung und kleinem Motorgehäuse.
PCA9685_PWM_Driver.JPG
PCA9685 16-Kanal-12-Bit-I2C-Bus-PWM-Treiber. Es unterstützt eine unabhängige PWM-Ausgangsleistung und ist ein einfach zu verwendender 4-Draht-I2C-Port für den parallelen Anschluss von 3-Farben-Ports für die PWM-Ausgabe.
Robot_hats.JPG
Robot HATS ist ein speziell für einen 40-Pin-Raspberry-Pi entwickelter HAT (Hardware Attached on Top), der mit den Raspberry-Pi-Modellen B +, 2-Modell B und 3-Modell B kompatibel ist. Er versorgt den Raspberry-Pi über die GPIO-Ports mit Strom. Dank des Designs der idealen Diode nach den Regeln von HATS kann der Raspberry Pi sowohl über das USB-Kabel als auch über den Gleichstromanschluss mit Strom versorgt werden. Dadurch wird verhindert, dass die TF-Karte durch tiefenentladene Batterien beschädigt wird. Der PCF8591 wird als ADC-Chip mit I2C-Kommunikation und der Adresse 0x48 verwendet.
Räder
Die verwendeten Räder sind aus einem Kunststoff, der mit Gummiüberzug versehen ist. Die Räder für vorne und hinten sind unterschiedlich im Design, aber gleich im Durchmesser.
Kamera
Die beigefügte Kamera besitzt einen Weitwinkel von 120 °.
Fernsteuerung
Um das Fahrzeug im Handbetrieb einsetzen zu können, wird die Modellbaufernsteuerung Reflex Wheel ultimate touch 2.4g von Carson Modell Sport eingesetzt. Diese Basiert auf einer Handsteuerung mit Gashebel, Steuerrad und diversen Schaltern, sowie einer Signaleinheit die am Heck des Fahrzeugs befestigt wird. Diese besitzt eine Antenne, die am höchsten Punkt des Fahrzeugs befestigt ist, um das 2.4 Ghz Signal zu empfangen, sowie diverser Kanäle, die das Signal zum Raspberry Pi übertragen.
Jeder Kanal besitzt drei Anschlüsse: Power (3.3V), GND und Signal. Die Signale Gas/Bremse, Steuerung und Schalter sind über drei seperate I/O Ports des Raspberry Pi verbunden. Das Signal wird über PWM übertragen. Dabei wird das Signal nur digital von niedrig zu hoch und wieder zu niedrig geschaltet, wobei die Dauer des hoch Pegels gemessen werden muss. Das Verhältnis von hoch zu niedrig gibt dann den analogen Signalwert. Da das Signal zyklisch auf dem Raspberry Pi gegeben wird, ist auch eine zyklische Signalauswertung notwendig. Diese wird auf folgende Art realisiert:
In die Funktion in Simulink wird das Signal vom I/O Port geschickt, sowie die Systemzeit. Für den Raspberry Pi gibt es leider keinen Systemblock der die interne Prozessorzeit ausgibt, deswegen muss die Simulationszeit verwendet werden. In der Funktion werden steigende und fallende Flanken detektiert und die Zeit gemessen. Aus der Funktion kommt der Duty Cicle zwischen 0% und 100%. Um dies auch während der Simulation sichtbar zu machen, ist eine Anzeige hinzugefügt worden.
function [y,DutyCicle] = PWM_Analyse(u,time)
persistent status % Sind wir gerade bei High oder Low
persistent firstRun % Prüfung ob schon einmal durchgelaufen
persistent Zeit % Systemzeit
persistent ZeitOutput % Ausgabezeit nach Berechnung
persistent Duty % Dutycicle Zeit
persistent DutyCicleMom % Dutycicle Gesamtzeit
if isempty(firstRun) % Initialisierung
status = 0; firstRun = 1; Zeit = 0; ZeitOutput = 0; Duty = 0; DutyCicleMom = 0;
end
if u > 1.5 % Sprung zu HIGH
if status == 0 % Vorher LOW Zeit = time status =1 Duty = Duty +1; DutyCicleMom = time / Duty; end
end if u< 1.5 % Sprung zu LOW
if status == 1 % Vorher HIGH ZeitOutput = time - Zeit status = 0 end
end y = ZeitOutput; DutyCicle = ZeitOutput/ DutyCicleMom;
Die Funktion hat in der Simulationsumgebung von Simulink sehr gut funktioniert. Getestet wurde dies über den Source Block Pulse Generator. Nach kurzer Einschwingzeit hat das System erfolgreich den Duty Cicle vom PWM Signal berechnet. Leider funktioniert dies nicht auf dem Raspberry Pi. Da die Systemzeit der Simulation verwendet werden muss, und das Signal erst über das W-Lan Signal zum Raspberry Pi gelangt viel zu hoch und ungbeständig ist, kann der Duty Cicle nicht erfolgreich gemessen und ausgewertet werden. Lösen würde man das Problem, indem man den Prozessor anweist, den Port zu überwachen, wenn es eine Änderung zwischen LOW und HIGH oder HIGH und LOW gibt und nur dann zu reagieren, auch bekannt als Interupt Service Routine. Diese Interupt Service Routine ist allerdings leider nur möglich, wenn der Code, der verwendet wird in C/C++ oder Python geschrieben ist. Dem Simulink Raspberry Pi Modul fehlt an dieser Stelle leider die Echtzeitfähigkeit und Flexibilität.
Installation Software beim A-Muster mit Phyton
Die Schritte die notwendig sind, um das Fahrzeug mit der von Sunfounder zur Verfügung gestellten Software zu flashen, sind alle sehr detailliert in der Beschreibung (PDF Sunfounder Pi Smart Video Car V2.0) beschrieben. Um einen Überblick zu gewinnen, sind die einzelnen Schritte hier kurz beschrieben.
A. Burn the Image
In diesem Schritt wird das Betriebssystem auf eine SD Karte geflasht. Benötigt wird Software, die ein Image verarbeiten kann, z.B. win32DiskImager (Siehe unten). Leider ist ein sehr gravierender Fehler in der Konfigurationsbeschreibung der Anleitung enthalten. Sunfounder ist bereits informiert und wird dies vermutlich im nächsten Update korrigieren. Die W-Lan Config startet nicht mit networ= sondern mit network=
Zur Netzwerkverbindung habe ich einen alten W-Lan Router verwendet, das Fahrzeug kann aber auf jeden beliebiges Netzwerk konfiguriert werden.
B. Car Power Supply
Es wird beschrieben, dass das Fahrzeug sowohl über USB, als auch über die Akkus während der gesamten Prozedur mit Strom versorgt werden muss.
C. Log into Raspberry Pi
Zum Einloggen auf den Raspberry Pi wird die IP Adresse benötigt. Diese kann z.B. über das Tool Advanced IP Scanner (siehe unten) ermittelt werden. Für Windows Nutzer wird zum einloggen PuTTY (siehe unten) empfohlen. Dort wird die IP Adresse eingetragen. Die Standard Login Daten beim Raspberry Pi sind User: pi Passwort: raspberry. Die Passwort Eingabe ist wird nicht dargestellt, erfolgt aber nach Betätigung von Enter.
D. Get Source Code
Dieser Schritt läd den Sourcecode aus dem Internet herunter. Der Router, der verwendet wird, muss zwingend Internetzugriff aufweisen.
E. Go to the code directory
Hier wird auf den richtigen Pfad für die Installation der Software gewechselt.
F. Install the Enviroment via the script
Dies startet die Installation aller notwendigen Pakete.
G. Configure the Servo to 90 degrees
Diese Software stellt die Servos einmalig auf ihre Nullstellung ein, bevor alle mechanisch verbunden werden. Wichtig! Wenn dieser Schritt nicht vorab durchgeführt wird, kann es zu defekten der Servos kommen!
Installing the client
Dies startet die Installation der Software vom Github Server.
Get on the Road beim A-Muster
1. Run the Server - Den Server auf dem Fahrzeug starten
Notwendige Schritte:
1) Vollgeladene Batterien in das Fahrzeug stecken.
2) Fahrzeug über den Schalter an der Platine einschalten.
3) Auf das Fahrzeug schalten mit Logindaten: pi und raspberry
4)Befehl ausführen: cd ~/SunFounder_PiCar-V/remote_control
5) Befehl ausführen: sudo ./start
2. Run the Client - Den PC mit dem Fahrzeug verbinden
Notwendige Schritte: 6) Einloggen mit Browser (Siehe unten) auf Adresse: http://<IP adress>:8000/ dort die IP Adresse vom Raspberry Pi einsetzen, z.B. http://192.168.0.25:8000/
7) Schalter LETS ROCK im Browser betätigen.
8) Oben links auf die Einstellungen gehen.
9) Dort die Servos falls nötig auf die Nullstellung stellen und überprüfen, ob die hinteren Antriebe richtig herum drehen. Falls nicht können diese in der Software oder am Fahrzeug invertiert werden.
10) Einstellung speichern.
11) Mit dem Fahrzeug Spaß haben! Gesteuert wird über die Pfeiltasten (Kamera) und über WASD (Fahrzeug). Mit den Zahlen 1-5 kann die Geschwindigkeit angepasst werden.
Software Tools
Win32DiscImager
Mit diesem Tool kann das Image für das Raspberry Pi Betriebssystem auf die SD Karte geflasht werden. Es werden zwei Partitionen erstellt, eins für das Betriebssystem und eins für die Datenverwaltung (Software, Medien, etc).
Link zum Download bei www.heise.de
Advanced IP Scanner
Der Advanced IP Scanner kann genutzt werden um die dynamische IP vom Raspberry Pi herauszufinden. Die IP wird benötigt, um sich auf den Raspberry Pi per Netzwerk zu verbinden und Änderungen vorzunehmen, sowie um den Browser Client zu verbinden.
Link zum Download bei www.advanced-ip-scanner.com
PuTTY
Das Tool PuTTy ist notwendig, um per Netzwerk Fernzugriff auf den Raspberry Pi zuzugreifen. Dabei ist die IP Adresse vom Raspberry Pi notwendig. Das Tool ist ähnlich der Eingabeaufforderung unter Windows und die erforderlichen Befehle sind alle in der Sunfounder Doku zu finden.
Link zum Download bei www.heise.de
Browser: Internet Explorer/Google Chrome/FIrefox
Um das Fahrzeug fernsteuern zu können, wird ein Standard Browser benötigt. Dabei wird das Fahrzeug über die dynamische IP Adresse mit dem Zusatz :8000 verbunden. Die Tests wurden mit dem Internet Explorer 7 vorgenommen. Da eigentlich jeder PC einen Browser vorinstalliert hat, sollte der vorhandene getestet werden, bevor ein anderer installiert wird.
Mechanischer Aufbau
Koordinatensysteme im Fahrzeug
Schwerpunkt des Fahrzeugs
Der Schwerpunkt des Fahrzeugs wurde über Aufhängung und Kippversuche ermittelt (Siehe Testplan).
Referenzpunkte für Software
Die Software benötigt für die korrekte Interpretation der Messdaten die Referenzpositionen der Kamera. Für die Erstellung des Einspurmodells, um die Fahreigenschaften abzubilden, werden Achsabstände, Spurbreite, Lenkwinkel etc. verwendet. Dies sind die relevanten Referenzpunkte am Fahrzeug:
Achsensystem 1:
Referenz Vorderachsmittelpunkt
Koordinaten: [0;0;0]
Achssysteme 2-5:
Vorderachse links [0;19;0]
Vorderachse rechts [0;-19;0]
Hinterachse links [-138;19;0]
Hinterachse rechts [-138;-19;0]
Achssysteme 5,6:
Kameradrehpunk 5: [36;0;21]
Kameradrehpunkt 6: [91;0;39]
Grundfläche Fahrbahn:
[x;y;-34]
Testing A-Muster
Für das abtesten der A-Muster Anforderungen in Lastenheft und Pflichtenheft, wurde ein Testplan erstellt der systematisch abgearbeitet wurde. Der Testplan ist unter folgendem Pfad im SVN zu finden:
D:\SVN\Autonomes_fahren\20_System\Testreport_A-sample.docx
Der Testablauf sah folgendermaßen aus:
Die ausführlichen Ergebnisse sind im Dokument dokumentiert. Die Tests haben folgende Ergebnisse hervorgebracht:
Geschwindigkeit: Das Fahrzeug kann in 5 Stufen gefahren werden. Die Geschwindigkeit variiert zwischen 250 und 829 cm/s.
Lenkwinkel: Es ergibt sich ein Lenkwinkel von 37° und einen Kreisumfang von 57cm.
Balltracking: Dieser Test ist nach Absprache mit Prof. Schneider entfernt worden, da er für die weiteren Projektabschnitte nicht erforderlich ist.
Geometrische Tests:
Fahrzeugabmessungen : BxLxH: 13,2cmx28,5cmx10,8cm (Zusätzlich maximal 4,1cm in der Höhe durch die Position der Kamera)
Radstand: 14,5cm
Spurweite: Messen mit Zentimetermaß oder Zollstock, anschließende Dokumentation 11cm
Höhe: Messen mit Zentimetermaß oder Zollstock, anschließende Dokumentation 10,8cm bei Kamera horizontal ausgerichtet, 14,9cm bei Kamera vertikal ausgerichtet
B-Muster und Serie
Matlab Simulink System
Gesamtsystem
Das System das in Matlab Simulink realisiert wurde, teilt sich in drei Bereiche auf:
1) Input: Dort werden alle Eingangssignale, die das Fahrzeug empfängt gesammelt. Im aktuellem Fall wäre dies der Input durch die Kamera. Sollte weitere Sensorik wie Ultraschall, Lidar, Radar etc. hinzukommen, können diese Module auch hier hinzugefügt werden. Die Signale dieses Systems fließen dann in den Bereich der Verarbeitung.
2) Verarbeitung: In diesem Bereich werden die Signale, die die Module Blinkermodul, Logiksystem und Fernbedienung austauschen verknüpft. Die Datenverarbeitung wird so angepasst, das die Signale in den Output Bereich fließen können.
3) Im Output Modul werden die Signale die durch Input und Verarbeitung erzeugt werden vom Fahrzeug interpretiert und verarbeitet.
Kamera Input
Im Kamera Modul wird der Baustein der Raspberry Pi Toolbox genutzt, um die einzelnen Farbkanäle (Rot Gelb Blau) weiterzugeben. Dabei ist wichtig das im Modul die richtige Bildwiderholfrequenz und Auflösung eingestellt ist. Diese wurde dem Datenblatt der verwendeten Kamera entnommen.
Bildwiderholfrequenz:
Auflösung:
Sollte eine andere Kamera verwendet werden, müssen diese Parameter unbedingt angepasst werden, da es sonst zu Fehlverhalten führen kann!
Blinkermodul
Das Blinkermodul besitzt drei Eingangssignale: BlinkerLinks, BlinkerRechts und Signallampe. Die beiden Signale BlinkerLinks und BlinkerRechts werden durch ein Sägezahnsignal zum blinken gebracht. Das Signal der Signallame wird einfach durchgeführt, da kein Blinken erforderlich ist.
Zur Überprüfung der Ergebnisse ist ein Scope zugeschaltet. So kann der Output der Blinker auch in der Software überwacht werden.
Logikmodul
Das Logikmodul ist das Kernstück des Fahrzeugverhaltens. Als Input dient das Kamerasignal, getrennt in die drei Farbkanäle.
Die einzelnen Module werden weiter unten genauer beschrieben und gezeigt.
Logikmodul BW Filter
Im Blocksatz ObjektDetection wird das Signal auf einen grünen Kanal gefiltert und ein BW Resultat ausgegeben. Dabei kann der Schwellwert über den Input Tresh angepasst werden.
Das Modul FindCentroid
Im Block FindCentroid wird die Mitte der größten grünen Fläche ermittelt. Dabei wird sowohl die Position, als auch die Größe des Objekts ausgegeben.
Die Größe der größten Fläche wird anschließend über eine Lookup Table als Geschwindigkeitsparameter ausgegeben. Damit der Wert normiert wird, ist vorher eine Multiplikation eingefügt.
Die Werte der Posx und Posy werden anschließend normiert auf Werte zwischen -1 und 1. Dann wird aus der Posx der Lenkwinkel ermittelt und an das Fahrzeug übertragen.
Das Modul MarkImage
Im Modul Mark Image wird die in FindCentroid ermittelte Position dem Videobild hinzugefügt und anschließend im Display ausgegeben. So kann die Logik des Moduls besser ausgewertet und optimiert werden.
Fernbedienung Modul
Da es Probleme mit dem Modul der Fernbedienung gab, ist dieses Modul mit festen Parametern versehen. Möchte man zukünftig eine Fernbedienung verwenden, können an dieser Stelle die Basispararmeter Lenkwinkel(-1 bis 1), Geschwindigkeit(0 bis 1) und FernbedienungAn(0 für aus und 1 für an) angesteuert werden.
Fahrzeug Modul
Im Fahrzeugmodul werden die einzelnen Systeme angesteuert. Momentan verfügt das Fahrzeug über Blinker, Lenkung und Antrieb. Weitere Systeme sind prinzipiell möglich und können in das System eingefügt werden.
Blinkerausgabe
Die Blinkerausgabe nutzt die GPIO Ports des Raspberry Pi und steuert die LED's direkt an. Die Blinker sind folgendermaßen verbunden:
GPIO Port 16 -> Blinker Links Vorne und Blinker Links hinten (blau)-> 100 Ohm Vorwiderstand -> Masse
GPIO Port 20 -> Blinker Rechts Vorne und Rechts Links hinten (rot)-> 100 Ohm Vorwiderstand -> Masse
GPIO Port 12 -> Signallampe (weiß) -> 100 Ohm Vorwiderstand -> Masse
Lenkung
Der gewünschte Lenkwinkel kommt als Signal zwischen -1 und +1 im Modul an. Der verwendete Servo benötigt ein PWM Signal zwischen -100 und +100. Um den Lenkwinkel nicht voll auszunutzen, habe ich eine Umwandlung auf -90 bis +90 angelegt.
Vorsicht! Sollte der Servo ausgetauscht werden, muss unbedingt an dieser Stelle angepasst werden! Die Daten befinden sich dazu im Datenblatt vom Servo. Sollte dies nicht beachtet werden kann dies zum defekt des Servos führen!
Antrieb
Testing B und C-Muster
Im B und C-Muster sollen sowohl Systemtests als auch Integrationstests durchgeführt werden.
Systemtests B-Muster
Im B-Muster soll die Ansteuerung der drei Module Blinker, Kamera Antrieb und Lenkung einzeln getestet werden.
Blinker: Über das Simulink Modell werden die Blinker einzeln über ein simulierten Input getestet. Dabei wird geprüft ob die Lampe angeht und ob die Blinkfrequenz stimmt.
Ergebnis: Die Blinker werden richtig angesteuert und die Blinkfrequenz passt zum Lastenhefteintrag.
Kamera: Das Kamerabild das der Sensor ermittelt wird im Logikmodul erfasst, analysiert und ausgegeben. Im Test ist zu überprüfen, ob ein grünes Objekt richtig erfasst wird.
Ergebnis: Die Kamera kann zuverlässig grüne Objekte im Sichtbereich erkennen.
Antrieb: Der Antrieb wird über einen simulierten Input von langsam bis schnell durchgefahren. Dabei soll das Fahrzeug ohne Unterbrechung und gleichmäßig fahren.
Ergebnis: Das Fahrzeug bewegt sich ohne Verzögerung oder Aussetzer mit dem vorher eingestelltem Wert.
Lenkung: wird über einen simulierten Input von links bis rechts durchgefahren. Dabei soll der Lenkwinkel verzögerungsfrei eingestellt werden.
Ergebnis: Das Fahrzeug lenkt ohne Verzögerung oder Aussetzer mit dem vorher eingestelltem Wert.
Integrationstests C-Muster
Im Integrationstest sollen alle Module ineinander greifen und eine gemeinsame Funktion abbilden. Der Testaufbau sieht dabei vor das das Fahrzeug ein grünes Objekt erkennt und auf dieses zufährt. Dabei soll das Fahrzeug möglichst nah an das Objekt fahren, ohne mit dem Objekt zu kollidieren. Als Parameter für das optimierte Verhalten dienen dabei:
- Der Treshold des Kameramoduls im Logikmodul: Ermitteltes Optimum = 50
- Die Lookuptable für das Geschwindigkeitsverhalten des Antribs
- Die Anzahl der Werte, die in den gleitenden Mittelwertfilter des Antriebs eingerechnet werden.
- Die Anzahl der Werte, die in den gleitenden Mittelwertfilter der Lenkung eingerechnet werden.
- Die Anzahl der Werte, die in den gleitenden Mittelwertfilter der Posx Ermittlung eingerechnet werden.
Wichtig ist dabei, das durch veränderte Umweltbedingungen wie Sonneneinstrahlung, störende Strukturen oder Farben die Parameter unter umständen angepasst werden müssen.
Ergebnis: Nach Anpassung der erforderlichen Parameter kann das Fahrzeug erfolgreich eine grüße Kunststoffkiste finden und direkt vor dieser zum stehen kommen. Auch wenn die Kiste in einiger Entfernung zum Fahrzeug positioniert wird, erkennt das Fahrzeug die Kiste und fährt zielgerichtet auf sie zu. Bei großen Lenkwinkeln reagiert der Blinker ohne Verzögerung und eine Detektion wird sicher durch die Signallampe signalisiert.
Kurzzusammenfassung und Ausblick
1. Semester
Der Aufbau des Bausatzes war eine Große Herausforderung für mich. Im Laufe des Projekts tauchten einige Fehler auf, die auf die mangelhafte Dokumentation und Software von Sunfounder zurückzuführen sind. Die Fehlersuche war sehr zeitintensiv, hat aber auch ein deutlich tieferes Verständnis der Software zur Folge gehabt. Dies zeigt, dass auch große Firmen nicht fehlerfrei arbeiten. Der Fehler ist Sunfounder bereits mitgeteilt worden und wird hoffentlich im nächsten Release behoben. Der mechanische Aufbau war sehr gut beschrieben und macht einen sehr guten Eindruck. Einige weiteren Anpassungen bzgl. Kameraposition wird es im nächsten Semester geben.
Alles in allem habe ich einen guten Stand, um das Projekt im nächsten Semester mit Matlab Simulink zu verbinden und steuern zu können. Eine Große Herausforderung wird es sein zu erkennen, wie Sunfounder die einzelnen Motoren antreibt, da die Steuerplatine, die auf dem Raspberry Pi sitzt, nicht mit Schaltplänen etc. dokumentiert ist. Hier wird man wahrscheinlich eher durch ausprobieren an die richtigen Steuerbefehle kommen. Parallel sind diese Unterlagen bereits bei Sunfounder angefragt.
2. Semester
Die Überführung des Fahrzeugs vom fertigem Bausatz mit lauffähiger Software zum Matlab Simulink Modell hat mir ein sehr tiefes Verständnis für den Systemaufbau vermittelt. Da ein Großteil der verwendeten Komponenten und Ansteuerungsstrategie nicht offen gelegt wurde, musste ich viel Recherchieren und Backward Engineering betreiben. Sehr hilfreich war das überwachen der Bussignale, die im Betrieb des Python Codes verwendet werden.
Die größte Hürde war das verwenden der Fernsteuerung. Durch die sehr hohe Auslastung des Raspberry Pi zum Auslesen der LIN Signale hat dieses Modul leider nicht zum Erfolgt geführt. Hier kann sicherlich das Projekt gut aufgegriffen und optimiert werden.
Rückblickend hat das Projekt eine sehr gute Brücke über alle Disziplinen des Masterstudiengangs BSE geschlagen und praktisch abgerundet.
Vorschläge für Fortsetzung des Projekts
- Modul Fernsteuerung betriebsbereit bringen
- Software für Kameratracking mit Fahrspurerkennung erweitern
- Anschluss von Ultraschall, Lidar oder Radar mit dem Sensor und Auswertung der Daten.
- Optimierung der Detektion durch das Kameramodul mit Partikelfilter oder Kalmanfilter, sowie dynamischen Korrekturfaktoren.
- Verbesserung des Logikmoduls auf neue Funktionen wie Labyrinth verlassen, Ball suchen, etc.
- Verwenden der I2C Platine zum sparen von Raspberry Pi Anschlusspins.
Weblinks
- Carolo Cup Homepage
- Carolo-Cup 2018: Kleine Autos ganz groß
- SunFounder Raspberry Pi Smart Video Car Kit V2.0
- Zukunftsrauschen: Mobilität in Meschede
Siehe auch
- Studentische Arbeiten bei Prof. Schneider
- Anforderungen an eine wissenschaftlich Arbeit
- Programmierrichtlinien für Matlab
- SVN Repositorium
→ zurück zum Hauptartikel: Studentische Arbeiten