Inhaltsverzeichnis Einleitung: ACV - Autonomous Camera Vehicle ...............................................................1 1: verwendete Hardware...................................................................................................2 1.1: Das Bildauswertungssystem Version 1 .............................................................................2 1.2: Das Bildauswertungssystem Version 2 ..............................................................................3 2: Software ........................................................................................................................3 2.1: Der Bildalgorithmus ...................................................................................................4 2.1.1: Grundüberlegungen zur Bildauswertung.........................................................................4 2.1.2: Zielsetzung des Algorithmus..........................................................................................4 2.1.3: Level 1: Kantenerkennung ...........................................................................................5 2.1.3.1: Kantenerkennung in X-Richtung.............................................................................5 2.1.3.2: Kantenerkennung in Y- Richtung............................................................................5 2.1.4: Level 2: Einteilen in eine 16x16 Matrix ..........................................................................7 2.1.5: Level 3: Erkennen der Horizonts-Linie - Abstanderkennung ............................................7 2.1.6: Level 4: Filtern der Matrix ............................................................................................8 2.1.7: Level 2: Einteilen in eine 16x16 Matrix ..........................................................................9 2.1.8: Level 2: Einteilen in eine 16x16 Matrix ........................................................................12 2.1.9: Ergebnisse ................................................................................................................12 2.2: Die Simulationssoftware für die Bildauswertung ................................................... 13 2.2.1: Zielsetzungen .............................................................................................................13 2.2.2: Programmierung und Geschichte .................................................................................13 2.2.3: Kleiner Überblick über die GUI des Simulators ..............................................................14 3: Das Kommuniaktionsprotokoll ................................................................................... 14 3.1: Das Serial Peripheral Protocol (genannt SPP) Version 2.1.................................................14 3.2: SPP Übertragungspakete ..............................................................................................14 4: Stromversorgung........................................................................................................ 16 5: Antriebskonzept ......................................................................................................... 16 Anhang...............................................................................................................................I

Abbildungsverzeichnis Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung

1: Projektplanung ............................................................................................................................................................. 1 2: Ermittlung von 4 Bereichen mit einer Hindernisgewichtung.............................................................................................. 4 3: Differenzverfahren / Kantenerkennung........................................................................................................................... 6 4: Programmablaufplan für die Kantenerkennung ............................................................................................................... 6 5: Erstellen einer repräsentativen Bildmatrix....................................................................................................................... 7 6: Abstandserkennung ...................................................................................................................................................... 8 7: Matrixfilterung .............................................................................................................................................................. 9 8: Ermittlung der Hinderniserwartungsstufen.................................................................................................................... 10 10: Hindernisbereiche ..................................................................................................................................................... 12 11: SPP Standard Übertragunspaket ................................................................................................................................ 14 12: SPP Long Session Pakete........................................................................................................................................... 15 13: Master – Slave - Kommunikation via SPP ................................................................................................................... 15 14 : Platinenlayout........................................................................................................................................................... II 15: SPP Hub ....................................................................................................................................................................IV

Einleitung: ACV - Autonomous Camera Vehicle Die Idee zu diesem Projekt kam mir, als im Roboternetz 1 in einen Beitrag behauptet wurde, dass eine Bildauswertung auf einem 8-Bit Mikrocontroller gar nicht, und wenn dann nur sehr schwer möglich sei, weil eine solche Auswertung zu viel Rechenzeit und Rechenleistung beanspruchen würde. Diese Aussage ging mir nicht mehr aus dem Kopf. Als ich auf eine Internet-Seite der Universität Minnesota stieß, auf der die Scout-Spionageroboter gezeigt wurden, gefielen mir deren Antriebskonzepte und Design so gut, dass ich beschloss, einen ähnlichen Roboter zu bauen. Dieser mobile Roboter sollte fähig sein, mittels einer Bildauswertung Hindernissen während der Fahrt auszuweichen. Als Kamera oder „Auge“ verwendet der Roboter eine Gameboy® Kamera. Diese ist einfach anzusteuern, und macht relativ kleine Bilder, was von vornherein den Rechenaufwand für die Auswertung minimiert. Im Endausbau könnte diese Technik in der autonomen Groberkundung von unzugänglichem Gelände (z.B. Minenfelder, biologisch, chemisch oder atomar verseuchtes Gelände) eingesetzt werden. Der Vorteil hierbei ist, dass die Auswertetechnik relativ kostengünstig ist. Bei der Entwicklung des Roboters habe ich alle Systeme und Programme selbst erdacht, entwickelt und die für den Roboter verwendeten Platinen auch größtenteils selbst geätzt. Die Platine für das Bildauswertungssystem Version 2 wurde von mir entworfen, jedoch industriell hergestellt, weil es meine Möglichkeiten überstieg. Der Fokus dieser Arbeit liegt in der Entwicklung der Software zur Bildauswertung, der speziell dazu entwickelten Simulationssoftware, und der Entwicklung eines eigenen Kommunikationsprotokolls zur Vernetzung der Einzelkomponenten.

Abbildung 1: Projektplanung

1

www.roboternetz.de größtes Roboternetzwerk Deutschlands

-1-

1: verwendete Hardware Beim Bau des Roboters kamen (bis auf eine Ausnahme) selbst entwickelte Schaltpläne bzw. Platinen zum Einsatz, die auch von mir gefertigt wurden. (s. Anhang 1 - Hardware) Für den geplanten Roboteraufbau durften die Platinenscheiben einen Durchmesser von max 7 cm haben, d.h. die Elektronik musste sehr klein werden. Daher verwendete ich hauptsächlich SMDBauteile. Die verwendeten 4 Mikrocontroller sind alle 8-Bit AVR Mikrocontroller der Firma Atmel. Sie haben mehrere entscheidende Vorteile: 1. Bis zu 16MHz Taktfrequenz 2. Einfache In-System-Programmierung 3. Viel On-Chip Hardware Die Aufnahme eines Bildes erfolgt über eine Gameboy-Kamera, deren 128*123 Pixel mit 256 Graustufen ausgelesen werden.

1.1: Das Bildauswertungssystem Version 1 Das Bildauswertungssystem Version 1 war das erste System, das ich für das ACV entwickelt habe. Es besteht aus einem AVR ATmega8, der mit 16MHz Taktfrequenz betrieben wird, und einem 128kb SRAM, von dem aber nur 64kb genutzt werden können. Des Weiteren befinden sich 2 Portlatches auf dem Board, da nur ein 8-Bit breiter Bus zur Ansteuerung des SRAMs zur Verfügung steht. Das ist auch das Manko des Boards. Dadurch, dass der Atmega8 über ‚nur’ 23 I/Os verfügt, mussten die Ausgänge mit Hilfe eines Multiplexers mehrfach belegt werden. Das erhöht den Zeitbedarf für die Bildauswertung. Des Weiteren stellte sich heraus, dass der gesamte Quellcode des Bildalgorithmus 1 und der Kommunikation 2 nicht in den Programmspeicher des Atmega8 passen. 1

: siehe 4. Der Bildalgorithmus : siehe 2.2. Serial Periheral Protocol und Technischer Anhang

2

-2-

Deshalb musste ich eine neue Version des Bildauswertungssystems entwickeln.

1.2: Das Bildauswertungssystem Version 2 Das Bildauswertungssystem baut auf Erfahrungen mit der Programmierung der Version 1 auf. Vor allem aber sollte es schneller sein als das erste System. Dies erreichte ich einerseits durch einen ATmega16-Controller, der 32 I/Os mit sich brachte. Dadurch wurde nur ein Port-Latch notwendig, was die Speicherung der Daten beschleunigte. Ich habe bei der Version 1 des Systems den OnChip ADC des AVRs genutzt, habe mich aber in der Version 2 für einen externen ADC entschieden, da dieser viel schneller wandeln kann. Ich habe einen ADC0820 verwendet, der nur 1,4µs Wandlungszeit benötigt. Des Weiteren gibt es jetzt zwei jeweils 8-Bit breite Busse, einmal den Datenbus, und einmal den Adressbus. Letzterer wird nur für das SRAM benötigt. Da der Adressbus des SRAMs aber 16 Bit breit ist (das 17. Bit zur Ausnutzung der vollen 128kb wurde separat angeschlossen) wurde das höhere Byte über einen Portlatch gemultiplext. Der Datenbus ist mit dem Daten-Ein-Ausgang des SRAMs, sowie mit dem Datenausgang des externen ADCs und dem Prozessor verbunden. Leider ist das System durch die Verschaltung der Chip Selects nicht DMA-fähig, was aber die Sicherheit erhöht. Es kann nie einen Kurzschluss auf dem Datenbus geben, wenn gleichzeitig der ADC etwas ausgibt, und aus dem SRAM gelesen wird. Selbst bei nicht perfekt ausgenutzter Prozessorgeschwindigkeit ist die Version 2 ganze 4,9 Sekunden schneller als die Version 1 (Benötigte Zeit Version 1: 7.9s ; Version 2: ca.3s).

1.3: Die Gameboy Kamera Die Gameboy® Kamera wurde von Nintendo® für den Gameboy®, als eine Art Foto-Spiel entwickelt. Sie verwendet einen 128*123 Pixel schwarz-weiß CCD Bildsensor. Sie lässt sich über 8 Register steuern. Das Ausgangssignal ist analog und wird seriell ausgegeben. Um die Kamera (für Belichtung usw.) abzustimmen, werden 7 Steuerleitungen verwendet, obwohl auch hier ein serielles Übertragungsverfahren angewendet wird. Die Kameradaten werden in Version 1 des Bildsystems mit dem 8-Bit On-Chip ADC des AVRs ausgewertet, in Version 2 mit einem externen High-Speed 8-Bit ADC. Dadurch kann das Bild der Kamera mit maximal 256 Graustufen dargestellt werden. Dadurch ergibt sich eine Dateigröße von ca. 16kb. Es können also in der Version 2 etwa 8 Bilder der Kamera im RAM (vgl.Version1, nur 4 Bilder) abgelegt werden.

2: Software Die Mikrocontroller des Roboters arbeiten mit einem semi-ereignisorientiertes System. Dies hat den Vorteil, dass der Prozessor nicht immer aufwändige Auswerteverfahren durchläuft, sondern nur bestimmte (beauftragte) Aufgaben (Tasks) durchführt (z.B. eine Kommunikationsanfrage von Hauptprozessor (siehe dazu Kapitel 3 und Technischer Anhang - ). Die gesamte Roboter-Software habe ich in BASIC geschrieben. Dies hat den Nachteil, dass der BASIC-Compiler für die AVR-Controller einen etwas voluminöseren Code erzeugt, aber die Vorteile, dass meiner Ansicht nach der BASIC-Dialekt leicht zu erlernen ist und schwierige Funktionen einfach im Programmcode angesprochen werden können. Hierzu wurde der BASCOM BASIC Compiler der Firma MCS Electronics ® verwendet. Des Weiteren habe ich mehrere PC Programme in C geschrieben: Ein komplettes Visualisierungstool („Simulator“) für den Bildauswertealgorithmus (um nicht alles gleich auf den Controller spielen zu müssen)

-3-

Eine Software zum Einlesen und Darstellen der Kamerabilder, die vom Bildauswertungssystem via RS232 zum PC gesandt wurden. Eine Software zum Darstellen der Bildauswerte-Ergebnisse der Level 2, 4 und 5. Weiterhin wurde von mir ein eigenes Kommunikationsprotokoll für die Kommunikation zwischen den Microcontrollern entwickelt (siehe dazu Kapitel 3 und Technischer Anhang).

2.1: Der Bildalgorithmus 2.1.1: Grundüberlegungen zur Bildauswertung Der vorliegende Bildauswertealgorithmus eignet sich nicht für Bewegtbilder. Vielmehr sollen Hindernisse in einem statischen Bild ohne Hilfe von Abstandssensoren o.ä. erkannt werden. In zahlreichen empirischen Versuchen, Tests und Diskussionen kristallisierte sich heraus, dass ein beliebiges Hindernis per se nicht erkannt werden kann. Hindernisse können hell, dunkel, kontrastreich, etc. sein, ebenso der Bildhintergrund. Somit ist eine eindeutige Abgrenzung ohne Festlegung von Randbedingungen nicht möglich. Es ist somit erforderlich, die Bildauswertung in einem vorher festgelegten (oder anwählbaren) Szenario durchzuführen, so dass im Bild gezielt nach charakteristischen Merkmalen gesucht werden kann. Ein solches Szenario könnte z.B. mittels eines Barcodes, RFID-TAGs o.ä. zu Beginn der Robotermission in das System eingegeben werden.

2.1.2: Zielsetzung des Algorithmus Das Ziel meines Algorithmus ist es, möglichst gute Auswertungsergebnisse bei möglichst geringem Ressourcenverbrauch zu erzielen, sowie die Rechenzeit möglichst kurz zu halten. Wie bereits erwähnt, läuft der Algorithmus auf einem AVR-Mikrocontroller. Allerdings hängt die Rechenzeit natürlich hauptsächlich vom verwendeten Prozessor, sowie der Taktfrequenz, der verwendeten Programmiersprache, und der Zugriffszeit zum RAM und der Kamera ab. Da dies alles Faktoren sind, die eher die Peripherie als das eigentliche Prinzip betreffen, habe ich diese zum aktuellen Zeitpunkt für die weiteren Betrachtungen als äußere Faktoren ausgeblendet. Der Algorithmus wurde entwickelt, um Hindernissen im täglichen Leben zu erkennen, und diese möglichst zu umfahren. Wie oben bereits erläutert, ist dies allerdings nur mit Einschränkungen bzw. nur durch Festlegen von Randbedingungen möglich. Bsp.: Fabrikkomplex mit drei Hallen. Jede Halle hat charakteristische „Hindernisse“. Halle 1 z.B. gestreifte Tonnen, Halle 2 karierte Kartons usw.. Die Ergebnisse des Algorithmus stellen dabei lediglich 4 Zahlen dar, die einem jeweiligen Bereich des Bildes eine Gewichtung geben und somit Bildbereiche charakterisieren. Durch diese Charakterisierung ist dann eine Zuordnung von Bildbereich und Hindernis möglich.

Abbildung 2: Ermittlung von 4 Bereichen mit einer Hindernisgewichtung

-4-

2.1.3: Level 1: Kantenerkennung Die Kantenerkennung ist notwendig um Kontrastunterschiede (aka „Kanten“) im Bild zu finden. Diese Analysen sind von essentiellem Wert für den ganzen Bildalgorithmus Im Weiteren soll ein Testszenario mit folgenden Merkmalen analysiert werden. • Eindeutig für den Computer erkennbare Hindernisse. • Reproduzierbare Bedingungen. • Von der Zielhardware erstelltes Bildmaterial. Der Algorithmus soll dabei Bereiche mit starken Kontrasten ermitteln und somit als Hindernis charakterisieren. 2.1.3.1: Kantenerkennung in X-Richtung Wenn das Bild aufgenommen wurde, und sich im SRAM befindet werden ‚Kanten’ beziehungsweise Kontrastunterschiede erkannt. Dabei hat sich ein pixelweises Differenzverfahren bewährt, das als Rückgabewert einen boolschen Wert liefert. Das heißt, alle Kontrastunterschiede zweier Bildpunkte (Helligkeitswert eines Bildpunktes von 0-255), die größer sind als ein festzulegender Grenzwert (18 Einheiten funktionieren am besten), werden als ‚gegeben’ angesehen. Diese bewerteten Ja-Nein-Ergebnisse werden wiederum in das SRAM gespeichert, nur diesmal in einen anderen Adressbereich. Das Auswerten im Detail funktioniert so: Das Programm lädt ein Pixel in eine Variable. Danach wird das nebenliegende (daneben oder darunter) Pixel geladen. Nun wird der Betrag der Differenz der beiden Pixel ermittelt. Negative Zahlen sind nicht erwünscht. Sie würden nur einen Mehraufwand an Programmierung erfordern und die Rechenzeit erhöhen. Ist das Ergebnis dieser Rechnung, also der Kontrastunterschied, größer als der festgelegte Grenzwert, wird das als ‚Kante’ erkannt. Diese Erkennung in X-Richtung oder von links nach rechts erkennt vertikale Linien sehr gut. Nur mit horizontalen Linien gibt es manchmal Probleme. Horizontale Kanten haben in sich ja den gleichen Grauwert bzw. Helligkeitsstufe. Deshalb ist die Differenz zwischen den Pixeln in XRichtung relativ klein. Dies ist bei der Y-Analyse und vertikalen Kanten gleich.

2.1.3.2: Kantenerkennung in Y- Richtung Die Kantenerkennung in Y-Richtung (oder von oben nach unten) funktioniert vom Prinzip her genau gleich wie die in X-Richtung, nur dass sie um 90° gedreht ist. Dies hat den Sinn, auch horizontale Linien auf dem Bild optimal zu erkennen. Die Ergebnisse werden wie bei der vorigen Analyse gespeichert. Dies geschieht auch im gleichen Adressraum im RAM. Im RAM liegt zum Zeitpunkt der Ausführung der Y-Erkennung das Bild der X-Analyse in Form von 255 und 0. Die Ergebnisse der Y-Analyse überschreiben jetzt die der X-Analyse teilweise. Hierbei gibt es 3 Fälle: Beide Ergebnisse sind NEIN, die Y-Analyse schreibt nichts in das RAM. Das Ergebnis der X-Analyse war JA, das der Y-Analyse war NEIN. Die Y-Analyse überschreibt den Datensatz nicht. Die X-Analyse ist NEIN, das Ergebnis der Y-Analyse aber JA. In diesem Fall überschreibt die YAnalyse das Ergebnis der X-Analyse. Es werden also immer JA-Ergebnisse auf Kosten von NEIN-Ergebnissen überschrieben, Dies entspricht einer einfachen ODER-Verknüpfung.

-5-

Hier sehen wir diese beiden Schritte in unserem Testszenario:

Dieses Bild wird zu:

Das ‚Hindernis’, das hier durch einen schwarz-weiß karierten Dummy charakterisiert wird, ist im Ergebnis sehr gut zu erkennen. Die Zwischenstufe sieht folgendermaßen aus:

Abbildung 3: Differenzverfahren / Kantenerkennung

Dies ist eine Darstellung des Betrags der Differenz der Bildwerte. Je heller das Pixel, desto größer die Differenz.

Abbildung 4: Programmablaufplan für die Kantenerkennung

-6-

2.1.4: Level 2: Einteilen in eine 16x16 Matrix Die Einteilung des Bildes in eine 16*16 Matrix ist der weitere Kernpunkt des gesamten Algorithmus. Der Sinn dieses Schrittes liegt darin, Rechenzeit zu sparen, indem man einfach die zu bewertende Datenmenge repräsentativ verringert. Nachdem die Auswertungen in X- und Y-Richtung vorgenommen worden sind, wird das gesamte Bild in eine 16*16 Matrix eingeteilt. Das heißt, dass das Bild in 256 Einheiten aufgeteilt wird, die jeweils 8*8 ausgewertete Pixel enthalten (da sich 123 (Pixel in Y-Richtung) nicht durch 16 teilen lässt, repräsentiert die unterste Bildzeile nur 3 Originalpixel). Grafisch dargestellt, sieht dies so aus:

W I R D Z U

Abbildung 5: Erstellen einer repräsentativen Bildmatrix

Auch in der reduzierten 16x16-Matrix ist das „Hindernis“ deutlich zu erkennen. Je dunkler eins dieser Elemente dargestellt wird, desto größer ist sein Wert.

2.1.5: Level 3: Erkennen der Horizonts-Linie - Abstanderkennung In den ersten Versuchen zum Roboterprojekt wurde nach dem Bildhorizont gesucht um eine höhere Präzision zu erreichen, da Kontrastpunkte am Himmel (z.B. ein Vogel) für den Roboter nicht von Bedeutung sein sollten. Aus bereits genannten Gründen ist die Horizonterkennung als solche nicht von Bedeutung.

-7-

Der Vollständigkeit halber hier in aller Kürze die Beschreibung der Horizonterkennung. Die Werte der Einheiten aus Level 2 werden zeilenweise zusammenaddiert. Ist die jeweilige Zeile darunter um einen gewissen Betrag größer (empirisch hat sich wiederum 20 behauptet) als die obere, ist hier der Horizont. Vielmehr wurden die Überlegungen hinsichtlich eines weiteren interessanten Gesichtspunktes erweitert. Es sollte eine Abstandsermittlung von Roboter und Hindernis ohne Abstandssensoren möglich sein.

1m 1m

Abbildung 6: Abstandserkennung

Ausgehend vom Roboter entspricht jede horizontale Bildlinie einem bestimmten Abstand. Voraussetzung (Randbedingung) hierfür ist natürlich, dass sich der Roboter auf ebenem Gelände befindet. So können Bildbereiche ab einem bestimmten Abstand (künstlicher Horizont) ignoriert oder im Speziellen analysiert werden. Beispiel: In einem Raum werden kontrastreiche Sperrbänder am Fuß der Wände angebracht, so kann der Abstand zur Wand und der Wandbereich selbst erkannt werden. Im aktuellen Projektstatus sind diese weiterführenden Überlegungen noch nicht implementiert.

2.1.6: Level 4: Filtern der Matrix Bei der XY-Auswertung des Bildes, werden einerseits Kanten erkannt, aber andererseits auch relativ viel ‚Hintergrundrauschen’. Dieses Hintergrundrauschen verfälscht das Ergebnis, da es auch auf freien Flächen auftritt, die im Prinzip kein Hindernis enthalten. Deshalb wird das Rauschen durch folgendes Verfahren zumindest vermindert. Dazu wird jede Einheit der Matrix aufgerufen, dazu die Einheiten darüber, darunter, links und rechts der Einheit. Nun wird der Betrag der Subtraktion zwischen den Werten der äußeren Einheiten von dem der inneren gebildet. Die 4 Ergebnisse werden addiert, und am Schluss durch 4 geteilt, sodass sich ein ganzzahliger Durchschnitt (ganzzahlig, da keine Gleitkomma-Variablen zu Verfügung stehen) ergibt. Diese Filterung hat den Sinn, unnötiges ‚Hintergrundrauschen’, also Bereiche in der Matrix, die von vorneweg in jeder Einheit den Wert von z.B. 20 haben (kommt z.B. bei Teppichböden vor) zu eliminieren.

-8-

Grafisch dargestellt:

aus diesem Bild aus unserem Testszenario wird:

Im normalen Auswertungsmodus

Nach dem Filtern

Abbildung 7: Matrixfilterung

2.1.7: Level 2: Einteilen in eine 16x16 Matrix Durch das Ermitteln einer Hindernisgewichtung in einem Bildbereich ist es möglich, den Roboter gezielt in einen hindernislosen Bereich zu steuern. Nachdem die Zählung und der Filter abgeschlossen sind, ist die Auswertung eigentlich schon fertig. Da aber Tests im Simulator zeigten, dass bei manchen Hindernissen (z.B. bei Steinen) die Kante,

-9-

aber nicht der ‚Inhalt’ erkannt wurde, musste noch eine weitere Stufe aufgesetzt werden. Der nächste Schritt soll dazu Abhilfe schaffen und dieses Problem korrigieren, Hier wurde wiederum auf möglichst einfache Programmierung und wenig Rechenzeit Wert gelegt. Die Ergebnisse des Filters werden nun Einheit für Einheit durchgegangen, und in 4 Stufen eingeteilt von 0 (unwahrscheinlich) bis 3 (sehr wahrscheinlich). Dies erfolgt über den Vergleich der Variablen Größen mit empirisch festgelegten Schwellwerten. In jedem Schritt werden nun alle 8 umliegenden Einheiten der zu bestimmenden Einheit X ermittelt. Diese umliegenden Einheiten werden nun bewertet. Ist eine Einheit größer als 10, wird eine Zählervariable erhöht, ist sie kleiner, geschieht nichts. Wenn sich der Wert der zu bearbeitenden Einheit X in bestimmten Grenzwerten bewegt, wird der Einheit die Hinderniserwartungsstufe 1 zugeordnet. Dies wird wiederum in einer separaten 16x16 Matrix gespeichert. Dann wird überprüft ob die Einheit X kleiner als 10 ist, und die Anzahl der umliegenden Einheiten die größer 10 sind, mehr oder gleichviel wie ein Grenzwert (z.B. 4) ist. Trifft dies zu, so hat diese Einheit die Hinderniserwartungsstufe 2 erreicht. Umliegende Einheit größer als 10

Umliegende Einheit kleiner als 10

Abbildung 8: Ermittlung der Hinderniserwartungsstufen

Sollte die Einheit X zuvor Hinderniserwartungsstufe 1 gehabt haben, erhält sie nun Stufe 2. Ist die Einheit X aber größer als 10, und die Anzahl der umliegenden Einheiten, die größer 10 sind, ist größer oder gleich groß wie ein Grenzwert (z.B. 3), so hat diese Einheit die Hinderniserwartungsstufe 3 erreicht. Diese Ergebnisse werden alle in der separaten Matrix gespeichert.

- 10 -

Aus unserem Test-Bild von vorher wird nach dem Abarbeiten des Algorithmus Folgendes:

Hinderniswahrscheinlichkeit 3

Man erkennt, dass das Dummy-Hindernis mit den beiden höchsten Hinderniserwartungsstufen belegt wird.

Name X G S1 Gs1 Gs2 S2 S3

Zweck Wert Aktuelle Eineheit Σ Umliegende Einheiten > 10 Schwellwert für X für Level 3 10 Schwellwert für G für Level 3 3 Schwellwert für G für Level 2 4 Schwellwert für X für Level 1 7 Schwellwert für X für Level 1 3

Tabelle 1: Aufschlüsselung der Schwellwerte

- 11 -

Abbildung 9a+b Ermittlung d. Hinderniserwartungsstufen

2.1.8: Level 2: Einteilen in eine 16x16 Matrix

Abbildung 10: Hindernisbereiche

Das Abzählen ist der letzte Schritt des Algorithmus. Er fasst die bisherigen Auswertschritte zusammen. Die Matrix wird in 4 Bereiche aufgeteilt, und die Hinderniserwartungsstufe (1, 2 und 3) in jedem der 4 Bereiche (die horizontal eingeteilt sind und jeweils 4 Einheiten umfassen) ab der vorher festgestellten Horizontlinie addiert (Abb.: 10 Hindernisbereiche, s.o.). Der Bereich mit der höchsten Zahl ist der mit der größten Hinderniserwartung. Das Hindernis liegt im Bereich 2 (Wert: 88) und 3 (Wert: 60). Der Roboter soll in den Bereich 1 oder 4 fahren. Wie die Bereiche eingeteilt sind hängt von der Anwendung ab.

2.1.9: Ergebnisse Der Algorithmus liefert keine genauen und detaillierten Bilddaten, aber er liefert Gewichtungen im Bild, wo Hindernisse liegen könnten. Letztlich ist auch nur dies notwendig. Dadurch, dass er eher einem Filter als einer komplexen Verarbeitungsstruktur gleicht, ist die Verarbeitung einfacher und dadurch schneller. Nun wird einfach auf das größte Ergebnis (siehe Abb. 10) reagiert und entsprechend ausgewichen.

- 12 -

2.2: Die Simulationssoftware für die Bildauswertung 2.2.1: Zielsetzungen Um eine effektive, einfache und schnelle Entwicklung der Robotersoftware zu ermöglichen war es notwendig, eine Simulationssoftware nur für die Bildauswertung zu entwickeln. Ein entscheidender Vorteil dieser Simulationssoftware besteht darin, dass durch Dekomposition der gesamten Projektproblemstellung in einzelne Problembereiche, das Bearbeiten der jeweiligen Teilaufgaben erheblich vereinfacht wird. So muss bei der Bildanalyse z.B. die Ansteuerung der Robotermotoren nicht berücksichtigt werden. Ein weiterer Vorteil ist natürlich das Testing mittels Simulation. Um den Algorithmus nicht jedes Mal mit der Mikrocontroller-Hardware aufs Neue zu testen (dort ist das Debugging weitaus schwerer), kann somit die Simulationssoftware eingesetzt werden. Der Simulator sollte möglichst einfach zu bedienen sein, und vor allem eine exakte Kopie des Algorithmus darstellen, der später auf der Zielhardware laufen soll. Ein weiteres wichtiges Ziel ist die Ausgabe möglichst vieler Zwischeninformationen, sodass weitere Möglichkeiten das Bild auszuwerten nicht unerkannt bleiben, und um dem Algorithmus sozusagen „ins Gehirn“ schauen zu können.

2.2.2: Programmierung und Geschichte Der Simulator wurde komplett in der Programmiersprache C mit Hilfe der Win32-API realisiert. In der zur Zeit aktuellen Version 1 umfasst der Code alles in allem ca. 1300 Zeilen. Der Simulator entstand quasi parallel bei der Entwicklung des Bildauswertealgorithmus. Zuerst habe ich einfache Experimente bzgl. Kantenerkennung und Horizonterkennung gemacht, mit großem Erfolg. Die Herausforderung war, nicht „Irgendetwas“ zu programmieren, das auf dem PC wunderbar funktioniert aber auf einem Controller schlicht nicht auszuführen ist. Es musste also ständig auf Einfachheit und Effektivität geachtet werden. Ich habe somit auch versucht, die Datenstrukturen denen im Zielsystem so gut wie möglich nachzuempfinden. Initialer Schritt des Simulators ist, das Bild in ein 128*128 Integer Array zu laden. Zum Testen in der ersten Entwicklungsphase verwendete ich Bilder von Marsmissionen, da mir diese zuerst geeignet erschienen. Sie haben deshalb auch mit Einfluss auf den Algorithmus genommen. Die logische Konsequenz aus den vielen praktischen Testreihen machte es dann erforderlich, weitere spezielle Testbilder einzusetzen, die über charakteristische Merkmale eines Bildszenarios verfügten. Nach Abschluss der Simulatorsoftware und erfolgreichen Tests konnte der jeweilige BASIC-Code des Bildalgorithmus für den AVR übersetzt und auf das Bildverarbeitungssystem gebrannt werden. In den weiteren Beschreibungen beziehe ich mich selbstverständlich auf die Hardwareumgebung des Roboters. Dort kommt letztendlich der Bildalgorithmus zum Einsatz.

1

Die aktuelle Version ist zum jetzigen Zeitpunkt 0.6G

- 13 -

2.2.3: Kleiner Überblick über die GUI des Simulators

3: Das Kommuniaktionsprotokoll 3.1: Das Serial Peripheral Protocol (genannt SPP) Version 2.1 Das speziell von mir entwickelte Kommunikationsprotokoll (SPP 2.x) dient der Vernetzung von mehreren Subprozessoren (sog. Slaves) mit dem Hauptprozessor. Das SPP Vers. 2.1 / 2.2 habe ich speziell für multiprozessorale Robotersysteme entwickelt. Das SPP nutzt die serielle Schnittstelle (UART) der Mikrocontroller, und ist daher auf fast allen Prozessorplattformen anwendbar. Es lassen sich bis zu 255 Slaves adressieren. Der Nachteil ist, dass hardwareseitig pro Slave ein extra AND-Gatter Eingang gebraucht wird, beim ACV sind 8 verfügbar. Das SPP Vers. 2.1 nutzt eine Übertragungsrate von 19200bps (Baud). Durch Acknowledge- bzw. Fail-Bytes (ACK bzw. FAIL) wird das SPP weniger störanfällig. Nähere Details sind dem technischen Anhang zu entnehmen.

3.2: SPP Übertragungspakete Ein SPP Übertragungspaket setzt sich in der Standard-Konfiguration aus 7 Bytes zusammen: 1 Byte

1 Byte

1 Byte

3 Byte

1 Byte

Start

Adr.

Type

Daten

Stop

Abbildung 11: SPP Standard Übertragunspaket

- 14 -

Es gibt aber noch 3 Sonderformen: - ESC-Sequenzen - Long-Pakete - Long-Sessions Long-Sessions werden durch ESC-Sequenzen eingeleitet. Eine Long-Session ist, wenn der Bus für eine gewisse Zeit gesperrt ist, um eine Kommunikation nur zwischen 2 Prozessoren zu ermöglichen. Diese Kommunikation kann total chaotisch sein, und muss nichts mit dem SPPProtokoll zu tun haben. Long-Pakete sind nichts anderes als Standard-Pakete, bei denen der Datensatz länger als 3 Byte ist. Sie können aber maximal 256 Datenbytes enthalten. Sie sind wie folgt aufgebaut: 1 Byte

1 Byte

1 Byte

1 Byte

n-Byte

1 Byte

Start

Adr.

Type

Length

Daten

Stop

Abbildung 12: SPP Long Session Pakete

Zu diesen speziellen Übertragungsarten ist zu sagen, dass nicht jeder Controller genug Speicher hat, um all diese Spezial-Sequenzen zu unterstützen. Das Protokoll wird einfach darauf abgestimmt. Die ESC-Sequenzen sind reine Steuerzeichen, die an alle Slaves gesendet werden. Im Gegensatz zu den anderen Protokoll-Sonderformen, müssen alle Controller diese Steuerzeichen Verstehen, und darauf reagieren können.

Abbildung 13: Master – Slave - Kommunikation via SPP

- 15 -

4: Stromversorgung Der Roboter wird von einem Lithium Poylmär Akku (LiPo) angetrieben. Dieder wird permanent vom Hauptcontroller auf Unterspannung überwacht. Im Unterspannungsfall wird der Roboter automatisch abgeschaltet. Die Betriebsspannung der Logik wird von 2 Festspannungsreglern auf einem konstanten Niveau von 5V gehalten. Die Getriebemotoren werden hingegen direkt vom Akku gespeist Nähere Details sind dem technischen Anhang zu entnehmen.

5: Antriebskonzept Der Roboter wird von 2 Faulhaber® Getriebemotoren angetrieben. Diese werden vom Motorcontroller über eine H-Brücke gesteuert. Dabei kann sowohl die Drehrichtung über die Polung, als auch die Drehgeschwindigkeit über eine Pulsweitenmodulation (PWM) geregelt werden. Dabei wird die PWM-Frequenz angepasst, um ein optimales Anfahren zu erlauben.

- 16 -

Technischer Anhang

Anhang 1: Der Roboter 1.1: Systemstruktur Der Roboter hat eine klare hierarchische Struktur. Es gibt einen Hauptprozessor (MCU), der über ein selbst entwickeltes Netzwerk 1 mit den ‚Slaves’ also den anderen Controllern verbunden ist. Dazu gibt es noch einen I²C-Bus. Dieser ist mit einem 8kb EEPROM verbunden, sowie mit einem I/O Baustein, der zum Debugging genutzt wird.

1.2: Der Hauptcontroller (MCU) Der Hauptcontroller ist ein ATmega8, der mit 16MHz getaktet ist. Er hat die Aufgabe, die anderen Controller zu koordinieren, und den Roboter zu steuern. Zudem fungiert er als Master des SPP-Kommunikationsprotokolls. Zudem gehört es zu seinem Aufgabenbereich, Telemetrie über das Funkmodul zu senden, und Steuerkommandos entgegenzunehmen. Er regelt auch die Flusssteuerung des Funkmoduls. Des Weiteren überwacht der Controller die Spannung des Akkus, da dieser für Unterspannung sehr empfindlich ist.

1.3: Der Motorcontroller Die Aufgabe des Motorcontrollers ist die Überwachung und die Steuerung der Räder und Motoren. Zum Einsatz kommt hier wiederum ein ATmega8 Controller. Die Motorsteuerung erfolgt über einen L293D D (in SMD-Bauform), ein H-Brücken Motortreiber, der 1

SPP, Siehe 3.

-I-

Technischer Anhang

pro Motor (2 Stk.) bis zu 500mA Leistung schalten kann. Die Motoren können unabhängig voneinander in 256 unterschiedlichen Geschwindigkeitsstufen geregelt werden, davon unabhängig die Drehrichtung. Ist der Motor also auf rückwärts geschaltet, so kann auch der "Rückwärtsgang" in 256 Stufen geregelt werden. Dies erfolgt über eine softwareemulierte Pulsweitenmodulation. Der Motorcontroller hat 4 unabhängige Odometrieeingänge, die von 2 Sensoren pro Rad ausgesteuert werden. An jedem Rad befindet sich eine Taktscheibe, die von den 2 Sensoren (CNY70 mit OPA2340 OpAmp) abgetastet werden. Dies ermöglicht einerseits eine Wegstreckenmessung mit einer Auflösung von ca. 1cm, und die Feststellung der Drehrichtung. Zudem überwacht der Motorcontroller aktiv die Fahrt des Roboters, und gleicht Ungleichheiten (die z.B. beim Überfahren einer Bodenfuge entstehen können) per PWM aus. Gesteuert und kontrolliert wird der Motorcontroller über das SPP von der MCU.

Abbildung 14 : Platinenlayout der Motorsteuerung

1.4: Der Hauptschalter Der Hauptschalter des Roboters ist keinesfalls, wie man annehmen könnte, ein Kippschalter oder etwas Vergleichbares. Der Roboter wird über einen REED-Kontakt ein- und ausgeschaltet. Dies wird von einem ATtiny12L Controller überwacht, dessen Programm ich in Assembler geschrieben habe. Ist der Roboter ausgeschaltet, ist auch der Schalt-Controller abgeschaltet. Er wird erst durch den REED-Kontakt mit Energie versorgt. Als erstes schaltet der Controller dann den Hauptstrom ein (dieser wird über einen IRF5305 MOSFET geschaltet). Somit kommt der Strom für den Controller aus der Hauptversorgung, und der REED-Kontakt kann losgelassen werden. Der Hauptschalter ist über 2 Leitungen mit der MCU verbunden, eine Request- und eine Answer-Leitung. Die Request-Leitung ändert ihren Pegel dann, wenn der REED-Schalter betätigt wird, solange der Roboter eingeschaltet

- II -

Technischer Anhang

ist (also zum Ausschalten). Ändert nun die MCU den Pegel der Answer-Leitung, so schaltet der Schalt-Controller den Roboter aus. Passiert innerhalb eines gewissen Zeitraumes nichts, kehrt der Schalt-Controller wieder in den normalen Modus zurück. Durch diesen Zeitraum kann die MCU noch rechtzeitig einen System-Shutdown einleiten, um die anderen Systemen ein Herunterfahren zu ermöglichen. Wenn die MCU im normalen Modus die Answer-Leitung auf LOW zieht, schaltet der Motorcontroller den Roboter aus. Dies ist z.B. der Fall, wenn der Akku schwach ist, und die Akkukontroll-Routine der MCU ein Abschalten befiehlt. Der folgende Programmablaufplan stellt den Programmablauf des Hauptschalters dar.

1.5: Das Funkmodul Das ACV ist mit einem Funkmodul ausgestattet. Es handelt sich dabei um ein kommerzielles easyRADIO ® Funkmodul auf dem 433MHz ISM-Band. Das Funkmodul wird dazu verwendet, Systemeinstellungen (z.B. Belichtung) und Telemetrie zur „Bodenstation“ zu übermitteln. Die Telemerie enthält Daten über das, was der Roboter gerade tut (z.B. eine neue Bildauswertung starten). Das Funkmodul ist an den SPP-HUB angeschlossen, die ausgesandten Daten werden aber von einer Flusskontrolle gesteuert, die von der MCU überwacht wird. Über SMA-Stecker angeschlossen ist eine λ/4 Antenne, die für das 70cm sowie das 2m Band geeignet ist.

1.6: Der SPP-HUB Das SPP ist das interne Netzwerkkommunikationsprotokoll des Roboters (siehe 3.) Dies läuft über UART. Da es ein Multislave-System ist, und man UART-TxD-Leitungen nicht ohne Weiteres einfach zusammen schließen kann, bedarf es hierzu zusätzlicher Hardware. (Würde man die TxDLeitungen der Slaves einfach zusammenschließen, so würden bei jeder Sendung Kurzschlüsse entstehen, und die Slaves würden sich nach und nach selbst zerstören.

- III -

Technischer Anhang

Ich habe dieses Problem mit einer hardwäremäßigen Kaskade aus AND-Gattern (der SPP-HUB) gelöst. Die TxDs der Slaves werden an die Eingänge der AND Gatter angeschlossen. Die Ausgänge der AND-Gatter gehen wiederum auf AND-Gatter, bis schließlich alle in einem einzigen Ausgang zusammengefasst sind. Da der UART mit invertierten Pegeln (negativer Logik ; 0 = HIGH und 1 = LOW) arbeitet kommen die bereits genannten AND-Gatter anstatt OR-Gatter zum Einsatz. Der letzte Ausgang der AND-Gatter kommt auf den RxD-Eingang des Masters. Der TxD des Masters ist durch einen Transistor in Emitterfolgerschaltung stromverstärkt. Insgesamt verfügt der HUB über 8 Steckplätze für Slaves. Der SPP-HUB befindet sich auf einer Platine mit dem PCF8574, der zum Debugging genutzt wird.

Abbildung 15: SPP Hub

In diesem Bild sind 8 Slaves dargestellt, es sind aber nur 2 Slaves + 1 Funkmodul angeschlossen.

1.7: Die Spannungsaufbereitung Die Spannungsaufbereitung des Roboters erfolgt über zwei 7805 Festspannungsregler, die zusammen die benötigten 5V für die Elektronik aus den 7,4V des Akkumulators erzeugen. Insgesamt sind so 2A verfügbar.

1.8: Der Akku Der Akku des Roboters ist ein Lithium Polymer-Akku (LiPo-Akku), mit 1200mAh und 7,4V Spannung. Dadurch dass es ein LiPo-Akku ist, muss dessen Spannung kontinuierlich überwacht werden. Ab einer Spannung von 6V muss der Roboter abgeschaltet werden, da sonst Explosionsgefahr für den Akku besteht. Fehlende Markenbezeichnungen können nicht zu der Annahme führen, dass keine Markenrechte bestehen. Dieses Dokument und alle in ihm enthaltenen Grafiken, Tabellen etc. sind urheberrechtlich geschützt. © 2006/2007 by Tobias Schlegel all rights reserved. www.tobias-schlegel.de

- IV -