Zuständiger Professor: Prof. Dr. Mächtel

Hochschule: HTWG

Scheinart: Projekt

Teampartner: Dennis Griesser & Torben Woltjen

Semester: SS2015

Fortführung des Projektes: Ja

Status: Pausiert seit Juli 2015

Während unseres Projektes soll ein realzeitfähiger "Putzroboter" realisiert werden, welcher dazu in der Lage sein soll, sich in einem Raum autonom fortzubewegen. Dabei wird davon ausgegangen, dass der Fußboden eine ebene Fläche darstellt: Es sollten keine kleineren Absätze oder ähnliche Hindernisse vorhanden sein. Größere Hindernisse wie Möbel, Tischbeine usw. sind allerdings erlaubt. Letztendlich soll der Roboter dazu in der Lage sein, sich mehr oder weniger zufällig im Raum zu bewegen, ohne dabei Möbel oder andere Gegenstände zu berühren.

Die Abstandmessung zu den vorhandenen Hindernissen erfolgt durch drei Ultraschallsensoren, welche an der Vorderseite des Roboters angebracht werden. Die Sensoren werden dazu periodisch abgefragt und die Rückgabewerte werden anschließen verarbeitet und interpretiert, das heißt in eine absolute Entfernung zu den vor dem Roboter vorhandenen Gegenständen umgerechnet. Diese Informationen werden dazu verwendet, die Motoren des Roboters anzusteuern und eine autonome und kollisionsfreie Fahrt des Roboters im Raum zu ermöglichen.

Im Gegensatz zu den kommerziell erwerbbaren Putzrobotern werden wir mehr Wert auf die Navigation als auf die Reinigungsqualität legen: Der Roboter soll einfach ein Swiffer-Staubtuch unter sich mitziehen.

Die drei Ulraschallsensoren sollen in einem noch zu definierenden Zeitintervall angesteuert werden. Derzeit wissen wir aber noch nicht, wie diese sich verhalten, also ob die Sensoren gleichzeitig verwendet werden können, oder man sie nacheinander abfragen muss, um eine gegenseitige Beeinflussung zu verhindern. Die Ultraschallsensoren können den Abstand zwischen sich selber und einem Gegenstand ermitteln, indem sie einen kurzen Ultraschallimpuls aussenden und das Echo wieder empfangen. Anhand der dazwischenliegenden Zeit und der Schallgeschwindigkeit, lässt sich anschließen der Abstand zwischen Ultraschallsensor und Gegenstand berechnen.

Nach Vorliegen der Sensordaten, soll der Roboter entscheiden, was diese für die Ansteuerung der Motoren bedeuten. Wenn der Roboter auf ein Hindernis zusteuert (oder sich ein Hindernis dem Roboter nähert), soll er sich um 25° drehen und erneut eine Abstandsmessung durchführen. Dieser Vorgang wird so lange wiederholt, bis der Roboter genügend Abstand zu allen Gegenständen vor ihm hat und wieder geradeaus weiterfahren kann.

Die Steuerung des Roboters erfolgt mehr oder weniger zufällig nach dem oben beschriebenen Prozess. Die Anforderung liegt darin, dass der Roboter nicht mit einem Objekt kollidiert.

Eine Schwierigkeit wird darin liegen, die drei Sensoren so auszuwerten, dass alle Realzeitbedingungen erfüllt werden und der Roboter nebenher noch weiterfahren kann. Da der von uns verwendete Raspberry Pi eine Singlecore-CPU verwendet, können wir diese zwei Aufgaben (Auswerten der Sensoren sowie Fahren) nicht auf zwei unterschiedliche CPUs verteilen.

Insgesamt muss der Roboter so entworfen werden, dass die Auslastung kleiner oder gleich der Anzahl der Rechnerkerne ist. Dies bedeutet, dass die einzelnen Threads so programmiert und synchronisiert werden müssen, dass die Rechnerauslastung in Bezug auf das Einkernsystem unter 100% bleibt.

Die Werte der Sensoren werden alle 100 ms gemessen, dadurch ergibt sich für das Abfragen der drei Sensoren eine maximale Reaktionszeit von 300ms. Anschließend kann der Motor angesteuert werden, welcher ebenfalls eine maximale zulässige Reaktionszeit von 300ms aufweist. Dies bedeutet die Reaktion muss dann jeweils innerhalb der Zeitspanne von 300ms erfolgen.

Des Weiteren müssen alle Deadlines in der vorgegebene Zeit eingehalten werden. Die Blockierzeiten sind zu berücksichtigen, da mehrere Threads verwendet werden und auf einen gemeinsamen Bereich zugreifen, der deshalb geschützt werden muss.

Hinweis 1: Bessere Darstellung der Formel im Buch "Moderne Realzeitsysteme kompakt" Im folgenden werden wir einen Realzeitnachweis auf Anwendungsebene durchführen, dabei gehen wir von einer idealen Hardware und einem idealen Betriebssysteme aus. Für weitere Informationen zu Schwierigkeiten, siehe Punkt "Probleme und Lösungen" Zeiten

Hinweis: Die Blockierzeit wird gemessen, indem für jede IO-Funktion die Blockierzeit berechnet wird.

Ultraschallsensoren tE,max = Executiontime mit Blockierzeit - Blockierzeit

Motor tE,max = Executiontime mit Blockierzeit - Blockierzeit

Verwendeter Scheduler: prioritätsgesteuertes Scheduling

Der Putzroboter ist ein Realzeitsystem, da er beide Realzeitbedingungen erfüllt:

Nachweis ohne Berücksichtigung der Ressourcen

u = Summe(tE,max / ( min( tD,max ; tP,min ))) <= n(21/n - 1); Summe -> Oben n und Unten j=1

*Auslastungsgrenze bei 4 Threads liefert eine Aussage -> Kein notwendiger Schedulertest nötig. * Nachweis unter Berücksichtigung der Ressourcen

Hinweis 2: In unserem Realzeitsystem gibt es keine Blockierzeiten, da wir uns entgegen der ursprünglichen Planung gegen einen mutex-geschützten, geteilten Speicherbereich entschieden haben. Weil der Motorthread nur lesend auf die Werte zugreift, kann es nicht zu einer Racecondition kommen.

Hinweis 3: Im Projekt werden die Protokolle PIP und PCP nicht verwendet, weshalb keine Berechnung erfolgen muss. Der Grund für dies ist, dass alle Threads die gleichen Prioritäten haben. Außerdem verwendeten wir keine blockierten Bereiche, weshalb die Implementierung von PIP und PCP unnötig wäre.

siehe Hinweis 2

Hinweis 1: Bessere Darstellung der Formel im Buch "Moderne Realzeitsysteme kompakt" Im folgenden werden wir einen Realzeitnachweis auf Anwendungsebene durchführen, dabei gehen wir von einer idealen Hardware und einem idealen Betriebssysteme aus. Für weitere Informationen zu Schwierigkeiten, siehe Punkt "Probleme und Lösungen" Zeiten

Hinweis: Da beim Motorthread ständig auf das Sysfilesystem zugegriffen wird, ergeben sich lange Blockierzeiten, wenn das Programm Stress mit vielen IO-Threads ausgeführt wird. Bei den Ultraschallsensoren werden auf WiringPi-Funktion zugegriffen, welche direkt in die Register der GPIO-IC geschrieben werden, deshalb ändert sich hier an den Zeiten nichts. Beim Motorthread erhöht sich die Blockierzeit auf das ca. 32-fache. Die Deadline von 40ms wird in diesem Fall trotzdem eingehalten.

Ultraschallsensoren tE,max = Executiontime mit Blockierzeit - Blockierzeit

Motor tE,max = Executiontime mit Blockierzeit - Blockierzeit

Verwendeter Scheduler: prioritätsgesteuertes Scheduling

Der Putzroboter ist ein Realzeitsystem, da er beide Realzeitbedingungen erfüllt:

Nachweis ohne Berücksichtigung der Ressourcen

u = Summe(tE,max / ( min( tD,max ; tP,min ))) <= n(21/n - 1); Summe -> Oben n und Unten j=1

Auslastungsgrenze bei 4 Threads liefert eine Aussage -> Kein notwendiger Schedulertest nötig. Nachweis unter Berücksichtigung der Ressourcen

Hinweis 2: In unserem Realzeitsystem gibt es keine Blockierzeiten, da wir uns entgegen der ursprünglichen Planung gegen einen mutex-geschützten, geteilten Speicherbereich entschieden haben. Weil der Motorthread nur lesend auf die Werte zugreift, kann es nicht zu einer Racecondition kommen.

Hinweis 3: Im Projekt werden die Protokolle PIP und PCP nicht verwendet, weshalb keine Berechnung erfolgen muss. Der Grund für dies ist, dass alle Threads die gleichen Prioritäten haben. Außerdem verwendeten wir keine blockierten Bereiche, weshalb die Implementierung von PIP und PCP unnötig wäre.

siehe Hinweis 2

Für die einzelnen Ultraschallsensoren wird jeweils ein Thread erzeugt. Jeder Thread hat die Aufgabe, die Messungen des ihm zugeordneten Sensors durchzuführen und die Daten in eine absolute Entfernung umzurechnen. Das Ergebnis wird in einer Variable abgespeichert.

• Minimale zulässige Reaktionszeit (tDmin): 0ms
• Maximale zulässige Reaktionszeit (tDmax): 250ms
• Maximale Auftrittshäufigkeit (tPmin): 250ms

Beide Motoren werden von einem Thread angesteuert. Dieser Thread wertet die von den Ultraschallsensoren gelieferten Abstandswerte aus, und entscheidet anhand dieser Daten, mit welcher Geschwindigkeit die Motoren angesteuert werden. Zum Beispiel kann der Roboter bei einem sich nähernden Hindernis die Geschwindigkeit reduzieren und sich um 25° drehen, wenn er direkt vor einem Hindernis steht. Auch hier ist das Einhalten der Realzeitbedingungen notwendig, da das Wissen eines nahenden Zusammenstoßes (also die rechtzeitig vorhandenen Abstandswerte der Ultraschallsensoren) nichts bringt, wenn die Roboter seine Motoren trotzdem nicht rechtzeitig stoppen kann. Wichtig ist außerdem, dass die Geschwindigkeitsanpassung beider Motoren direkt nacheinander erfolgt (zum Beispiel könnte diese Sektion durch einen Mutex geschützt sein), um zu verhindern, dass die beiden Motoren mit einem zu großen zeitlichen Abstand angesteuert werden, was eine ungewollte Drehung zur Folge hätte (angenommen, Motor 1 fährt los und Motor 2 reagiert erst 1 Sekunde später).

• Minimale zulässige Reaktionszeit (tDmin): 0ms
• Maximale zulässige Reaktionszeit (tDmax): 40ms
• Maximale Auftrittshäufigkeit (tPmin): 40ms

Wir sind bei der Berechnung der maximal zulässigen Reaktionsgeschwindigkeit der einzelnen Funktionen von folgenden Annahmen ausgegangen:

Der Roboter schafft beim geradeausfahren eine Geschwindigkeit von 0,4m/s (= 4m pro 10s). Tatsächlicher gemessener Wert = 0,42m/s

Der Bremsweg beträgt bei voller Geschwindigkeit zwischen 6 und 7cm

Das Auswerten der Ultraschallsensoren benötigt pro Sensor 100ms, bei den vorhandenen drei Sensoren wären das insgesamt maximal 300ms.

Die Ansteuerung der Motoren inklusive der Entscheidungsfindung über die zu fahrende Geschwindigkeit sollte nicht länger als 300ms dauern.

Aus den oben aufgelisteten Einschränkungen lassen sich nun weitere Schlüsse ziehen:

0,42m/s * (0,2s Sensorauswertung * 3 Sensoren + 0,3s Motoransteuerung) + 0,07m Bremsweg = 0,448m

• Zeit der Motoransteuerung wird angenommen

Das heißt, das unser Roboter spätestens bei einem Sicherheitsabstand von 0,49m zu einem Hindernis eine Bremsung einleiten muss. Eventuell wäre es sinnvoll, schon vorher ein wenig abzubremsen, um den "Sicherheitsabstand" zu Hindernis verkürzen zu können und damit die gereinigte Fläche zu vergrößern.

Zu beachten ist, dass der Raspberry keine Hardware-PWM besitzt, sondern nur Software-PWM. Somit sind je nach PWM-Bibliothek noch weitere Threads in den Realzeitnachweis mit ein zu berechnen.

Haushaltshilfe: Der Roboter soll die Bodenreinigung im Haushalt übernehmen.

• HC-SR04 Modul (Ultraschall-Abstandssensor)
• Widerstände (330Ω, 470Ω, 820 Ohm)
• L293D (Motoransteuerungs-IC)
• 2WD Robot Motor Chassis

Erste Planung des Gehäuses für den 3D-Drucker

• Zusammenbau des Roboters
• Verdrahtung der elektrischen Bauteile
• Ansteuern und kalibrieren der Ultraschallsensoren
• Auswertung der Daten von den Ultraschallsensoren
• Implementierung der Geschwindigkeitsregelung nach den oben genannten Realzeitbedingungen
• Auswertung der gemessenen Zeiten für die Belegung des Realzeitbetriebes
• Formeller Realzeitnachweis

• Zusammenbau des Roboters
• Verdrahtung der elektrischen Bauteile
• Ansteuern und kalibrieren der Ultraschallsensoren
• Auswertung der Daten von den Ultraschallsensoren
• Entwicklung des Gehäuses
• Implementierung der Geschwindigkeitsregelung nach den oben genannten Realzeitbedingungen
• Zusammenbau des Roboters
• Auswertung der gemessenen Zeiten für die Belegung des Realzeitbetriebes
• Formeller Realzeitnachweis

Zahlenüberlauf eines long integer in der Abstandsberechnung mithilfe der Daten der Ultraschallsensoren. Das Problem trat nur innerhalb einer Zwischenrechnung in einer Zeile auf und ist uns daher zuerst nicht aufgefallen.

Lösung: Verwendung eines unsigned long long Datentyps

Durch das freirotierbare Steuerrad am hinteren Ende des Roboters, wird die Fahrtrichtung so abgelenkt, dass der Roboter nicht geradeaus fährt sondern einen Bogen nach links oder nach rechts fährt.

Lösung: Hinterrad fixieren

Die Ultraschallsensoren geben Störwerte aus, wenn der Abstand zu einem Objekt außerhalb des Messbereichs ist, sprich wenn ein Objekt entweder kürzer als 3cm entfernt ist oder weiter als 3,5m entfernt ist. Da die fehlerhaften Werte innerhalb eines plausiblen Wertebereichs liegen, "erkennt" der Roboter in solchen Fällen Hindernisse wo keine sind und dreht sich dann...

Diese Störungen haben wir versucht mit einem Oszilloskop zu debuggen:

Im folgenden Bild ist das Verhalten des Ultraschallsensors bei vernünftigen Werten zu erkennen. Auch schön zu sehen ist unsere Periode von 250ms. Der Channel 1 (oben) zeigt das Echo-Signal während der Channel 2 (unten) den Trigger zeigt (letzterer wird bei dieser Zoomstufe aufgrund der geringen Auflösung des Oszilloskop-Bildschirms nur manchmal dargestellt; es existiert aber kurz vor jeder Echo-HIGH-Flanke):

In folgendem Bild sieht man hingegen das Fehlverhalten des Ultraschallsensors bei out-of-range. Es sind immer wieder sehr kurze Flanken zu sehen.

Wenn der Sensor konstant "out-of-range" detektiert, treten diese Flanken genau jede zweite Messung auf. Nun könnte man auf die Idee kommen, einfach jede zweite Messung zu verwerfen - das war auch unser erster Ansatz:

Leider treten diese falschen Messwerte in der Praxis (z.B. bei Stuhlbeinen, welche auf Entfernung nur unzuverlässig detektiert werden, weil sie zu schmal sind) nur sehr unregelmäßig auf - teils gibt es auch mehrere falsche Messwerte in Folge. -> Schlussfolgerung: Durch weitere Testvorgänge kamen wir zum Entschluss, dass ein Ultraschallsensor defekt ist und deshalb diese Problematik auftritt

Lösung: Keine

Raspberry Pi - Ultraschallsensor

• Aufruf 16.04.2015, 17:10

Dokumentation, Realzeitnachweis und Codebeispiele

• Verwendetes Buch