Home

PG524-RAPTOR: Endbericht - Lehrstuhl 12

1. Schaltplan der Hauptplat Ach Ny TS TL mE Sr I E SETIT be g er am 04 gu E 8 Mt Ka et e ER vert B zns B NS 0N9 dei E R BS E E E tat BB B B 5 2 h EA DEN nn SS S S Su BP vo CC C P Fiola Elo Ze onst E EB zusam SE B la D gt s ng RE R E Odat gt EH s awra0 an gef E WE Zi voam HEET G t el ae zon Le gt Baa Tacos cl ee vz SE S a EIKSUD zc Ap Az I a a 7 sa BHR Sadao 2 zc vg zono Le ari Sietzen EES a gece ec mg oe to et gt PON E SCHWER Zeien cl A Ar Le SS E E 2 z se gt EE s o vr ks zu pose ana sec von var ka El SEdcIson 39m NEE Haccos n vol Ins ano 7 goe onay OZEZSU Sa E DIS T ONEI a es SE V ZEUOEN 9 RUE Gerd OESCH DE SIS E UNMETES SC Mu E Sua z el are zon Le gt ak Kee g Cox Bot El or eat ZZ Soe St ES a z E u et eet ZS ac Lem ES A Lemmer SAduTI0 BALENI S 5 Su rT u SAINT e gt 9NS UND ENE T EE EE en E yaa TOG e 69 n6 op dE l so va Sans oe A ET ZF 4 nsed lalala kolol le 5 ze ano T eet Ging E near Ee 09 o Ap Ar ke ZION amp 3 d Es 0 N Se ES vr 3 R ano
2. 10 11 12 void bumper_init 13 BUMPER_PORT_DDR amp 1 lt lt BUMPER_PIN_BUMPER Eingang 14 BUMPER_PORT_OUT 1 lt lt BUMPER_PIN_BUMPER 15 kein Pullup 16 MCUCSR 1 lt lt ISC2 fallende Flanke triggert 17 GICR 1 lt lt INT2 externer Interrupt2 aktiviert 18 Listing B 6 Ausschnitt aus bumper c 1 uint8_t radencoder_init 2 RADENCODER_PORT_DDR 1 lt lt RADENCODER_PIN_LINKS 3 1 lt lt RADENCODER_PIN_RECHTS als Eingang schalten 4 RADENCODER_PORT_OUT 1 lt lt RADENCODER_PIN_LINKS 5 1 lt lt RADENCODER_PIN_RECHTS kein PullUp 6 7 datenregister DATAREG_RADENCODER1_MSB 0xff 8 datenregister DATAREG_RADENCODER1_LSB 0xff 9 datenregister DATAREG_RADENCODER2_MSB 0xff 10 datenregister DATAREG_RADENCODER2_LSB 0xff 11 datenregister DATAREG_RADENCODERSUM_MSB 0xff 12 datenregister DATAREG_RADENCODERSUM_LSB 0xff 14 datenregister DATAREG_RADENCODERU1_MSB 0x00 15 datenregister DATAREG_RADENCODERU1_LSB 0x00 16 datenregister DATAREG_RADENCODERU2_MSB 0x00 17 datenregister DATAREG_RADENCODERU2_LSB 0x00 5 19 MCUCR 1 lt lt ISCO1 fallende Flanke trigger 20 MCUCR 1 lt lt ISC11 fallende Flanke trigger 21 return 0 22 23 24 uint8_t radencoder_ablauf 25 datenregister DATAREG_STATUS 26 1 lt l
3. 444455667 3455667789 7890123456789012 2109877666 5556 3334456 44455678 890123456789012 1098766555 4445 2223345 3334456 01234567890123 1098765444 3334 1112345 222345 1234567789012 0987654333 2223 0001234 11123 345556789012 0987654322 1123 9901234 00123 334445678901 0987654321 0123 8901234 90123 223345678901 98765432109 890123 678901234 789012 112345678901 987654321098 78901234 56789012345 6789012 001234567890 8765432109876 5678901234 3456789012345 45678901 901234567890 87654321098765 456789012345 234567890123456 3456789012 7890123456789 8765432109876543212345678901234567890123456789012345678901234567890123 678690123456789 8765432 1098765432223456789012345678901234567890123456789012345678901234 567890123456789 8765432 10987654333334567890123456789012345678901234567890123456789012345 3456789012345678 9876543210987654444456789012345678901234567
4. PG 524 Endbericht 161 MIKROCONTROLLERPROGRAMMIERUNG 11 72 73 74 75 76 TT 78 79 80 81 82 83 84 85 86 87 radencoder_tickdown DATAREG_RADENCODER1_MSB DA rade DA rade DA TAREG_RADENCO DER1_LSB ncoder_tickdown DATAREG_RADENCO TAREG_RADENCO ncoder_tickup DERSUM_LSB DATAREG_RADENCODERU1_MSB TAREG_RADENCO DERU1_LSB SR IN T1_vect DERSUM_MSB Interrupt Routine fuer Radencoder PD3 ist INTI radencoder_tickdown DATAREG_RADENCODER2_MSB DATAREG_RADENCODER2_LSB radencoder_tickdown DATAREG_RADENCODERSUM_MSB DATAREG_RADENCODERSUM_LSB radencoder_tickup DATAREG_RADENCODERU2_MSB DATAREG_RADENCODERU2_LSB Listing B 7 Ausschnitt aus radencoder c void motor_init MOTOR_DIR_PORT_DDR 0xf0 TCCRIA 1 lt lt WGM10 Waveform Generation Mode auf Fast PWM setzen 1 1 lt lt COM1A1 1 lt lt COM1B1 Output Compare Mode auf non inverting Mode setzen TCCRIB 1 lt lt WGM12 Waveform Generation Mode auf Fast PWM setzen 1 lt lt CS12 1 lt lt Ccs10 Frequenzvorteiler auf 1024 setzen TCNT1 0x0000 Vorladen des Timerl PWM_DDR 1 lt lt PWM_PIN_L 1 lt lt PWM_PIN_R ZA x DDR Pins von OC1A un
5. 2 2 9 Robotersteuerung Die Robotersteuerung ist die Instanz auf der High Level Programmierebene die alle vor gesehenen Modi und deren Algorithmen f r den Roboter mit den echten Fahrbefehlen 36 PG 524 Endbericht SOFTWARE realisiert Sie verwaltet die Modi Bahnplanung Routenplanung sowie den Follow Modus und f hrt diese mit entsprechenden Sequenzen von Fahrbefehlen aus W hrend die Bahn und Routenplanung eine Route erzeugen die nacheinander durch Fahrbefehle abgearbeitet wird wird beim Follow Modus der Winkel und der Abstand zum zu verfolgenden Zielob jekt gemessen und in Fahrbefehle umgesetzt Wichtig in diesem Zusammenhang ist auch der Einfluss der Odometrie Diese ist daf r zust ndig die Robotersteuerung stets ber die aktuelle Position des Roboters zu informieren 2 2 10 Schmutzerkennung Bei aktuellen Staubsaugerrobotern kommen nur unpraktikable L sungen im Bereich der Schmutzerkennung zum Einsatz Diese erkennen den Dreck nur indem sie ihn aufnehmen Normalerweise wird hierbei der Schmutz durch geschickte Luftf hrung gegen eine Metall platte geschleudert welche den Aufprall registriert Anhand der H ufigkeit der Kollisionen wird der Verschmutzungsgrad berechnet Die Projektgruppe verfolgt eine andere Strategie Hierzu wurde eine Kamera installiert die Aufnahmen des Bodens macht Die so entstandenen Fotos werden mit Hilfe von Metho den des maschinellen Lernens ausgewertet Dieser Vorgang der Schmutzerkennun
6. Betriebsspannung 3 5V 6V e Gr e 93mm x 20mm Dieses Board wird prim r zur drahtlosen Kommunikation zwischen dem Roboter und den Hauptrechnern eingesetzt Wichtige Eigenschaften sind die Ethernetf higkeit und die Unterst tzung von WLAN 802 11 b und 802 11 g Kommunikationsnormen Es gibt ins gesamt zwei Versionen dieses Board wobei eine Version einen EU inkompatiblen WLAN Standard unterst tzt Zus tzlich ist auf dem Board ein Slot f r microSD Karten vorzufin den Zwar besitzt das Gumstix bereits 32 MB Flash und 128 MB Arbeitsspeicher doch gerade bei speicherintensiven Prozessen wie in der Bildbearbeitung st t man hier schnell an m gliche Kapazit tsgrenzen Deshalb erweist sich eine Aufr stung des Platz Speichers als sinnvoll Ein weiterer Vorteil bei der Benutzung einer Speicherkarte besteht darin dass die Daten bertragung im Gegensatz zum konventionellen Flashen mittels serieller Schnitt stelle wesentlich schneller erfolgen kann PG 524 Endbericht 15 GRUNDLAGEN Erfahrungen mit dem Gumstix Aufgrund seiner Empfindlichkeit ist Vorsicht im Umgang mit dem Gumstix geboten Die PG Teilnehmer d rfen z B das Board nur mit angelegtem Erdungsband ber hren damit keine statische Entladung innerhalb des Boards stattfindet und somit evtl Besch digungen in der Hardware hervorgerufen werden W hrend der Inbetriebnahme des Gumstix traten diverse Probleme auf e Falls eine zu geringe Versorgungspannung angeleg
7. D L100 Messung S 1 lt lt A ADCL muss zuerst DSC Wart CALE C a Cern uint8_t analog_abfrage uint8_t adcAuswahl Bits und legt sie te bis Messung fertig sen werden usgel Listing B 3 Ausschnitt aus analog c ifdef USE_LED_BO LED GO DEN_PORT_ D 1 lt lt LED_ BO DEN_P uint8_t leds_init lediglich auf Ausgang schalten DEN DR N 156 PG 524 Endbericht 17 27 28 29 30 31 32 33 34 35 36 37 Q T AUNI leds_setzeBoden 0 endif ifdef USE_LED_AKKU LED_AKKU_PORT_DDR 1 lt lt LE leds_setzeAkku 0 endif return 0 D_AKKU_PIN uint8_t leds_setzeBoden uint8_t neuStatus Bei der Akku LED wird die Kathode auf Dies geschieht ueber einen Transistor ifdef USE_LED_BODEN if neuStatus LED_BODEN_PORT_OUT 1 GND gezogen lt lt LED_BODEN_PIN jelse LED_BODEN_PORT_OUT lt lt LED_BODEN_PIN tendif return 0 uint8_t leds_setzeAkku uint8_t neuStatus Bei der Akku LED wird die Kathode auf Dies geschieht direkt ifdef USE_LED_AKKU if neuStatus anschalten LED_AKKU_PORT_OUT amp 1 lt lt LE else ausschalten LED_AKKU_PORT_OUT 1 lt lt LE endif return 0 D_AKKU_PI D_AKKU_
8. PG 524 Endbericht 101 SOFTWARE U Spannung Iteration Abbildung 4 12 Verlauf von 14 Startzeitpunkt liegt der Wert bei 0 0 Die ben tigten Koordinaten werden aus dem Maus sensor und Radencoder berechnet wobei der aktuelle Winkel zur Berechnung der Position aus dem Kompassensor und Maussenor in die Berechnung mit einbezogen werden Der Kalman Filter sch tzt die aktuellen Werte des Maussensors Diese werden dann mit den gesch tzten Radencoder und Kompassensorwerten verrechnet Der Kompassensor ist so platziert dass die x Koordinaten des Maussensor nur dann Werte liefern wenn der Ro boter sich dreht Der Zusammenhang zwischen Drehung und Winkel ist in der Abbildung 4 13 gezeigt 1 void datenfusion maus_winkel double x_Mauswert Listing 4 21 Funktion zur Winkelsch tzung mittels Maussensor Mit dieser Methode wird aus den Maussensorwerten der Drehwinkel berechnet Dazu wird zun chst der momentane Winkel Startwinkel des Roboters bergeben Um die Methode einzusetzen wird die Abmessung vom Maussensor zum Mittelpunkt des Roboters ben tigt Aus der Kreisgleichung siehe Abbildung 4 13 lassen sich R ckschl sse ziehen um wieviel Grad der Roboter sich gedreht hat Die Kreisgleichung ist in vier Bereiche aufgeteilt die eine nderung der x und y Koordinate kennzeichnen e Bereich I x und y Koordinate positiv e Bereich II x Koordinate positiv und y Koordinate negativ e Bereich III x und y
9. datei und f r die berpr fung des aktuellen Befehlsmodus hierher verlagert 1 void starteSensordatenAusgabe 2 void starteGetModusName Listing 4 38 Initialisierung Somit existieren im Hauptprogramm nur noch zwei Threads f r die Odometrie Da tenfusion und der Robotersteuerung welche nicht ausgelagert werden k nnen da diese beiden Threads h ufiger und parallelisiert ausgef hrt werden m ssen Im Prozesszustand kann seitens der Robotersteuerung und der Odometrie weitaus besser kontrolliert werden wann die Methoden der Threadauslagerung aufgerufen werden Alle Methoden wurden in einer einzigen Funktion zusammengefasst 1 void execute Listing 4 39 Initialisierung Die werden nun weitaus seltener ausgef hrt als die verbleibenden zwei Threads im Haupt programm Zum Beispiel wird der aktuelle Betriebsmodus des Roboters nur noch alle 5 Sekunden berpr ft w hrend die Bilder beider Kameras sogar nur noch alle 10 Sekunden aktualisiert werden 136 PG 524 Endbericht 5 Ausblick Das zweite dritte und vierte Kapitel beschreibt die bisherige Arbeit der Projektgruppe RAPTOR Nach Abschluss des einj hrigen Projektes h lt dieser Abschnitt fest was f r Verbesserungs und Erweiterungsm glichkeiten sich ergeben Eine Erweiterungsm glichkeit des Prototyps w re es eine Saugvorrichtung zu implemen tieren Dabei muss widerrum darauf geachtet werden ob die Akkuleistung ausreicht oder gegebenenfalls ein
10. sensoren werden durch Anpassen der Koordinaten an die richtigen Stellen gesetzt Bei dem Pioneer wurden die Koordinaten dazu wie folgt gesetzt scount 4 spose 0 0 170 0 0 0 spose 1 0 050 0 130 90 spose 2 0 250 0 0 180 spose 3 0 050 0 130 90 Durch diese Einstellungen wird ein Roboter wie aus Abbildung 4 17 generiert Links im Konsolenfenster der Abbildung 4 17 sind die Sonardaten aus der aktuellen Position des Roboters zu sehen 110 PG 524 Endbericht PLAYER STAGE UL IL Aj E Befehistenster SES El bal 0 78 subs 4 Stage v2 0 3 Abbildung 4 17 Simulationsumgebung 4 6 3 Simulation starten Um Player Stage letzendlich zu starten m ssen noch einige Umgebungsvariablen gesetzt werden Dazu muss in der Konsole folgendes eingegeben werden export LD_LIBRARY_PATH home lt Name gt Player lib export PKG_CONFIG_PATH home lt Name gt Player lib pkgconfig Um eine einfache Welt aus Stage zu laden muss aus dem Verzeichnis home lt Name gt Player player lt version gt server die simple cfg Datei wie folgt aufgerufen werden player home lt Name gt Stage stage lt version gt worlds everything world cfg Es stehen auch noch andere Karten zur Verf gung wie z B die simple cfg die nur aus einigen R umen und einen Roboter besteht Diese Karte ist f r unsere Zwecke ausreichend Ist die Simulation erfolgreich gestartet worden dann m sste eine Karte zu sehen se
11. www Philips com PLAYER STAGE GAZEBO http www home htwg konstanz de marcel Robo index html ROBOTERNETZ http www roboternetz de wissen ROBOTERNETZ http www roboternetz de wissen index php AVR ISP_Programmierkabel SGL http www sgi com tech stl STUTTGART UNI ftp Etp informatik uni stuttgart de pub library medoc ustuttgart_fi DIP 2072 HtmlDateien node49 html UBLAS BOOST NUMERIC LIBRARY http www boost org doc libs 1_36_0 libs numeric ublas doc index htm VISHAY http www vishay com VX GUMSTIX CONSOLE http pubs gumstix org boards CONSOLE YX PCB10003 R1753 WIKI GUMSTIX http docwiki gumstix org WIKIPEDIA http en wikipedia org wiki Floodfill WIKIPEDIA http en wikipedia org wiki Round robin_ scheduling WINAVR http winavr sourceforge net 176 PG 524 Endbericht
12. 24 pin Flex ribbon e Gr e 80mm x 20mm Gewicht 8g Das Board enth lt bei Bestellung bereits einen vorgefertigten Linux Kernel 2 6 auf dem Flash Speicher welcher nach Belieben ver ndert oder neu beschrieben werden kann Dieses gilt jedoch nicht f r den Bootloader Sollte dieser besch digt oder fehlerhaft eingestellt werden so muss das Produkt zur ck zum Hersteller gesendet werden damit der Speicher gegen Aufpreis neu geflasht werden kann Mit diesem Board ist der Bedarf nach einer hohe Rechenleistung inkl gen gendem Ar beitspeicher erf llt Nun muss sichergestellt werden dass eine ausreichende Menge an An schl ssen f r die verschiedenen Ein Ausgabeger te vorhanden ist Erreicht wird dies durch die folgenden zwei Erweiterungs Boards Erweiterungs Board Console vx Das Erweiterungs Board console vx wird an den 60 pin Hirose connector des gumstix ver dex XL6P angeschlossen PG 524 Endbericht 13 GRUNDLAGEN za console vx Abbildung 2 2 console vx 12 Technische Details e 3 x RS 232 Ports mit miniDIN8 Verbindungssteckpl tzen e USB mini B Anschlu mit USB Host Signalen 18 bit LCD Anschlu e Serielle Funktionsports alternative GPIO Verbindungen auf 0 100 Zoll kleinen L chern e Verbindungsanschlu 60 pin I O header Gr e 80mm x 34mm e Betriebsspannung 3 5V 5V Urspr nglich wurde es bestellt damit die PG Teilnehmer erste Arbeitserfahrungen mit dem Gumstix sammeln k nnen Hi
13. des Gitters zu verletzen Der Laptop Auf dem Laptop l uft das Linux Betriebssystem und die gesamte Software die von der Projektgruppe entwickelt wurde Um ihn zu befestigen wurden kleine Ecken an der oberen Seite des Gitters ausgeschnitten Diese Ecken wurden dann mit weichem Schwammstoff gepolstert damit keine Kratzer an ihn kommen In der Abbildung A 4 ist zu sehen an welcher Position sich der Laptop befindet Die Status LEDs und der An Aus Schalter Mit den Status LEDs wird festgestellt ob der Roboter angeschaltet ist Leuchtet die gelbe LED so ist der Roboter aktiv Leuchtet die rote Lampe so ist die Akkuleistung knapp 78 PG 524 Endbericht KAROSSERIE Die Status LEDs und der An Aus Schalter wurden am Gitter befestigt So sind sie leicht zu sehen und der Roboter l sst sich einfach anschalten bzw ausschalten Befestigung der oberen Platte an der Stange Nachdem alle oben genannten Komponenten an der oberen Platte befestigt wurden konnte die Platte samt Gitter an den Stangen befestigt werden In Abbildung 3 25 ist der fertig montierte Roboter zu sehen Abbildung 3 25 Der fertig montierte RAPTOR PG 524 Endbericht 79 HARDWARE SU PG 524 Endbericht 4 Software Nachdem das zweite Kapitel Einblick in die zu programmierende Software gab spezialisiert sich dieses Kapitel auf die Realisierung der Software f r den RAPTOR Beginnend mit der Software f r den Gumstix wird danach das Weltmodell de
14. die in die entgegengesetzte Rich tung zum RAPTOR liegt wie zum Beispiel eine offene T r so f hrt der Roboter so weit nach vorne bis er sich so drehen kann dass er gefahrenlos an der neuen Wand entlang fahren kann ohne gegen die Wand zu fahren Es wird stets ein Sicherheitsabstand zur Wand gehalten der variabel eingestellt werden kann Hat der Roboter die Wand kom plett abgefahren ist somit in der Karte eine Grenze eingezeichnet worden Sofern es noch unerkundete Fl chen in der Karte gibt deren Fl cheninhalt gr er als Im ist wird die Bahnplanung aktiviert um den Raum komplett zu erkunden 4 6 Player Stage Player Stage besteht aus zwei Komponenten welche Player und Stage hei en Player ist eine Softwareschicht die den Zugriff auf die Roboterhardware unterst tzt und den Zugriff auf Netzwerkschnittstellen erm glicht Stage ist ein Simulator f r Player der neben dem Roboter auch diverse Sensoren zur Verf gung stellt Mit Stage ist es m glich Software zu testen bevor sie am realen Roboter eingesetzt wird Neben Stage gibt es noch Gazebo einen 3D Simulator Abbildung 4 16 gibt die Zusammenh nge wieder Player fungiert als Server Selbst geschriebene Programme k nnen sich ber eine Socketverbindung mit Player verbinden Wenn eine Simulationsumgebung gestartet wird kann der Benutzer ber ein selbstgeschriebenes Programm mit einem Roboter in der Simulationsumgebung mit Hil fe von Player kommunizieren Es ist auch m glich Play
15. ssen beim gleichzeitigen Zu griff verschiedener Threads abgesichert werden damit die Threads sich nicht gegenseitig beeinflussen und es weder zu Inkonsistenzen noch zu Konflikten kommt Das Hauptpro gramm verwaltet dazu Rechenzeit der verschiedenen Threads Abh ngig vom eingestellten Modus saugt der RAPTOR f hrt eine bestimmte Route ab oder folgt einem Objekt 2 2 7 Odometrie Mit Hilfe der Odometrie l sst sich die Position des Roboters durch das Beobachten der R der bestimmen Auf diese Funktion kann beispielsweise die Robotersteuerung zugreifen da sie f r die Befehlssequenzen der einzelnen Modi notwendig sind Die Odometrie ist ein zentraler Bestandteil der Navigation bzw Orientierung des Robo ters da sie die Schnittstelle zwischen der realen und der internen Repr sentation der Welt bildet 2 2 8 Kartenerstellung F r die Bahn bzw Routenplanung ist eine vorgefertigte Karte des Raums notwendig Die Kartenerstellung wird nach dem Einschalten des Roboters aktiviert Zun chst werden f r die Erstellung der Karte alle W nde eines Raumes systematisch abgefahren W hrenddes sen sammelt der Roboter mittels geeigneter Sensoren und Fahrmethoden alle Sensordaten bereitet diese auf und speichert sie in einer Karte welche den abgefahrenen Raum repr sen tiert Die erstellten Karten k nnen dann gespeichert und wieder geladen werden sobald der Roboter beim Erfassen des Raumes eine bereinstimmung mit bereits vorhandenen Karten findet
16. target color replacement color 2 if node color target color then return 3 node color replacement color 4 Flood fill west of node target color replacement color 5 Flood fill east of node target color replacement color 6 Flood fill north of node target color replacement color 7 Flood fill south of node target color replacement color 8 return Listing 4 32 Floodfill Algorithmus in Pseudocode In einem zweidimensionalen Array hat jeder Knoten acht Nachbarn meistens reicht aber die Betrachtung von nur vier oben unten links und rechts von dem Startknoten damit der Zielbereich komplett gef llt werden kann Dieses Vorgehen hilft dabei Speicher und Rechenzeitanforderungen an den Algorithmus zu verringern und wird 4 Way Floodfill genannt Die Betrachtung aller acht Nachbarn 8 Way Floodfill dagegen verbraucht mehr Systemressourcen kann aber dabei helfen den Zielbereich besser abzudecken Durch die Eigenschaft einen zusammenh ngenden Bereich unabh ngig von der Form komplett zu f llen ist der Floodfill Algorithmus auch sehr gut dazu geeignet eine Route zu erstellen die den gesamten Raum erfasst der abgefahren werden soll Die interne Git terkarte des Roboters besteht aus einzelnen Feldern welche die Rolle der Knoten in dem Algorithmus bernehmen Eine Route entsteht dadurch dass die Felder in der Reihenfolge ausgegeben werden in der sie gef
17. 1 1 Linux Board Der Staubsaugerroboter soll in der fertigen Version eine hohe Anzahl an teilweise sehr komplexen Funktionalit ten wie z B Stauberkennung Navigation Objekterkennung etc ausf hren k nnen Die ben tigten Daten aus der Umgebung werden durch verschiedene Sensoren bereitgestellt anhand derer der Roboter dann seine n chsten Aktionen planen kann Eine Bearbeitung von Sensordaten erfordert ein hohes Ma an Rechenleistung da Methoden aus den Bereichen der Bild und Signalverarbeitung ben tigt werden Zudem soll der Roboter einen Gro teil der Berechnungen in Echtzeit durchf hren k nnen da er z B m glichst rechtzeitig Objekte erkennen und ggf ausweichen soll Hierf r ist neben einer effektiven Programmierung auch leistungsf hige Hardware erforderlich Zus tzlich muss eine Vielzahl an verschiedensten Ein und Ausgabeger ten wie z B Sensoren Kameras usw unterst tzt werden k nnen Im Gegenzug zur ben tigten Rechenleistung und Flexibilit t stehen jedoch diverse Ein schr nkungen die beim Roboter ber cksichtigt werden m ssen Diese bestehen vor allem in der begrenzten Platz und Energiekapazit t welche nicht jede beliebige Hardware wie sie bei normalen Desktop PCs verwendet werden zul sst Aus Sicht der Software wird die Programmierung des Roboters extern auf Desktop PCs durchgef hrt da diese immer noch eine erh hte Rechenleistung im Vergleich zum Roboter aufweisen und der Programmierkomfort wegen der Vielza
18. 1 Aufbau der Datenfusion iria sad a a 93 e EE A E ee Eh ee EC 96 4 3 3 Selbstlokalisation mittels Maus Kompassensor 100 4 3 4 Integration der Boost Library sy ia 2 een Er br san 104 44 ee O A a a m an a ae a A E a 104 4 5 Kart nerstell uns lit Danzer na er ee Gen ee 105 4 5 1 Sensorwerte interpretieren nur le wre aber ds e 106 4 5 2 Raum erkunden 44 2 8 8 288 Ab eek 106 46 Player taz Ae ten des a de ea een Sa 107 4 6 1 Installation A EE es Be 108 4 6 2 Konfiguration des Roboters oras wies Era Ne 8 110 463 Simu lati n starkem er Eat Porras se ee 111 4 6 4 Eigene Programme erstellen 111 46 5 Makefilensa O Br a EE 113 4 7 Application Programming Interface as ar 22 Ha 2 am a a aa 114 48 Webinterface en Er sa ee E 118 4 9 Robotersteuerung 2a Narr einen 122 1 92 Follow Modus te a Le at een ef ef 124 49 20 B hnplan ne 22 2 0252 Fe wer ent 125 49 3 erer Na a a age a Sa 128 4 10 Schmutzerkennung aer ai Aer dat eg er ae weh 130 AO Trainer aa AN e ru a Te TE a un a 132 410 2 Klassifikation 23 282 8 2 E Erin BE rag 133 A Hauptprogramm 5 4 isg a area trete een 135 5 Ausblick 137 A Hardwarekomponenten 141 A 1 Skizzen der arosserie ya A Du dr en a rar EN mE En 141 AZ Schallpl ne lee ses sa rta RA a Bern 145 PG 524 Endbericht 5 Inhaltsverzeichnis 2 3 pa se er a etta ra RA Eu NE ee WR 3 145 B Mikrocontrollerprogrammierung 153 Literaturverzeichnis 175 6 PG 524 En
19. 22 AGND 8 AGND schp87 S s vierge 28 ucc cmospres LB a1 GND spas gt lt AIN1 0C PB3 AINB INTDIPB2 H gt App Z crarxcopge pi erosczpc 22 TOSCIOPCE lt TDDPCS eToo pc 26 TNSIPC3 rn lt TCKIPCZ 2 sspaypc H23 scoopeo 22 OC2PD7 Se Motoren ICPIPDE S LOCA MAMA 19 Abbildung 3 12 Realisierung der Hauptplatine B rstenmotor und GND4 auf den logischen Wert Null gesetzt Die Pins 1Y und 2Y werden ber eine Steckverbindung an den ersten Motor der R der befestigt die Pins 3Y und 4Y an den zweiten Motor der R der Der L293D erh lt am Pin VCC1 5V Spannung f r die logische Schaltung und an VCC2 12V Spannung f r die Radmotoren Um den Motor ber die Software ansprechen zu k nnen besitzt er vier Anschlusspins am ATMega32 Pin 1A kom muniziert mit PC7 des Mikrocontrollers Pin 2A mit PC6 Pin 4A mit PC5 und Pin 3A mit PC4 F r die Pulsweitenmodulation PWM kommuniziert 1 2EN des Motortreiber IC s mit PD4 des Mikrocontrollers Der Pin 3 4EN ist mit PD5 verbunden Mittels PWM wird die Fahrtgeschwindigkeit gesetzt Es werden Impulse mit voller Spannung aber variabler Breite an einen Verbraucher gesendet Dieses modulierte Rechtecksignal wird in einer kon stanten Frequenz generiert Die Breite der Schaltimpulse wird durch das Tastverh ltnis das Verh ltnis der L nge eines HIGH zu einem LOW Signal innerhalb einer Periode bestimmt Dies hat den Vorteil dass keine Spannung geregelt werden muss Da
20. 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 e 0N MOTOR_DIR_PORT_OUT amp 1 MOTOR_DIR_PORT_OUT 1 void motor_l_stopp MOTOR_DIR_PORT_OUT 1 MOTOR_DIR_PORT_OUT 1 void motor_r_fw MOTOR_DIR_PORT_OUT 1 MOTOR_DIR_PORT_OUT amp 1 void motor_r_bw MOTOR_DIR_PORT_OUT 1 MOTOR_DIR_PORT_OUT 1 void motor_r_stopp MOTOR_DIR_PORT_OUT 1 MOTOR_DIR_PORT_OUT 1 Za Setzt die PWM Werte wird nur void motor_setzepwm uint8_t speed_left uint8_t speed_right PWM_L speed_left PWM_R speed_right void motor_buerste_start MOTOR_BUERSTEN_PORT_OUT void motor_buerste_stopp lt lt lt lt lt lt lt lt lt lt lt lt lt lt lt lt lt lt lt lt MOTOR R_PIN_FW MOTOR R_PIN_BW MOTOR R_PIN_FW MOTOR R_PIN_BW MOTOR R_PIN_FW MOTOR R_PIN_BW MOTOR R_PIN_FW MOTOR R_PIN_BW MOTOR R_PIN_FW MOTOR R_PIN_BW intern aufgerufen 1 lt lt MOTOR_BUERSTEN_PIN MOTOR_BUERSTEN_PORT_OUT amp 1 lt lt MOTOR_BUERSTEN_PIN Listing B 8 Ausschnitt aus motortreiber c uint8_t checkTIWI
21. B rsten die in Abbildung 3 21 zu sehen sind wurde jeweils ein Loch f r die Befestigung der Motoren gebohrt Dann wurden die Motoren f r die B rsten an die Platte geschraubt und die B rsten an den Motoren befestigt siehe Abbildung 3 22 Befestigung der Stange an der unteren Platte Es wurden 5mm dicke Stangen gekauft und diese in 15cm lange St cke ges gt Durch zuvor gebohrte L cher in den Aluminiumplatten wurden die Stangen mit den Platten und damit letztendlich beide Platten miteinander verbunden Abbildung 3 23 Befestigung des Maussensors Der Maussensor dient zur Positionsbestimmung des Roboters Um die abgefahrene Strecke korrekt zu ermittelt muss der Maussensor sehr nah am Boden angebracht werden Er wurde mit 3mm Abstand zum Boden an der unteren Platte des Roboters befestigt Die Abbildung A 2 zeigt genau an welcher Stelle der Platte der Maussensor positioniert wurde Besfestigung der Bumper und Sto stange Im idealen Fall sollte es nicht zur Kollision mit Gegenst nden kommen Falls es trotzdem einmal dazu kommt wurden Bumper und eine Sto stange an der unteren Platte des Ro boters befestigt F r den Aufbau werden f nf Bumper gebraucht Diese werden m glichst 74 PG 524 Endbericht KAROSSERIE Abbildung 3 22 Befestigung der B rsten an der unteren Platte Abbildung 3 23 Befestigung der Stange an der unteren Platte PG 524 Endbericht 75 HARDWARE gleichm ig an der vorderen H lfte der
22. Befehle Das neue Konzept sah nun vor diese Befehle umzuleiten und statt einen Kernel Treiber anzusprechen diese Befehle anderweitig zu verwerten Die Methode ioctl zum Beispiel wird anhand seiner Parameter ausgewertet und globale Zustandsvariablen dienen der Speicherung der bergebenen Werte Auch read und write werden auf andere Befehle umgeleitet und der bergebene Datenstrom wird um spezielle Daten erweitert Es wurde ein sogenanntes Header Byte entworfen welches den Beginn einer jeden Kommu nikation darstellt Dieses Header Byte enth lt Informationen ber die n chste anstehende Aktion die Zieladresse der Kommunikation und die Gr e des Datenstroms Diese Werte werden aus dem eigentlichen Datenstrom der aufgerufenen Funktion und den ber ioctl gesetzten globalen Zustandsvariablen extrahiert und auf entsprechende Weise zusammen gestellt Anschlie end wird das Header Byte mit dem Datenstrom vereint und ber die serielle Schnittstelle an der angeschlossenen Adapter versandt Eine dritte Anbindung der API wurde bisher noch nicht behandelt und wird auch nur ganz kurz erw hnt Es kann beim Start des Kompiliervorgangs auch gew hlt werden kei nerlei Anbindung an Hardware herzustellen In diesem Fall kommt eine sogenannten leere APT zum Einsatz welche jeden Funktionsaufruf mit einem Fehler beantwortet Diese dient dazu die Fehlerbehandlungsroutinen der h heren Funktionen zu testen Eine Kapselung durch
23. CURE a A ug Time 0 1 24 01 500 sim real 0 73 subs 4 Stage v2 1 0rc2 Abbildung 4 22 Bahnplanung im Simulator 4 9 3 Routenfahrt Es folgt nun die Routenplanung Diese dient dazu einen m glichst optimalen Weg von ei nem angegebenen Startpunkt zu einem gew nschten Zielpunkt zu berechnen Diese Funk tionalit t ist innerhalb der Gitterkarte gekapselt weil ein Algorithmus verwendet wird der direkt auf der Gitterkarte arbeitet und eine speziell f r solche Zwecke implementierte Sondereigenschaft der einzelnen Gitternetzknoten welche im folgenden als Feld bezeichnet werden nutzt Es handelt sich hierbei um eine einfache Variable in den Datenstrukturen der Gitterkarten welche h here Funktionen bei Berechnungen unterst tzen und entlasten soll In dem Fall der Routenplanung werden hier Sch tzwerte der Entfernungen vom Start punkt gespeichert und anschlie end ausgewertet Bevor mit der detaillierten Beschreibung dieser Funktion begonnen wird werden noch ein paar Vor berlegungen zur Routenberech nung angef hrt Die Gitterkarte ist intern unabh ngig von der Gr e der einzelnen Felder 128 PG 524 Endbericht ROBOTERSTEUERUNG Dennoch m ssen ihr diese Angaben mitgeteilt werden Auch die Gr e des Roboters ist hier von Bedeutung Es muss ein gewisser Abstand zu den Objekten im Raum eingehal ten werden Um diesen zu berechnen werden die gerade erw hnten Werte in Form von Konstanten gebraucht Konstanten tragen der Tat
24. Datei gespeichert bis das Training beendet werden soll Bis dies jedoch geschieht werden st ndig weitere Bilder erzeugt und in ihre Histogramme berf hrt Dies dient der Merkmalsreduktion denn die Betrachtung von 640x480 Bildpunkten mit jeweils drei Farbwerten w rde die F higkeiten der verwendeten Hardware bei weitem bersteigen In Form eines Histogramms besteht ein Bild nur noch aus 3x256 Merkmalen Wenn das Ende der Trainingsphase erreicht ist was berlicherweise nach der Aufnahme von 100 Bildern der Fall ist wird ein abschlie ender Lernprozess gestartet Dieser berf hrt die gesammelten Histogramme siehe Abbildung 4 26 in eine Normalverteilungsfunktion 21 Diese besteht zum einen aus dem Mittelwert aller Histogramme und der Standard abweichung Letztere ist ein Ma daf r wie chaotisch der Boden ist Je h her die Stan dardabweichung ausf llt desto ungleichm iger ist die Farbgebung des Bodens Diese Um rechnung hat das Bodenmodell siehe Abbildung 4 27 zum Ergebnis Dieses besteht aus 3x256x2 Daten womit klar sein d rfte dass das Bodenmodell klein genug ist um eine performante Klassifikation zu erreichen Dennoch ist der Informationsgehalt so hoch dass Verschmutzungen auf dem Boden zu einem gewissen Grad erkannt werden k nnen Dieser Grad ist das Qualit tskriterium an dem sich die Schmutzerkennung des RAPTOR messen lassen muss Abbildung 4 25 Bild der Bodenkamera 4 10 2 Klassifikation Die Klassifikations
25. Der Roboter soll einen Ausschnitt des Bodens fotografieren anschlie end staubsaugen und noch ein mal fotografieren um dann durch eine Analyse der Bilder den Verschmutzungsgrad in diesem Abschnitt zu bestimmen Da der RAPTOR keinen Saugmechanismus enth lt m ssen die Teilnehmer der Projektgruppe das Staubsaugen mit anderen Hilfsmitteln bernehmen e Menschen und Haustiere sollen mittels Sensoren erkannt werden damit diese recht zeitig umfahren werden k nnen und das Staubsaugen nicht als St rung empfunden wird e Der Roboter soll eine gr ndliche Reinigung der Ecken und R nder von M bel und Tischen in einem Raum gew hrleisten Dies setzt eine Software voraus die in der Lage ist Ecken und R nder zu erkennen Ferner wird die Hardware ben tigt die in der Lage ist ein nahes Heranfahren an Hindernisse zu erm glichen damit auch dort der Schmutz entfernt werden kann 8 PG 524 Endbericht ZIEL Die mechanische Realisierung kann vom c t Bot weitestgehend bernommen werden Da der Durchmesser des c t Bots nur 12cm betr gt m ssen seine Komponenten f r den RAP TOR angemessen skaliert werden Anstelle des Mikrocontrollers wird ein Embedded Li nux Board benutzt um eine ausreichende Rechenleistung f r die vorgestellten Erweiterun gen sicherzustellen Damit steht den Teilnehmern der Projektgruppe eine fertige Entwick lungsumgebung zur Verf gung Um neben den Infrarotsensoren auch Ultraschallsensoren Navigations und Ortun
26. Epi B k 4 8 PG 524 Endbericht 99 SOFTWARE Die Matrix A beschreibt das Systemverhalten Die Matrix B legt die Gewichtung des Vektors u fest ohne Gewichtung ist B eine Einheitsmatrix Po Ax Pri A Q 4 9 Q ist die Kovarianzmatrix und erfasst das Rauschen der Sensoren bzw des Systems Der Kalmanzuwachs lautet kesha ErP rR 4 10 Matrix H legt fest wie stark die aktuelle Messung in den Systemzustand eingeht Die gelieferten Sensorwerte sind mit einem Rauschen berlagert diese wird in der Matrix R abgebildet Die Sch tzung muss anschlie end aktualisiert werden und zwar durch folgende Formel p Kp 24 H p 4 11 Die Fehler Kovarianzmatrix muss anschlie end aktualisiert werden In diesem Abschnitt wird an einem Beispiel gezeigt welchen Einfluss die Einstellungen der Filterparameter auf die gesch tzte Gr e haben In diesem Beispiel wird eine simulierte Messung einer skalaren Gr e vorgenommen also eine 5 Volt Spannung Es wird ange nommen dass die gemessene Spannung mit einem Gau schen Rauschen berlagert sei Die Standardabweichung liegt bei 0 1 Volt Der Startwert 26 bleibt f r jede Einstellung unver ndert auf Null Volt damit die Ergebnisse miteinander verglichen werden k nnen Der Wert von P _ kann zwischen 0 und 1 liegen Als erste Einstellung werden folgende Werte festgelegt eP 1 e Prozess Varianz Q exp 5 5 e Messkovarianz R 0 1 Volt Abbildung 4 10
27. OC1B PD4 PC1 SDA OCIA PDS PCO SCL ICP1 PD6 PD OCH Abbildung 3 5 Pinbelegung des ATMega32 existieren ausf hrliche Anleitungen zum Selbstbau Im einfachsten Fall wird der Mikro controller quasi direkt an den Parallelport des PCs angeschlossen was nicht empfohlen wird da im Fehlerfalle der Port besch digt werden kann Sicherer ist die Verwendung von Dioden oder einem kompletten Bustreiber 27 Zudem gibt es Programmierhardware zum Anschluss an den seriellen Port des PCs Serial ISP Aufgrund der gro en Verbreitung von USB Anschl ssen und des Komfort dieses Busses gibt es auch Adapter um Mikrocon troller ber den USB Port zu programmieren AVR ISP mkil Abbildung 3 6 zeigt ein AVRISP mkII welcher f r das Projekt angeschafft wurde Dabei handelt es sich um einen USB Programmer direkt von der Firma Atmel Die Verwendung eines bereits montierten Programmierger ts bietet den Vorteil dass dieser auch direkt von der firmeneigenen Software Suite unterst tzt wird und im Gegensatz zu Eigenbau L sungen davon ausgegangen werden kann dass er funktioniert eine Fehlersuche dort kann entfallen Anschluss am Mikrocontroller Auch wenn es verschiedenste Programmieradapter mit verschiedensten Anschl ssen auf der PC Seite gibt klassisch seriell parallel oder USB ist der Anschluss auf der anderen Seite standardisiert Zwar gibt es auch hier noch verschiedene Bauformen e Die Firma Atmel definiert eine Belegung an ein
28. Odometrie die die Werte zur Erstellung der Karte eingesetzt wird 1 void datenfusion reset double x double y Listing 4 22 R cksetzfunktion Die Methode in Listing 4 23 setzt die Koordinaten des Roboters auf einen gew nschten Punkt Sie wird in der Odometrie als Zusatzfunktion bereitgestellt 4 3 4 Integration der Boost Library F r eine Implementierung der Matrizen inkl deren Operationen wurden Datenstrukturen der Boost Library 30 verwendet Diese stellt eine Vielzahl an vorgefertigten Matrizen typen und operationen wie z B Einheitsmatrizen inverse Matrizen usw bereit welche laufzeiteffiziente Berechnungen erm glichen 4 4 Odometrie Der reale Raum wird ber eine implizit dar bergelegte Gitterkarte in Gitterzellen eingeteilt von denen jede entweder von einem Hindernis belegt oder frei sein kann Selbstverst ndlich soll der RAPTOR auch mehrfach im gleichen Raum eingesetzt wer den Eine seiner St rken besteht gerade darin einen bereits erkannten und eingespeicherten Raum wiederzuerkennen anstatt ihn erneut komplett abzufahren und eine neue Karte f r ihn zu erstellen Dabei ist es sehr unwahrscheinlich dass er sich beim neuen Start exakt am gleichen Punkt respektive in der exakt gleichen Gitterzelle befindet auf dem er beim letzten Durchlauf durch diesen Raum begonnen hat Es muss also eine Umrechnung zwischen den Punkten der bereits bekannten Karte und den Punkten der aktuell erkannten Karte vorgenommen
29. PD6 ICP1 kann zusammen mit Z hlerl verwendet werden um den aktuellen Wert einzufangen e PD7 OC2 kann als Ausgang f r Z hler2 verwendet werden 5 I2C Schnittstelle e PCO SDA ist die Datenleitung der 1 C Schnittstelle e PC1 SCL ist die Clockleitung der I C Schnittstelle PG 524 Endbericht 59 HARDWARE 6 JTAG Interface e PC2 PC3 PC4 PC5 TCK TMS TDO und TDI geh ren zum JTAG Debug Interface wor ber der Mikrocontroller programmiert und debuggt wer den kann e PC6 PC7 TOSC1 TOSC2 kann als externer Taktgeber f r Z hler2 ange schlossen werden 7 Serielle Schnittstelle e PDO RX ist Eingang der seriellen Schnittstelle USART e PD1 TXD ist der Ausgang f r die Serielle Schnittstelle und externe Takt f r den USART 8 Externe Interrupts e PD2 PD3 INTO INTI sind externe Interrupt Leitungen Des Weiteren ist der ATMega32 ausgestattet mit e Reset Setzt den Controller zur ck wenn ein LOW Pegel f r mindestens zwei Zy klen des Systemtaktes anliegt e XTAL1 XTAL2 Anschluss eines externen Taktgebers hier Quarz e AVCC Betriebsspannung f r den Analog Digital Wandler e AGND Alternative Masse AREF Referenzspannung f r den Analog Digital Wandler e VCC Versorgungsspannung e GND Masse 3 4 2 Quarz Der ATMega32 ben tigt ein Quarz Bauelement mit einer Taktfrequenz von bis zu 16Mhz Obwohl der ATMega32 einen internen Oszillator besitzt dient der externe Quarz
30. Player lib pkgconfig SPKG_CONFIG_PATH export PYTHONPATH Player lib python2 2 site packages SPYTHONPATH UY Ur Ur Ur 6 berpr fen dass Flags nicht gesetzt sind env grep CFLAGS S env grep LDFLAGS 7 Falls vorheriger Punkt eine Ausgabe verursacht m ssen die Flags deaktiviert werden S unset LDFLAGS unset CFLAGS 8 Konfiguration starten configure prefix home lt Name gt Player 9 Kompilieren make 10 Installieren S make install PG 524 Endbericht 109 SOFTWARE Stage Installation Bevor Stage installiert werden kann muss Player installiert und funktionst chtig sein 1 Download der neuesten Version von Stage vor dem Entpacken tar xzvf stage lt version gt tgz 2 In das entsprechende Unterverzeichnis wechseln cd stage lt version gt 3 Konfiguration starten configure prefix home lt Name gt Stage 4 Kompilieren make 5 Installieren make install 4 6 2 Konfiguration des Roboters Beim Starten der Simulation wird wenn nicht bewusst ge ndert der mitgelieferte Simu lationsroboter Pioneer gestartet Dieser besitzt 16 Sonarsensoren Da der realer Roboter nur vier besitzt jeweils einen vorne links hinten und rechts muss der Pioneer an unseren realen Roboter angepasst werden In dem Ordner worlds der Stage Installation befindet sich die Datei pioneer inc In dieser wird scount 16 auf scount 4 gesetzt Die vier Sonar
31. Roboter angebracht aber nicht direkt befestigt Sie wird zwischen Gitter und Lap top festgeklemmt Die Abbildung A 4 zeigt an welcher Stelle des Roboters sich die Kamera f r den Follow Modus befindet Der I C Adapter Um einen Datenaustausch zwischen dem ATMega und dem Laptop zu gew hrleisten wurde ein I C Adapter zur seriellen Schnittstelle hergestellt Der Adapter wurde an ein Gitter befestigt Zur Befestigung wurde nicht leitendes Material verwendet um einen Kurzschluss zu vermeiden Der USB Hub Der USB Hub stellt vier USB Anschl sse zu Verf gung Er wurde auf der Innenseite der oberen Platte des Roboters angeschraubt Die Abbildung der Karosserie A 3 zeigt seine Position Die Spannungsversorgungsplatinen Damit die Platinen die gew nschte Spannung erhalten wurden zwei Versorgungsplatinen hergestellt Eine versorgt das Controllerboard und die andere den USB Hub An welcher Position auf der oberen Platte diese Platinen angebracht worden sind ist in der Abbildung der Karosserie A 3 zu sehen Das Gitter Damit die Komponenten an der Innenseite des Roboters nicht sehr deutlich zu sehen sind wurde ein Gitter zwischen den zwei Ebenen des Roboters befestigt Ausserdem wurden an das Gitter zus tzliche Komponenten wie beispielsweise der An Aus Schalter und der I C Adapter angebracht Am oberen Rand des Gitters wurde ein PVC Schlauch mit einem Durchmesser von 9mm befestigt um das Risiko zu verringern sich mit den scharfen R ndern
32. St rungen einen Sch tzwert des Systemzustandes mit einer minimalen Sch tzfehlervarianz ermittelt Als Sch tzverfahren wurde der Kalman filter angewendet Dies ist ein rekursives Verfahren das den Systemzustand mittels einer Gau verteilung sch tzt PG 524 Endbericht 37 GRUNDLAGEN 2 2 12 Umgebungsmodell Da bei der Entwicklung des Roboters versucht wurde besondere Aspekte wie Schmutzer kennung zu ber cksichtigen blieb es nicht aus ma geschneiderte Software zu entwickeln die diesen Anforderungen entsprechen Hierbei ist vor allem die interne Repr sentation der Umgebung zu erw hnen Dieses Abbild der realen Welt ben tigt eine besondere Auf merksamkeit es wurden daf r verschiedene Anforderungen formuliert zum einen muss eine Anpassung an die begrenzte Rechenleistung der verwendeten Hardware m glich sein zum anderen darf dies nicht die Effizienz des Umgebungsmodells verringern Hier war es notwendig eine eigene Entwicklung vorzunehmen Die Kartenarchitektur basiert auf einer Gitterkarte Diese bietet durch ihren schnellen Zugriff eine bessere Basis zur Routenberechnung Sie wird durch verschiedene Techniken der Bildverarbeitung realisiert die aber rein auf Operationen ganzzahliger Werte aufbaut welche von der verwendeten Hardware problemlos bew ltigt werden kann Auch handelt es sich um einfacher zu implementierende Algorithmen welche durch verschiedenste Tech niken zus tzlich optimiert werden k nnen Dadurch sinkt
33. Variante f r diesen Vorgang darstellt Im Fol genden wird deshalb das Flashen des Kernel ber das Betriebssystems und den Bootloader beschrieben ber das Betriebssystem Nat rlich gibt es auch die M glichkeit einen kompletten neuen Kernel oder ein anderes Dateisystem auf den Gumstix zu berspielen Hierf r werden folgende Dateien ben tigt e rootfs arm_nofpu jffs2 das Root Filesystem PG 524 Endbericht 83 SOFTWARE e ulmage der Kernel Diese Dateien werden wieder auf den Gumstix kopiert Die Befehle df oder mount sollten anzeigen in welchem Bereich im Speicher das Root Image liegt Das Ergebnis sollte dem Beispiel Folgendem hneln 1 dev mtdblock1 on type Jffs2 rw noatime Listing 4 5 in der Konsole Sollte aber etwas anderes als mtdblockl ausgegeben werden muss beim Flashen auch eine andere Zieladresse angegeben werden Zun chst einmal muss jedoch das Dateisystem neu eingebunden werden allerdings aus Sicherheitsgr nden im Nur Lese Modus ro Das eigentliche Flashen geschieht dann ber folgende Befehls Reihe 1 modprobe sal1001_wdt margin 1 mount o remount ro echo amp amp flashcp v tmp rootfs arm_nofpu jffs2 dev mtdl amp amp flashcp tmp ulmage dev mtd2 amp amp echo gt dev watchdog or wN Listing 4 6 Flashen des Dateisystems Der Watchdog sorgt daf r dass der Gumstix nach dem Flashen automatisch neu gestar tet wird Am Terminalprogramm sollte der
34. Wird mehr als 100 KHz genutzt sollte nach Schreiben der Registeradresse eine kurze Pause von ca 50u s eingebaut sein Nachfolgend wird die Pinbelegung des Kompasssensors beschrieben Pin 1 und 9 Stromversorgung Das Kompassmodul ben tigt lediglich 5V am Pin 1 und verbraucht im Durchschnitt ca 15 mA Pin 9 wird mit Ground verbunden Pin 6 Kalibrierung Damit das Modul in jeder Umgebung m glichst genau arbeitet ist eine einmalige Jus tierung Kalibrierung empfehlenswert Die Kalibrierung erfolgt indem das Modul exakt waagerecht in alle vier Himmelsrichtungen ausgerichtet wird und jedes Mal dabei Pin 6 kurz mit GND verbundet wird Das Ergebnis wird intern gespeichert und bleibt auch dann erhalten wenn keine Spannung anliegt Alternativ kann auch ber den I C Bus die Kalibrierung durchgef hrt werden Dort funktioniert es auf die gleiche Weise mit dem Unterschied dass statt des Tasterdrucks eine 255 in das Register 15 geschrieben wird 26 PG 524 Endbericht HARDWARE Pin 7 Wechselspannungsfelder Die Abtastrate der Kompassposition erfolgt bei unbeschaltetem Pin 7 intern gew hnlich mit 60 Hz In Umgebungen mit starken Wechselspannungsfeldern kann es wegen des da durch erzeugten Magnetfeldes zu Ungenauigkeiten kommen In diesem Fall kann es g nstig sein die Netzfrequenz ber diesen Pin mit dem Modul zu synchronisieren Dazu muss das passende 50 Hz Taktsignal mit TTL Pegel angelegt werden Dies kann das Ergebnis in solch
35. ZA 158 PG 524 Endbericht 50 51 52 93 54 99 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 TT 78 79 80 81 82 83 84 CV GO Ne SCK 0 Sensor bereitet Daten auf fallender Flanke vor x _delay_us 1 Sensor kurz Zeit lassen MAUS_PORT_OUT 1 lt lt MAUS_PIN_SCK SCK 1 Daten lesen auf steigender Flanke if MAUS_PORT_IN amp 1 lt lt MAUS_PIN_SDA Bit einlesen data 1 lt lt i jelse data bes 1 lt lt i return data void maus_write uint8_t address uint8_t data address 1 lt lt 7 MSB auf 1 fuer Schreibzugriff maus_writeByte address maus_writeByte data sleepus 100 uint8_t maus_read uint8_t address maus_writeByte address sleepus 100 return maus_read Byte int8_t maus_verschiebungx return maus_read 0x03 int8_t maus_verschiebungy return maus_read 0x02 Listing B 5 Ausschnitt aus maussensor c SR INT2_vect datenregister DATAREG_STATUS 1 lt lt DATAREG_STATUS_BUMPER if datenregister DATAREG_STATUS 1 lt lt DATAREG_STATUS_BUMPERIGNORE PG 524 Endbericht 159 MIKROCONTROLLERPROGRAMMIERUNG Bumper zu ignorieren nichts machen 6 7 else 8 9 motor_stopp
36. a pd aa de a ge Get ee a eg d a a an d n 58 IE OEM a a en ee Seege 58 Ee EE 58 3 4 1 Mikrocontroller I Ns Nah Beach aha 58 Sd uerge Ea a Seal a are ba re 60 3 4 3 Kompasssensor und Gumstix ey ar rn EEE 61 34A Reset MR A A A 61 34 5 Radencoder Ut srt ct E A E DA AS E E 61 3 4 6 Ultraschallsensoren 2 a Bra aa He A A A A 63 SAT dee better s est a ds ls ts NEE Ad E 63 Bi A NR e 63 3 4 9 Stromversorgung EA a E AT EN 65 3 4 10 Kontaktsensoren paca aaa a a 67 3 4 11 Abgrundsensoren ooo a re Eee re yes 67 34 12 NIAUSSEHROR e p Za Ae IN 68 3 3 RS232 I2C Adapter 4 22 2 4 ra aa AE 68 du BESCHalliyna ner went Ge A EI ee EI 69 3 90 25 Probokell zung re er EE 69 ds DOM Ware 1 e de ee Ls ae en ee 70 207 Karosseren Ae EE en ae 70 3 6 1 Die untere Ebene sea a ne nu ae ag 70 3 6 2 Die obere Ebene iaa ee ae re 76 4 Software 81 4 PG 524 Endbericht Inhaltsverzeichnis AT Sense us A a Rs a a we 81 4 1 1 Aufbau des Flash Speichers 81 4 102 MOE ar or Is a Dc o et ai 82 ALS Inbetriebnahme peral de ns a a a ae lina 82 4 1 4 Konfiguration des Betriebssystems 0 82 4 1 5 Flashen des Kernels Dateisystems 0 83 4 1 6 Eigene Programme l ds e er e A A 85 4 1 7 Zus tzliche Hardware y tae ee EE mit 86 4 1 8 I2C auf dem Gumstix a aan lesen AR 88 4 1 9 I2C Kommunikation 2 ae re ne AC e 89 4 1 10 dro A o e ENEE 90 122 e Esto E a li ia Be 92 4 3 O E E O ee 92 4 3
37. alias eth0 smc911x 2 alias ethl smc911x Listing 4 3 etc modprobe conf ersetzt werden Als N chstes wird nun der Ethernettreiber eingebunden Durch den Kom piliervorgang von Buildroot entstehen die in Listing 4 4 aufgef hrten Dateien Diese Da teien m ssen nun mit Hilfe einer micro SD Karte oder einer seriellen Verbindung auf den Gumstix kopiert werden Die ersten beiden Module m ssen in das Verzeichnis lib mo dules 2 6 21gum kernel drivers net und die dritte Datei in das Verzeichnis lib modu les 2 6 21gum kernel drivers usb host Optional kann nun die Bluetooth Funktion so fern sie nicht genutzt wird abgeschaltet werden indem im Verzeichnis etc init d die Datei S30bluetooth gel scht oder umbenannt wird Nach einem Neustart des Gumstix kann nun ber den Befehl ifconfig festgestellt werden ob der Ethernet Controller korrekt eingebun den ist 1 gumstix buildroot build_arm_nofpu linux 2 6 21gum drivers net gumstix smc911x ko gumstix buildroot build_arm_nofpu linux 2 6 21gum drivers net smc911x ko gumstix buildroot build_arm_nofpu linux 2 6 21gum drivers usb host ohci hcd ko Q OWN Listing 4 4 Ethernet Treiber Dateien 4 1 5 Flashen des Kernels Dateisystems Um die Software auf dem Gumstix auf dem neuesten Stand zu halten werden des Ofter ne nderungen am Kernel und auch am Dateisystem vorgenommen Es wurde daher ein Verfahren entwickelt welches eine sichere
38. ar 7 Vom B amp 2112 Soda E Ze 971 Tan naz t Ir Als Siotzen F j ZIdAZISOL KE e 2 E En geen ano E42 5 Sas E El l 6 TEAT Ze ZECCZINI ONIG EN 2 we Code gt e z A nzr SEH zu P sadasow 98dcosIM CH N pl DEE S TUTI Coachen N o Evde 309 gt H BU IOV KM SEcS20e Hudk9200 280200 N380 Fat epes Abbildung A 6 Endbericht PG 524 HARDWAREKOMPONENTEN ISP su1 VO WEE RESET lt ADC7IPA CADCS PAS C ADC5 PAS XTAL2 CADCHPA4 ADCHIPA3 XTAL1 CADCZPA2 CADCIPAL AREF CADCO PAO AUCC AGND SCKYPB lt MISO gt PB6 UCC lt MOSDPBS GND SS gt PB4 lt AIN1 0C0 gt PB3 lt AINO INT2 gt PB2 T1 PB1 T XCK PB o SECH Ik pri L t O L5 IC2 100nF lt TOSC2 gt PC lt TOSCIIPCE lt TDDPCO TDO gt PC4 TMS gt PC3 TCKIPC2 SDAPCL SCLIPCO 5U OC2 PD ICP gt PD6 lt oc1MmPDS 0C1B gt PD4 lt INT1 gt PD3 2 lt INTE PD2 TxD AUR AH vum nm LA3 RX OC CTXD PDL RXD gt PD RXD_AUR T2IN T20UT u ZK R1OUT RAIN MEGA323 P R2OUT R2N S Ge A MAX3232CPE X1 ajs to o Je coo ox Abbildung A 7 Schaltplan des RS232 12C Adapters 148 PG 524 Endbericht PLATINENLAYOUTS Y veoroe ASe 94 Abbildung A 8 Layout der Maussensorplatine PG 524
39. auf den Bus gelegt wird wird sie oftmals direkt mit in den Parameter bernommen In diesem Datenbyte werden die h chstwertigen Bits f r die Adresse verwen det und die Datenrichtung als letztes Bit angeh ngt von daher ist das Datum doppelt so gro wie die eigentliche I C Adresse und im Lesemodus nochmals um eines erh ht Die richtige Adresse des Kompassmoduls ist somit die 96 das Datenbyte f r Schreibmodus lautet 192 das Datenbyte f r Lesemodus lautet 193 3 1 6 Daten bertragung Nachdem nun der Slave angesprochen und die Datenrichtung festgelegt wurde findet der eigentliche Datenaustausch statt Der Master sorgt f r die Impulse auf der SCK Leitung und je nach Modus legen er oder der Slave die Daten auf die SDA Leitung Nat rlich ist im Master Receiver Modus zu beachten dass der Master auch das ACK f r die erhaltenen Daten zu senden hat Hat der Slave verschiedene M glichkeiten Daten zu versenden z B durch verschiedene Register so muss ihm zun chst mitgeteilt werden welche Daten er senden soll Wie schon oben erw hnt bietet es sich dazu an zun chst im Schreibmodus auf den Slave zuzugreifen und ihm als Datum die Anweisungen f r den darauf folgenden Lesezugriff zu bermitteln Beispielsweise hat der Kompass ein Register f r Firmware ein Register f r die aktuelle Ausrichtung auf Byte Wert normiert zwei Register f r die aktuelle Ausrichtung in De zimalgrad 3599 entspricht 359 9 Grad hierbei werden dann schon zwei B
40. dazu dem Mikrocontroller einen genaueren Takt zu geben Ein Pin vom Quarz ist mit dem XTAL1 Eingang des Mikrocontrollers verbunden und der andere Pin mit dem XTAL2 Eingang Die Polung des direkt anschlie baren Quarzes ist irrelevant Beide Pins des Quarzes werden zus tzlich ber einen 22pF Kondensator mit der Masse verbunden Die beiden Quarze werden im Schaltplan siehe Anhang mit Q3 und Q4 bezeichnet 60 PG 524 Endbericht HAUPTPLATINE 3 4 3 Kompasssensor und Gumstix Abbildung 3 9 zeigt dass Kompasssensor und Gumstix ber eine Steckverbindung an die Hauptplatine anzuschlie en sind Hierf r werden die Pins PC1 SDA und PCO SCL des SMD ATMega32 benutzt Beide Leitungen sind ber zwei PullUp Widerst nde mit jeweils 47k Q an eine 3 3V Leitung verbunden rupp PL GND TB XCKIPBB TOSC2IPC TOSCI PC6 CTDDPCS lt TDO gt PC4 TMS PC3 TCKYPC2 PC1 SDA gt PCarscL gt OC2 gt PD7 CICP gt PD6 lt OC1APD5 lt OC1B gt PD4 lt INT1 PD3 lt INTO gt PD2 lt TXD gt PD1 RXD gt PDO MEGA32 A Abbildung 3 9 Realisierung der Hauptplatine Kompasssensor und Gumstix 3 4 4 Reset Es ist m glich den Roboter durch einen Taster neu zu starten Abbildung 3 10 zeigt wie der Schalter S3 an den invertierenden RESET Pin des Mikrocontrollers angeschlossen ist Ist der Taster gedr ckt wird GND durchgeschaltet und der Vorgang ausgel st ber einen 100 PullUp Widerstand bekommt der Taster eine Spannung vo
41. dem Roboter zu intera gieren Die Mikrocontrollerprogramme k nnten an einigen Stellen verbessert werden Beispiels weise sind einige Warteschleifen eher unelegant und einige Funktionen lie en sich durch bessere Ausnutzung von Interrupts optimieren Auch werden die Stromsparmodi nicht aus genutzt Da die Controller nicht die gr ten Stromverbraucher am RAPTOR sind stellte das bisher kein Problem dar dennoch besteht hier Verbesserungspotenzial Wie an mehreren Stellen im Endbericht erw hnt wurde ist der Gumstix irreparabel besch digt worden Das Ersetzen durch ein Laptop anstelle eines eingebetteten Systems war nur eine Notfalll sung Mit Hilfe einer zuverl ssigen Schutzschaltung und Stromver sorgung sollte der Roboter auch wieder ber den Gumstix kontrolliert werden k nnen Abgesehen von der integrierten 1 C Funktionalit t stellt der Gumstix weitaus mehr Spei cher und Rechenleistung zur Verf gung als das verwendete Notebook Auch unterst tzt 137 AUSBLICK das Gumstix Erweiterungsboard W LAN Verbindungen so dass der zus tzliche USB Stick entfallen kann In der Sensordatenfusion gibt es ebenfalls Verbesserungsm glichkeiten Es ist eine ber legung wert statt des Kalman Filters einen Partikel Filter f r die Selbstlokalisation einzu setzen Der Partikelfilter k nnte m glicherweise bessere Werte liefern jedoch m sste dies in der Praxis mit dem Kalman Filter verglichen werden um genauere Aussagen zu tref fen Eine w
42. der Aufgaben angezeigt und im Modus Routenplanung ist der sonst ausgegraute Button zum setzen der Zielkoordinaten verf gbar Des Weiteren wird gepr ft ob Zielkoordinaten f r die Routenplanung bergeben wurden welche gegebenenfalls in die Modus Datei hinzu gef gt werden m ssen Schlie lich werden beim Aufgabenplaner die bergebenen Termine in einem bestimmten Format in die Aufgaben Datei geschrieben Nachdem die verschiede nen Konfigurationsdateien ausgelesen und die Benutzereingaben gepr ft wurden wird der HTML Code erzeugt Die HTML Seite besteht aus dem festen Code des Grunddesigns der Seite den dynamischen Daten die vom Roboter erzeugt werden und den Benutzereinga ben Nach dem Einlesen und Verarbeiten der Daten k nnen sie an den richtigen Positionen innerhalb des HTML Codes platziert werden Cascading Style Sheets Das u ere Erscheinungsbild der Seite wurde mit Cascading Style Sheets realisiert CSS ist eine erg nzende deklarative Sprache zu HTML mit der eine HTML Seite gesondert formatiert werden kann Dar ber hinaus k nnen mittels bestimmter CSS Eigenschaften auch die Positionierung von HTML Elementen manipuliert werden Formatierungen und Positionierungen innerhalb des HTML Codes fallen damit weg Der HTML Code wird an bestimmten Stellen ausgezeichnet damit das Design mit einer externen CSS Datei ge ndert werden kann Dadurch wird der Inhalt der HTML Seite von dem Design getrennt JavaScript Es wurde ebenfal
43. der verwendeten Hardware nicht m glich stattdessen wurden Threadauslagerungen in normale Prozesse implementiert Da 138 PG 524 Endbericht durch ging ein beachtlicher Teil an Genauigkeit und Korrektheit verloren Das Webinterface k nnte deutlich interaktiver werden Beispielsweise k nnte mit Ajax Asynchronous JavaScript and XML realisiert werden dass das Webinterface nicht per Refresh in regelm igen Zeitabst nden neugeladen werden muss sondern die nderungen der Sensorwerte ohne Verz gerung sofort dargestellt werden k nnen Au erdem w re es dann m glich die Fernbedienung in das Webinterface zu integrieren Durch einen besseren Algorithmus k nnte die Bahnplanung auch die Form des Raumes besser in die Bahnberechnung einbeziehen Der zur Zeit verwendete Algorithmus deckt zwar den gesamten Raum ab aber im schlimmsten Fall muss der Roboter zwischen einzelnen Teilbereichen im Raum oft hin und her fahren Die Projektgruppe besuchte im September einen Wettbewerb der in Abschnitt 1 2 2 beschrieben wurde Eigens hierf r wurde der sogenannte Follow Modus entwickelt Diese zus tzliche Funktion dient dazu dem Menschen zu folgen und dabei beispielsweise ein Ta blett mit Getr nken zu fahren Hier w re eine teurere und bessere Frontkamera sehr von Nutzen Das w rde die Kamerabilder verbessern und dieser positive Effekt w rde sich di rekt auf den Follow Modus auswirken Des Weiteren k nnte ein Erwartungsbild berechnet werden s
44. die Fehleranf lligkeit deutlich aufgrund der geringeren Komplexit t 2 2 13 Follow Modus Ein zus tzliches Feature das der RAPTOR beherrscht ist der Follow Modus Die Idee einer solchen Funktion ist unter Anderem die Programmierung von Wegen Auch k nnte der Follow Modus dazu verwendet werden den Roboter in den zu reinigenden Raum zu f hren oder einfach nur den Roboter schwere Lasten fahren zu lassen In diesem Modus sind die prim ren Funktionen wie Bahn und Routenplanung inaktiv Lediglich die Datenfusion und Odometrie laufen f r die Schmutzerkennung im Hintergrund weiter Mit Hilfe der Frontkamera werden Bilder aufgenommen die mit verschiedenen Farb filtern gefiltert werden Anschlie end wird je nach Einstellung der gr te Farbblock einer bestimmten Farbe in den Bildern gesucht Dabei wird entweder nach dem gr ten roten gr nen oder blauen Farbblock gesucht Mit den gefundenen Bl cken wird anschlie end ein Korrekturwinkel berechnet den der RAPTOR fahren muss Durch die vertikale Position des Blockes l sst sich der Abstand des Objektes zum Roboter berechnen Somit ist eine Verfolgung eines Objektes m glich 2 2 14 Webinterface Ein Webinterface ist eine Schnittstelle zu einem System welches ber einen Browser an gesprochen werden kann F r den RAPTOR wurde eine solche Webschnittstelle entwi ckelt in der dem Benutzer alle Sensordaten angezeigt und bestimmte Funktionalit ten zur Verf gung gestellt werden Zun chs
45. die entsprechenden Bibliothe ken auf dem Entwicklungsrechner installiert sind In diesem Fall muss die Bibliothek VAL Video for Linux vorhanden sein Um das cross compiling erfolgreich durchzuf hren muss noch eine nderung im Makefile des Treibers vorgenommen werden Die Zeile 86 PG 524 Endbericht GUMSTIX 1 KERNELDIR 1lib modules KERNEL_VERSION build Listing 4 9 Makefile muss durch folgende Zeilen ersetzt werden 1 KERNELDIR gumstix buildroot build_arm_nofpu 2 linux 2 6 21gum 3 BUILD_ARM gumstix buildroot build_arml_nofpu 4 CROSS_COMPILE BUILD_ARM staging_dir bin arm linux Listing 4 10 Makefile Jetzt muss die Zeile 1 S MAKE C S KERNELDIR SUBDIRS PWD CC CC modules Listing 4 11 Makefile durch 1 S MAKE C S KERNELDIR SUBDIRS PWD ARCH arm 2 CROSS_COMPILE S CROSS_COMPILE modules Listing 4 12 Makefile ersetzt werden Dadurch bekommt der Compiler die Informationen wo sich der Kernel befindet und um welche Architektur es sich handelt Erneut kann durch den make Befehl in einer Konsole der Quellcode kompiliert werden Es entsteht eine ko Datei in diesem Fall das Kernel Modul gspca ko Diese und die drei zus tzlich in Listing 4 13 aufgef hrten Dateien m ssen nun auf den Gumstix kopiert werden und zwar ins Verzeichnis lib modu les 2 6 21gum kernel
46. dieser Methode erfolgt also die Fusionierung der Sensorwerte 4 3 2 Sch tzung Die Sch tzung kann als ein Verfahren definiert werden dass auf Basis von Wissen ber die Systemeigenschaften und durch Trennung von Signalen und St rungen einen Sch tzwert des Systemzustandes mit einer minimalen Sch tzfehlervarianz ermittelt Die Abweichung der Sch tzung vom wahren Ergebnis kann zwischen 10 und 100 Prozent liegen Der Grund daf r ist dass jede Messung mit unvermeidlichen kleinen Fehlern behaftet ist so dass der wahre Wert nicht geliefert werden kann Kalman Filter Der in diesem Abschnitt gezeigte Kalman Filter lehnt sich in weiten Teilen an 6 7 und 29 an Der Kalman Filter wurde 1960 von Emil Kalman entwickelt Es handelt sich hierbei um eine rekusives Verfahren das den Systemzustand mittels einer Gau verteilung sch tzt Dieser wird h ufig im Bereich von autonomen Fahrzeugen eingesetzt Es ist ein stochastischer Zustandssch tzer f r dynamische Systeme Der Kalman Filter besteht aus mehreren mathematischen Gleichungen Er ist sehr leistungsf hig wenn es darum geht vergangene derzeitige und zuk nftige Systemzust nde zu sch tzen Die Variablen 2 und 2 1 repr sentieren Messwerte diese k nnen von verschiedenen Sensorquellen stammen oder aber nur aus einer Die Variablen Ar und Ar sind die dazugeh rigen Varianzen Wie schon vorher erw hnt liefern Sensoren keine Absolutwerte die Gr nde liegen unter an derem in der Pro
47. eigene Klasse Bahnpla nung benutzt welche eine einzige public Methode namens start hat Diese nimmt den Zeiger auf die Karte und die Startkoordinaten die Stelle wo der Roboter sich gerade be findet entgegen und erzeugt als Ausgabe einen Stack von Feldern der dann als Route an die Robotersteuerung weitergegeben wird Die Hauptaufgabe der start Methode besteht in der korrekten Neuinitialisierung von internen Variablen und tempor ren Werten und dem Aufruf von Unterfunktionen welche die eigentliche Route berechnen Als Grundlage f r die Berechnung der Route wird ein modifizierter Floodfill Algorithmus 34 verwendet Dieser Algorithmus kommt urspr nglich aus der Grafikverarbeitung und dient dazu ausgehend von einem Pixel zusammenh ngende Areale gleicher Farbe zu be stimmen Es wird unter anderem f r das Eimer Tool in Paintprogrammen benutzt um die Bereiche in einem Bild zu bestimmen die mit gleicher Farbe gef llt werden sollen Ein anderes Verwendungsbeispiel sind Spiele wie Minesweeper wo mit diesem Algorithmus die Felder berechnet werden die der Spieler ge ffnet hat Der Algorithmus nimmt als Ein gabe den Startknoten die Zielfarbe und die F llfarbe Zuerst wird der Startknoten mit der F llfarbe gef rbt danach f r alle Nachbarn des Startknotens die mit der Zielfarbe bereinstimmen wird der Algorithmus rekursiv neu aufgerufen mit dem Nachbarknoten als neuem Startknoten 1 Flood fill node
48. gegeben ist Zusammengefasst wird dies in der Funktion 1 void robosteuerung fahrefollow Listing 4 31 Funktion f r den Follow Modus f r den Follow Modus welche auch als einzige Funktion in der Robotersteuerung neben dem Konstruktor die Existenz eines Kameraobjekts voraussetzt PG 524 Endbericht 123 SOFTWARE Abschlie end sei erw hnt dass die Robotersteuerung neben seiner Vielzahl an Funktio nen auch eine gro e Menge an Hilfsvariablen zur Abfrage des Roboterzustandes besitzt Die beiden wichtigsten Variablen sind modus_changed und active Die Variable modus_changed berpr ft ob der aktuelle Modus des Roboters ver ndert wurde Falls dieses stattfand m ssen neue Fahrbefehle zusammengestellt werden ansonsten wird wie vor der ber pr fung weiter verfahren Mit Hilfe von active wird hingegen berpr ft ob der Roboter sich in einem aktiven Zustand befindet oder im Stillstand verweilt Diese Variable ist n tz lich falls vom Benutzer keine expliziten Befehle eingegeben werden und der Roboter in Leerlaufzeiten seine t glichen automatischen Aufgaben abarbeiten kann Letztlich symbiotisiert die Robotersteuerung die komplexen Algorithmen der Software mit dem primitiven Fahrbefehlen der Hardware und ist deshalb ein unverzichtbarer Be standteil des Roboters Im Folgenden werden die einzelnen verf gbaren Modi des Roboters n her erl utert 4 9 1 Follow Modus Der RAPTOR soll im Follow Modus einem Menschen m
49. if TWCR amp 1 lt lt TWINT return 0 F Mena nix los ist ist nix les switch TWSR amp 0xf8 164 PG 524 Endbericht oo N On OU 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 21 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 case TW_SR_SLA_ACK Empfang registerauswahl COMMANDREGS while TWSR 0xf8 TW_SR_STOP TWCR 1 lt lt TWEN 1 lt lt TWEA 1 schickt ACK while TWCR amp 1 lt lt TWINT warte auf Anforderung switch TWSR 0xf8 lt lt TWINT case IW_SR_DATA_ACK Raptor sendet noch datenregister registerauswahl TWDR registerauswahl break y case case TW_SR_STOP break default TWIerror TWSR break switch while Wenn ich hier lande habe ich ein TWCR 1 lt lt TWEN 1 lt lt TWEA ich bin bereit break case Empfang case TW_ST_SLA_ACK senden Stopp bekommen 1 lt lt TWINT registerauswahl datenregister COMMAN while TWSR 0xf8 TWDR datenregister registerauswahl registerauswahl irgendwelch DREGS IW_ST_DATA_NACK 1 Daten TWCR 1 lt lt TWEN 1 lt lt TWEA Daten senden while TWCR 1 lt lt TWINT warte auf Anforderung while NACK eingetroffen TWCR 1 lt lt TWEN 1 lt lt TWEA und ich bin wieder bereit break y ca
50. komplexen Be schaltungen k nnte dieser allerdings nicht mehr ausreichen es empfiehlt sich also zus tzlich einen externen PullUp Widerstand z B 10 kQ einzusetzen Bei dieser Verschaltung hat der Controller noch keinerlei M glichkeiten sich mit der Au Benwelt zu verst ndigen LEDs Datenverbindungen etc Allenfalls ein Amperemeter k nnte ber den Stromverbrauch anzeigen dass der Controller aktiv ist Erste Kommunikation mit dem PC Die zuverl ssigste Methode den Mikrocontroller am PC zu erkennen ist das Program mierger t anzuschlie en und die Kennung des Controllers auszulesen Die dazu n tigen Verbindungen lassen sich aus Tabelle 3 1 entnehmen Dabei ist jedoch zu beachten e Aus Sicherheitsgr nden gibt das Programmierger t am Reset Pin keinen Pegel aktiv vor Der PullUp Widerstand wird weiterhin ben tigt 50 PG 524 Endbericht ATMEGA32 e Weder kann das Programmierger t den Mikrocontroller mit Strom versorgen noch umgekehrt Beide Bauteile m ssen von einer externen Spannungsquelle gespeist wer den Zwar sind mit dem AVRISP mkll einige Basisoperationen schon durch die 5 Volt des USB Ports m glich aber f r die echte Verwendung ist die Speisung des Control lers eine Notwendigkeit e Alle Bauteile in den Aufbauten sollten den gleichen Massepegel haben Auch das Programmierger t stellt keine Ausnahme dar Programmiersoftware Zun chst wurde das AVR Studio des Herstellers 4 zur Programmieru
51. r die B rsten und Radmotoren der I C Bus die Spannungsversorgung und alle Anschl sse f r die Sensoren Das Board wurde auf der inne ren Seite der oberen Platte befestigt damit die Kabel leichter verbunden werden k nnen Die Skizze der Karosserie Abbildung A 3 zeigt an welcher Stelle das Controllerboard angebracht wurde Die Kameras Der RAPTOR ben tigt zwei Kameras Die erste nach unten gerichtete Kamera dient der Schmutzerkennung Die Frontkamera dient dem Follow Modus In den folgenden Abschnit ten wird erl utert wo diese beiden Kameras angebracht wurden Kamera f r die Schmutzerkennung Mit dieser Kamera der Marke Philips werden Bilder des Bodens aufgenommen und analysiert Zuerst wurde ein Loch in die obere Platte mit der Fr smaschine gebohrt Um Bilder des Boden aufzunehmen wurde die Ka mera mit der Linse nach unten gerichtet an der oberen Platte befestigt Ausserdem wurden LEDs an die Kamera angebracht um den Boden ausreichend zu beleuch ten Die Abbildung A 3 zeigt an welcher Stelle der Karosserie die Kamera f r die Schmutzerkennung vorgesehen hat Kamera f r den Follow Modus Die Kamera f r den Follow Modus der n her in Ab schnitt 4 9 1 erl utert wird dient dazu Menschen zu folgen um beispielweise Ge tr nke einer Person hinterher zu tragen oder vom Menschen an eine Stelle des Bo dens gef hrt zu werden die stark verunreinigt ist Die Kamera wurde frontal an dem PG 524 Endbericht 77 HARDWARE
52. rbt wurden Der rekursive Ansatz ist sehr einfach zu implementieren und auf Fehler zu berpr fen 126 PG 524 Endbericht ROBOTERSTEUERUNG Abbildung 4 21 Unterschiedliche F rbung mit dem 4 Way und 8 Way Floodfill 34 allerdings kann er nur bei relativ kleinen R umen angewandt werden da sonst der f r die Rekursion notwendige Speicherplatz auf dem Programmstack schnell ersch pft wird Deswegen wurde der Algorithmus so modifiziert dass anstelle von rekursiven Aufrufen die Knoten in einer Liste hier Stack gespeichert werden die dann sukzessiv abgearbeitet wird Zuerst wird ein Knoten vom dem Stack genommen dann alle seine noch nicht gef rb ten Nachbarn auf den Stack gelegt Anschlie end wird der Vorgang solange wiederholt bis der Stack komplett leer ist Dieser Ansatz erlaubt es eine korrekte Route selbst f r sehr gro e R ume zu berechnen in den Tests konnte sogar f r einen 200 200 Meter gro en Raum eine Route problemlos erstellt werden Die Effizienz der berechneten Route ist dadurch gew hrleistet dass der Algorithmus nur solche Felder betrachtet die bisher noch nicht gef rbt also noch nicht besucht wurden jedes Feld wird also nur einmal angefahren Da die Nachbarn eines Feldes immer in einer bestimmten Reihenfolge betrachtet werden bilden sich lange gerade Strecken bis der Al gorithmus auf eine Wand trifft Dann wird eine parallele Strecke in umgekehrter Richtung abgefahren Somit wird eine m anderform
53. schwierigen Umgebungen verbessern In der Regel kann der Pin unbeschaltet gelas sen werden 2 1 7 Getriebemotoren Bei der Entwicklung eines mobilen Roboters ist es erforderlich irgendeine Art von Motor einzusetzen Bei der Auswahl des richtigen Motors m ssen mehrere Kriterien beachtet werden e Gr e e Strombedarf e Steuerbarkeit e Drehmoment Die Gr e der Motoren m ssen je nach Robotergr e ausgesucht werden denn die Motoren nehmen auf der einen Seite wichtige Fl chenressourcen f r andere Bauteile weg Auf der anderen Seite d rfen die Motoren nicht zu schwach sein dadurch w re der Roboter nicht mehr in der Lage sich fortzubewegen Klare Schrittweiten und oder pr zise Geschwindigkeiten erm glichen es den zur ckge legten Weg relativ exakt zu bestimmen sowie die Fahrt grader Strecken zu realisieren Der Motor sollte auch pr zise halten k nnen wenn die Abstandsensoren einen Abgrund erfassen um das Runterfallen des Roboters zu vermeiden Das Drehmoment der Motoren bestimmt die Fortbewegung Ein geringer Drehmoment in Kombination mit hoher Last f hren zu einer berlastung des Motors bzw Motortreibers Es existieren Motortreiber L293D die bei berhitzung abschalten Dadurch besteht aber das Problem dass der Roboter st ndig stehen bleibt F r fahrende Roboter kommen nur zwei Motoren in Frage Getriebemotoren oder Schritt motoren Die Projektgruppe hat sich f r Getriebemotoren entschieden da sie zu den ein fa
54. sehr genau abgefahren werden F r eine nicht durch Abstand bestimmte Fahrt kann der Motorstopp bei Countdown Ablauf auch abgeschaltet werden e Analog zum Maussensor war es jedoch sp ter n tig auch einen Aufw hrtsz hler zu implementieren der wie der Maussensor die abgefahrene Strecke aufsummiert Motoren F r jeden Antriebsmotor werden am Mikrocontroller direkt drei Pins ben tigt e ber einen Pin wird per PWM Signal eine pseudo analoge Spannung zur Regelung der Motorgeschwindigkeit bereit gestellt Der ATMega32 unterst tzt die Ausgabe von PWM Signalen nativ per Timer Counter Timer Counterl l sst sich sogar mit zwei Vergleichswerten verwenden so dass beide Antriebsmotoren ber den gleichen Z hler angesteuert jedoch unterschiedliche Geschwindigkeiten haben k nnen e Zwei weitere Pins werden ben tigt um die Drehrichtung des Motors zu bermitteln Hiermit ist auch ein sofortiger Stopp des Motors m glich Dieser ist f r ein genaues Abfahren von Strecken n tig Ein Nullsetzen der Geschwindigkeit sorgt noch f r ein sanftes Ausrollen PG 524 Endbericht 55 HARDWARE Die Programmst cke zur Ansteuerung des Motoren befinden sich im Anhang unter Lis ting B 8 Der gr ere Fallstrick ist dabei die Beschaltung zum Motortreiber und zu den Motoren richtig auf die Pins im Quelltext abzubilden 3 2 4 12C am Atmel Die ATMega Baureihe kann direkt an einen C Bus angeschlossen werden I C hei t bei Atmel TWI Two Wire
55. werden 104 PG 524 Endbericht KARTENERSTELLUNG Diese Umrechnung der von der Datenfusion als real gelieferten Umgebungskoordinaten und der im Speicher befindlichen Karten wird von der Odometrie vorgenommen In der Regel f hrt das auf eine einfache Transposition hinaus Abbildung 4 15 bei komplexeren Karten kann jedoch auch eine Skalierung n tig sein e S0 Abbildung 4 15 Transposition zwischen Startpunkten im gleichen Raumkomplex 4 5 Kartenerstellung Um die von der Bahn und Routenplanung ben tigten Karten auch nutzen k nnen m ssen diese zun chst einmal erstellt werden Hierzu wird die in Abschnitt 4 2 beschriebene Grid map genutzt Das Erstellen der Karte l sst sich zun chst in zwei grobe Berreiche untertei len das Interpretieren der Sensorwerte zur Erstellung der Karte und die Raumerkundung um eine vollst ndige Karte zu erstellen PG 524 Endbericht 105 SOFTWARE 4 5 1 Sensorwerte interpretieren Der Messbereich des Ultraschallsensors ist ein Kreissektor Beim Auslesen des Sensors wird der gemessene Abstand zum Hinderniss genutzt um zun chst 3 Punkte in diesem Sektor zu bestimmen der erste Punkt ist die Position des Ultraschallsensors in der Karte und zugleich der Mittelpunkt im Kreissektor der zweite und dritte Punkt sind die Verbindungspunkte des Kreisbogens mit den Kreisradien Aus Gr nden effizienterer Berechnungen wird der Kreissektor in ein gleichschenkliges Dreieck abstr
56. zeigt den Verlauf der gesch tzten Werte Ausrei er 50 60 Iteration haben bei dieser Einstellung keinen so gro en Einfluss auf den gesch tzten Zustand Wird die Messkovarianz reduziert siehe Abbildung 4 11 erh ht sich das Vertrauen der gemessenen Werte Statt ein Bereich nahe bei 5 Volt auszugeben liefert der Filter bereits Werte die mehr als die H lfte darunter liegen 2V olt gt ca 3 5V olt gt ca 4 3V olt gt Der Grund daf r ist dass der Filter die Messungen als sehr zuverl ssig einstuft Die Messungen erhalten eine h here Gewichtung was zu einer langsamen Anpassung der Spannung an den wahren Wert f hrt Wird f r Q ein zu hoher Wert gew hlt siehe Abbildung 4 12 verschlechtern sich die Ergebnisse 4 3 3 Selbstlokalisation mittels Maus Kompassensor Damit der Roboter sich im Raum zu Recht findet ben tigt der Roboter die aktuellen x y Koordinaten Die Klasse Datenfusion liefert die aktuelle Position des Roboters Zum 100 PG 524 Endbericht DATENFUSION P 1 R 0 01 Q e 5 5 5 4 AENA 4 8 4 5 4 23 3 93 3 6 3 33 ER 2 7 2 4 2 13 1 8 1 53 1 23 0 9 0 6 0 3 0 T T T T T T 1 0 10 20 30 40 50 60 70 Iteration U Spannung Abbildung 4 10 Verlauf von 141 P 1 R 0 001 Q e 5 5 5 57 4 57 U Spannung e gt AM AW Uu un mn w mn Se L L l L L L L L o o 10 20 30 40 50 60 70 Iteration Abbildung 4 11 Verlauf von 2 y2
57. 24 Endbericht HAUPTPLATINE 3 4 6 Ultraschallsensoren Wie in Abschnitt 2 1 2 des zweiten Kapitels bereits erw hnt werden die Ultraschallsensoren im Modus 2 betrieben Das bedeutet dass diese eine gemeinsame Trigger und Echolei tung benutzen Hierf r werden die zwei entsprechenden Pins auf GND gesetzt die die Hauptplatine zur Verf gung stellt Ebenfalls wird eine 5V Spannungsquelle f r einen Pin bereitgestellt Die sechs Ultraschallsensoren bzw dessen Trigger Echo Leitungen sind an die Pins PAO ADCO DAT ADC1 PA2 ADC2 PA3 ADC3 PA4 ADCA und PA5 ADC5 des SMD Mikrocontrollers angeschlossen 3 4 7 Leuchtdioden RAPTOR besitzt mehrere verschiedene LEDs die unterschiedlichen Zwecken dienen e Betriebszustand e Akkumulatorzustand e Bodenbeleuchtung F r den Betriebszustand und den Akkumulatorzustand existieren am Geh use des Robo ters zwei LEDs mit einem Durchmesser von 10mm Der Nutzer wird ber eine rote LED informiert wenn die Akkuleistung sinkt Diese Information wird ben tigt da der Prototyp keine Aufladestation hat die er selbstst ndig anfahren k nnte Wird der Roboter in Betrieb genommen signalisiert er dies mit einer gelben LED an dem Geh use Beide Leuchtdioden wefrden ber den Pin PB4 SS des Mikrocontrollers in SMD Bauform geschaltet Die Vorwiderst nde der beiden LEDs betragen 1600 und befinden sich auf der Hauptplatine Damit die Kamera gen gend Licht zum Fotografieren hat besitzt der St
58. 443322222 09001112 8899900123 1234567890123456789 5544 33221111 899000 78889901 23456789 4433 22110000 788990 6777890 345678 3322 11009999 677890 566678 5667 90 2211 00998888 566789 45567 55 0 11000 999887777 456789 34567 EE HH 009998 9888776666 345678 23456 Hr 3 HH 887776655555 23456789 123456 2 Ett 77766655444445 1234567890 9012395 1 H H H H H H H H 77666554444455666555443333344 901234567890 89012345 ER 665554433333445554443322222334 89012345678901 7890123456 90 Ae 5544433222223344543322111112233344567890123456789012334567890123456 E 44333221111122345432110000011222345678901234567890112345678901234567 678901 23 33222110000011 009999900111 901234567899001 9012345678 45678901 012 321110099990 9888889900 2 2 1234567788890 2 2 123456789990123456789012 210009988888 77777889 23455667778 234567788890123456789012345678901 21099887777 666677
59. 890123456789012345678901234567890123456789012345678 Abbildung 4 23 Entfernungssch tzung f r die Routenplanung 6Darstellung 0 2 99 39 coche co tr tt tt Ett rt Ett EE EE tt tritt tt tt HH HAHAHA Det nn tt tt O o HH Bert co hhh tt De e tt tt o Hd EE At O CRE CHA o HH AAA o CHA Ebbe n e HEHHEHE e a Ett o rt HHHHHH H H tt EE Ett tt 4 4 Ett D EE D bbs DE E EE tt tt tr DE rt Sir C tt tt tt Ett tt tr Arr DEE rt HR CHA CHA HA tt Ett Ett tt Ett E tt AHH CH coo hhh ES HH tt DEE tt tt e bebe tt 1234567890123456789012 Vegl nge 76 Abbildung 4 24 Die berechnete Route PG 524 Endbericht 131 SOFTWARE B den und der Menge der verschiedenen Verschmutzungsarten Die Vielzahl der Kombina tionen welche hier betrachtet werden m ssen ist so enorm dass es nicht m glich ist diesem Problem direkt zu begegnen Es werden daher in heutigen Robotern Systeme verbaut die das aufgenommene Material detektieren 2 Dieses hat zum Nachteil dass Verschmutzun gen die nicht von dem Roboter beseitigt werden k nnen nicht wahrgenommen werden Dies w re aber eine wichtige Information f r den Menschen da eine gesonderte Reinigung n tig wird Bei der Entwicklun
60. Adresse welche sich im RAM be findet geschrieben werden Als n chstes m ssen nat rlich auch die Daten an den Gumstix gesendet werden Dies geschieht mittels einer Funktionalit t in Minicom Mit CRT L A wird der Men modus ge ffnet Durch Dr cken der Taste S wird in das Kommunikations men gewechselt Hier sollte yModem ausgew hlt werden In dem nun auftauchenden Dialog sollte das Dateisystem Image ausgew hlt werden welches durch Kompilieren von Build Root entstanden ist Es tr gt normalerweise den Namen rootfs arm_nofpu jffs2 Wenn der Kopiervorgang beendet ist sollte der Flash Vorgang mit dem Befehl pro on 1 0 1 D jera all BE cp b 2000000 40000 4 filesize gestartet werden Um den Kernel zu ko pieren wird wieder das Empfangsprogramm des Bootloaders mit loady 2000000 gestartet und mittels CTRL A in das Men des Minicom gewechselt mit S in den Kommunika tionsmodus yModem und im auftauchenden Dialog das Kernel Image ausgew hlt Es tr gt normalerweise den Namen ulmage Nach dem Kopiervorgang sollte zum Flashen des Kernel die Befehle aus Listing 4 7 eingetippt werden Der Kernel und das Dateisystem sollten jetzt geflasht sein Um U Boot zu beenden sollte bootm eingetippt oder der Gumstix vom Strom getrennt werden 1 katinstall 100000 2 katload 100000 Listing 4 7 Flashen des Kernel 4 1 6 Eigene Programme Es gibt zwei M glichkeiten eigene Programme auf dem Gumstix laufen z
61. CHALL_PIN_RECHTS 11 break 12 case USCHALL_HINTEN 13 uschallPin USCHALL_PIN_HINTEN 14 break 15 case USCHALL_LINKS 16 uschallPin USCHALL_PIN_LINKS 17 break 18 ifdef USE_USCHALL_6DIR 19 case USCHALL_VORNELINKS 20 uschallPin USCHALL_PIN_VORNELINKS 21 break 22 case USCHALL_VORNERECHTS 23 uschallPin USCHALL_PIN_VORNERECHTS 24 break 25 fendif 26 default return 1 break 27 28 29 USCHALL PORT_DDR 1 lt lt uschallPin 30 USCHALL PORT_OUT 1 lt lt uschallPin 31 _delay_us USCHALL_IMPULSBREITE 32 USCHALL_PORT_OUT amp 1 lt lt uschallPin 33 USCHALL_PORT_DDR amp 1 lt lt uschallPin 34 39 Timer stoppen und 0 setzen 36 TCNTO 0 37 zeiter 0 38 TCCRO 2 lt lt CS00 39 40 Warte bis der Echo Impuls kommt 154 PG 524 Endbericht 41 while USCHALL_PORT_IN 1 lt lt uschallPin 0 42 i f TIFR amp 1 lt lt TOVO 43 zeiter 44 TIFR 1 lt lt TOVO 45 if zeiter gt 250 kommt wohl kein Impuls mehr 46 TCCRO amp 7 lt lt CS00 47 return 2x58x0x00 Fehlerwertl 48 49 50 51 Timer stoppen 52 TCCRO 7 lt lt CS00 53 Timer neu starten 54 TCNTO 05 55 zeiter 0 56 TCCRO J 2 lt lt CS00 57 58 Warte bis Echo Impuls geht 59 while USCHALL_PORT_IN 1 lt lt uschallPin 60 if TIF
62. Dieser Thread ruft die initialize Methode in der Robosteuerung auf welche die Ausf hrung der einzelnen Fahrmodi bernimmt siehe Abschnitt 4 9 Die Reihenfolge in der die Threads ausgef hrt werden wird durch die Round Robin Scheduling Strategie 35 festgelegt Bei dieser Strategie wird die Zeit in sehr kleine Schei ben aufgeteilt welche dann den einzelnen Threads nacheinander in bestimmter zuvor festgelegter Reihenfolge zugewiesen werden Das erm glicht eine faire Verteilung der Sys temressourcen so dass kein Thread unendlich lang auf die Ausf hrung warten muss das PG 524 Endbericht 135 SOFTWARE sogenannte Aushungern kommt somit nicht vor Zusammen mit der Robustheit des Verfahrens und der Einfachheit der Implementierung waren das die Hauptgr nde f r die Entscheidung diese Strategie zu w hlen Aus Performancegr nden wurden mehrere Methoden die urspr nglich als Threads f r das Hauptprogramm konzipiert wurden in eine seperate Klasse ausgelagert und in norma le Prozesse umgewandelt Hierzu geh ren vor allem Threads die eine im Verh ltnis zur ben tigten Rechenleistung untergeordnete Funktionalit t erf llen Prim r sind es die Pro zesse zur Erzeugung von Bildern der Front und Bodenkamera 1 void starteBilderzeugung_boden 2 void starteBilderzeugung_front Listing 4 37 Initialisierung Zus tzlich wurden auch die Prozesse f r die Ausgabe der aktuellen Sensordaten als Text
63. Endbericht 149 PLATINENLAYOUTS Abbildung A 10 Layout der Unterseite der Hauptplatine PG 524 Endbericht 151 HARDWAREKOMPONENTEN 152 PG 524 Endbericht B Mikrocontrollerprogrammierung 1 include lt avr io h gt 2 include uart h 3 4 ifndef BAUDEXT 5 define BAUDEXT 96001 6 endif 7 define BAUDINT F_CPU 16 BAUDEXT 1 8 9 10 uint8_t uart_putc unsigned char c 11 while UCSRA amp 1 lt lt UDRE 12 x warten bis Senden moeglich x 13 UDR c sende Zeichen 14 return 0 15 16 17 uint8_t uart_puts char s 18 while xs 19 uart_putc x s 20 s 21 22 return 0 23 24 25 uint8_t uart_init uint8_t modus 26 if modus amp 1 lt lt 0 1 Bit 0 LSB Senden 27 UCSRB 1 lt lt TXEN 28 29 if modus amp 1 lt lt 1 1 Bit 1 empfangen 30 UCSRB 1 lt lt RXEN 31 32 UBRRH BAUDINT gt gt 8 33 UBRRL BAUDINT amp Oxff 34 return 0 35 153 MIKROCONTROLLERPROGRAMMIERUNG Listing B 1 Ausschnitt aus uart c 1 uint16_t uschall_read uint8_t AuswahlRichtung 2 uintl6_t zeiter 3 4 uint8_t uschallPin 5 switch AuswahlRichtung 6 case USCHALL_VORNE 7 uschallPin USCHALL_PIN_VORNE 8 break 9 case USCHALL_RECHTS 10 uschallPin US
64. GND ziehen Durch die implizite Verundung lesen alle Ger te einen LOW Pegel wenn auch nur ein Ger t die Leitung auf LOW gezogen hat Umgekehrt lesen alle Ger te einen HIGH Pegel wenn kein Ger t die Leitung auf LOW zieht 3 1 3 G ltigkeit von Daten Grunds tzlich gilt dass ein Bit auf der SDA Leitung nur dann g ltig ist wenn es w hrend eines gesamten SCK Impulses konstant bleibt Wenn der Taktgeber selbst die Daten auf den Bus legt so wird er sicherlich selber darauf achten Wenn der Datengeber aber nicht gleich dem Taktgeber ist so darf er seinen Pegel nicht zwischen der steigenden Flanke und der fallenden Flanke auf der SCK Ader ndern siehe Abbildung 3 2 42 PG 524 Endbericht INTER INTEGRATED CIRCUIT SDA darfsich ndern SDA SDAkonstant SCK Bit g ltig Abbildung 3 2 SDA darf sich w hrend eines SCK Impulses nicht ndern 26 Eine Ausnahme von dieser Regelung sind die Start und die Stopp Bedingung die gerade dadurch zu erkennen sind dass der SDA Pegel w hrend eines SCK Impulses ge ndert wird siehe Abbildung 3 3 Startbedingung Zieht ein Ger t die SDA Leitung auf GND obwohl SCK auf HI liegt zum Beispiel zwischen einzelnen Kommunikationspaketen so signalisiert es damit dass es zum Master auf dem Bus werden und eine Kommunikation beginnen m chte Stoppbedingung Ein ansteigender SDA Pegel bei SCK Leitung auf HI Niveau signalisiert das Ende eines Kommunikationspaketes Der Bus ist s
65. Hierf r wurde eigens ein speziell angepasstes Dateiformat entworfen welches die zu speichernden Infor mationen in m glichst kompakter Form enth lt Da die begrenzende Ressource nicht der Speicherplatz sondern die Rechenleistung ist wurde auf eine Kompression der Daten ver zichtet Dies beschleunigt das Einlesen der gespeicherten Karten Um weitere Performanzvorteile zu erreichen wurde eine der h heren Funktionen direkt in die Gitterkarte integriert Es handelt sich um die Routenplanung welche einen optimalen Weg zwischen zwei Punkten berechnet Hierf r ist es von gro em Vorteil direkten Zugriff auf die Daten der Gitterkarte zu haben weil nicht der Umweg ber die f r externe Zugriffe zust ndigen Funktionen genommen werden muss N heres zur genauen Funktionsweise der Routenplanung befindet sich im Abschnitt Routenfahrt 4 9 3 4 3 Datenfusion Alle derzeitigen Roboter haben gemeinsam dass sie sowohl Sensoren als auch Aktuato ren ben tigen um ihre Umwelt zu erfassen und darauf zu reagieren Umso wichtiger ist es dass die empfangenen Informationen so genau wie m glich sind Trotz dieser einfachen Erkenntnis l sst sich dieses Problem nicht so leicht l sen weil nicht ideale Sensoren das genaue Erfassen der Umwelt fast unm glich machen Bedingt durch Fertigungstoleran zen liefert jeder Sensor neben dem Nutzsignal auch einen Rauschsignal Es gilt nun diesen Rauschsignal zu reduzieren um die Qualit t der Information zu erh hen was ei
66. Interface Das Protokoll muss nicht von Hand implentiert wer den statt dessen werden nur die vorgesehenen Register des Mikrocontrollers beschrieben und ausgelesen Zudem verhalten sich die beiden ATMega32 auf dem I C Bus wie auch der Kompass als einfache Registermaschinen Dadurch wird die TWI Routine zus tzlich entlastet so dass die eigentliche Abfrage ob ein Befehl auf dem Bus anliegt Listing in B 9 sehr kurz und bersichtlich gehalten werden kann Diese Routine muss regelm ig aus dem Hauptprogramm des Mikrocontrollers aufgeru fen werden die Befehlsauswertung wird ebenfalls vom Hauptprogramm vorgenommen 3 3 Herstellung von Platinen Einfache Leiterplatten bestehen aus einem elektrisch isolierenden Tr germaterial dem so genannten Basismaterial auf dem eine oder zwei Kupferschichten aufgebracht sind Die typische Schichtst rke betr gt 35 um f r Anwendungen mit h heren Str men werden St rken zwischen 70 um und 140 um verwendet Als Basismaterial werden in der Pro jektgruppe RAPTOR mit Epoxidharz getr nkte Glasfasermatten verwendet Auf die Kup ferschicht ist Fotopositivlack aufgetragen der mit einer lichtundurchl ssigen Schutzfolie abgeklebt ist Bei den zweiseitigen Platinen ist die Kupfer Fotolack und Schutzschicht auf beiden Seiten Die Platinen f r den Staubsaugerroboter ist in sieben Schritten manuell von den Mitgliedern der Hardwaregruppe hergestellt worden Die verwendeten Methoden werden im Folgenden n her besch
67. Koordinate negativ e Bereich IV x Koordinate negativ und y Koordinate positiv Abh ngig von dieser nderung wechseln sich die Winkelvorzeichen und m ssen umgerech net werden um den richtigen Winkel zu berechnen Bei dem Kompasswert und der aus dem 102 PG 524 Endbericht DATENFUSION y sart r Arcustangensty x alpha Abbildung 4 13 Zusammenhang Winkel und Maus nderung Maussenso ompassensor ar thmetisches Mitte Abbildung 4 14 Maussensor und Kompassensor PG 524 Endbericht 103 SOFTWARE Maussensor berechneten Winkel handelt es sich nicht um absolute Werte Die Werte ent halten noch Abweichungen vom wahren Wert Die Abweichung k nnen reduziert werden indem das arithmetische Mittel der beiden Werte gebildet wird Die Roboterposition wird in definierten Zeitabst nden aktualisiert Dazu wird der gesch tzte zur ckgelegte Weg x und die ge nderte Orientierung a ebenfalls gesch tzt mit der zu letztgespeicherten Position des Roboters verrechnet Hier wird angenommen dass sich bis zur n chsten Ak tualisierung der Roboter geradlinig bewegt Da die Zeitspanne sehr klein ist ist der Fehler der in die Rechnung eingeht auch nur sehr klein Die Position des Roboters p zx y a wird folgenderma en berechnet e Eingabe a x p el f l a x r x sin a p y x cos a dp a 0p Diese Formel berechnet die neue Roboterposition und bergibt die berechneten Werte der
68. L EE EE 74 Befestigung der B rsten an der unteren Platte 75 Befestigung der Stange an der unteren Platte 2 22222 75 Ultraschallsensor an dem Metallst ck 77 Der fertig montierte RAPTOR 2 222 oo on nn 79 Anschluss an das Carrier Board a ser ner Var 88 Carrier Board mit Anschlusskabel 89 Nutz nd St rsignal se sa terio li Dec ee a st 93 e se ae a N a a a ea ier Bere ege E 94 Extrapolieren der verz gerten Daten 94 Oben Ohne die Werte zu extrapolieren Unten Extrapolieren der Werte 95 Qualit t einer Messung anhand der Gau glocke 6 98 Varianz zweier Messungen 6 scada a ae 98 der Tino eo dd a I en 99 Verlauf VOM Tpi un d e den A E ST A a A ee er 101 Verlauf VOD Ur in ae le a ee a o AEN ee 101 Verla E Sa Date Aa he an BAR hr Ser ne ee EE 102 Zusammenhang Winkel und Maus nderung 103 Maussensor und Kompassensor 103 Transposition zwischen Startpunkten im gleichen Raumkomplex 105 Komponentenuebersicht Player Stage Gazebo 25 108 Simulationsumgebung ud de en een 111 Sinllationsumeebunf e Ye 2a a a Ee e he 112 Ein Darstellung der API a a A te les 114 KC e GET 121 Unterschiedliche F rbung mit dem 4 Way und 8 Way Floodfill 34 127 Bahnplanung im Simulator 2 2a as a a Bea A 128 Entfernungssch tzung f r die Routenplanung 2 2 2 22 22 131 Die berechnete Route 3 22 x zu E mer ee De 131 Bild der Bodenkamera Ae o et Ina ER 133 Histogramme
69. PI GND gezogen N N Listing B 4 Ausschnitt aus leds c void maus_init MAUS_PORT_DDR 1 lt lt MAUS_PI SCK und SDA auf Output MAUS_PORT_OUT 1 lt lt MAUS_PI SCK und SDA auf high N_ N_ S S DA DA 1 lt lt MAUS_PIN_SCK 1 lt lt MAUS_PIN_SCK PG 524 Endbericht 157 MIKROCONTROLLERPROGRAMMIERUNG 17 sleepns 100 maus_write 0x00 0x80 Reset sleepns 10 maus_write 0x00 0x01 kein Sleep modus sleepms 10 void maus_writeByte uint8_t data int8_t i MAUS_PORT_DDR 1 lt lt MAUS_PIN_SDA SDA auf Output for i 7 i gt 0 i MAUS_PORT_OUT amp 1 lt lt MAUS_PIN_SCK SCK auf Low Daten vorbereiten if datas 1 lt lt i Bit rausschieben MAUS_PORT_OUT 1 lt lt MAUS_PIN_SDA jelse MAUS_PORT_OUT 1 lt lt MAUS_PIN_SDA MAUS_PORT_OUT 1 lt lt MAUS_PIN_SCK SCK 1 Sensor uebernimmt aul _delay_us 1 Sensor Zeit lassen um Bit zu holen steigender Flanke MAUS_PORT_DDR amp 1 lt lt MAUS_PIN_SDA MAUS_PORT_OUT 1 lt lt MAUS_PIN_SDA Hochohmig schalten uint8_t maus_readByte int8_t i uint8_t data 0 _delay_us 3 Sensor Zeit lassen x um die Daten aus dem Register zu holen x for i 7 i gt 1 i MAUS_PORT_OUT 1 lt lt MAUS_PIN_SCK
70. Re 1 lt lt TOVO 61 zeiter 62 TIFR 1 lt lt TOVO 63 if zeiter gt 250 kein Ende in Sicht 64 TCCRO amp 7 lt lt CS00 65 return 2x58x0x00 Fehlerwert2 66 67 68 69 Timer Stoppen 70 TCCRO amp 7 lt lt CS00 71 zeiter zeiter lt lt 8 TCNTO 72 73 Halte den Pin zwischen den Messungen auf LO 74 USCHALL_PORT_DDR 1 lt lt uschallPin 75 USCHALL_PORT_OUT amp 1 lt lt uschallPin 76 TI return zeiter 78 79 uint16_t zeiter2cm uint1l16_t pulsbreite 80 81 x pulsbreite 1 entspricht 500nS 82 x pulsbreite 2 entspricht lus 83 PG 524 Endbericht 155 MIKROCONTROLLERPROGRAMMIERUNG 84 85 86 87 x 58uS entsprechen Lem return pulsbreite 2 58 Listing B 2 Ausschnitt aus uschall c uint8_t analog_init ADCO 00000 1 lt lt REFSO 0x00 0b00000000 Prescaler von 128 ADMUX REFS AVCC 01 x ADLAR leftadjust 1 x MUX40 PAO Se ADMUX 1 lt lt ADLAR EF Gens 7 x ADCSRA Bei 16MHZ ADPS2 0 111 x ADEN Enable ADCSRA ANALOG_PRESCALER lt lt A ADCSRA 1 lt lt ADEN Ja x loescht die letzten 3 x wie in der Auswahl x Auswahl x 0 und x ADMUX ADCSRA while A return A 0xf8 liegt DPSO im Bereich zwischen 7 Pinnummer ADMUX 1 lt lt ADSC DCSRA amp DCH 0b1111 0xf8 adcAuswahl
71. Reboot verfolgt werden k nnen Sollte alles funktionieren startet der Gumstix nach der U Boot Wartezeit sofort das neue Image ber den Bootloader Der Kernel oder das Dateisystem sollte nur im Bootloader geflasht werden wenn das Betriebssystem nicht mehr funktioniert weil das Flashen im Bootloader bis zu einer Stunde dauern kann und durch Tippfehler die ganze Prozedur von neuem beginnt Als Erstes muss der Gumstix an einen seriellen Port angeschlossen werden Mit dem Befehl minicom s wird auf dem angeschlossenen Rechner das Konsolenprogramm gestartet das einen Zugriff auf die Konsole des Gumstix erm glicht Doch zuerst m ssen im Men folgende Parameter eingestellt werden e Serial Device dev ttyS0 e Bps Par Bits 115200 8N1 e Hardware Flow Control No e Software Flow Control No Nachdem die Daten gespeichert sind und die Konfiguration verlassen wurde sollte die Gumstix Konsole mit minicom o gestartet werden Um in den Bootloader zu kommen 84 PG 524 Endbericht GUMSTIX muss sofort nach dem Einschalten des Gumstix eine Taste gedr ckt werden Wenn ein Gum gt erscheint hat der Vorgang geklappt Zuerst sollte das Dateisystem geflasht werden indem das Image des Dateisystems auf den Gumstix kopiert wird Hierf r wird zun chst das Empfangsprogramm des Bootloaders mit dem Befehl loady 2000000 gestartet Dieser Befehl sorgt daf r dass die ber den seriellen Port empfangenen Daten im Speicher an die angegebene
72. Sensoren st ndig der aktuelle Standort des Roboters neu berech net und die Fahrt anschlie end fortgesetzt wird Au erdem besteht die Gefahr dass der Schrittmotor Schritte verlieren kann Es ergibt sich das selbe Problem wie beim Getrie bemotor und es m sste ein zus tzlicher Sensor eingebaut werden um den Effekt wieder auszugleichen Der Schrittmotor verliert auch mit steigender Drehzahl an Kraft also ist der Motortyp nicht f r schnelle Roboter geeignet Ausserdem m sste wenn ein Schrittmotor eingesetzt wird ein geeignete Getriebewahl getroffen werden der die Motorkraft auf die Antriebsr der realisiert Ohne Getriebe h tten wir folgende Probleme e Ein Schrittmotor h tte mit einem Schrittwinkel von 18 Grad eine zu ungenaue Be wegung e Die am Rad einwirkende Kraft ist zu gro der Motor w rde zu stark belastet 28 PG 524 Endbericht HARDWARE Abbildung 2 17 Ein ATMega32 in in PDIP Bauform 2 1 8 Mikrocontroller Obwohl der Gumstix selbst auch mit diversen Ein und Ausg ngen f r digitale Signa le ausgestattet ist hat sich die Projektgruppe entschieden die Sensordatenerfassung und Motoransteuerung auf Mikrocontroller auszulagern Abgesehen davon dass hierbei erheb lich mehr Einfluss bei zeitkritischen Abfragen genommen werden kann erm glicht dies eine bessere Trennung zwischen der Hardwareansteuerung und Aufgaben wie Routenplanung und Kartenerfassung Zudem ist im Fehlerfalle ein Mikrocontroller erheblich g
73. Suche nach der Position gr ter hnlichkeit erfolgt innerhalb eines vor ab definierten Suchbereiches der um die unverschobene Position des Blockes definiert ist Denkbar w re den Suchbereich so gro wie das Bild zu w hlen dies geschieht aber auf Kosten der Rechenzeit Der Suchbereich sollte daher so klein wie m glich aber auch so gro wie n tig sein um alle Bewegungen im Bild detektieren zu k nnen Auch die Wahl der Blockgr e h ngt davon ab wie genau die Ergebnisse sein sollen Hier gilt umso klei ner die Bl cke umso rechenintensiver und genauer sind die Ergebnisse Analog gilt umso gr sser die Bl cke umso rechenzeitsparender und ungenauer die Ergebnisse F r die Be wertung der hnlichkeit zwischen Bl cken wird die normierte Kreuzkorrelationsfunktion normalized cross correlation function NCCF verwendet M glich w re es auch andere Funktionen zu verwenden wie z B den quadratischen Fehler squared error SE oder den absoluten Fehler auch displaced frame difference DFD genannt Ein Vorteil der NC CF ist die Robustheit gegen ber Kameraschwenks 1 Dadurch werden die gefundenen Verschiebungsvektoren durch die Bewegung des Roboters w hrend der Verfolgung eines Menschen nicht verf lscht M glich w re eine Kombination aus dem ersten und den zweiten Verfahren um robus tere Ergebnisse zu erzielen Durch die beschr nkten Rechenressourcen ist dies aber nicht m glich auch das NCCF Verfahren alleine ist mit d
74. TECHNISCHE UNIVERSIT T DORTMUND FACHBEREICH INFORMATIK PG 524 RAPTOR Room Adaptive Precisely Topologically Orienting Robot Endbericht Sommersemester 2008 INTERNE BERICHTE INTERNAL REPORTS Lehrstuhl XII Embedded System Design Fakult t f r Informatik Technische Universit t Dortmund Betreuer Olivera Jovanovic Robert Pyka GERMANY D 44221 DORTMUND Endbericht Projektgruppe 524 Room Adaptive Precisely Topologically Orienting Robot RAPTOR Sommersemester 2008 Teilnehmer Ender Ayalp Sariette Bille Omar Bousbiba Daniel Etges Igor Ionov Selma Jabour Oliver Jokiel Dominik Kopczynski Markus Kiinne Yi Lin Samir Rachidi Daniel Richter Betreuer Olivera Jovanovic Robert Pyka Technische Universit t Dortmund Fachbereich Informatik LSXII Prof Dr Peter Marwedel PG 524 Endbericht Inhaltsverzeichnis 1 Einleitung AA a siset E a a En ee Reg Eet ar ara a ns A Br a rra EE E He KE EE 1 2 2 Erweiterungsm glichkeiten 1 3 Vorgehens EEN 2 Grundlagen Za Hardware esta al E a o ar eet A e 2 1 1 Jee Board EEN a a 22 Ultraschallsensoten i ds Bars a e rn aii 2 1 3 Kontaktsensoren e 2 1 4 Lichtsensoren 2 129 Maussensofr Vo er 280 e it ida a ee e 210 Kompasssensor tes sa a dl e ita ef 2 1 7 Getriebemotoren SES Mikrocontroller Lsu eag tt Aa a Kun Dans en DOS Kameras an ge e De a a A a get 2 27 OEL WARE E a NE Ne ta VE Ta EB A O EC 252 411 B ild
75. TWARE 4 2 Weltmodell Ein Roboter erfasst die Welt mit Hilfe seiner Sensoren Er errechnet aus diesen Wahrneh mungen ein Modell der Umwelt welches dazu dient seine Position im Raum zu lokalisieren und zuk nftige Aktionen zu planen Dieses Modell wird das Weltmodell genannt Der RAPTOR nutzt hierf r eine Gitterkarte Diese stellt den bisher erfassten Raum als Koor dinatensystem dar Jeder einzelne Punkt in diesem Koordinatensystem repr sentiert einen Abschnitt im Raum f r welchen mehrere Informationen hinterlegt sind Diese sind zum Beispiel die Belegungswahrscheinlichkeit welche angibt mit welcher Wahrscheinlichkeit diese Stelle f r den RAPTOR befahrbar ist Intern wird f r die Gitterkarte die Datenstruktur Vector verwendet die ein Teil der Standard Template Library 28 ist Sie ist bestens f r diesen Anwendungszweck geeignet denn sie ist dynamisch w hrend der Laufzeit in ihrer Gr e ver nderbar und bietet zudem einfachen und sicheren Zugriff auf die in ihr gespeicherten Informationen Da sich in der Datenstruktur Vector wiederum Datenstrukturen einbetten lassen wird auch von einer Containerstruktur gesprochen F r den RAPTOR wurde hier eine eigene Klasse entwickelt welche alle relevanten Informationen wie zum Beispiel den Grad der Verschmutzung be reith lt Neben der Datenspeicherung w hrend der Laufzeit ist auch eine Speicherung des Welt modells von Bedeutung welche ein Ausschalten des Roboters berlebt
76. affen k nnen selbstprogrammierte Treiber von Privatanwendern aus der Linux Community allerdings sind diese meist experimenteller Natur und unterstehen keinerlei Qualit tskontrolle durch die Hersteller Es sei erw hnt dass ein Treiber unter Linux kom patibel f r eine gr ere Gruppe an Peripherie ist leider geh hren die beiden Webcams des Roboters nicht derselben Gruppe an weshalb zwei verschiedene Treiber ausfindig gemacht und installiert werden mussten Aus Sicht der Hardware werden Webcams standardm ig durch einen USB Anschlu betrieben welcher gleichzeitig als Stromquelle und zur Daten bertragung benutzt wird Unter normalen Desktop PCs bestehen keinerlei Probleme bei der Stromversorgung da der Strombedarf durch den Netzbetrieb gedeckt wird F r den Roboter mit seinen begrenzten Energiekapazit ten sollte die Benutzung der Webcams genau kalkuliert werden damit es nicht zu Engp ssen in der Stromversorgung kommt zumal andere Sensoren und Aktoren auch Energie ben tigen und die Ressourcen dementsprechend verteilt werden m ssen Un ter Umst nden w re es sinnvoll wenn die Stromversorgung der Webcams extern durch seperate Stromleitungen gesichert und der USB Anschlu lediglich zur Daten bertragung benutzt wird F r erste Testbilder in einer Linuxumgebung wurde eine verh ltnism ig billige Webcam der Marke Logitech SweetPea QuickCam Express von der Firma Logitech 18 gekauft Im Laufe der Projektgruppe stellte sich aber herau
77. ahiert Da der Ultraschallsensor einen Messwinkel von 50 hat l sst sich nicht exakt bestimmen wo genau auf diesem Kreisbo gen sich das Hinderniss befindet Deshalb wird in diesem Verfahren das Ausschlussprinzip genutzt Zun chst werden die Kreisradien gerastert Mittelpunktschema Algorithus 11 so dass sie dem Raster der Gridmap entsprechen Im Weiteren Verlauf werden alle Grids die sich im Dreiecks befinden auf Null gesetzt was bedeutet dass es sich bei diesen Grids um keine Hindernisse handelt Dies geschieht mittels eines Algorithmus der Polygone f llt 11 Der Algorithmus f ngt beim Mittelpunkt des Kreissektors an Es werden parallel zur vom Mittelpunkt gegen berliegenden Kante Kanten gebildet und danach berpr ft welche Grids sich auf der Kante befinden Wenn ein Grid auf der Kante erkannt wird wird dieser auf Null gesetzt Nachdem alle Grids auf der Kante neu gesetzt sind wird eine neue Kante gebildet die sich immer weiter vom Mittelpunkt entfernt bis sie an die Kante des Kreisbogens ankommt Die Grids die sich an der Kante des Kreisbogens befinden werden auf 1 somit als Hinderniss gesetzt Beim einmaligen Messen des Ultraschallsensors kann somit ein kleiner Ausschnitt der Karte geschrieben werden Um eine Karte des kompletten Raumes zu erstellen muss der RAPTOR nun durch den ganzen Raum fahren damit eine m glichst exakte Karte des Raumes erstellt werden kann 4 5 2 Raum erkunden Die Raumerkundung folgt einem s
78. altung von der Simulation auf den Roboter und umgekehrt war das gleichzeitige Arbeiten eine weitere Hilfe Es konnte parallel am Roboter und am PG 524 Endbericht 107 SOFTWARE Simulator gearbeitet werden ohne das Mitglieder der Projektgruppe auf andere warten mussten client Abbildung 4 16 Komponentenuebersicht Player Stage Gazebo 25 4 6 1 Installation Im Folgenden wird die Installation von Player Stage dokumentiert Player Installation Diese Installationsanleitung beschreibt die User spezifische Installation von Player Stage in einem Unterordner Player des eigenen Home Verzeichnisses Standardm ig sind die Installationsroutinen von Player Stage darauf eingerichtet eine lokale Installation f r alle Nutzer vorzunehmen Daher mussten einige nderungen an dem empfohlenen Installati onsablauf vorgenommen werden 1 Download der aktuellen Version player lt version gt tar bz2 von SourceForge nach home lt name gt Player 2 Wechseln nach home lt name gt Player cd home lt name gt Player 108 PG 524 Endbericht PLAYER STAGE 3 Entpacken S bzip2 d player lt version gt tar bz2 tar xvf player lt version gt tar 4 Wechseln ins Player Verzeichnis cd player lt version gt 5 Setzen von Umgebungsvariablen export PATH Player bin PATH export CPATH Player include SCPATH export LIBRARY_PATH Player 1lib LIBRARY_PATH export PKG_CONFIG_PATH
79. ame 6 if pthread_mutex_unlock m mutex 0 T cerr lt lt FEHLER API_Mutex UnLock fehlgeschlagen lt lt endl 8 return rueckgabe 9 Listing 4 26 Pre Compiler Macro einer Funktion in der Thread Safe API Wie zu erkennen ist werden auch Fehlermeldungen generiert die dazu dienen eventuelle Probleme mit den angesprochenen Mutexen zu lokalisieren Der eigentliche Funktionsaufruf wird an das Objekt real_api weitergeleitet welches die angebundene Hardware repr sen tiert Diese kann zum einen reale Hardware sein oder simulierte Im Verlauf der Entwicklung der h heren Funktionen ist es n tig geworden viele Tests mit angebundener Hardware zu machen Da jedoch nur ein Roboter zur Verf gung steht musste auf einen Simulator siehe 4 6 5 zur ckgegriffen werden Um sicherzustellen dass die Software welche mit Hilfe des Simulators entwickelt wurde auch mit dem verwendeten RAPTOR funktioniert mussten alle Funktionsaufrufe welche in der API definiert sind un ver ndert bleiben Es war also n tig alle Befehle der API an den Simulator in angepasster Form weiterzuleiten Anders als das Ansprechen von realer Hardware wird der Simula tor ber Funktionsaufrufe angesprochen Dies dient einem intuitiveren Programmierstil und ist sehr einfach zu implementieren da die Funkitonalit ten der API Funktionen oft denen der Simulator Funktionen gleichen Dennoch birgt die Anbindung eines Simulators ein paar T cken wie zum Beispi
80. amm f r den Roboter verwendet Wichtig hierbei war es ein System zu finden welches alle verwendeten Sensoren unterst tzt Die Wahl fiel auf Player Stage da es sich hierbei um ein Open Source Projekt handelt welches frei erweiterbar ist und somit zus tzliche Funktionalit ten integriert werden konnten Des Weiteren wies das Projekt eine solide Be nutzergruppe auf was von gro er Bedeutung war da ihr Wissen genutzt werden konnte um zum Beispiel spezielle Einstellungen vorzunehmen Es handelt sich hierbei um eine Kombination aus zwei Systemen Bei Player handelt es sich um einen Server der mittels Einbinden von Treibern beispielsweise Odometrietreiber die Kommunikation der ver schiedenen Komponenten eines Roboters steuert und verwaltet Um Befehle an den Server schicken zu k nnen oder Sensorwerte empfangen zu k nnen stellt Player eine TCP Ver bindung bereit Selbst entwickelte Steuerprogramme k nnen so mit Player kommunizieren Ein spezieller Treiber von Player ist Stage Dieser dient dazu eine k nstliche Umwelt zu erschaffen in der ein simulierter Roboter bereit gestellt wird um darauf basierend Sensor werte zu simulieren und Fahreigenschaften zu testen Durch die Kombination beider Komponenten l sst sich Software f r den Roboter entwi ckeln und testen ohne auf die verwendete Hardware zur ckgreifen zu m ssen So k nnen mehrere Teams gleichzeitig Bestandteile der Robotersoftware entwickeln Hierzu muss lediglich die Vorbedingung
81. astische Differenzgleichung beschrieben 6 Zu k Kpt 2k41 Er 4 1 1 void kalmanfilter_time_update Listing 4 18 Time Update Phase Diese Methode realisiert die erste Formel und stellt die brechneten Werte bereit die f r die anschlie ende Fusion ben tigt wird Krti Sr k Oky 4 2 1 void kalmanfilter_fusion Listing 4 19 Fusions Phase Hier werden die berechneten Werten weiterverarbeitet um die Zust nde des Roboters wie beispielsweise Position Winkelausrichtung Geschwindigkeit etc optimal zu sch tzen 1 void messung Listing 4 20 Aufruf der Sensorwerte F r den Kalman Filter ist es wichtig dass er laufend Sensorinformationen bekommt Dies wird mit der Methode void messung realisiert Nach jedem Aufruf bergibt die API der Methode die aktuellen Sensorwerte Um den neuen Sch tzwert zu erhalten wird der alte Sch tzwert f r k 0 ist es der Sensorwert mit einer Korrektur Kr multipliziert und mit der Differenz vom aktuellen Messwert und dem alten Sch tzwert addiert Man nehme an dass zum Zeitpunkt k ein Sensor eine Messung 21 liefert Wie schon erw hnt kann nun der ausgelesene Wert vom wahren Wert abweichen Es wird ein Bereich angegeben in der sich der Wert mit einer gewissen Wahrscheinlichkeit befindet Dies wird mittels einer Gau Glockenkurve dargestellt siehe Abbildung 4 7 Wie im Bild zu sehen erreicht die Kurve ihr Maximum an der Stelle des Messer
82. aubsaugerroboter auf seiner untersten Ebene sechs Leuchtdioden mit jeweils einem Durchmesser von 5mm Der Pin PB3 AIN1 DC0 des ATMega32 benutzt einen Vorwiderstand von 10002 zum N MOSFET Transistor BD139 Wenn das Licht der Bodenbeleuchtung f r die Kamera ben tigt wird wird der Transistor vom Mikrocontroller in Durchlassrichtung gesetzt und die sechs Leuchtdioden die durch Kabel mit der Hauptplatine verbunden ist erhalten die ben tigte Spannung Die LEDs haben jeweils zus tzlich einen Vorwiderstand von 1609 3 4 8 Motoren Der RAPTOR besitzt vier Getriebemotoren zwei f r die R der und zwei f r die vorde ren B rsten F r einen autonomen Staubsaugerroboter muss die Geschwindigkeit und die Fahrtrichtung steuerbar sein Hierf r muss die Drehrichtung und die Anzahl der Umdre hungen der Motoren variiert werden k nnen Die Realisierung geschieht ber den Baustein L293D Da die Motoren mehr Strom ben tigen als ein Mikrocontrollerausgang liefern kann muss die Ansteuerung ber einen Motortreiber erfolgen PG 524 Endbericht 63 HARDWARE Die Eing nge sind TTL Kompatibel Transistor Transistor Logik und der Baustein hat einen integrierten berspannungs und Temperaturschutz Der Spannungsbereich liegt zwi schen 4 5V und 36V und der Ausgangsstrom pro Ausgang betr gt 500mA Der L293D Baustein besitzt drei Eing nge und zwei Ausg nge womit zwei Motoren gesteuert wer den k nnen F r die Hauptplatine reichen somit zwei Motor
83. auf den Gumstix kopiert werden 1 SOURCES 2 OBJECTS SOURCES cpp o 3 BINARY 4 5 all clean S BINARY 6 7 S BINARY OBJECTS 8 gumstix buildroot build_arm_nofpu staging_dir 9 bin arm linux uclibcegnueabi g o S BINARY OBJECTS 10 11 S OBJECTS S SOURCES 12 gumstix buildroot build_arm_nofpu staging_dir 13 bin arm linux uclibcegnueabi g c SOURCES 14 15 clean 16 rm OBJECTS BINARY Listing 4 8 Makefile 4 1 7 Zus tzliche Hardware Es werden beim Raptor verschiedene Hardwarekomponenten wie zum Beispiel Ultraschall sensoren Kompass und Radencoder verwendet Diese werden mittels des ATMega Mikro controllers siehe Kapitel 3 2 eingebunden und angesteuert Doch andere Hardwarekom ponenten wie der WLAN Stick oder die WebCam ver f gen ber eine USB Schnittstelle so dass sie direkt am Gumstix angeschlossen werden k nnen Anhand des Beispiels einer WebCam wird gezeigt wie Hardware direkt am Gumstix eingebunden und angesprochen werden kann Als erstes werden die richtigen Linux Treiber f r die WebCam ben tigt Der Raptor hat eine Logitech Quickcam Express also wird der Treiber GSPCA SPCA5xx als Quellcode ben tigt Zuerst muss wie in Abschnitt 4 1 6 beschrieben der Treiber cross kompiliert werden Hierf r wird im gumstix buildroot Verzeichnis ein Ordner angelegt und der Treiber in den Ordner eingef gt F r die Videofunktionen ist wichtig dass
84. aussensors zur Verf gung aber aus den reinen Werten geht nicht die Position des Roboters hervor Diese und andere Berechnungen finden sich in der h heren Softwareebene Somit kann gesagt werden dass in der Richtung von der Hardware zur Soft ware nur die reinen Rohdaten aufbereitet aber nicht modifiziert werden In der anderen Richtung wurde dagegen Wert auf abstraktere Funktionen gelegt So wird zum Beispiel in den h heren Funktionen kein Wissen dar ber n tig sein wie die genaue Ansteuerung der Motoren realisiert wird Dies wird von der Implementierung der API umgesetzt Diese Kombination bringt zwei gro e Vorteile mit sich Es wird die Gefahr verringert dass auf der Sensorenseite Informationen verloren gehen oder verf lscht werden da die Auswertung von spezialisierten Algorithmen bernommen wird Die Aktoren dagegen be kommen f r ihre Arbeit alle Informationen die sie brauchen in einer m glichst kompri mierten Form Des Weiteren wird die Geschwindigkeit des Gesamtsystems erh ht da die Sensordaten sehr schnell zur Verf gung stehen und die Aktoren durch die hardwarenahe Implementierung der API effizient angesteuert werden k nnen Dies alles trug dazu bei ein H chstma an Effizienz bei der Nutzung der verwendeten Hardware zu erreichen 2 2 4 Bahnplanung Der autonome Roboter soll einen kompletten Raum m glichst effizient abzufahren Basie rend auf der von der Kartenerstellung bereitgestellten Karte berechnet ein Algorithmus
85. ber nicht verwunder lich schlie lich wurden sowohl Kamera als auch passende Treiber f r den Einsatz unter einem Windows System optimiert und nicht an die Grafikmodule von Linux angepasst Interessant ist zu erw hnen dass unter dem Gumstix Bilder von besserer Qualit t erzeugt werden als unter der Linuxumgebung des Hauptrechners Diese Kamera wird nach vorne ausgerichtet oben auf dem Roboter befestigt und visualisiert den vorderen Sichtbereich In regelm igen Abst nden wird durch die Software ein neues Bild aufgenommen wel ches einerseits extern ber das Webinterface gesehen werden kann und andererseits auf Zielobjekte und Hindernisse analysiert werden kann Philips SPC 900 NC Laut Herstellerangaben gelten als minimale Systemvoraussetzungen e Microsoft Windows 98SE 2000 Me or XP e Pentium III 500 MHZ oder schneller e 128 MB Arbeitspeicher e 200 MB freier Festplattenspeicher Diese Kamera wird senkrecht Richtung Boden im unteren Teil des Roboters befestigt Ihre Aufgabe ist die Erzeugung von Bildern f r die Schmutzerkennung Wichtig in diesem Zusammenhang ist der passende Abstand zwischen Kamera und Boden Einerseits darf der Abstand nicht zu gro sein da die erzeugten Bilder unsch rfer werden und die Schmut zerkennung beeintr chtigen k nnten andererseits darf der Abstand nicht zu klein sein 32 PG 524 Endbericht SOFTWARE PHILIPS a Abbildung 2 19 Philips SPC 900 NC 24 da bei kleiner erfasster Boden
86. bservers befinden Das Programm erzeugt zun chst die Ausgabe Content type text html gefolgt von einer Leerzeile Danach wird der eigentliche HTML Code ausgege ben welcher ber CGI an den Webbrowser bertragen und am Bildschirm angezeigt wird CGI legt nur die bergabe von Parametern fest und ist deshalb nicht an eine Program miersprache gebunden weshalb prinzipiell jede Programmiersprache die auf dem System ausf hrbar ist genutzt werden kann Erwartungsgem fiel die Entscheidung auf C als CGI Programm da bereits die gesamte Software des Roboters in dieser Sprache implemen tiert wurde C Das datenverarbeitende CGI Programm ist in C implementiert worden Mittels des Pro gramms Webinterface html werden zun chst alle Daten ausgelesen die angezeigt werden sollen Die Datei sensordaten txt wird vom Hauptprogramm regelm ig erzeugt und enth lt alle Sensorwerte zum Zeitpunkt der Erzeugung der Datei In einer weiteren Datei modus txt wird der aktuelle Betriebsmodus des Roboters abgespeichert Diese Datei wird vom Hauptprogramm ausgelesen damit eine Modus nderung seitens des Webinterface im Hauptprogramm respektive in der Robotersteuerung initiiert werden kann Es stehen sechs verschiedene Modi zur Auswahl Follow Mode Routenplanung Bahnplanung Kar tenerstellung Aufgabenplaner und Kein Modus Im Follow Modus kann der Roboter anhand der Frontkamera einem Gegenstand oder
87. ch ber den Spannungsregler Die eingesetzte Schottky Diode bernimmt den so entstandenen inver sen Stromfluss Des Weiteren ist die Schaltung f r den Gumstix nicht einsetzbar da keine Spannungsspitzen abgefangen werden Treten Spannungsspitzen auf so kann der Gumstix dadurch zerst rt werden 66 PG 524 Endbericht HAUPTPLATINE IC1 8LBSZ UDD 180nF 22pF GND Abbildung 3 14 Realisierung der Stromversorgung 3 4 10 Kontaktsensoren Wie in Abschnitt 2 1 3 schon erw hnt ist der vordere Bereich des Staubsaugerroboters mit f nf Kontaktsensoren sogenannte Bumper ausgestattet Falls der autonome Roboter auf ein Hindernis trifft wird dem Mikrocontroller dies mitgeteilt so dass dieser entsprechend reagieren kann Bei dieser Implementierung kann nicht erkannt werden welcher Bumper ausgel st wurde Im idealen Fall sollte der RAPTOR es nicht zu einer Kollision kommen lassen da die Ultraschallsensoren Hindernisse vorher erkennen sollten Die Bumper sind demzufolge eine Absicherung gegen eine Fehlfunktion der Ultraschallsensoren Die f nf Kontaktsensoren sind ber einen 40poligen Stecker der sich auf der Hauptplatine befindet mit GND verbunden Als Signalleitung wird der Pin PB2 AINO INT2 des ATMega32 verwendet Hier befindet sich auch die 5V Versorgungsspannung f r die Bumper mit einem Vorwiderstand der 1kQ betr gt Sollte ein Kontaktsensor ausgel st werden setzt sich GND gegen ber HIGH durch 3 4 11 Abg
88. ch f r die Achse des Motors der sp ter an den B rsten befestigt wird und drei L cher f r die Befestigung der Motoren an die Platte Da die genauen Positionen der drei L cher zur Motor Aluplattenbefestigung schwierig auszumessen sind wurde daf r eine Schablone er stellt F r das St tzrad wurde im hinteren Teil der Platte mit einem Spezialwerkzeug f r die Fr smaschine ein Kreis herausgeschnitten in das die Halterung des Kugelrades gesteckt wurde Zur besseren Befestigung wurde diese zus tzlich an der Aluplatte festgeklebt Das Ergebnis der bisherigen Schritte ist in Abbildung 3 16 zu sehen Nachdem diese L cher in die untere Platte gefr st wurden konnte mit der Befestigung der R der begonnen werden Befestigung der R der an den Motoren Um die R der an den Motoren und diese anschlie end an der Platte zu befestigen wurde ein zylinderf rmiger Metallblock mit einer Hands ge und danach zur Gl ttung mit der Drehmaschine auf die Radbreite gebracht Der Durchmesser hatte schon die richtige Gr e PG 524 Endbericht 71 HARDWARE Die klein geschnittenen Zylinderst cke passten damit genau in die Achse der R der Auf einer Seite der Zylinder wurde ein Loch f r die Motorachse gebohrt Senkrecht zu diesem Loch wurde noch ein kleineres Loch von 3mm Durchmesser gebohrt wodurch der Motor an den Zylinder geschraubt werden konnte siehe Abbildung 3 17 Auf der anderen Seite der Zylinder wurden zwei kleine L cher gebohrt Dam
89. chen Zeit ankommen erh hen die Unsicherheit und PG 524 Endbericht 93 SOFTWARE Sensor 1 gt Sensor 2 gt o o o Datenfusion gt optimale Sch tzung Sensor n gt Abbildung 4 4 Fusionsprozess der gesch tzte Parameter wird zu ungenau Ist aber die zeitliche Verz gerung zwischen den Sensoren sehr klein der Fehlerterm in der Datenfusion hat in dem Fall einen geringen Einfluss kann dies vernachl ssigt werden Ansonsten m ssen bzw k nnen die verz ger ten Daten extrapoliert werden was meist zu einer erh hten Unsicherheit in den Daten f hrt Beim Extrapolieren muss n mlich sichergestellt werden dass nur Daten miteinander fusioniert werden die zur gleichen Zeit erfasst wurden Das heisst f r jeden Sensorwert muss die zeitliche Verz gerung erfasst werden anschlie end erfolgt eine zeitliche Zuord nung sortiert nach der Verz gerungszeit in der Daten nacheinander extrapoliert werden damit keine Informationen verloren gehen Die Daten die zu einem sp teren Zeitpunkt ankommen werden in einem zweiten Fusionsprozess kombiniert damit wird eine optimale Sch tzung f r jede Zeit gew hrleistet Die Messungen die zum selben Zeitpunkt gemacht X2s it De Messung x2 Messung 1 Abbildung 4 5 Extrapolieren der verz gerten Daten wurden werden miteinander fusioniert Anschlie end werden die versp teten Daten mit dem fusionierten Wert weiter fusioniert Die Genauigkeit v
90. chsten kleinsten und universellsten Motoren z hlen Diese Motoren eignen sich besonders gut zur Konstruktion von flinken wie auch langsamen Robotern Es k nnen aber nur Robo ter bis zu 5kg Gewicht angetrieben werden Die Motorsteuerung f r den Getriebemotor ist relativ einfach Es gibt zwei Anschl sse welche mit jeweils unterschiedlicher Polarit t be legt werden um den Motor laufen zu lassen Je nach Richtung des Stromflusses dreht sich der Motor entweder vorw rts oder r ckw rts Die Getriebemotoren k nnen abh ngig von PG 524 Endbericht 27 GRUNDLAGEN ihrer Belastung und dem Untergrund Fliesen Teppich Laminat etc in ihrer tats chli chen Umlaufgeschwindigkeit voneinander abweichen Um sicherzustellen dass zwei ver schiedene Getriebemotoren gleich oft drehen m ssen externe Sensoren eingesetzt werden die die Radumdrehung st ndig berwachen und die Information an einen Mikrocontroller senden Trotz dieser Nachteile werden Getriebemotoren eingesetzt auch wenn die Fahrt gerader Strecken zu einer Herausforderung wird Um zu verstehen warum der Schrittmotor nicht in Frage kommt muss zun chst das Prinzip des Schrittmotors verstanden werden Die Schrittmotoren sind grundlegend anders konzipiert als die Getriebemotoren Der Rotor besteht meist aus einem Permanentmagneten der durch Anlegen einer Spannung an den Spulen bewegt wird Jeder Motor enth lt zwei Spulen welche wiederum jeweils zwei Anschl sse besitzen und be
91. cht DATENFUSION enth lt auch dieser einen Messfehler der mit w ausgedr ckt wird Um das ganze besser zu verstehen soll es an einem Beispiel noch einmal verdeutlicht werden Es soll die Position eines Roboters bestimmt werden Einfaches Beispiel der Roboter bewegt sich auf einer Linie und zwar in x Richtung die y Achse soll hier nicht n her betrachtet werden Da der Roboter im bewegten Zustand Messwerte sammelt muss die zur ckgelegte Strecke mit einbezogen werden Es gilt Ar At u w Die Variable w kompensiert die tats chli che Geschwindigkeit Kurz vor der zweiten Messung wird ein Sch tzwert der Position des Roboters ermittelt in der er sich zu diesem Zeitpunkt befinden m sste Zi Tp Luft ty w ik UE Uf 4 4 Var Vz Vw tor tk Vz Vw x taiff 4 5 Um die optimale Position zu sch tzen geht die zweite Messung 27 1 folgenderma en in die Formel ein Zu Er Kar 2041 k41 4 6 Kar Vr VI 1 Veal Dabei ist e It a posteriori Sch tzung e y a priori Sch tzung e Kr Gewichtung und e 2 11 Zu Abweichung Abbildung 4 9 der Einflu u 6 Kalman Filter f r den n dimensionalen Raum Die Gleichungen entsprechen dem eindimensionalen Raum Zur Erfassung des mehrdimen sionalen Raums werden die einfachen Koeffizienten durch Matrizen ersetzt und die Mess werte werden in einem n Dimensionalen Vektor abgebildet der gesch tzte Systemzustand lautet Ax
92. com ATMEL CORPORATION http www atmel com BROWN http ww cs brown edu stc education course95 96 Kalman Filters kalman html CAROLINA UNIVERSITY OF NORTH http www cs unc edul N sim welch media pdf kalman_intro pdf C T BOT http www heise de ct projekte ct bot DEVANTECH http www robot electronics co uk EAGLE http www cadsoft de FOLEY JAMES D amp DAM ANDRIES VAN Grundlagen der Computergrafik Addison Wesley GmbH GUMSTIX http www gumstix com HARTMANN http www hartmann codier de HISTOGRAMM WIKIPEDIA http de wikipedia org wiki Histogramm Histogramm_in_der_Bildverarbeitung I2C GUMSTIX WIKI http www davehylands com gumstix wiki i2c KAISER ULRICH amp KECHER CHRISTOPH C C Von den Grundlagen zur pro fessionellen Programmierung mit CD Galileo Press 175 Literaturverzeichnis 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 KUNG LONG http www klb com tw LOGITECH http www logitech com MARSHALL DAVID http www cs cf ac uk Dave Vision_lecture node35 html NEUBURGER EDGAR Einf hrung in die Theorie des linearen Optimalfilters Olden bourg Verlag 1972 ISBN 3 486 39361 8 NORMALVERTEILUNG WIKIPEDIA http de wikipedia org wiki Normalverteilung OPENSOURCE http www nongnu org avrdude PATENTE STUDIERENDE http www patente studierende de PHILIPS http
93. d OCIB x welche PWM Signal erzeugen motor_stopp Zu Beginn ohne Fahrt 162 PG 524 Endbericht 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 ol 52 93 54 99 56 57 58 59 60 61 62 63 64 65 66 MOTOR_BUERSTEN_PORT_DDR 1 lt lt MOTOR_BUERSTEN_PIN motor_buerste_stopp void motor_forward uint8_t speed_left uint8_t speed_right motor_l_fw motor_r_fw motor_setzepwm speed_left speed_right radencoder_enable void motor_backward uint8_t speed_left uint8_t speed_right motor_l_bw motor_r_bw motor_setzepwm speed_left speed_right radencoder_enable void motor_turn_left uint8_t speed_left uint8_t speed_right motor_l_bw motor_r_fw motor_setzepwm speed_left speed_right radencoder_enable void motor_turn_right uint8_t speed_left uint8_t speed_right motor_l_fw motor_r_bw motor_setzepwm speed_left speed_right radencoder_enable void motor_stopp radencoder_disable motor_1_stopp motor_r_stopp void motor_1 fw MOTOR_DIR_PORT_OUT 1 lt lt MOTOR_L_DIR N_FW lt lt MOTOR_L_DIR MOTOR_DIR_PORT_OUT amp 1 N_BW void motor_1 bw PG 524 Endbericht 163 MIKROCONTROLLERPROGRAMMIERUNG 67 68 69 70 71 12 73 74 75 76 77 78 79 SU 81 82 83
94. dbericht 1 Einleitung Die Projektgruppe 524 auch RAPTOR Room Adaptive Precisely Topologically Orienting Robot genannt entwickelt mit dem c t Bot als Grundlage einen Staubsaugerroboter ohne Saugmechanismus Motiviert von den Unzul nglichkeiten bestehender Roboter strebt die Projektgruppe einige Verbesserungen siehe Abschnitt 1 1 auf dieser Seite an Auf das Ziel und die Vorgehensweise wird in den Abschnitten 1 2 und 1 3 n her eingegangen 1 1 Motivation Schon immer war es ein Traum der Menschen k nstliche Wesen zu erzeugen Diese sollten ihnen m hsame beziehungsweise gef hrliche Arbeiten abnehmen oder zur Unterhaltung der Menschen dienen Inzwischen gibt es eine Vielzahl von Robotern f r die unterschied lichsten Einsatzbereiche Die bekanntesten Roboter sind die Industrieroboter Diese ber nehmen unterschiedliche Aufgaben wie beispielsweise schwei en und montieren in An wendungsbereichen wie zum Beispiel Schiffsbau und Elektrotechnik In der Forschung und Unterhaltungsindustrie werden humanoide Roboter entwickelt dessen Herausforderung vor allem darin liegt dem Roboter das Gehen auf zwei Beinen beizubringen Desweiteren gibt es unterschiedliche mobile Roboter die f r den Einsatz im Weltraum oder als berwachungs und Serviceroboter dienen In der Computer Fachzeitschrift ct erschien 2006 das Projekt c t Bot 8 In diesem Projekt wurde ein Roboter vorgestellt der sich einfach nachbauen l t Mit Hilfe des Simulators c
95. dem Start von RAPTOR und dem Booten des Betriebs systems ausgef hrt und regelt alle weiteren Aspekte der Verwaltung restlicher Teilsoftware f r den Betrieb des Roboters Die Aufgabe des Hauptprogramms besteht darin alle f r den Betrieb des Roboters notwendige Softwareteile zu initialisieren und auszuf hren Um die Sensordaten von der Umgebung des Roboters aktuell zu halten muss die Sensordaten fusion immer laufen damit die Sensoren in gen gend kurzen Abst nden abgefragt werden k nnen Zu diesem Zweck wurde die Datenfusion im Hauptprogramm in einen eigenen Thread ausgelagert welcher die notwendige Parallelisierung der Berechnungen gew hrleis tet Fin anderer Thread nimmt die Robotersteuerung mit den Funktionen zum Ausf hren der einzelnen Fahrmodi auf Somit besteht die Funktionalit t des Hauptprogramms darin alle Objekte der gebrauchten Klassen zu erstellen zu initialisieren und zu starten Des Weiteren wird im Hauptprogramm die Threadverwaltung durchgef hrt Im Folgenden werden der Aufbau und die Aufgabe der einzelnen Threads ausf hrlicher beschrieben 1 void starteDatenfusion void xarg Listing 4 35 Datenfusion Thread Dieser Thread beinhaltet eine endlose while Schleife in der alle 200 Millisekunden die start T hread Methode der Datenfusion ausgef hrt wird Diese Methode liest dann alle Sensordaten ber die API ab 1 void starteRobosteuerung void xarg Listing 4 36 Robotersteuerung Thread
96. des Mikrocontrollers f r Debug Ausgaben oder andere Anwendungen zu nutzen Ein zus tzlicher Vorteil ist dass beide Bausteine Anschl sse f r den Bus anbieten und das Protokoll direkt unterst tzen e In Bezug auf den Kompass bietet I C den Vorteil dass die Orientierung direkt aus gelesen werden kann und nicht erst aus einem PWM Signal ermittelt werden muss 41 HARDWARE Da der Kompass direkt an den C Bus angeschlossen wird m ssen daf r keine zus tzlichen Pins am Mikrocontroller oder am Gumstix belegt werden 3 1 2 Die Technik Der Bus verwendet zwei Leitungen Eine Leitung SCK Serial Clock wird f r die Taktung verwendet die andere Leitung SDA f r die eigentliche Daten bertragung Beide Leitun gen werden ber Pull Up Widerst nde auf einem hohen Spannungspegel gehalten In vielen Anwendungen sind dies 5V im RAPTOR erzwingen die Spezifikationen des Gumstix al lerdings einen Pegel von 3 3V Weder der Mikrocontroller noch das Kompassmodul hatten damit Probleme Diese beiden Leitungen sind parallel an die entsprechenden Anschl sse der Bus Ger te angeschlossen somit sind also alle SDA Pins aller Ger te miteinander verbunden wie Ab bildung 3 1 zeigt Nee Device 1 Device 2 Device 3 Device n R1 R2 SDA gt SCL a gt Abbildung 3 1 Anbindung von Ger ten am C Bus 26 Die Kommunikation zwischen den Ger ten geschieht nun dadurch dass Ger te diese Leitungen auf
97. die Thread Safe APT findet aber aus design technischen Gr nden auch hier statt Wie gezeigt wurde kann auf der Hardwareseite der API eine Vielzahl von Anbindun gen realisiert werden Aufgrund der Modularit t des API Konzeptes kann aber auch eine sehr gro e Zahl von Programmen auf die zur Verf gung gestellten Funktionalit ten zugrei fen Es wurde daher nicht nur die eigentliche Betriebssoftware des RAPTOR auf die API aufgesetzt sondern auch einfache Programme Als Beispiel kann hier die Fernbedienung angef hrt werden die zum Testen der Fahrfunktionen implementier wurde Sie erlaubt es mittels der Pfeiltasten einer Tastatur den Roboter zu steuern Auch mehrere Buchsta bentasten werden genutzt um spezielle Kommandos wie das Schalten von LED oder das Setzen der Geschwindigkeit zu realisieren Ein weiteres Beispiel ist das sogenannte Raptor demo Dieses dient dazu eine effektvolle Vorf hrung des Raptors zu erm glichen Es dient keinem sinnvollen Zweck au er das Publikum zu begeistern Es nutzt die Fahrfunktionen und die Ultraschallsensoren W hrend des laufenden Programms f hrt der RAPTOR solan ge geradeaus bis ein Hinderniss gefunden wird In diesem Fall wird eine Drehung gestartet bis die Geradeausfahrt wieder m glich ist Es wird also deutlich dass die API die Entwick lung verschiedenster Software auf vielf lltige Weise unterst tzt Es kann zusammenfassend festgestellt werden dass die Entscheidung der Definition einer API abso
98. die Daten selber als Parameter angegeben werden sondern die Speicherstelle an der sie zu finden sind Es bedarf also zus tzlicher Vorbereitungen um einen entsprechenden Datenstrom f r den Transfer vorzubereiten Die dritte und letzte zur Verf gung stehende Funktion ist read Auch hier ist intuitiv klar dass hiermit Daten vom Bus gelesen werden Auch hier muss wieder ein Speicherbereich angegeben werden welche aber dazu dient die vom Bus gelesenen Daten aufzunehmen Es muss hierbei sicher gestellt sein dass der Speicherbereich entsprechend vorbereitet ist um diese Daten aufzu nehmen Der Device Treiber des I C Bus sorgt sowohl bei write als auch bei read daf r dass die richtigen Anfragen an den Bus gestellt werden und die Kommunikation ungest rt ablaufen kann Aufgrund von Hardwaredefekten ist es n tig geworden den RAPTOR mit einer anderen als der geplanten Hardware zu betreiben Diese Tatsache hat zur Folge dass kein An 116 PG 524 Endbericht APPLICATION PROGRAMMING INTERFACE schluss f r den 12C Bus mehr zur Verf gung steht Es wurde hierf r eine L sung in Form eines Adapters entwickelt mit dem die Kommunikation zum C Bus ber eine serielle Schnittstelle realisiert wird siehe 3 5 Die bereits implementiere API musste daraufhin abge ndert werden um mit der neuen Situation zurecht zu kommen Wie bereits weiter oben festgestellt geschieht die Kommunikation mit dem I C Bus ber gerade einmal drei
99. die L f rmigen Metallst cke mit den Motoren und R dern an die Platte geschraubt Abbildung 3 19 Abbildung 3 19 Befestigung der R der an der unteren Platte Befestigung des Kugelrads an die untere Platte Damit der Roboter sp ter stabil auf dem Boden steht wurde im hinteren Abschnitt der Platte ein Kugelrad befestigt Bei der Bearbeitung der unteren Platte wurde schon das Loch ausgeschnitten in dem dieses Rad angebracht wird Nach einigen berlegungen wurde die Entscheidung getroffen die Halterung des Kugelrades an die Platte zu kleben Befestigung des Akkus Zur besseren Gewichtsverteilung wurde der Akku im hinteren Bereich der unteren Ebene angebracht Damit die zweite Ebene m glichst tief angebracht werden kann wurde der Akku auf der unteren Ebene liegend montiert Ein am Lehrstuhl vorhandenes rechteckiges Metallst ck wurde durch Fr sen in eine L Form gebracht hnlich wie bei der Motorbefestigung der R der Danach wurden St cke mit der Hands ge klein ges gt und L cher zur Befestigung in die Metallst cke und die Aluplatte gebohrt Abbildung 3 20 zeigt das Resultat Die Metallst cke wurden dann an der Platte befestigt und der Akku eingesetzt Durch die Platzierung der Metallst cke sitzt der Akku fest auf der unteren Ebene PG 524 Endbericht 73 HARDWARE Abbildung 3 20 Befestigung des Akkus an der unteren Platte Befestigung der B rsten an der unteren Platte Abbildung 3 21 B rsten An den
100. drivers media video Zum Schluss muss in der Datei etc modules der Name des neuen Moduls hinzugef gt werden erkennbar in Listing 4 14 Nach einem Neustart des Gumstix sollte die WebCam nun einsatzbereit sein 1 gspca ko gumstix buildroot build _arm _nofpu root lib modules 2 6 21gum kernel drivers media video videodev ko gumstix buildroot build _arm _nofpu linux 2 6 21gum drivers media video v411 compat ko gumstix buildroot build _arm _nofpu linux 2 6 21gum drivers media video v412 common ko zl On Ou wMNM Listing 4 13 Cross kompilierte Kernel Module 1 WebCam 2 gspca Listing 4 14 etc modules PG 524 Endbericht 87 SOFTWARE 4 1 8 DC auf dem Gumstix Der Gumstix verdex XL6P besitzt keinen separaten Anschluss f r den I C Bus Es exis tieren aber dennoch zwei M glichkeiten eine Anbindung an diesen zu erm glichen Zum einen ist auf dem Motherboard ein Anschluss f r ein 24 poliges Folienkabel vorhanden welches die I C Anschl sse liefert Zum anderen kann auf dem Carrier Board an vorge sehenen L tstellen ein Anschluss f r den C Bus angebracht werden Es kam die zweite Variante zum Einsatz zu sehen in Abbildung 4 1 Die Belegung der I C Anschl sse stehen in den Board Layouts des console vx 32 BC Anschluss Abbildung 4 1 Anschluss an das Carrier Board Das Kabel Abbildung 4 2 musste von der Raptor Gruppe selbst gebaut werden Es wurde so entworfen um eine falsc
101. duktion solcher Sensoren denn die Technologie mit der solche Sensoren entworfen werden unterliegen Grenzen Der Kalman Filter berechnet aus den Messwerten und deren zugeh rigen Varianzen einen Sch tzwert 1 mit einer minimalen Fehlervari anz dr Dieser hat eine kleinere Varianz als die einzelne Varianzen der Messungen bzw Sensoren 1 void kalmanfilter_init double pk_wert double pk_wert_2 2 double q_wert double rk_wert double rk_wert_z int dimension Listing 4 17 Kalman Filter initialisieren Mit dieser Methode wird der Kalman Filter initialisiert d h hier werden die Anfangswer te wie Varianzen der Sensorwerte eingetragen Der Algorithmus arbeitet in einer Schleife Bevor die Schleife betreten wird werden die vom Kalman Filter ben tigten Initialisie rungswerte gesetzt Der Kalman Filter arbeitet in zwei Hauptschritten die in einer Schleife ausgef hrt werden Im ersten Schritt wird abh ngig vom letzten Zustand Zr und 67 der neue Zustand 1 und neue Fehlerkovarianz Ai 1 vorhergesagt Der zweite Hauptschritt sorgt daf r dass mittels der vorhergesagten Werte der neue aktuelle Zustand mit der dazu geh rigen Fehlerkovarianz gesch tzt wird Dabei geht ein Gewichtsfaktor in die Rechnung 96 PG 524 Endbericht DATENFUSION ein Dieser Wert dr ckt aus wie stark die Differenz aktueller Messwert und gesch tzter Wert f r den Zeitpunkt in den gesch tzten Zustand eingehen Das System wird durch eine lineare stoch
102. e Pin der Diode wird an den BC557 Transistor angeschlos sen Die Schaltung des Transistors wird ber den LED CNTL Pin gesteuert Schaltet der Transistor so liegt am zweiten Pin der Diode Ground an Des Weiteren wird die Ground Leitung ber einen 14 F Kondensator an den REFA Pin angeschlossen und direkt an den GND Pin des Sensorchips Ein weiterer 100nF Kondensator befindet sich zwischen den Ground und 5V Leitungen Die SDIO und SCK Leitungen werden direkt vom Stecker an die entsprechenden Pins des Chips gef hrt Abbildung 3 15 Der optische Maussensor 8 3 5 RS232 12C Adapter Der gr te Teil der Hardware wird per I C angesprochen da dieser Bus nicht zur Grund ausstattung der meisten Rechner geh rt war zu Beginn eine Ansteuerung der Hardware ohne Gumstix nicht m glich Stellenweise insbesondere bei Fehlersuche und Tests war jedoch auch eine Ansteuerung ber normale PC Hardware erw nscht und n tig Um auch mit regul rer PC Hardware auf den RAPTOR zuzugreifen wurde ein RS232 I C Adapter konzipiert und hergestellt Als gegen Ende der Projektgruppe das Gumstix 68 PG 524 Endbericht RS232 I2C ADAPTER Board nicht mehr zur Verf gung stand und ein PC Laptop verwendet werden musste wurde dieser Adapter notwendig um mit der Hardware kommunizieren zu k nnen 3 5 1 Beschaltung Die Schaltung Abbildung A 7 enth lt im Wesentlichen nur die Komponenten die f r den reinen Betrieb des ATMega32 die serielle Ko
103. e bessere Alternative gefunden werden muss Aufrgund der festen Position des Maussensors und der Abgrundsensoren 3mm ber dem Boden ist die Gefahr sehr gro dass diese bei der Fahrt durch Gegenst nde besch digt werden k nnen Ungewollt besteht die Gefahr das die Sensoren bei zu hohem Teppich ber den Boden schleifen Diese Sensoren waren zwar g nstig jedoch sind sie im praktischen Ge brauch eines Staubsaugerroboters ungeeignet Beispielsweise k nnte der Maussensor durch eine bessere Linse mit mehr als 3 mm Abstand zum Boden laufen Des Weiteren k nnte dar ber nachgedacht werden ein weiteres St tzrad am vorderen Teil des Roboters zu montieren Ohne Akku verlagert sich der Schwerpunkt nach vorne Ein St tzrad k nnte hier helfen dass dabei keine Sensoren besch digt werden Zugleich w rde es das Problem l sen dass sich der RAPTOR bei einem starken Stopp nach vorne verneigt Die Praxis lehrte die Projektgruppe das die verwendeten Reifen f r viele Untergr nde zu d nn sind Auch hier ist der RAPTOR zu sehr vom Boden abh ngig Wie der Schaltplan der Hauptplatine A 6 zeigt ist eine Schnittstelle f r ein LCD Li quid Crystal Display freigehalten worden Ein LCD am RAPTOR zu montieren w rde den Staubsaugerroboter qualitativ aufwerten Der Benutzer k nnte direkt am Roboter Stati ablesen und m sste nicht das Webinterface dazu benutzen Zus tzliche Kn pfe als Bedienelemente w rden es dem Benutzer weiter vereinfachen mit
104. ebinterface zu realisieren wurden folgende Software Technologien verwendet e HTML zur Darstellung des Webinterfaces in einem Webbrowser e Cascading Style Sheets CSS zur Formatierung und Design der HTML Seite JavaScript um kontextbezogenen Inhalt darzustellen und Bildkoordinaten anzuzeigen e Common Gateway Interface CGI zur client und serverseitigen Kommunikation C als Programmiersprache des CGI Programms Hypertext Markup Language Die Benutzerschnittstelle des Roboters sollte m glichst einfach gestaltet werden und je dermann zug nglich sein Die Entscheidung fiel auf HTML da Inhalte so strukturiert und mit jedem beliebigen Webbrowser dargestellt werden k nnen Dazu muss eine WLAN Verbindung mit dem Roboter hergestellt werden Das Webinterface ist dann lokal unter http raptor cgi bin Webinterface html zu erreichen Common Gateway Interface Die Benutzerschnittstelle sollte nicht nur f hig sein Daten anzuzeigen sondern auch dem RAPTOR bestimmte Eingaben zu liefern wie zum Beispiel das ndern des Modus oder die Eingabe von Zielkoordinaten f r die Routenplanung Die client und serverseitige Kommu nikation wurde hierbei mittels CGI umgesetzt Mithilfe von CGI ist es m glich Program me bereit zu stellen die von HTML Dateien aus aufgerufen werden und selber dynamisch 118 PG 524 Endbericht WEBINTERFACE HTML Code erzeugen Um das Programm auszuf hren muss es sich im Verzeichnis cgi bin des We
105. egister zaehler TW zaehler TWCR 1 lt lt TWEN 1 lt lt uint8_t registerAuswahl ui datenregister 0 registerAu twi_senden adresse 1 twi_lesen adresse byteCount int main void uart_init 1 lt lt 0 1 lt lt 1 twi_sender_init uint8_t datenPaket uint8_t modus uint8_t adresse uint8_t byteCount uint8_t zaehler for zaehler 0 zaehler lt MAXD datenregister zaehler za DR IWINT 1 lt lt TWSTO void twi_registerLesen uint3_t adresse nt8_t byteCount swahl ATAREGS Zaehler ehler PG 524 Endbericht 167 MIKROCONTROLLERPROGRAMMIERUNG 87 88 READY_LED_PORT_DDR 1 lt lt READY_LED_PIN 89 while 1 90 zaehler 0 91 READY_LED_PORT_OUT amp 1 lt lt READY_LED_PIN 92 datenPaket uart_wait_and_getc 93 READY_LED_PORT_OUT 1 lt lt READY_LED_PIN 94 uart_putc datenPaket Echo 95 modus datenPaket 1 lt lt 7 1 lt lt 7 96 adresse datenPaket 3 lt lt 5 1 lt lt 5 96 97 byteCount datenPaket 31 lt lt 0 98 if modus 1 Lesen vom Slave 99 if adresse lt 99 twi_lesen adresse byteCount 100 for zaehler 0 zaehler lt byteCount zaehler 101 uart_putc datenregister zaehler 102 103 104 if modus 0 schreiben auf Slave 105 for zaehler 0 zaehle
106. ehlerfall erscheint bedingt durch die Tatsache dass bewegliche Hindernisse erst im Laufe einer Fahrt des Roboters erscheinen Damit die se Hindernisse rechtzeitg erkannt werden finden in regelm igen Abst nden Anfragen an die vorderen Ultraschallsensoren statt Sollte trotzdem eine Kollision mit einem Hindernis stattfinden wird der Roboter beauftragt zur ckzuweichen die Bumper zur ckzusetzen und die vorhandene Karte zu aktualisieren Abschlie end wird eine neue Fahrt berechnet Zwei weitere wichtige Funktionen sind 1 int robosteuerung getWegpunktpositionX stack lt Feld gt 2 route 3 int robosteuerung getWegpunktpositionY stack lt Feld gt 4 route Listing 4 29 R ckgabe der aktuellen Koordinaten Sie liefern die aktuelle X und Y Koordinate des Roboters wobei die Funktionen selber wie derum auf die Werte aus der Odometrie zugreifen und sie mit einer umgebungsabh ngigen Abweichung versehen Aus diesen Informationen kann die aktuelle Zielrichtung zur n chs ten Position bestimmt werden realisiert durch die folgende Funktion 1 int robosteuerung berechneWegpunktrichtung Listing 4 30 R ckgabe der Zielrichtung zur n chsten Position Im Gegensatz zu den anderen Modi setzt die Realisierung des Follow Modus keinerlei Berechnungen mit Datenstrukturen wie Stacks voraus stattdessen richtet die Roboter steuerung die Fahrbefehle des Follow Modus danach welcher aktuelle Winkel und Abstand zum Zielobjekt
107. ei ne optimale Route Der erfasste Raum wird in der internen Repr sentation des RAPTOR in mehrere Felder unterteilt welche vom Bahnplanungsalgorithmus abgearbeitet werden Hierbei erfasst ein modifizierter Floodfill Algorithmus alle Felder des Raumes und legt sie auf einem Stack ab welcher dann abgearbeitet wird Der Algorithmus versucht m glichst lange gerade Strecken zu suchen und sie bis zur Wand abzufahren Anschlie end wird ein m glichst langer paralleler Kurs in entgegengesetzter Richtung gesucht Sobald ein Feld komplett abgearbeitet ist und der RAPTOR in kein benachbartes Feld fahren muss wird die Routenplanung benutzt um den k rzesten Weg zu einem weiter entfernten Feld zu berechnen PG 524 Endbericht 35 GRUNDLAGEN 2 2 5 Routenplanung Die Routenplanung berechnet gegen Angabe eines Start und Endpunktes eine effiziente Route Die Bahn und Routenplanung unterscheiden sich in der Hinsicht dass die Bahn planung eine komplette Route berechnet in der die ganze Fl che des Raumes abgefahren wird und bei der Routenplanung lediglich der k rzeste Weg zwischen zwei Punkten gesucht wird 2 2 6 Hauptprogramm Das Hauptprogramm vereinigt alle Softwarekomponenten des Roboters Damit alle Kom ponenten m glichst parallel arbeiten k nnen wurden die Prozesse in Threads ausgelagert Somit kann gleichzeitig die Schmutzerkennung arbeiten w hrend die Robotersteuerung den RAPTOR durch den Raum navigiert Einzelne Funktionen m
108. eil in manchen Anwen dungen das Bereitstellen zus tzlicher Bytes f r den Sender mit Zusatzaufwand verbunden ist Durch das Senden des NACK wei der Sender somit dass er diesen Zusatzaufwand nicht betreiben muss da diese zus tzlichen Bytes nicht abgefragt werden 44 PG 524 Endbericht INTER INTEGRATED CIRCUIT Daten vom Sender Daten vom Empf nger SCK 1 2 8 9 er u ee Start Best tigung bedingung Acknowledgment Abbildung 3 4 Der Empf nger quittiert den Empfang eines Paketes indem er die SDA Ader beim 9 Bit auf Null zieht 26 3 1 5 Adressierung Das erste Byte nach der Startbedingung ist die Adressierung des Slaves Der Master w hlt aus mit welchem Slave er kommunizieren m chte zudem wird an dieser Stelle auch schon der Modus lesend schreibend definiert I C Ger te die als Slaves fungieren k nnen haben eine Adresse auf die sie reagieren Diese l sst sich je nach Ger t frei vergeben wie im Mikrocontroller m glich teilweise frei vergeben manche ICs der gleichen Baugruppe sind immer im gleichen Adressraum nur die letzten Bits k nnen manipuliert werden oder kann auch fest in der Hardware vorgegeben sein wie im Kompassmodul Nach der urspr nglichen Definition des Bus hat eine Adresse exakt sieben Bit Einige Bitkombinationen sind jedoch f r andere Zwecke reserviert so dass nach dieser Reservierung nur 114 Ger te angesteuert werden k nnten In manchen An
109. einem Menschen folgen Dieser Modus wird in Kapitel 4 9 1 n her beschrieben Wird der Modus Routenplanung angesto en kann der Benutzer dem Roboter konkrete Zielkoordinaten bergeben die der Roboter daraufhin ansteuert Hierf r besteht die M glichkeit mit dem Mauszeiger die im Webinterface an gezeigte Karte des Raumes an zu klicken Sobald der Button Ziel setzen bet tigt wird werden die Koordinaten die in das untere Textfeld bernommen wurden in der Modus Datei abgespeichert so dass sie von dem Hauptprogramm ausgelesen werden k nnen Dar aufhin wird der Modus ge ndert die Route von der aktuellen Position bis zur Zielposition wird berechnet und anschlie end vom Roboter abgefahren Wird der Modus Bahnplanung eingestellt f hrt der Roboter den kompletten Raum in gleichm igen Bahnen ab Eine n here Beschreibung hierzu befindet sich in Kapitel 4 9 2 Au erdem kann der Modus Kar tenerstellung aktiviert werden Dies hat zur Folge dass der Roboter sich an einer Wand orientierend den kompletten Raum abf hrt und dabei eine interne Karte des Raumes er stellt welche sobald verf gbar im Webinterface angezeigt wird In Kapitel 4 5 wird dieser Modus beschrieben Als weitere Option steht der Aufgabenplaner zur Verf gung Mit dem Aufgabenplaner wurde eine Funktionalit t implementiert mit der der Benutzer einmali ge t gliche oder periodische Termine einstellen kann an denen der Roboter automatisch eine Bahnplanung durchf hren wi
110. eitere berlegung ist dass zur Sch tzung der Position die Regressionsanalyse eingesetzt wird Diese kann so verwendet werden dass von f nf oder mehr Messpunk ten in dem Fall die Koordinaten des Maussensors eine Funktion bestimmt wird welche die Werte so genau wie m glich abbildet Hiermit w re es m glich eine Prognose f r den n chsten Zeitschritt zu stellen Dieser vorhergesagte Wert k nnte anschlie end mit dem Kalman Filter kombiniert werden um die Positionssch tzung zu verbessern Die Gitterkarte ben tigt eine effizientere Datenhaltung Es werden noch Vektoren ver wendet bei einer Neuimplementierung k nnten diese komplett weggelassen werden Mit einer Baumstruktur k nnten die Daten komprimiert und komplett im Speicher gehalten werden so dass der bisherige Overhead der eigens entwickelten Klasse entfallen w rde Die Kartenerstellung k nnte erweitert werden indem implementiert wird dass R ume wiedererkannt werden Das bedeutet dass der aktuelle Raum w hrend der Kartenerstellung mit gespeicherten R umen abgeglichen wird um diese Karten dann zu laden und die Kartenerkennung vorzeitig zu stoppen Auch kann mit etwas Aufwand die Pr zision der Karte erh ht werden Dies verlangt zugleich eine genauere Sensordatenfusion Des Weiteren k nnte anhand der internen Karte eine Positionsbestimmung erfolgen Diese Daten finden zur Zeit keine Beachtung bei der Positionsermittlung Anhand der erkannten Abst nde zu Objekten bzw W nde
111. el die Tatsache dass der verwendete Simulator ber eine Netzwerkverbindung angesprochen wird wogegen die Roboterhardware ber ein Bussys tem angebunden ist Auch die Anbindung mehrerer Bibliotheken die f r den Simulator PG 524 Endbericht 115 SOFTWARE von essentieller Bedeutung sind musste geregelt werden Auch hier wurde wieder auf ei ne L sung zur ckgegriffen die automatisiert die entsprechenden Anpassungen w hrend des Kompiliervorgangs vornimmt Die entsprechenden Pre Compiler Befehle abstrahieren die einzelnen Hardwareanbindungen so stark dass ein Austausch durch die Angabe ei nes Kompilierparameters m glich wurde Um den bersetzungsvorgang zu starten wird zuerst angegeben ob reale Hardware oder ein Simulator genutzt wird Im Falle des Si mulators erfordert dies noch die Angabe des Netzwerkports welcher f r die Anbindung benutzt wird Alle anderen n tigen Einstellungen werden automatisiert vorgenommen und ben tigen keinerlei menschliches Zutun mehr Da aber auch auf realer Hardware gearbeitet werden soll muss die API eine Anbin dung an die reale Hardware besitzen Auch diese wird wieder ber eine Kompilierpara meter ausgew hlt Die Anbindung erfolgt ber einen 2C Bus siehe Abschnitt 3 1 ber diesen kommuniziert die API mit dem entsprechenden Mikrocontroller um diesem den entsprechenden Befehl zu bermitteln Hierbei werden f r die einzelnen Funktionalit ten keine Funktionsaufrufe verwendet sondern es
112. elen 2 1 9 Kamera Kameras werden beim Roboter zu zwei Hauptzwecken eingesetzt e Durch eine Analyse der Bodenstruktur soll erkannt werden ob die aktuelle Boden fl che unter dem Roboter verschmutzt ist und eine Reinung ben tigt e Fine Analyse von aufgenommenen Bildern aus der unmittelbaren Raumumgebung soll in Verbindung mit anderen Sensordaten dem Roboter in der Objekt bzw Hin derniserkennung helfen e Ein spezieller Modus des Roboters erlaubt es Lebewesen Mensch oder Tier in einem Raum zu verfolgen Hierbei wird eine Webcam als Visier benutzt um das Zielobjekt zu erfassen Moderne Webcams wie sie heutzutage f r Videokonferenzen eingesetzt werden zeich nen sich durch eine kompakte Gr e und akzeptabler Bildaufl sung aus Mittlerweile erzie len auch Standardmodelle unter Echtzeitbedingungen ausgezeichnete Ergebnisse bedingt durch immer leistungsf higere Hardware von Desktop PCs heutzutage F r den Staubsau gerroboter m ssen nicht dauerhaft fl ssige Videobilder erzeugt werden stattdessen gen gt es in regelm igen Abst nden Bilder der Umgebung Bodenfl che aufzunehmen und diese zu analysieren 30 PG 524 Endbericht HARDWARE Bei der Benutzung von Webcams f r Linuxsysteme besteht das generelle Problem dass mitgelieferte Treiber bzw Software f r die Kameras grunds tzlich nur f r Windows Systeme konzipiert wurden und der Einsatz der Ger te unter Linux nicht ohne Weiteres m glich ist Abhilfe sch
113. em Lichtsensor dem CNY70 der so am Roboter angebracht ist dass er auf die Streifen der Encoderscheiben zeigt Der Lichtsensor erzeugt analoge Si gnale Sie werden f r die weitere Verarbeitung durch den Mikrocontroller mit Hilfe eines 22 PG 524 Endbericht HARDWARE Schmitt Triggers in digitale Signale umgesetzt Ein Schmitt Trigger erzeugt aus einem ana logen Eingangssignal eindeutige digitale Schaltzust nde Aufgrund dessen reicht es wenn der Mikrocontroller nur noch die Flankenwechsel von High nach Low z hlt Abgrundsensor Abgr nde wie beispielsweise Treppen und Tischkanten erkennt der RAPTOR mit Hilfe von drei CNY70 die als Abgrunddetektoren fungieren Sie befinden sich an der unteren Front des Staubsaugers Wie bei dem Maussensor darf der Abstand zwischen Lichtsensor und Boden nicht mehr als 3mm betragen Problematisch k nnen beispielsweise Linien am Boden sein die der Abgrundsensor f lschlicherweise als Abgrund erkennt 2 1 5 Maussensor Da die Radencoder und die Ansteuerung der Motoren keine hinreichende Sicherheit bei der Erkennung der L nge abgefahrener Strecken gew hrleisten k nnen hat die Projektgruppe sich f r einen Maussensor als zus tzliche Navigationshilfe entschieden Optische Maussen soren sind heutzutage feste Bestandteile moderner M use Im Gegensatz zu M usen mit Rollkugel in der die Bewegung des Benutzers mechanisch erfasst wird erfolgt hier eine optische Erfassung der Bewegung Prinzipiel
114. en Follow Modus der Ausrichtungswinkel des Roboters zum zu verfolgenden Zielobjekt Die Erstellung einer aktuellen Karte des Raumes wiederum ben tigt eine Ak tivierung der Odometrie Die zweite wichtige Hauptfunktion der Robotersteuerung ist 1 void robosteuerung fahreStackAb 2 optional void robosteuerung fahreStackAbBlind Listing 4 28 Funktion zur Abarbeitung von Stacks Diese Funktion wird f r die Bahnplanung und die Routenplanung ben tigt da diese ihre Funktionalit t dadurch realisieren dass Stacks von Feldern in einer effizienten Reihenfol 122 PG 524 Endbericht ROBOTERSTEUERUNG ge aufgebaut und abgefahren werden Zus tzlich enth lt sie Funktionen f r eine primitive Fehlererkennung und Korrektur Fehlerszenarien kommen zum Vorschein wenn der Robo ter sich an einer falschen Position befindet oder ein vorher nicht einkalkuliertes Hindernis zum Vorschein kommt Der erste Fall zeigt auf dass der Roboter physikalisch nicht genau genug f hrt und minimal von der Strecke abweicht somit korrespondieren die reale Posi tion und die ideale Position des Roboters nicht miteinander Ein solches Verhalten kann nicht vollst ndig vermieden werden da ein exaktes Fahren unter realen Bedingungen sehr schwierig zu bewerkstelligen ist Eine Ausweichl sung wurde realisiert indem die fehler hafte Abweichung in der zur cklegten Strecke durch eine zus tzliche Fahrt zur korrekten Position kompensiert wird Der zweite F
115. en bisherigen Ressourcen kaum zu bew ltigen 4 9 2 Bahnplanung Die Bahnplanung ist einer der internen Modi in der Robotersteuerung und hat die Aufgabe in einem bereits erkundeten Raum eine m glichst effiziente Route f r die Komplettabfahrt des Raumes zu erstellen und diese dann entsprechend abzufahren Diese Route soll alle f r den Roboter erreichbaren Stellen erfassen damit die gr ndliche Reinigung des Raum es gew hrleistet ist Somit stellt die Bahnplanung den Saugmodus dar der nach dem Einschalten des Roboters und Erkundung des Raumes im Normalbetrieb aufgerufen wird Die Bahnplanung arbeitet auf der internen Karte des Raumes die in GridMap Format zuvor von der Odometrie erstellt und abgespeichert wurde Das schr nkt das Einsatzge biet vom Saugmodus auf bereits erfasste R ume ein f r einen neuen Raum muss somit die Kartenerstellung zuerst ausgef hrt werden bevor die Bahnplanung starten kann Die abzu fahrende Route wird als eine Liste von benachbarten Feldern zur ckgegeben die auf einem Stack gespeichert sind Somit hat die Route f r die Komplettabfahrt nach der Erstellung das gleiche Format wie alle anderen Routen in der Robotersteuerung und kann mit der fahreStackAb Methode abgefahren werden In Folgenden wird also nur die Berechnung PG 524 Endbericht 125 SOFTWARE der Route beschrieben da diese sich von allen anderen Modi unterscheidet F r die Berechnung der Route f r die Bahnplanung wird eine
116. ene Messwerte als Sensor wert in die Datenzuordnung eingehen Mit der Sensordatenfusion soll das Fehlerrauschen im Nutzsignal durch kombinieren von Sensordaten reduziert werden Bei der Kombinati on zweier Sensoren treten synergetische Effekte auf Bei der Datenfusion geht es darum aus verschiedenen Datens tzen oder gleichartigen Datens tzen eine optimale Sch tzung zu bestimmen die besser als die einzelnen Daten sind Die Datenfusion soll also einen neuen Datensatz produzieren der inhaltlich mehr Informationen enth lt als die einzelnen Da ten f r sich liefern Die Tatsache dass im RAPTOR mehrere Sensoren eingesetzt werden bietet die M glichkeit die Informationen der Sensoren miteinander zu kombinieren und so eine h here Genauigkeit zu erzielen Wie Abbildung 4 4 zeigt flie en die Sensordaten in den Fusionsblock hinein dort werden sie verarbeitet um so eine optimale Information zu liefern Durch das Einsetzen redundanter Sensoren wird au erdem die Ausfallsicherheit erh ht Beispielsweise bleibt im Falle eines Ausfalls eines Ultraschallsensors der RAPTOR noch funktionsf hig jedoch vergr ert sich der tote Winkel Eine gute Fusionsmethode bietet der diskrete Kalman Filter der hier zum Einsatz kommt 20 Dieser Filter kommt h ufig bei mobilen Robotern zum Einsatz Allerdings besteht hier das Problem dass der Kalman Filter davon ausgeht dass alle Daten Nutzsignale zur gleichen Zeit erfasst wer den d h Daten die zur unterschiedli
117. enutzt so sollten Pin 2 und 3 ber einen Widerstand ca 10k bis 47k mit 5V verbunden sein damit St rungen vermieden werden Die Kommunikation ber den I C Bus erfolgt wie bei fast allen Modulen ber verschie dene Register Es stehen folgende Register zur Verf gung Register Funktion 0 Software Version Firmware Version 1 Kompasswert Ein Byte 0 bis 255 entspricht 0 bis 359 9 Grad 2 3 Kompasswert als Word also 2 Byte Low and High Der Wert von 0 bis 3599 entspricht 0 bis 359 9 Grad 4 5 Interne Testregister werden nur vom Hersteller genutzt 6 7 Interne Testregister werden nur vom Hersteller genutzt 8 9 Interne Testregister werden nur vom Hersteller genutzt 10 11 Interne Testregister werden nur vom Hersteller genutzt 12 Unbenutzt liefert immer 0 zur ck 13 Unbenutzt liefert immer 0 zur ck 14 Unbenutzt liefert undefinierten Wert zur ck 15 255 startet die Kalibrierung Justierung der Richtungen 0 Beendet Kalibierung Werte werden im EEPROM gespeichert Tabelle 2 1 Registerbelegung des Kompassmoduls Die Slave Adresse ist fest auf Hex CO also Dezimal 192 eingestellt Wie bei TC blich wird immer erst die SLAVE Adresse und dann das abzurufende Register als Byte versendet Anschlie end erfolgt ein Lesezugriff in dem die SLAVE Adresse 1 gesendet und danach 1 oder 2 Bytes abgerufen werden CMPS03 unterst tzt die Standard TC Taktraten von 100 und 400 KHz
118. er tes gelegt Um m gliche Fehlerursachen zu vermeiden muss darauf geach tet werden dass das Layout bei diesem Vorgang nicht verrutscht und die Glasplatte sauber ist Die Vakuumpumpe des Belichtungsger tes sorgt daf r dass das Layout nicht verrut schen kann Der Deckel des Belichtungsger tes kann anschliessend geschlossen werden um die Platine eine angemessene Zeit zu belichten In Abh ngigkeit von dem verwendetem Belichtungsger t sowie der verwendeten Epoxid Platine ergibt sich eine optimale Belich tungsdauer von 2 Minuten und 30 Sekunden 3 3 3 Entwicklung Nach der Belichtung kann die Platine entwickelt werden um die belichteten Lackteile abzul sen Dazu wird eine Natriumhydroxid L sung mit einem Mischungsverh ltnis von 1 100 verwendet Die Platine kann nach etwa einer halben Minute aus der L sung genom men und anschliessend mit Wasser abgesp lt werden Das komplette Layout der Platine sollte sichtbar sein Es d rfen keine Lackreste mehr vorhanden sein ansonsten muss der Vorgang wiederholt werden Ferner sollten die Platinen an den Kupferstellen gl nzen an denen der Fotopositivlack abgel st wurde Diese Stellen werden beim Eintauchen in das tzbad sofort matt was den beginnenden tzprozess zeigt Ist dies nicht der Fall muss die Entwicklung wiederholt werden Die fertig entwickelte Platine sollte dann auf unterbroche ne Verbindungen kontrolliert werden diese k nnen zum Beispiel mit einem wasserfesten Stift repariert w
119. er mit einem realen Roboter zu verbinden Zudem ist es m glich Player ber eine Konfigurationsdatei zu konfigurieren Die Simulationsumgebungen lassen sich ebenfalls konfigurieren Stage wird benutzt um die Steuerungssoftware f r den RAPTOR zu testen Die Simulationsumgebung Player Stage war in der Softwareentwicklung eine grosse Hilfe vor allem in den Zeiten in denen die Roboterhardware nicht funktionierte und ein fahrender Roboter zum Testen der geschriebenen Software nicht vorhanden war Zu Beginn wurde Player Stage wenig genutzt da der Roboter bis dato keinen oder nur wenige Ausf lle hatte Nach dem ersten l ngeren Ausfall des Roboters stiegen dann alle Softwareteams gezwungenerma en auf die Simulationsumgebung um und lernten dann erst die Vorteile eines Simulators kennen Der Umstieg von der Simulation auf den Roboter war mit wenigen Handgriffen im Code durchf hrbar das Verhalten war dann aber nicht immer genauso wie es im Simulator war Das lag unter Anderem daran dass die Sensorwerte die aus der Simulationsumgebung gewonnen wurden immer exakt waren in der realen Welt die Sensormesswerte aber ein Rauschen beinhalten Dadurch dass in der Simulation etwas funktionierte was in der realen Welt nicht genauso funktionierte konnte der Programmierer den eigenen Algorithmus als Fehlerquelle ausschliessen und sich somit die gewonnenen Sensordaten aus dem Roboter einmal genauer ansehen und dort zur Korrektur ansetzen Neben der problemlosen Umsch
120. er sechspoligen Buchsenleiste Diese findet sich auch am AVRISP mkII e In vielen Pl nen im Netz wird von einer zehnpoligen Buchsenleiste ausgegangen F r diese l sst sich einfacher Anschlusshardware finden Daher hat sich dieser Anschluss als ein Standard der Hobbybastler etabliert 48 PG 524 Endbericht ATMEGA32 e In manchen Anwendungen wird ein neunpoliger D Sub Stecker D shaped subminia ture verwendet oftmals dient er zur bergabe auf eine zehnpolige Buchsenleiste e Da die f r die Programmierung zust ndigen Pins an einem ATMega32 sowohl in SMD als auch in LDIP Bauform direkt nebeneinander liegen kann es zur Vereinfa chung bei der Platinenerstellung sinnvoll sein einen einreihig sechspoligen Verbinder Abbildung 3 6 AVRISP mkII unser Programmierger t zu verwenden Im Wesentlichen sind dort aber immer die gleichen Signale enthalten Tabelle 3 1 listet die verschiedenen Pinbelegungen sowie den Anschluss am ATMega32 auf Die Details werden sp ter noch erl utert Belegung ATMega32 6 pol Wanne 10 pol Wanne 9 pol DSub 6 pol einreihig MISO 7 1 9 5 2 VCC z B 10 2 2 6 5 SCK 8 3 7 4 3 MOSI 6 4 1 1 1 Reset 9 5 5 3 4 GND z B 11 6 4 6 8 10 7 8 9 6 LED n a n a 3 2 n a Um die verschiedenen Adern eines Kabels an einer Buchsenleiste zu identifizieren muss der Stecker so gehalten werden dass die markierte Ader nach links zeigt Pin 1 befindet s
121. erden 3 3 4 tzen Nach dem Entwickeln der Platine folgt das Weg tzen der freigelegten Kupferschicht Als tzmittel wurde Natriumpersulfat eingesetzt Das tzmittel muss vor Beginn mit Hilfe eines Heizstabes auf eine Temperatur von mindestens 40 Grad Celsius und h chstens 60 Grad Celsius gebracht werden Zus tzlich wird in den tzbeh lter von unten Luft geblasen um den tzvorgang zu beschleunigen Nach einer ungef hren Dauer von 5 10 Minuten ist die Platine fertig ge tzt und kann mit Wasser abgesp lt werden 3 3 5 S ubern und Versiegeln Nach dem tzen sind auf der Platine noch R ckst nde von Fotopositivlack vorhanden Dieser kann mit Spiritus entfernt werden Die ges uberte Platine wird abschliessend mit PG 524 Endbericht 57 HARDWARE L tlack bespr ht Die Versiegelung verhindert die Oxidation der Leiterbahnen 3 3 6 Bohren Ist die mit L tlack behandelte Platine trocken kann gebohrt werden Es wurde ein Hartme tallbohrer verwendet da normale High Speed Steel Bohrer HSS Bohrer bei dem Einsatz mit Glasfaserplatinen schnell brechen k nnen 3 3 7 L ten Im letzten Vorgang werden die Bauelemente mit Hilfe eines L tkolbens auf die Platine gel tet Beim L tvorgang wird L tzinn erhitzt Das Flussmittel das im L tdraht enthalten ist reduziert die Oxidation der metallischen Oberfl chen und gew hrleistet eine zuverl ssi ge mechanische und elektrische Verbindung zwischen den Metallteilen Fehler be
122. eren vier Nachbarn w rden die Entfernung des aktuellen Feldes v2 erhalten Da diese Pr zision aber nicht n tig ist wird hier auf die Wurzelberechnung verzichtet und die Entfernung des aktuellen Feldes 1 414 angenommen In Abbildung 4 23 kann ein Beispiel f r diese Sch tzung betrachtet werden Die Entfernungswerte wurden auf der Darstellung gerundet und modulo 10 gerechnet um auf der Konsole eine verwertbare Darstellung zu erreichen Mit etwas berlegung kann schnell der Startpunkt der Routenplanung erkannt werden Er befindet sich direkt unter dem linken unteren Hindernis auf dem Feld welches mit einer 1 gesch tzt wurde Der zus tzlich eingehaltene Abstand zu den Objekten und Kartenr ndern kann ebenfalls wahrgenommen werden Letzteres resultiert aus der Tat sache dass unbekannte Regionen potentiell Hindernisse enthalten k nnen und daher ein Sicherheitsabstand eingeplant werden muss Nun muss jedoch aus den berechneten Entfer PG 524 Endbericht 129 SOFTWARE nungen die eigentliche Route extrahiert werden Hierf r wird am angegebenen Zielpunkt gestartet und der folgende Algorithmus umgesetzt HE lege Zielpunkt auf Stack setze Zielpunkt als aktuelles Feld while aktuelles Feld Startpunkt do for alle Nachbarn vom aktuellen Feld do suche k rzeste Entfernung end lege Nachbarn mit k rzester Entfernung auf Stack Nachbar mit k rzester Entfernung wird aktuelles Feld end return stack SO IT WMN E L
123. erf gbar ist und keinerlei Informationen ber aktuelle Sensorwerte und Positions koordinaten vorliegen kann auch eine Blindfahrt des Roboters aktiviert werden allerdings erreicht sie aufgrund fehlender Umgebungsinformationen keine hohe Zuverl ssigkeit und ist stark abh ngig von vorgegebenen Parameterwerten Ihre Ausf hrung hat daher einen rein testorientierten Hintergrund Eine Hauptfunktion der Robotersteuerung welche auch vom Hauptprogramm aufgeru fen wird ist 1 void robosteuerung initialize Listing 4 27 Initialisierung Diese Funktion enth lt alle Hauptfunktionalit ten f r die verschiedenen Funktionsmodi des Roboters wobei die Modi sich durch eine einfache if else Fallunterscheidung voneinan der ausschlie en Sie l uft in einer unendlichen while Schleife und wird somit fortlaufend aufgerufen solange der Roboter eingeschaltet ist Falls im Moment keine Aktion ausgef hrt werden soll f hrt sie einen seperat definierten Modus namens kein Modus aus welche den Roboter zum Stoppen zwingt und ihn in Wartestellung f r die n chsten Befehle bringt Falls der Roboter unerwartet einen ung ltigen Modus erh lt wird das gleiche Verhalten erzwungen Die Komplexit t der Fahrbefehlsequenzen f llt je nach Modus unterschiedlich aus W h rend die Bahn und Routenplanung zur Berechnung der optimalen Fahrstrecke Stacks von Felder ben tigen und eine st ndige Aktualisierung der Positionskoordinaten erfordern reicht f r d
124. erf llt werden eine Schnittstelle zwischen der selbst entwickelten API vom RAPTOR und der von Player Stage zu implementieren Da zu wurde eine eigene API definiert welche die Hardware des Roboters abstrahiert Durch die erfolgreiche Verwendung von Player Stage war es m glich unabh ngig vom RAPTOR Software zu implementieren und testen zumal der Roboter in der Anfangsphase des Pro jekts nicht fahrbereit war Dies erm glichte es parallel an der Software und an der Hardware zu arbeiten 34 PG 524 Endbericht SOFTWARE 2 2 3 Application Programming Interface Eine API ist eine Programmierschnittstelle zwischen mehreren Softwarebestandteilen Sie unterst tzt viele Aspekte der Softwareentwicklung so dass zum Beispiel ein Programmierer der h heren Softwareebene keine Kenntnisse zur Ansteuerung von Sensoren und Aktua toren ben tigt Durch Einbinden der API kann somit der Code intuitiver verwendet und einfacher implementiert werden So kann die zugrundeliegende Hardware effizient angespro chen werden was sich als gro er Vorteil bei der Fehleranalyse erwiesen hat Zudem war die API dabei behilflich die Entwicklung der h heren Funktionen parallel vorzunehmen Haupts chlich dient sie dem Abfragen von Sensorwerten und dem Setzen von Status variablen Daher stellt die Implementierung nur eine Aufbereitung der Daten dar welche von der Hardware geliefert werden jedoch keine Interpretation Beispielsweise stellt die API die Werte des M
125. erf r wurden drei Pins eines RS 232 Ports verkabelt mit einer Stromquelle verbunden und mit Hilfe eines seriellen Anschlusses an den Hauptrechner der Projektgruppe im Hardware Labor angeschlossen Bei ausreichender Versorgungsspan nung wird das Gumstix automatisch vom Rechner erkannt und kann nun mit Hilfe des Programms Minicom konfiguriert werden Die ersten Versuche Daten vom Hauptrechner auf das Gumstix zu flashen verliefen ohne gr ere Komplikationen Leider erweist sich die Geschwindigkeit des seriellen Anschlusses als sehr langsam weshalb im Laufe der Zeit nach anderen schnelleren M glichkeiten zur Daten bertragung auf das Gumstix gesucht wurden Das Erweiterungs Board verf gt zus tzlich ber GPIO Schnittstellen welche den Anschlu weiterer einfacher Peripherie wie z B Sensoren unterst tzen Erw hnenswert ist die auch Unterst tzung von USB Host Signalen welche dem console vx erlauben selber als Host z B f r Netzwerke zu agieren Diese M glichkeit wurde f r den Roboter allerdings nicht in Anspruch genommen 14 PG 524 Endbericht HARDWARE Erweiterungs Board netwifimicroSD EU Das Erweiterungs Board netwifimicroSD EU wird an den 120 pin MOLEX connector des gumstix verdex XL6P angeschlossen za netwifimicroSD EU Abbildung 2 3 netwifimicroSD EU 12 Technische Details e 10 100baseT ethernet e microSD Slot 802 11 b und 802 11 g WLAN Verbindungsprotokoll Verbindungsanschlu 120 pin Busheader
126. ers ten Motor gel tet analog gilt das f r die Pins 3Y und 4Y und den zweiten Motor Die Anschl sse GND1 GND2 GND3 und GND4 m ssen geerdet werden Die maximale Fahrt geschwindigkeit des Roboters wird durch die an VCC2 anliegende Spannung gesteuert dies entspricht demnach 12V Akkuleistung W nschenswert ist hierbei noch eine Regulierung der Fahrtgeschwindigkeit An VCC1 liegen 5V an die die erforderliche Spannung f r den Motortreiber IC liefern Die Pins 1 2EN und 3 4EN Enable Eing nge f r den rechten und linken Motor sind ebenfalls beide mit der 5V Spannungsquelle verbunden Auch hier ist der Vorteil dass keine zus tzliche Steuerung per Software erfolgen muss und auch keine zus tzlichen Pins des Atmel Bausteins belegt sind Der ATMega32 steuert die B rsten ber seinen Pin PD6 ICP R der F r die Motorsteuerung des Rades ist wichtig zu beachten dass der Roboter sowohl r ckw rts als auch vorw rts mit unterschiedlichen Geschwindigkeiten fahren kann Anders als bei der Ansteuerung des Motortreiber ICs f r die B rsten ist hier die Drehrichtung des Motors nicht festgelegt Wie Abbildung 3 13 zeigt sind die Pins GND1 GND2 GND3 64 PG 524 Endbericht HAUPTPLATINE IC3_UNTEN SC RESET AOCZIER eer gt cancospas 24 D oca pas 5 12 36 12 era 3 capat 3 13 lt ADCHPA3 GE 23 xTAL1 ADC2PA2 28 caocopar 2 32 AREF ocopae t2 30 Aaucc
127. erschlechtert sich wenn z B die Radencoderwerte nicht zur gleichen Zeit wie die Ultraschallsensorwerte extrapoliert wur den Im ersten Schritt gehen in die Sch tzung nur die Ultraschallsensorwerte ein Dieser wird in einem zweiten Schritt mit den Radencoderwerten die Geschwindigkeit bzw die zur ckgelegte Strecke weiterverarbeitet Der gesch tzte Parameter verschlechtert sich in dem Fall siehe Abbildung 4 6 Ohne diesen Ansatz ist der gesch tzte Parameter als gr ne Gau glocke dargestellt besser dieser liegt n her am zweiten Parameter zo Die Gau glocke c siehe Abbildung 4 6 oben stellt das endg ltige Ergebnis dar dieser liegt sehr nahe am zweiten Wert Die Gau glocke c unten stellt das endg ltige Ergebnis dar dieser Wert liegt sehr weit vom zweiten Wert Vorteile der Datenfusion e Durch den Einsatz mehrerer Sensoren ist der Ausfall eines einzelnen Sensors leichter zu verkraften als wenn nur ein einziger Sensor vorhanden ist der Systembetrieb wird 94 PG 524 Endbericht DATENFUSION Abbildung 4 6 Oben Ohne die Werte zu extrapolieren Unten Extrapolieren der Werte robuster e Die Zuverl ssigkeit wird verbessert dadurch dass mehrere Sensoren redundante Sen soren das gleiche Objekt erfassen wird die Glaubw rdigkeit der Beobachtung erh ht e Durch die Verwendung mehrerer Sensoren mit unterschiedlicher Ausrichtung wird die r umliche Erfassung erh ht e Unsicherheiten werden durch kombini
128. erte Sensoren reduziert Also der Einsatz kom plement rer Sensoren k nnen die Schw chen des einen Sensors mit den St rken eines anderen ausgeglichen werden Zur Fusionierung der Sensordaten wurde ein Algoritmus auf Basis des in Bild 4 4 darge stellten Modells verwendet Die Datenfusion arbeitet in zwei Teilen die von einem Thread gestartet werden Im ersten Teil wird die zur ckgelegte Strecke A At bestimmt dieser Wert wird f r den Kalmanalgorithmus ben tigt Im zweiten Schritt werden die Update Fusions Funktionen aufgerufen die die Sensordaten sch tzen und fusionieren Die zweite wichtige Hauptfunktion der Datenfusion ist 1 void datenfusion Sensorvorverarbeitung Listing 4 15 Funktion zur Sch tzung der Sensorwerte und der zur ckgelegten Strecke Die Methode bestimmt zun chst in welchem Zustand der Roboter ist ausgehend davon wird die Geschwindigkeit bzw 91 0t bestimmt die f r den Kalman Filter ben tigt wird 1 void datenfusion Sensorschaetzung Listing 4 16 Funktion zum Fusionieren der Sensorwerte Mit der zweiten Methode wird die gesch tzte Geschwindigkeit in die Update Funktion des Kalman Filters bergeben die eine Art Voraussch tzung des Zustandes zum Zeitpunkt PG 524 Endbericht 95 SOFTWARE t 1 durchf hrt Die Methode Sensorschaetzung fusioniert hier unter anderem auch die vom Maussensor gesch tzten Winkel siehe Abschnitt 4 3 3 mit den gesch tzten Kompass werten In
129. es einige Ans tze die heutigen Staubsaugerroboter um wichtige Eigenschaften zu erweitern e Die Analyse des Verschmutzungsgrades e Das Erkennen von Menschen und Haustieren e Das S ubern von Ecken und R ndern Um die Erweiterungen zu realisieren k nnen die Mechanik bestimmte Sensoren und Al gorithmen vom c t Bot bernommen werden F r eine gen gende Rechenleistung sollte ein Embedded Linux Board benutzt werden Dieses ist eine vorgefertigte standardisierte Steuereinheit auf der ein eingebettetes Linux oder RTLinux zum Einsatz kommt 1 2 Ziel Die Projektgruppe soll in zwei Semestern einen autonomen mobilen Roboter entwickeln der als Staubsaugerroboter in einer Wohnung eingesetzt werden k nnte Allerdings braucht der Roboter keinen Saugmechanismus zu enthalten da die heutige Technologie in derartig kleiner Bauform noch keine ausreichende Reinigungsleistung erreicht Auf Grund dessen soll die mechanische Konstruktion auf das zur Fortbewegung Notwendige reduziert werden Zugleich kann damit mehr Zeit in die Softwareentwicklung und Strategieplanung investiert werden Der Staubsaugerroboter RAPTOR hat folgende Besonderheiten e Der Verschmutzungsgrad des Bodens soll mit Hilfe eines Kameramoduls erkannt wer den Da gr tenteils immer dieselben Stellen in einem Raum besonders verschmutzt sind soll der Roboter immer direkt dorthin fahren Mit Hilfe dieser Strategie kann so schnell ein gepflegtes Gesamtbild der Wohnung erreicht werden
130. es Roboters beschrieben wird wird erkl rt wie die Hardwaregruppe ihre Platinen hergestellt hat Des Weiteren wird auf den RS232 I C Adapter des Roboters n her eingegangen den die Pro jektgruppe bereitstellte Abschliessend wird die Karosserie beschrieben Dabei wird auf die Platzierungen der einzelnen Hardwareelemente und die entsprechenden Befestigungsme thoden eingegangen 3 1 Inter Integrated Circuit Der Inter Integrated Circuit I C auch TIC oder Inter IC Bus ist ein serieller Zweidraht Bus der auf Grund seiner Vorteile heutzutage in vielen Systemen verwendet wird Als er vor etwa zwanzig Jahren von der Firma Phillips entwickelt wurde waren die Ziele mit m glichst wenig Adern auszukommen Damit konnten Pins an den ICs Leiterbahnen und somit auch wertvolle Fl che gespart werden Inzwischen hat sich dieser Bus zu einem Industriestandard in unz hligen Embedded L sungen entwickelt 3 1 1 Verwendung im Roboter Im RAPTOR wird der 12C Bus zur Kommunikation zwischen dem Gumstix dem Mikro controller ATMega32 und dem Kompassmodul CMPS03 verwendet e In Bezug auf den Mikrocontroller bietet I C den Vorteil dass auf einen bestehenden Standard zur ckgegriffen werden kann und keine neuen Methoden zur Kommunikati on berlegt werden m ssen Als Alternative war vor bergehend der RS232 Standard im Blickfeld dieser h tte aber gro e Nachteile im Bereich der Geschwindigkeit ge habt Au erdem besteht so die M glichkeit den UART Port
131. eschreibung des ersten Modus ist die L nge des zur ckgelieferten High Impulses PG 524 Endbericht 17 GRUNDLAGEN Programming pins Used once only to program the PIC chip during manufacture 5v Supply Echo Output Trigger Input Mode No Connection Dv Ground Do not connect to these pins Connections for 2 pin Trigger Echo Mode SRFO4 compatible Abbildung 2 5 Anschl sse f r seperaten Trigger und Echo Pin 9 proportional zur Entfernung des Objektes Indem die gemessene Zeit durch die Konstante 58 dividiert wird wird die Entfernung in Zentimetern erhalten Programming pins Used once only to program the P C chip during manufacture 5v Supply No Connection Trigger Input Echo Output Mode Low Connect to Ground 0y Ground Do not connect to these pins Connections for single pin Trigger Echo Mode Abbildung 2 6 Anschl sse f r gemeinsamen Trigger und Echo Pin 9 Distanzen berechnen Die Zeitdiagramme des SRFO5 werden f r den jeweiligen Modus in den Abbildungen 2 7 und 2 8 gezeigt Wie zuvor in den Abschnitten ber Modus 1 und 2 erw hnt reicht ein mindestens 1045 langes High Signal aus um den Messvorgang auszul sen Der SRF05 sendet acht Zyklen hintereinander einen ultrahochfrequenten Ton bei 40kHz aus W hrend 18 PG 524 Endbericht HARDWARE dieser Zeit hat er einen High Pegel Wird ein Echo registriert wird der Pegel in diesem Fall auf Low gesenkt Die L nge de
132. eses Limit auf 31 Zeichen per Kommunikation stellte im RAPTOR kein Hindernis dar da niemals mehr als 31 Zeichen pro Einzel datenaustausch bermittelt werden mussten Auf diese Art und Weise war bei jeder Kommunikation nur ein zus tzliches Byte n tig ins besondere bei h ufiger Kommunikation sollte diese Methode den Geschwindigkeitsverlust durch Protokoll Overhead minimieren Nach dem Steuerbyte beginnt die eigentliche bertragung Soll von einem Busger t gelesen werden so holt der Adapter die entsprechende Anzahl Zeichen und schickt sie anschlie end ber die serielle Schnittstelle Wird auf ein Busger t geschrieben so werden zun chst alle Daten ber die serielle Schnittstelle empfangen und anschlie end ber den Bus geschickt PG 524 Endbericht 69 HARDWARE 3 5 3 Software Das Programm des Mikrocontrollers Listing B 10 implementiert das definierte Proto koll Um Fehler in der Kommunikation fr hzeitig zu erkennen wird jedes per RS232 vom ATMega32 empfangene Byte zus tzlich zur ckgegeben Echo Funktionalit t 3 6 Karosserie Nach einigen berlegungen fiel die Entscheidung auf einen Roboter der aus zwei Ebenen besteht So ist es m glich alle Komponenten problemlos unterzubringen Die Ebenen ha ben eine runde Form Dadurch wird das Drehen auf der Stelle ohne Anecken erm glicht Auf den Ebenen werden die zuvor vorgestellten Bauteile befestigt Die untere Ebene beher bergt unter anderem die Motoren den Akku
133. fl che der Roboter zunehmend mehr fahren und anaylsieren m sste um den gesamten Boden in einem Raum abzudecken Zus tzlich muss in der N he der Webcam eine passende Beleuchtung angebracht werden um geeignete Bilder f r die Auswertung erhalten zu k nnen 2 2 Software In der Robotik gibt es keine universell einsetzbare Software f r datenverarbeitende Sys teme eines Roboters wie beispielsweise Sensordatenfusion oder Odometrie Zwar gibt es Projekte wie Player Stage die eizelne Bereiche wie allein die Routenplanung oder nur die Bahnplanung der Projektgruppe simulieren doch w re ein erfolgreiches und effizientes Zusammenspiel solcher Open Source Projekte nicht gew hrleistet da jedes Projekt anders aufgebaut ist und nicht darauf ausgelegt ist mit anderen Projekten verkn pft zu werden Aus diesen Gr nden hat sich die Projektgruppe dazu entschlossen eigene Software zu entwickeln Ein wichtiger Punkt in der Entwicklung war die Festlegung der verwendeten Program miersprache Die Entscheidung fiel auf C C Die objekt orientierte Programmiersprache C war eine gute Basis f r paralleles Arbeiten an den einzelnen Klassen der Roboter software Mit C lie sich eine effiziente und hardwarenahe Implementierung f r den Mi krocontroller erreichen Des Weiteren haben sich beide Sprachen in allen Bereichen der Softwareentwicklung etabliert und es existieren umfangreiche Dokumentationen zu dieser Sprache wie zum Beispiel 16 Im Folgenden wi
134. g ben tigt zwei Phasen Die erste Phase besteht aus einem Training in dem der Roboter lernt wie in einem bestimmten Raum ein sauberer Boden aussieht Hierf r m ssen w hrend der Fahrt mehrere Bilder aufgenommen werden welche in ein Modell des Bodens einflie en Dieses Modell stellt die Referenz dar welche in der zweiten Phase die Bewertung des Bodens erm glichen soll Hierbei werden die aktuellen Fotos des Bodens ausgewertet und eine Dif ferenz zu dem Modell des sauberen Bodens ermittelt Diese Differenz wird Fehler genannt Anhand des berechneten Fehlers lassen sich R ckschl sse auf den Verschmutzungsgrad ermitteln 2 2 11 Sensordatenfusion Da der RAPTOR verschiedene Sensoren benutzt ist eine Fusion der Werte notwendig um einen Wert zu erhalten mit dem gearbeitet werden kann Des Weiteren liefern die Senso ren aufgrund von Produktionstolleranzen keine genauen Werte Der Datenfusion geht es darum aus verschiedenen Messungen eine optimale Sch tzung zu berechnen die genauer ist als die einzelnen Messungen der Sensoren Die Tatsache dass der RAPTOR mehrere Sensoren verwendet bietet die M glichkeit die Sensorwerte mit einander zu kombinieren um eine h here Genauigkeit zu erzielen Anhand der Sensorwerte wird ein Sch tzwert ge bildet der versucht der realen Situation am n chsten zu kommen Die Sch tzung kann als ein Verfahren definiert werden das auf Basis von Wissen ber die Systemeigenschaften und durch Trennung von Signalen und
135. g des RAPTOR wurde von Anfang an die Vorraussetzung f r eine optische Schmutzerkennung mittels einer Webcam geschaffen um diesem Prolem zu begegnen Im Folgenden wird beschrieben wie die genaue Umsetzung dieses Ansatzes aussieht und welche Probleme dabei gel st werden mussten Ebenso wird aufgezeigt wel che Beschr nkungen die Projektgruppe nicht berwinden konnte und welche F higkeiten angestrebt wurden Als Hardware kommt eine eigens f r diesen Zweck installierte Webcam siehe Abschnitt 3 6 2 zum Einsatz welche eine Aufl sung von 640x480 Pixeln besitzt Diese wurde an der oberen Ebene des RAPTOR angebracht um von dort aus Bilder des Bodens anzufertigen In der unteren Ebene wurde zu diesem Zweck eine ffnung gebohrt durch die dies m glich wird Diese interne L sung hat den Vorteil dass das Umgebungslicht weniger Einfluss auf die Kamerabilder hat Die zus tzlich an der Kamera angebrachte LED Beleuchtung f hrt dazu immer eine einheitliche Belichtung des Bodens zu erhalten Somit wird die St rungs quelle des wechselnden Lichtes gr tenteils eliminiert Dies ist von gro er Wichtigkeit denn die Schmutzerkennung basiert auf Methoden des maschinellen Lernens und diese arbeiten umso besser je geringer die zu kompensierenden St rungen sind Wie genau diese Algo rithmen arbeiten wird nun n her erl utert Das Vorgehen beim maschinellen Lernen gliedert sich in zwei Phasen Als erstes eine Trainingsphase in der das Wissen anhand von Tes
136. gebnisses die den Wert z darstellt Der Verlauf der Kurve gibt an wie gut die Messgenauigkeit ist Je flacher die Kurve verl uft desto ungenauer sind die Messungen und desto weniger vertrauensw rdig ist das Ergebnis Die Varianz AC liefert die Genauigkeit von 21 Ist die Varianz Null so handelt es sich hierbei um einen exakten Wert Wird eine zweite Messung 23 zum Zeitpunkt k mit Varianz de ausgelesen so wird sie anschlie end mit der ersten Messung kombiniert PG 524 Endbericht 97 SOFTWARE DN Abbildung 4 7 Qualit t einer Messung anhand der Gau glocke 6 O K Ai o Li 21 e K2 01 0 03 o 1 Ko x z2 21 Der Kalman Gain Ky 1 8 0k AS legt fest wie stark die Differenz zwischen vorhe rigen Sch tzwert und der aktuellen Messung in eine weitere Sch tzung eingeht Die neue Varianz wird durch folgende Formel berechnet 71 1 0 Kan 4 3 Das Ergebnis in Abbildung 4 8 hat eine geringere Varianz und die Kurve ist steiler Bei X N AR 2 H ha k2 Abbildung 4 8 Varianz zweier Messungen 6 einer dynamischen nderung des Signals wird ein Faktor u in die Gleichung eingerechnet Dieser Fall tritt ein wenn z B ein Roboter im bewegten Zustand Ar At Null die Umgebung mit mehreren Ultraschallsensoren abtastet so ndern sich die Werte der Sen soren mit der zur ckgelegten Strecke Da der Faktor nicht genau angegeben werden kann 98 PG 524 Endberi
137. gssensoren anschlie en zu k nnen besitzt das Board vielf ltige I O Anschl sse Der Roboter sollte selbstst ndig nach einer von der Projektgruppe ausgew hl ten Strategie den Raum beziehungsweise auch mehrere R ume wenn m glich erkunden und eine Karte erstellen Au erdem sollte er in der Lage sein sich selbst zu lokalisieren Zus tzlich soll eine graphische Kontroll und Steuerungsschnittstelle implementiert werden Mit Hilfe dieser Schnittstelle werden Parameter wie beispielsweise der Akkuladestand die Sensorwerte und das aktuelle Kamerabild des Roboters berwacht und die graphisch auf bereitete Darstellung des Raummodells zug nglich gemacht Die Kommunikation mit dem Roboter erfolgt funkbasiert Das ausgew hlte Embedded Linux Board stellt eine WLAN kompatible Schnittstelle zur Verf gung 1 2 1 Minimalziele F r den Erwerb des Leistungsnachweises sind die folgenden Minimalziele zwingend erfor derlich e Hardwareentwurf des Roboters inklusive Auswahl der zu verwendenden Bauelemen te Beim Entwurf ist zu gew hrleisten dass sich der Roboter unter Nutzung der Navigationsvorrichtung zielsicher in einem Raum bewegen kann e Implementierung einer Low Level Steuerungssoftware zur Bewegungssteuerung des Roboters und Positions beziehungsweise Distanzmessung Der Roboter soll damit vordefinierte Punkte im Raum anfahren k nnen e Implementierung einer High Level Steuerungssoftware zur Navigation Dabei soll ein Modell des Rau
138. he Benutzung zu vermeiden Dennoch ist hier grofe Vorsicht geboten Auf dem Kabel sind farbige Markierungen angebracht Diese kennzeichnen jede Leitung individuell und unverwechselbar e blau X SCL e gelb X SDA e schwarz GND e weif VCC Um sicher zu stellen dass auch das 1 C Modul im Kernel eingebunden ist was beim Verdex Board der Fall sein sollte k nnen mit dem Befehl Ismod alle eingebundenen Module angezeigt werden Sollte das Modul i2c pxa oder i2c dev nicht dabei sein so muss in der 88 PG 524 Endbericht GUMSTIX Abbildung 4 2 Carrier Board mit Anschlusskabel Buildroot Konfiguration der I C Support aktiviert werden der Kernel erneut kompiliert und der neue Kernel geflasht werden Anschlie end m ssen in der Datei etc modules folgende Zeilen hinzuf gt werden 1 12C 2 i2c pxa 3 12c dev Nach einem Reboot sollte nun 1 C einsatzbereit sein In der Ausgabe von lsmod ist zu sehen ob die I C Module auch eingebunden sind 4 1 9 12C Kommunikation Zu Testzwecken wird ein simples C Programm 15 benutzt Am Beispiel des Kompass sensors soll die Kommunikation mittels I C verdeutlicht werden Der Kompasssensor wird zun chst mit dem I C Kabel verbunden Die Adresse des Kom passsensors ist 96 Um vom Kompasssensor einen Wert zu erhalten muss zun chst der Sensor in einen Zustand des Sendens berf hrt werden indem ihm ein Integer in diesem Fall eine 2 als Byte gesc
139. hickt Dies erfolgt durch den ersten Befehl aus Listing 4 1 9 An die Adresse 96 wird nun ein Byte mit dem Wert 2 geschickt Die vom Sensor geschickten Daten k nnen mit dem zweiten Befehl aus Listing 4 1 9 empfangen werden count 2 bedeutet dass 2 Byte von der Adresse 96 empfangen werden sollen Es erscheint in der Konsole nun ein Kompasswert in Hexadezimal Um eine API f r die Hardware des Raptors zu erstellen k nnen die Funktionen im Quellcode vom JC genutzt werden F r die Kommunikation mit dem Mikrocontroller muss zuerst ein Protokoll erstellt wer den damit sowohl der Gumstix als auch der Mikrocontroller wissen welche Daten an wel PG 524 Endbericht 89 SOFTWARE che Hardware gesendet werden sollen oder welche Daten von der Hardware zum Gumstix geschickt werden sollen 1 i2c 96 SendByte 2 2 i2c count 2 96 RcvByte 4 1 10 Buildroot Das Buildroot 33 ist ein System welches ein standardisiertes Dateisystem Image basierend auf Linux f r den Gumstix erstellt Es werden alle Schritte automatisiert die zur Erstel lung eines brauchbaren Komplettsystems ben tigt werden im Einzelnen wird folgendes durchgef hrt e Herunterladen aller n tigen Quellcodes und Daten e Bauen eines Cross Compilers mit der n tigen Toolchain e Kompilieren der gesamten Software inklusive Kernel und Anwendungen e Zusammenf hrung aller Ergebnisse in ein fertiges Dateisystem das auf den Gumstix Flash Speicher geladen werden
140. hl verschiedener Software h her einzusch tzen ist Es w re aufwendiger direkt auf dem Roboter zu programmieren zumal mehrere Personen f r verschiedene Softwarebereiche nicht mehr gleichzeitig an der Pro grammierung arbeiten k nnen Der fertig kompilierte Programmcode wird auf dem Robo ter ausgelagert und lokal auf dem Ger t ausgef hrt Ohne ein Betriebssystem welches die passende Programmierumgebung unterst tzt ist dies jedoch nicht ohne weiteres m glich Ein geeignetes Betriebssystem f r den Roboter und eingebettete Systeme allgemein w re Linux Es ist als OpenSource Software verf gbar beansprucht wenig Speicherplatz l uft 11 GRUNDLAGEN bei korrekter Konfiguration sehr stabil und schnell erlaubt viele Freiheiten in der Trei berprogrammierung f r verschiedene Peripherie und stellt viele bereits vorgefertigte Tools und Treiber zur Verf gung Die geeignete Rechnerhardware f r eingebettete Systeme zu denen der Roboter sicher lich zu z hlen ist wurde in den sog Gumstix Boards der amerikanischen Firma gumstix inc gefunden Diese zeichnen sich durch eine hohe Rechenleistung bei kompakter Gr e die einheitliche Gr e der Rechner Boards betr gt 80mm x 20mm und geringer Betriebss pannung 3 3V 5V aus Um eine Vielzahl unterschiedlicher Peripherie zu unterst tzen k nnen die Rechner Boards mit einer breiten Palette an verschiedenen Erweiterungs Boards welche eine hnliche Gr e wie die Hauptplatinen aufweise
141. i angelegter Spannung den Motor um einen Schritt fort bewegen Die Fortbewegung des Rotors pro Schritt ist relativ pr zise die Toleranz liegt h chsten bei 5 Prozent Der Schrittwinkel gibt dabei an wieviele Schritte notwendig sind damit das Rad einmal um die Achse dreht z B werden bei einem Schrittwinkel von 1 8 Grad 200 Schritte ben tigt Der Schrittwinkel liegt je nach Bauart des Motors in der Regel zwischen 1 8 Grad und 18 Grad Es kann aber ber das Getriebe nach belieben verkleinert werden So ist eine hohe Pr zision und Gleichl ufigkeit verschiedener Motoren erreichbar Der Haltemoment eines Motors ist etwa gleich der Gr e des Drehmomentes Der Schritt motor erm glicht es mittels der Motordrehschrittanzahl eine pr zise Angesteuerung d h der Motor muss z B nicht kurzgeschlossen werden um zu bremsen Im Vergleich zu den Getriebemotoren ist die Ansteuerung der Schrittmotoren aufwen diger Der Schrittmotor ben tigt vier Anschl sse damit der Rotor einen Schritt ausf hrt Au erdem m ssen spezielle Folgen von Polarit tsmustern abgearbeitet werden Die An schaffungskosten sind viel gr sser als beim Getriebemotor denn zwei Getriebemotoren k nnen an einem Motortreiber z B L293D angeschlossen werden w hrend jeder Schritt motor einen eigenen Treiber beansprucht Im Projekt hat sich herausgestellt dass die pr zise Ansteuerung die der Schrittmotor gew hrleistet nicht in diesem Umfang ben tigt wird da mittels anderer
142. i_lesen uint8_t adresse uint8_t byteCount uint8_t zaehler 0 TWCR 1 lt lt TWEN 1 lt lt TWEA 1 lt lt TWSTA 1 lt lt TWINT Startsignal und trigger while TWCR 1 lt lt TWINT warte auf Anforderung if IWSR 0xf8 TW_START TWIerror TWSR TWDR adresse lt lt 1l 1 Adressauswahl lesen TWCR 1 lt lt TWEN 1 lt lt TWEA 1 lt lt TWINT TWSTA wird geloescht Daten Adresse senden while TWCR 1 lt lt TWINT warte auf Anforderung if TWSR 0xf8 TW_MR_SLA_ACK TWIerror TWSR while zaehler lt byteCount 166 PG 524 Endbericht 44 45 46 47 48 49 50 51 52 93 54 595 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 SU 81 82 83 84 85 86 if zaehler byteCount 1 TWCR 1 lt lt TWEN 1 Auf naechstes Datum while TWCR amp 1 lt lt TWI warte auf Anforderun letztes Byte lt lt TWINT warten dabei NACK senden NT g if TWSR amp Oxf8 TW_MR_DATA_NACK TWlerror TWSR else TWCR 1 lt lt TWEN 1 Auf naechstes Datum while TWCR 1 lt lt TWI warte auf Anforderun lt lt TWEA 1 lt lt TWINT warten dabei ACK senden CERS ESKS g if TWSR amp 0Oxf8 TW_MR_DATA_ACK TWwIerror TWSR datenr
143. ich dann oben links die anderen Pins folgen im Zickzackmuster welches Abbildung 3 7 aufzeigt Tabelle 3 1 Die Pinbelegung verschiedener Stecker PG 524 Endbericht HARDWARE meee pee efelett ls Abbildung 3 7 Pinbelegung von Wannenbuchsen 3 2 2 Inbetriebnahme des ATMega32 Um den Mikrocontroller zum Laufen zu bringen reicht es aus die GND Pins Pin 11 und Pin 31 mit GND zu verbinden und den Spannungspin Pin 10 an die Stromversorgung anzuschlie en Dennoch sollten weitere Verbindungen geschaffen werden e Zur Spannungsstabilisierung wird ein Kondensator z B 100 nF zwischen GND und P5V geschaltet Solche Filter werden sehr h ufig an ICs eingesetzt e Auch wenn der Mikrocontroller nicht f r analoge Messungen verwendet wird sollte auch AVCC Pin 30 mit P5V verbunden werden e In diesem Aufbau ist der Reset Pin Pin 9 unbeschaltet Generell l sst sich nicht vorhersehen welcher Pegel an einem unbeschalteten Pin anliegt eventuell wird ein vorhandenes Rauschen aus der Luft abwechselnd als LOW und als HIGH erkannt Da der Controller sich bei einem als LOW erkannten Pegel zur cksetzt kann ein un beschalteter Reset Eingang zu ungew nschtem Verhalten f hren Somit sollte dieser Eingang bei fehlender weiterer Beschaltung auf den sicheren Pegel P5V gesetzt werden diese Aufgabe bernimmt ein PullUp Widerstand Der Atmega32 verf gt zwar ber einen integrierten PullUp Widerstand am Reset Pin bei
144. ige Bahn gebildet die den Raum m glichst kom plett abdeckt Da der Raum aber h ufig aus mehreren zusammenh ngenden Teilbereichen von Feldern besteht kann es vorkommen dass nach Abfahren eines bestimmten Teilbe reichs keine benachbarten Felder mehr gefunden werden Ist der Stack hier noch nicht leer so wird zu dem letzten noch nicht besuchten Nachbarfeld gesprungen und ab dieser Stelle die Route weiter berechnet Durch diesen Sprung k nnen also L cher in der Bahn ent stehen d h zwei Felder die nicht direkt benachbart sind Da die Robotersteuerung nur eine Route aus jeweils zueinander benachbarten Feldern annimmt und die R ckfahrt auf dem gleichen Weg sehr ineffizient w re wird an dieser Stelle mit Hilfe der Routenplanung eine Route zwischen den zwei voneinander entfernten Feldern berechnet Diese Route wird dann in die eigentliche Bahn an die Stelle zwischen den beiden Feldern eingef gt Da die sehr hohe Pr zision der Routenplanung bei der Wegberechnung hier nicht not wendig ist benutzt die Bahnplanung eine modifizierte Version der Routenplanung die in wenigen F llen etwas l ngere Pfade erzeugt daf r aber 10 bis 20 Mal so schnell arbeitet Dies ist insbesondere deswegen von Vorteil da die Spr nge und somit die neuen Routen PG 524 Endbericht 127 SOFTWARE berechnungen mehrmals vorkommen k nnen Abbildung 4 22 zeigt ein Beispiel der Bahnplanung im Simulator File Edit View Clock Help d GP ar u E fh
145. im L ten k nnen mit Hilfe einer Entl tpumpe korrigiert werden Diese dient zum Absaugen von fl ssigem L tzinn beim L sen einer L tverbindung 3 4 Hauptplatine Die Hauptplatine auch Controller Board genannt ist die zentrale Platine des Staubsauger roboters Auf ihr befinden sich die meisten Bauteile um diese mittels der beiden Mikrocon troller ATMega32 zu kontrollieren Ein Mikrocontroller ist f r alle Sensoren die sich auf der unteren Platte des Roboters befinden zust ndig Der andere ATMega in SMD Bauweise ist dementsprechend f r alle Sensoren und Aktoren verantwortlich die sich auf der oberen Platte befinden Die Hauptplatine wurde von der Projektgruppe selbst hergestellt Wie diese hergestellt wurde ist im vorherigen Abschnitt 3 3 beschrieben Der Schaltplan A 6 und das dazugeh rige Layout A 9 und A 10 der zentralen Platine befindet sich im Anhang Da die Hauptplatine umfangreich ist wurden zur Erkl rung einige Ausschnitte aus der logischen Ansicht der Schaltung extrahiert Auf das Kapitel 2 aufbauend wird hier die Elektronik der Bauelemente behandelt 3 4 1 Mikrocontroller Der Mikrocontroller ATMega32 besitzt 32 I O Pins verteilt auf vier Ports e Port A PAO bis PAT Port B PBO bis PB7 e Port C PCO bis PC7 e Port D PDO bis PD7 58 PG 524 Endbericht HAUPTPLATINE In den nachfolgenden Abschnitten wird beschrieben welcher Pin des Mikrocontrollers wie belegt ist und mit welchem Bauteil er verbunden
146. implen Muster Zuerst f hrt der RAPTOR solange gerade aus bis er zu einer Wand gelangt Die Implementierung sieht vor dass der Roboter sich immer links von einer Wand bei der Erkundung halten soll also der rechte Ultraschallsensor den direkten Abstand zur Wand misst Der Roboter dreht sich hierbei solange nach links bis er sich parallel zur Wand ausgerichtet hat Fine ann hernd optimale Ausrichtung nimmt der RAPTOR ein sobald der n rdliche Ultraschallseonsor einen leicht gr eren Wert als der nord stliche Ultraschallsensor hat Es wird die Differenz der beiden Werte gebildet Sobald die Differenz ca 4cm betr gt hat sich der Roboter optimal ausrichtet und bleibt stehen Nur wenn der RAPTOR parallel zur Wand ausgerichtet ist werden der linke und der rechte Ultraschallsensor genutzt um die Karte zu schreiben Solange nun kein direktes Hinderniss im Weg ist f hrt der Roboter die Wand entlang und zeichnet die Karte auf Eine Art der Hindernisse sind Ecken im Raum Durch eine aufwendigere Korrektur der Richtung passt sich der Roboter der neuen Wand an und f hrt weiter Eine Sonderstellung nehmen Ecken ein deren Winkel kleiner als 90 ist Hierbei bleibt der RAPTOR komplett 106 PG 524 Endbericht PLAYER STAGE stehen und orientiert sich komplett neu Dabei dreht er sich wieder nach links bis der Messwert des n rdlichen Ultraschallsensors gr er ist als der des nord stlichen Kommt der Roboter an einer Kante an also eine Ecke
147. in wie in Abbildung 4 18 Zu sehen sind dann sechs Roboter in verschiedenen Farben zwei Geistobjekte und eine B roumgebung W nde werden durch schwarze Linien dargestellt 4 6 4 Eigene Programme erstellen F r eigene Programme bernimmt Player die Rolle des Servers so dass Benutzer ihre eige nen Programme zu Steuerung des Roboters schreiben k nnen Diese Programme bemerken keinen Unterschied zwischen einen realen Roboter und dem Roboter aus der Simulation Die Programme die in der Simulation den Roboter steuern funktionieren also auch auf dem realen Roboter ohne oder mit nur geringf gigen Modifikationen Um die Funktionen des Simulationsroboters benutzen zu k nnen muss die Bibliothek PG 524 Endbericht 111 SOFTWARE ang H e RRE E Abbildung 4 18 Simulationsumgebung 112 PG 524 Endbericht PLAYER STAGE lt libplayerc playerc h gt in das C Programm inkludiert werden Dann stehen dem Programmierer diverse Klas sen in Player Stage auch Proxys genannt zur Verf gung Zuerst wird die Verbindung zu dem Roboter mit der Klasse PlayerClient im Konstruktor der C Klasse hergestellt Zu dem wird der Roboter mit den Sonar den Bumpern und den Position2dProxy verbunden Diese sind Instanzen der Klassen SonarProxy BumperProxy und Position2dProxy 1 Roboter 2 m_roboter localhost m_sonarproxy m_roboter 0 m_position2dproxy 6m_roboter 0 m_bumperproxy m_roboter 0 m_mappr
148. ird sie von einem anderen ATMega32 angesteuert als von jenem der die Akkumes PG 524 Endbericht 53 HARDWARE sung vornimmt Bewusst wurde darauf verzichtet eine Kreuzkommunikation zwischen den beiden Mikrocontrollern zu konzipieren die LED wird daher softwareseitig ber den Gumstix angesteuert Das Controllerboard wurde so angelegt dass die LED nicht ber einen Pin des Mi krocontrollers gespeist wird sondern direkt von der 5V Spannungsquelle Der Atmel Pin muss lediglich die Masse bereit stellen Dies bedeutet dass die LED leuchtet wenn der Pin auf Ausgang und auf LOW geschaltet wird Der entsprechende Quelltext befindet sich im Anhang unter Listing B 4 Beleuchtung f r Bodenkamera Die Bodenkamera zur Stauberkennung befindet sich innerhalb des Geh uses und nimmt daher Bilder auf die meist nicht hell genug sind um Schmutz ausreichend zu erkennen Um dies auszugleichen wurden einige ultrahelle LEDs zur Beleuchtung des Bodens genutzt Auf der anderen Seite w rden diese bei durchg ngiger Beleuchtung den Stromverbrauch des Aufbaus erh hen daher werden diese LEDs nur angeschaltet wenn ein Bild aufgenommen werden soll Die Steuerung erfolgt ber den Gumstix Um den dazugeh rigen Controllerpin nicht zu berlasten wird hier die Masse nicht direkt bereitgestellt sondern ber einen Transistor geschaltet Daher leuchten diese LEDs wenn der entsprechende Pin auf Ausgang und auf HIGH geschaltet wird Die Methoden zur An
149. isting 4 34 Routenextraktion Hierbei werden als Entfernungen die zuvor berechneten Entfernungen vom Startpunkt verwendet Die Interpretation k nnte sein dass Entfernungen als H henwerte eines Gebir ges angenommen werden Am Zielpunkt entspringt ein Fluss und der Weg den das Wasser zum Startpunkt w hlt ist die k rzeste Route Hierbei kann es auch mehrere Routen ge ben was dazu f hrt dass bei der Suche nach dem Nachbarn mit der k rzesten Entfernung mehrere m gliche Kandidaten gefunden werden In diesem Fall wird beliebig ausgew hlt denn die L nge der Route wird auf jeden Fall minimal sein Wie die k rzeste Route in dem aufgef hrten Beispiel aussieht ist in Abbildung 4 24 zu sehen Die Zahlen in dieser Abbil dung stellen hier nicht die zuerst berechneten Entfernungen dar sondern die Reihenfolge der Felder modulo 10 Durch den verwendeten Stack werden also nicht nur die Felder auf der Route ermittelt sondern auch die Reihenfolge in der diese angefahren werden m ssen Dieses ganze Verfahren hat sich als schnell herausgestellt Tests auf der von uns ver wendeten Hardware zeigten auch bei gr eren Karten gute Leistungsresultate Trotzdem k nnen noch mehrere Optimierungen eingebaut werden Zum Beispiel kann die resultieren de Route auf wenige markante Punkte reduziert und mit verschiedenen Verfahren aus der Bildverarbeitung eine glattere Kurve berechnet werden die nicht dazu f hrt dass sich der RAPTOR auf der Stelle drehen muss wie e
150. it Hilfe einer Kamera unter Wah rung eines Sicherheitsabstandes folgen Dies kann zum Beispiel dazu dienen den Roboter von einem Ort zu einem anderen zu bekommen ohne ihn selbst tragen zu m ssen Der Roboter k nnte auch w hrend er einem Menschen folgt schwere Lasten tragen Mit der Kamera werden zwei aufeinanderfolgende Bilder aufgenommen und analysiert Die Dif ferenz die sich aus den beiden zeitlich unterschiedlichen Bildern ergibt gibt Aufschluss dar ber in welchen Bildbereichen Bewegung stattgefunden hat und in welchen nicht Es wurden zwei Verfahren entwickelt um dieser Aufgabe gerecht zu werden Das erste Verfah ren betrachtet ausschlie lich die Farben in den beiden Bildern Somit ist es dem Roboter m glich einem Menschen mit einem bestimmten Merkmal z B einer roten Hose zu folgen Das zweite Verfahren bestimmt f r einen Block der Gr e n x n mit n gt 4 die korrespon dierende Position im darauflegenden Bild Es ist auch denkbar dies f r jedes einzelne Pixel zu machen im Allgemeinen aber ist der Luminanzwert eines Bildpunktes nicht charakte ristisch genug um den Bildpunkt in einem anderen Bild zu identifizieren Das verwendete Verfahren ist auch als Blockvergleichs Verfahren Block matching bekannt F r das Farberkennungsverfahren werden die Bilder zun chst aus dem RGB Farbraum in den HSV Farbraum konvertiert Dadurch f llt es leichter die jeweils gew nschte Farbe in einem Bild relativ unabh ngig von der Beleuchtu
151. it konnte ein kleines Metallst ck befestigt werden dessen Funktion es ist die Zylinder fest mit den R dern zu verbinden Andernfalls h tten sich die R der beim Fahren l sen k nnen Abbildung 3 17 Bearbeitung der unteren Aluminiumplatte An den R dern wurden kleine St cke mit der Fr smaschine ausgeschnitten Die Schraube zur Motor Zylinderbefestigung dient damit gleichzeitig als Zylinder Radbefestigung Damit waren die R der mit den Motoren verbunden wie Abbildung 3 18 zeigt Der n chste Schritt bestand darin die Motoren mit der unteren Ebene zu verbinden Abbildung 3 18 Bauteile zur Motormontage Befestigung der R der an die untere Platte Am Lehrstuhl 12 der Technischen Universit t Dortmund waren L f rmige Metallst cke vorhanden die durch Fr sarbeiten auf die im Anhang angegebene Gr e gebracht wurden In eine Seite des rechtwinkligen Metallst cks wurden die L cher zur Motorbefestigung gebohrt analog zu den L chern in der unteren Ebene Dann wurden sowohl auf der anderen Seite des Winkels als auch auf der Platte selbst vier kleine L cher gebohrt Mittels Schrauben konnte dann der Winkel an der Platte befestigt werden 72 PG 524 Endbericht KAROSSERIE Als n chstes wurden die Motoren an die L f rmigen Metallst cke geschraubt und dann die Motoren mit den Metallst cken an den vorher bearbeiteten Zylinder geschraubt Da nach wurden die Zylinder in die L cher der R der gesteckt Zuletzt wurden dann
152. kann Im Folgendem wird genauer darauf eingegangen wie ein Dateisystem Image erstellt wird und wie der Cross Compiler zu benutzen ist Kompilieren des Buildroots Um ein Buildroot zu erstellen m ssen folgende Programme vorhanden sein e Subversion e GNU Compiler gcc e autoconf Zun chst wird der aktuelle Quellcode mit Hilfe von Subversion vom Gumstix Server her untergeladen Dabei ist zu beachten dass falls ein Proxy benutzt wird dieser in die Um gebungsvariablen http_proxy und ftp_proxy des Systems eingetragen werden Jetzt kann mit folgendem Befehl ein check out ausgef hrt werden sun co http sun gumstix com gumstix buildroot trunk gumstix buildroot Dabei wird der Quellcode in das Verzeichnis gumstix buildroot kopiert Jetzt wird in das gumstix buildroot Verzeichnis gewechselt und das Buildroot kann konfiguriert werden Daf r gibt es zwei M glichkeiten 90 PG 524 Endbericht GUMSTIX Die erste M glichkeit ist eine schnelle L sung Dazu wird der Befehlt make defconfig eingegeben In unserem Fall wird bei der CPU Speed die 600 Mhz Option gew hlt und die restlichen Fragen werden mit der vorgegebenen Option beantwortet Die zweite M glichkeit ist sehr viel detaillierter Dazu wird der Befehl make menucon fig ben tigt Dabei wird ein Men ge ffnet wo das zu erstellende Image sehr genau konfiguriert werden kann Es kann zum Beispiel aus einer gro en Anzahl von Programmen ausgew h
153. l ist ein optischer Maussensor nichts anderes als eine kleine Kamera die st ndig Bilder der erfassten Fl che aufnimmt und nderungen mathematisch ermittelt Somit kann eine Positions nderung pr zise berechnet werden Das Project c t Bot 8 benutzt einen Maussensor der auch sehr gut die Anforderungen f r einen Staubsaugerroboter erf llt und wurde somit von der Projektgruppe weitestge hend bernommen Als Sensorchip wird der ADNS 2610 der Firma Agilent Technologies 3 eingesetzt Dieser wird gemeinsam mit einer LED zur Beleuchtung des Bodens einer Linse und einigen weiteren Bauteilen wie Quarz zur Taktgebung auf einer eigenen Platine untergebracht und von unten an den Staubsaugerroboter befestigt Die Verbindung zu dem Mikrocontroller wird ber die beiden Pins SDIO und SCLK realisiert Funktionsweise Der ADNS 2610 besteht aus einem Bilderfassungssystem einem DSP zur Bildverarbeitung und einem seriellen 2 Pin Bus Interface zur Host Kommunikation Der Chip verarbeitet 1512 Bilder pro Sekunde bei einer Sensorgr e von 18x18 Pixeln und einer Aufl sung von 64 Graustufen Die Aufl sung betr gt 400 dpi Das Funktionsprinzip nennt sich Optisches Navigationssystem und beruht darauf dass der Bildsensor st ndig mikroskopisch kleine Bilder von der Oberfl che aufnimmt und der DSP diese Bilder st ndig miteinander vergleicht Aus den unterschiedlichen Bildern wird dann die Richtung und die zur ckgelegte Strecke errechnet Als Ausgabe s
154. ls noch die clientseitige Skriptsprache JavaScript verwendet Der JavaScript Code wird mit der Datei raptor js eingebettet und beinhaltet spezielle Zusatzfunktionen Zum einen sind Methoden implementiert worden die zum Auslesen der Koordinaten auf der als Bitmap angezeigten Karte dienen Diese Koordinaten dienen der Routenplanung als Zielposition f r den Roboter Zum Anderen beinhaltet das Skript Methoden die daf r sor gen dass die passenden Auswahlboxen f r den Aufgabenplaner kontextbezogen erscheinen um eine gewisse Datenkonsistenz beizubehalten 120 PG 524 Endbericht WEBINTERFACE Projektgruppe RAPTOR Nord Nord West Nord Ost Ost S d x Y 28 124 87 54 105 208 198 West 205 Modus seien Abbildung 4 20 Webinterface PG 524 Endbericht 121 SOFTWARE 4 9 Robotersteuerung Die Robotersteuerung ist die Instanz in der Software welche die verschiedenen Modi des Roboters in reale Fahrbefehlsequenzen umsetzt Hierbei wird f r jeden Modus eine indivi duelle Abfolge von Fahrbefehlen aufgestellt welche dann abgefahren werden Da sie jeden verf gbaren Modus des Roboters realisiert werden Instanzen aller Klassen welche die ver schiedenen Modi implementieren erzeugt und weiterverwendet Weiterhin werden f r eine korrekte Ausf hrung genaue Sensorwerte und aktuelle Positionskoordinaten ben tigt wel che von einem Objekt aus der Klasse Odometrie bereitgestellt werden Falls eine Odometrie nicht v
155. lt werden welche f r den Gumstix bereitgestellt werden sollen und welche nicht Nachdem die Konfigurierung abgeschlossen ist kann die Erstellung des Images durch den Befehl make gestartet werden Nach ungef hr einer Stunde ist das Image im Verzeichnis zu finden Jetzt kann dieses auf den Gumstix bertragen werden Cross Compiler Ein Cross Compiler ist ein Compiler der auf einem Hostsystem in unserem Fall Linux installiert ist und Quellcode f r eine andere Zielplattform in unserem Fall ARM ber setzt so dass das die entstanden Programmdateien auf der Zielplattform ausgef hrt werden k nnen Der vom Buildroot erstellte Cross Compiler ist f r die meiste Software zu gebrauchen au er nat rlich f r Software die speziell f r eine Architektur geschrieben wurde die nicht ARM entspricht Die meisten Programme lassen sich mit Hilfe von autoconf automatisch konfigurieren Um einen Quellcode zu bersetzten wird in das Hauptverzeichnis des Quellcodes gewech selt und durch den Befehl configure host arm linux autoconf gestartet Dabei ist zu beachten dass sich ein Verweis auf den Cross Compiler in der PATH Variable befinden muss Ist das nicht der Fall muss diese gesetzt werden Jetzt kann der bersetzungsvorgang durch den Befehl make gestartet werden Wenn die bersetzung ohne Fehler abgelaufen ist kann das Programm auf den Gumstix bertragen und ausgef hrt werden PG 524 Endbericht 91 SOF
156. lut richtig war und sich als beraus vorteilhaft erwiesen hat PG 524 Endbericht 117 SOFTWARE 4 8 Webinterface Das Webinterface ist eine HTML Benutzerschnittstelle des Roboters mit der der Benutzer alle Sensordaten und Kamerabilder des Roboters einsehen und den Betriebsmodus ndern kann Die Sensordaten und die Kamerabilder werden vom Hauptprogramm in regelm igen Abst nden aktualisiert so dass der aktuelle Zustand der Sensoren des Roboters beobach tet werden kann Die Bilder der beiden Kameras geben dem Benutzer Aufschluss ber die verwendeten Bilder der Berechnungen f r den Follow Modus und die Schmutzerken nung Zus tzlich kann der Benutzer ber das Webinterface Termine f r den Aufgabenplaner einstellen Des Weiteren wird im Webinterface die aktuelle interne Karte des Roboters an gezeigt welche im Laufe des Betriebs erstellt wird Der durch das Linux Betriebssystem gestartete Webserver des Roboters erm glicht es auf die HTML Seiten zuzugreifen Der Zugriff darauf ist ber das WLAN Modul des Roboters gew hrleistet Da das Webinterface als eigenst ndiges Programm implementiert wurde ist es losgel st von der restlichen Soft warestruktur Dies hat den Vorteil neben der Portabilit t dass das Webinterface nur Re chenzeit verbraucht wenn es ben tigt wird was zu Performancevorteilen f hrt Es wird le diglich eine Header Datei integriert die wichtige Pfade in Form von Pr prozessordirektiven bereitstellt Um das W
157. men hat Jedoch arbeitete die Projektgruppe die meiste Zeit mit dem Gumstix die daraus gewonnenen Erkenntnisse werden im Folgenden festgehalten 4 1 1 Aufbau des Flash Speichers Neben dem 128MB gro en RAM besitzt der Gumstix einen 32MB umfassenden Flash Speicher welcher in mehrere Sektionen aufgeteilt ist Diese werden an dieser Stelle nur kurz aufgelistet aber es wird nicht n her auf die genauen Spezifikationen eingegangen 1 0 In dieser Sektion werden die relevanten Daten und Programme des Bootloaders U Boot gespeichert Sollten diese Daten beim Flashen besch digt werden w re es nicht mehr ohne Weiteres m glich den Gumstix zu reparieren 1 1 Diese Sektion ist reserviert f r dy namische Daten wie zum Beispiel Laufzeitvariablen U Boot besitzt einen Softwareschutz 81 SOFTWARE um nicht zuf llig die ersten beiden Sektionen zu berschreiben 1 2 Hier l sst sich das JFFS2 Dateisystem wiederfinden welches die Root Partition f r das Betriebssystem ist Im Dateisystem ist auch der Linux Kernel enthalten sowie die Betriebsumgebung 4 1 2 U Boot Bei U Boot handelt es sich um den Bootloader des Gumstix Mit diesem gibt es die M glich keit ein falsch geflashtes Dateisystem oder einen falsch geflashten Kernel wieder zu repa rieren indem das Dateisystem oder der Kernel noch mal ber den Bootloader geflasht wird Um in die Konsole des Bootloaders zu gelangen muss sofort nach dem Einschalten des Gumstix eine beliebige Taste ged
158. mmunikation zum PC sowie zum Ansprechen des 1 C Bus notwendig sind Die PullUp Widerst nde k nnen abgeschaltet werden damit das Board kompatibel zu Hardware ist die bereits PullUp Widerst nde enth lt Sp ter wurde der Quarz von 16MHz gegen einen Baudratenquarz ausgetauscht um auch h here Kommunikationsgeschwindigkeiten fehlerlos zu erreichen 3 5 2 Protokoll W hrend bei einer C Verbindung die Teilnehmer adressiert werden k nnen ist RS232 eine direkte Kommunikation zwischen zwei Ger ten Es musste also eine Art Protokoll ge schaffen werden mit welchem die Ger te am Bus adressiert sowie der Lese Schreibmodus ausgew hlt werden konnte Die Kommunikation geht immer vom PC aus jede Kommunikation ber die serielle Schnittstelle beginnt mit einem Steuerbyte 7 Das h chstwertige Bit w hlt den Kommunikationsmodus Ist dieses Bit gesetzt soll von einem Busger t gelesen werden Ist dieses Bit nicht gesetzt so soll auf dem Ger t geschrieben werden 6 5 Adressauswahl im Raptor werden lediglich drei I C Ger te verwendet daher reichen zwei Bit zur Adressierung aus Intern wird die Konstante 96 addiert somit steht 00 f r den Kompass auf Adresse 96 Adresse 11 virtuelle Adresse 99 wird f r Tests verwendet und kann beispielsweise die reine RS232 Funktionalit t auch ohne laufenden Bus verifizieren 4 0 Die restlichen 5 Bits teilen mit wie viele Bytes auf das Busger t geschrieben respek tive von dort gelesen werden sollen Di
159. ms zur Verf gung stehen und eine festgelegte Mission implementiert sein Eine Mission k nnte beispielsweise sein den Raum m glichst vollst ndig abzu fahren e Demonstration der Funktionsf higkeit der erstellten Hard und Software im prakti schen Einsatz 1 2 2 Erweiterungsm glichkeiten Der Wettbewerb Patente Studierende 23 pr miert im September 2008 in D ssel dorf Haushaltsroboter die dem Menschen sowohl behilflich als auch individuell einsetzbar sind Dabei sollte er nicht allein die Funktion eines Staubsaugers aus ben Diese Tatsache PG 524 Endbericht 9 EINLEITUNG hat die Projektgruppe RAPTOR bereits animiert ber Erweiterungsm glichkeiten nach zudenken Der Abschnitt 4 9 1 beschreibt die Idee und Realisierung Die Bewertungskriterien der Jury die sich im Wesentlichen aus Vertretern von Unterneh men und Universit ten zusammensetzt sind Originalit t in der Probleml sung e Neuheit gegen ber dem Stand der Technik Anwendernutzen und Verwertbarkeit im Markt e Effizienz Praktischer Nutzen zum technischen Aufwand Sorgfalt in der inhaltlichen und formalen Ausf hrung Pr sentation 1 3 Vorgehensweise Die Projektgruppe 524 findet im Wintersemester 2007 2008 und im Sommersemester 2008 mit zw lf studentischen Teilnehmern am Lehrstuhl 12 der Fakult t Informatik der Tech nischen Universit t Dortmund statt Betreut wird das Projekt von den wissenschaftlichen Mitarbeitern Olivera Jovanovic und R
160. muss ein Datenstrom erzeugt werden der ber den C Bus geschickt wird Es gestaltet sich sehr schwierig eine gute Umsetzung der API Funktionen auf die Hardware zu erreichen Zum Beispiel m ssen die Messwerte der Radencoder st ndig berwacht werden was aber nicht von den h heren Funktionen erledigt werden kann Somit muss diese berpr fung in andere Funktionen eingebettet werden um die Funktionsf higkeit sicherzustellen Dies resultiert aus der Tatsachen dass die API nur auf Anforderung aktiv wird und nicht im Hintergrund mitl uft Auch m ssen die Funktionen der API so schnell wie m glich beendet werden um eine Blockade des Pro grammablaufs zu verhindern Es steht somit nur sehr begrenzte Rechenzeit zur Verf gung Die Kommunikation ber C erfordert ein grundlegendes Verst ndniss der Nutzung von Kernel Devices So gibt es nur drei Befehle die beim 1 C Bus genutzt werden k nnen Die Erste ist oct was f r IO Controll steht Hier ber werden Grundeinstellungen der Hardware vorgenommen In unserem Fall ist dies die Bus Adresse des entsprechenden Mikrocontrollers Diese Einstellung muss vor jeder Kommunikation vorgenommen werden weil sich diese seit der letzten Nutzung ver ndert haben k nnte Der zweite Befehl welcher zur Verf gung steht ist write Hiermit werden die Daten auf den Bus geschrieben Der Device Treiber sorgt automatisch daf r dass der richtige Empf nger diese Daten erh lt Zu beachten ist dass nicht
161. n kombiniert werden Insge samt gibt es drei verschiedene Gruppen von gumstix Rechner Boards basix connex und verdex Diese unterscheiden sich haupts chlich in der Rechenleistung der Speichergr e und der Anzahl an kompatiblen Erweiterungs Boards Rechner Board gumstix verdex XL6P Die Projektgruppe entschied sich f r das Modell gumstix verdex XL6P welches bis zu zwei Erweiterungs Boards unterst tzt und ber die h chste Rechenleistung aller bestellba ren Rechner Boards verf gt Zwar ist das gumstix verdex XL6P das teuerste verf gbare Board um 70 Dollar teurer im Vergleich zum billigsten Modell der Produktgruppe basix daf r ist es in der Lage allen vom Roboter gestellten Anforderungen gerecht zu werden Wichtig ist insbesondere die M glichkeit bis zu zwei Erweiterungs Boards an das gums tix verdex XL6 anzuschlie en wodurch die Anzahl m glicher Ein Ausgabeger te deutlich erh ht wird Zudem gibt es einige spezielle Erweiterungs Boards u a das console vx und das netwifimicroSD welche nur mit den Rechner Boards der verdex Klasse kompatibel sind zm verdex XL6P Abbildung 2 1 gumstix verdex XL6P 12 12 PG 524 Endbericht HARDWARE Technische Details e Prozessor Marvell PXA270 XScale Prozessor mit 600 MHZ Speicher 128MB RAM 32MB Flash Speicher Features USB host Signale CCD camera Signale e Anschl sse f r Erweiterungs Boards 60 pin Hirose connector 120 pin MOLEX connector
162. n 5V Dies ist n tig damit er bei unbeschaltetem Zustand einen HIGH Pegel hat und sich nicht zur cksetzt Der Kondensator hat eine Kapazit t von 100nF Zus tzlich ist die Leitung an den zweiten Mikrocontroller angeschlossen so dass bei Bet tigung auch beide neu gestartet werden 3 4 5 Radencoder Da die Bauelemente CNN 0 sich sehr nah an den Drehscheiben der R der befinden m ssen wurde f r jeden dieser Sensoren eine gesonderte Platine zur Stabilisierung bereitgestellt Auf ihr befindet sich au erdem jeweils ein Vorwiderstand der IR LED des CNY70 mit 1000 Die Signale der Lichtsensoren werden ber die Kabel zu einem 40 poligen Stecker auf der Hauptplatine gesendet Dort sind die Widerst nde f r den IR Fototransistor mit jeweils 680 montiert was in der Abbildung 3 11 des Schaltplanauschnittes zu sehen ist Die beiden Pullup Widerst nde vor dem invertierenden Schmitttriggern mit IC13A und IC13B bezeichnet betragen 47k 0 Sie sind an die 5V Spannungsquelle angeschlossen Der Schmitttrigger gibt das invertierte Ausgangssignal an den Mikrocontroller weiter Pin PD2 INTO und PD3 INT1 werden daf r verwendet PG 524 Endbericht 61 HARDWARE GND 5U RESE T de 14 Abbildung 3 10 Realisierung der Hauptplatine Reset OC1B gt PD4 INT1 gt PD3 INTO gt PD2 lt TXD gt PD1 RXD gt PDB MEGA32 P R9 LS14N 47k Abbildung 3 11 Realisierung der Hauptplatine Radencoder 62 PG 5
163. n durch Ultraschall und der Blickrichtung des Roboters durch seinen Kompasssensor w re es m glich seine Position im Raum zu bestimmen Dies k nnte dann mit der bisherigen Positionsbestimmung abgeglichen werden um eine genauere Position zu ermitteln Die Robotersteuerung k nnte eine kontrollierte Geradeausfahrt implementiert haben die daf r sorgt dass der RAPTOR eine gerade Linie f hrt Alternativ dazu k nnte die zu fahrende Route in eine Bezier Kurve berf hrt werden die daraus resultierende Bewegung w re runder und w rde erheblich weicher wirken als der bisherige Stopp des Roboters bei jeder Richtungs nderung Zus tzlich k nnte eine angestrebte Verbesserung sein dass bei einer Blockade der Route bzw der Bahn durch ein Hindernis automatisch die Routen planung zum Umfahren gestartet wird Dies ist zur Zeit nicht integriert und somit f hren unerwartete Hindernisse zu Problemen Das Problem der Schmutzerkennung gilt mit der heutigen Technik der Fachwelt als unl sbar Damit war es der Projektgruppe unm glich optimale Ergebnisse zu erzielen Bei spielhaft kann hier aufgef hrt werden dass Verbesserungen vorgenommen werden k nnen durch eine angemessenere Ausleuchtung des Bodens durch blockiertes Umgebungslicht schnellere Aufnahme der Bilder zur Verringerung der Bewegungsunsch rfe schnellerer Pro zessor um mehr Merkmale betrachten zu k nnen und eine Kamera mit Autofokus Der Betrieb des Hauptprogramms mit Threads war mit
164. nbindung von Ger ten am I C Bus 26 42 SDA darf sich w hrend eines SCK Impulses nicht ndern 26 43 Start und Stopp Bedinzung 26 et 2 5 2m N Eu ar 44 Der Empf nger quittiert den Empfang eines Paketes indem er die SDA Ader beim 9 Bit auf Null zieht 26 st Era a ua 45 Pinbelegung des ATMega32 aoaaa aaa aa 48 AVRISP mklI unser Programmierger t 49 Pinbelegung von Wannenbuchsen 50 Verbindung zwischen ATMega und PC 52 Realisierung der Hauptplatine Kompasssensor und Gumstix 2 61 Realisierung der Hauptplatine Reset 2 2 2 2 Emmen 62 Realisierung der Hauptplatine Radencoder 62 Realisierung der Hauptplatine B rstenmotor 2 2 222 220 65 Realisierung der Hauptplatine Radmotor 2 2 22 nn 66 Realisierung der Stromversorgung ooo a e a 67 169 Abbildungsverzeichnis 3 15 3 16 3 17 3 18 3 19 3 20 3 21 3 22 3 23 3 24 3 25 4 1 4 2 4 3 4 4 4 5 4 6 4 7 4 8 4 9 4 10 4 11 4 12 4 13 4 14 4 15 4 16 4 17 4 18 4 19 4 20 4 21 4 22 4 23 4 24 4 25 4 26 4 27 Al A 2 A3 Der optische Maussensor 8 anre as aa a 68 Bearbeitung der unteren Aluminiumplatte 2 222 222mm nen 71 Bearbeitung der unteren Aluminiumplatte 72 Bauteile zur Motormontage e 72 Befestigung der R der an der unteren Platte 73 Befestigung des Akkus an der unteren Platte 2 22 222222 74 POT S
165. ne genauere Erfassung der Umgebung m glich macht Damit ist das Ziel die Genauigkeit der erfassten Umgebung und die Robustheit des Roboters zu verbessern Eine M glichkeit die sich anbie 92 PG 524 Endbericht DATENFUSION Sensor Nutzsignal UMWELT E gt ROBOTER Rauschen Abbildung 4 3 Nutz und St rsignal tet ist es Sensoren die dieselbe Umgebung erfassen miteinander zu verkn pfen Dadurch dass mehrere Sensoren dieselbe Umgebung erfassen wird zwar Redundanz erzeugt aber der Roboter wird durch diese Ma nahme robuster hinsichtlich Ausfallsicherheit und der Einsatz unterschiedlicher Sensoren erh ht au erdem die Genauigkeit da die Schw chen des einen Sensors durch die St rken des anderen Sensors kompensiert werden Durch den Einsatz eines Filters soll auch das Rauschen der einzelnen Sensoren reduziert werden die bei einer anschlie enden Datenfusion die Genauigkeit noch einmal verbessert 4 3 1 Aufbau der Datenfusion Bild 4 4 zeigt grob den Aufbau der Datenfusion Die Sensoren liefern verschiedene Mess werte mit verschiedenen Fehlerwahrscheinlichkeiten Es erfolgt eine Datenzuordnung in der Messerwerte geeignet zugeordnet werden Es k nnen nur gleichartige Daten zugeord net werden z B mehrere Ultraschallsensoren oder Daten die den gesch tzten Parameter verbessern bzw die f r einen dritten Parameter ben tigt werden z B die Lokalisation Anschlie end wird der Sch tzwert gebildet wobei auch vergang
166. nen vorne vorne rechts vorne links rechts links und hinten Eine schematische Darstellung bietet die Abbildung A 3 Der Schall des Sensors breitet sich im Raum als Welle aus Als Medium dient die Luft Die Ausbreitungsgeschwindigkeit h ngt von der Dichte der Luft und somit vom Ort ab Dabei wird die Schallwelle zus tzlich an Stellen mit einer Dichte nderung teilweise reflek tiert Durch jede Dichte nderung wird ein Echo zur Ultraschallquelle reflektiert welches als Signal wieder auffangbar und auswertbar ist Die Zeitdifferenz zwischen aussenden und empfangen des Signals gibt bei bekannter Mediumsdichte Aufschluss ber die Distanz zwi schen Grenzfl che und Sensor Somit ist eine L ngenmessung entlang der Schallausbreitung m glich Die Firma Devantech 9 hat eine Serie von kleinen Ultraschallsensoren entwickelt Ein vergleichbares Modul selbst zu bauen w re ungenauer und teurer Die Projektgruppe hat 16 PG 524 Endbericht HARDWARE Abbildung 2 4 Der Ultraschallsensor SRFO5 9 sich f r das Modell SRFO5 entschieden siehe Abbildung 2 4 Dieses besitzt eine Reich weite von bis zu 4 Meter Des Weiteren hat er einen zweiten Modus in dem sowohl der Start der Messung als auch das Ergebnis ber die gleiche Leitung bertragen werden siehe Abschnitt ber Modus 2 Der Ultraschallsensor kann folglich ber einen einzigen Port Pin gesteuert werden Diesen Vorteil verwendet die Projektgruppe f r ihre sechs Ultraschallsens
167. ng des Mikrocon trollers verwendet Diese Software ist kostenlos auf der Homepage des Herstellers erh ltlich und unterst tzt den von uns verwendeten USB Programmer nativ Nach der Einbindung von WinAVR 36 kann mit dieser Software auch C Code kompiliert und bertragen werden Sp ter wurde es n tig auf Linux Software umzuschwenken Dies bot zudem den Vor teil einer gr eren Flexibilit t in den Makefiles Die bis dahin geschriebenen Programme konnten zum gr ten Teil ohne nderungen weiter verwendet werden Unter Linux kann die Programmierung des Mikrocontrollers ber das Programm AVR DUDE 22 vorgenommen werden ein geeigneter C Compiler findet sich unter dem Namen avr gcc in der GNU Compiler Collection Verbindung zum PC W hrend der Entwicklung war es an vielen Stellen n tig genau zu erfahren in welchem Programmteil sich der Mikrocontroller gerade befindet respektive wieso er nicht so ar beitet wie es erwartet wird Hier empfielt sich eine Kommunikationsverbindung zum PC so dass Debug Ausgaben erstellt und bermittelt werden k nnen Leider ist eine derartige Kommunikation ber den Programmieradapter nicht m glich Zwar verf gt der ATMega32 ber eine JTAG Schnittstelle die zum Debuggen verwendet werden kann der von der PG verwendete AVRISP mkII unterst tzt diese Schnittstelle jedoch nicht Die Entwicklung eines zus tzlichen JTAG Adapters wurde ebenfalls nicht in Betracht gezogen Der ATMega32 besi
168. ng zu finden Nachdem beide Bilder konvertiert wurden wird in dem ersten Bild ein Bereich gesucht in dem die Farbe am st rksten vertreten ist dabei ist es auch m glich nach bestimmten Formen zu suchen wie z B einem hohen roten Rechteck als Abstraktion f r ein rotes Ho senbein Im n chsten Bild wird in der unmittelbaren Umgebung im Bild wieder nach diesem Muster gesucht Als Ergebnis liefert die Suche eine korrespondierende Bildspaltennummer f r die Muster nach denen gesucht wurde Aus diesem Ergebnis wird anschlie end der Win kel des gefundenen Musters relativ zur Kamera zugeordnet Die Berechnung der Winkel zu jeder Spalte eines Bildes wird zu Beginn des Follow Modus einmal berechnet und f r die nachfolgenden Zuordnungen gespeichert Zur Berechnung werden die Breite und H he 124 PG 524 Endbericht ROBOTERSTEUERUNG der gemachten Bilder Kamerah he und der Horizontale sowie der vertikale ffnungswinkel der Kamera herangezogen Dabei dient die vertikale Winkelzuordnung zu einer Zeile eines Bildes der Entfernungssch tzung bei der Verfolgung eines Menschen F r das Blockvergleichs Verfahren werden die RGB Bilder in Graustufenbilder konver tiert Dieses Verfahren liefert als Ergebnis Verschiebungsvektorfelder f r zwei aufeinan derfolgende Bilder Die Technik dieses Verfahrens besteht darin f r jeden Block des ers ten Bildes diejenige Position im zweiten Bild zu bestimmen f r die die hnlichkeit am gr ten ist Die
169. nstiger und einfacher auszutauschen als das Linux Board Schon sehr schnell limitierte sich die Auswahl auf die ATMega Baureihe der Firma At mel da die Mikrocontroller dieser Baureihe den Vorteil haben dass Prozessor und Speicher in einem Chip integriert sind Zudem werden sie heutzutage in vielen Projekten einge setzt von daher existiert f r viele Sensoren bereits umfangreiche Dokumentation und gut verst ndlicher Beispielcode Nicht zuletzt wird der komplette c t Bot ber einen einzigen ATMega Mikrocontroller angesteuert was ein guter Hinweis f r die Leistungsf higkeit die ser Mikrocontroller ist Innerhalb dieser Baureihe fiel die Entscheidung auf den ATMega32 Dieser unterst tzt eine Taktrate von 16 MHz Dank seiner guten RISC Architektur k nnen die meisten Be fehle innerhalb eines Taktes abgearbeitet werden und f r jeden Einzelbefehl kann eine Ausf hrungszeit von etwa 62 5 nS angenommen werden das reicht auch f r die schnells ten an den Roboter angeschlossenen Sensoren aus Weiterhin hat er einen integrierten 32 kB Flash Speicher Dieser kann In System programmiert werden was beim sp teren Debugging ein gro er Vorteil sein kann zus tzliches Aus und Einbauen des Mikrocon trollers entf llt PG 524 Endbericht 29 GRUNDLAGEN Ein weiteres Argument f r den ATMega32 im Vergleich zu anderen Mikrocontrollern sind die 32 I O Pins verteilt auf 4 Ports die auf der einen Seite frei in der Programmie r
170. nter der Sto stange befinden sich f nf Bumper die bei Ber hrung eine Notbremsung ausl sen Die folgenden Abschnitte erl utern die Fertigungs schritte und den Einbau aller angebrachten Teile Die genauen Konstruktionspl ne sind im Anhang A zu finden und enthalten alle eingebauten Komponenten 3 6 1 Die untere Ebene In diesem Abschnitt wird beschrieben welche Komponenten an der unteren Aluminium platte befestigt wurden Ferner wird erkl rt wie die Platte daf r bearbeitet werden musste und was f r Befestigungsmethoden ausgew hlt wurden 70 PG 524 Endbericht KAROSSERIE Bearbeitung der unteren Platte Bevor mit der maschinellen Bearbeitung der Platte begonnen werden konnte wurden mit Hilfe eines Zirkels zwei rechtwinklige Diagonalen durch den Mittelpunkt gezeichnet An hand dieser Diagonalen wurden dann die genauen Positionen f r die folgenden Bearbei tungsschritte festgelegt Mit Hilfe der Fr smaschine des Lehrstuhls 12 wurden als erstes Abbildung 3 16 Bearbeitung der unteren Aluminiumplatte die L cher f r die R der ausgefr st Diese sind jeweils 10 7cm lang und 3 2cm breit Der Abstand eines Lochs vom Rand der Platte betr gt an der Diagonalen 2 5cm Danach wur de weiterhin mit dem Fr ser das Loch f r die Bodenkamera ausgeschnitten Das Loch f r die Kamera ist 5 5cm lang und 10cm breit Um die B rstenmotoren an die untere Platte zu befestigen wurden f r jeden Motor jeweils vier L cher gebohrt ein Lo
171. o dass Ver nderungen im Bild nicht mehr betrachtet werden die durch die Eigen bewegung des RAPTOR entstehen So w rden die Bewegungen von anderen Objekten viel besser zu erkennen sein Bei dem Wettbewerb erhielt dieser Modus ausschlie lich positive Resonanz wie auch seine innovativen L sungen mit der Kartenerstellung und Schmutzer kennung PG 524 Endbericht 139 AUSBLICK 140 PG 524 Endbericht A Hardwarekomponenten A 1 Skizzen der Karosserie Feder Ausbuchtung der Sto stange Sto stange zur 20 00 Befestigung Bun 10 00 Bogen der Bogen der Sto stange kj Sto stange S B rste RAPTOR Bumper gt Untere Ebene von oben aus gesehen 168 ederhalteruns elen 2 B rstenmotoren 2 Radmotoren Motor 2 R der 2 Lichtsensoren CNY7O f r Radencoder as 100 00 1 Kugelrad Deoball 1 Akku 5 Akkubefestigungen verschiebbar 1 Freiraum f r die Webcam mper 155 00 s 5 00 Ausbuchtung der Sto stange zur Befestigung 110 20 5 00 Zo 4 00 g 8 Halterung f r ks Sto stange 42 00 42 00 107 Halterung f r Sto stange 8 00 00 E Gm 2 00 116 00 10 Abbildung A 1 Untere Ebene von oben aus gesehen 141 HARDWAREKOMPONENTEN RAPTOR Untere Ebene von unten aus gesehen 2 B rsten 2 R der 3 Lichtsensoren CNY70 mit Befestigung momentan ungenutzt 1 Maussensor
172. obert Pyka des Lehrstuhls 12 f r Technische Infor matik und Eingebettete Systeme Unter der URL http 1s12 www cs tu dortmund de raptor ist der Internet auftritt der Projektgruppe zu finden Das Projekt befasst sich sowohl mit Hard als auch mit Software Kapitel 2 1 beschreibt die Auswahl der Hardwareelemente die die Projektgruppe in den Anfangswochen traf Nach dem die Grundlagen gekl rt waren konnte die Realisierung des Prototyps eines autonomen Staubsaugerroboters beginnen Nachzulesen ist dies im Kapitel 3 Da sich die Projektgruppe bei der Herstellung ihres Staubsaugerroboters nah an dem Pro jekt des c t Bots orientiert gibt es einiges an vorgefertigter Software In den ersten Wochen verschaffte sich die Projektgruppe einen berblick ber vorhandene Software zu diesem Themengebiet Das Kapitel 2 2 beschreibt die Vor berlegungen Die letztendliche Realisie rung der Software wird in dem Kapitel 4 gekl rt Die ausbleibenden Programmierarbeiten und Hardwareerg nzungen werden im Kapitel 5 festgehalten 10 PG 524 Endbericht 2 Grundlagen 2 1 Hardware Zu Beginn der Projektgruppe wurde die entsprechende Hardware f r den autonomen Ro boter ausgesucht Dazu geh rt die Auswahl des passenden Linux Board der Ultraschallsen soren der Kontaktsensoren der Lichtsensoren des Maussensors des Kompasssensors der Getriebemotoren des Mikrocontrollers und der Kamera Die folgenden Abschnitte befassen sich mit diesem Thema 2
173. omit wieder frei f r die n chste Kommunikation Repeated Start Wenn ein Master zwar eine Kommunikation beenden aber sofort eine neue beginnen m chte ohne den Bus freizugeben so kann er statt der Stoppbedin gung auch eine erneute Startbedingung senden Dies wird dann als Repeated Start bezeichnet In der Praxis ist solch ein Vorgehen sinnvoll weil eine Einzelkommunika tion nur lesend oder schreibend sein kann jedoch keine Mischung davon Wenn also ein Master zun chst ein Datum schreiben und dann vom gleichen Slave ein Datum le sen m chte so ist es zu empfehlen nicht erst den Bus freizugeben Dieser gemischte Zugriff mag zun chst unsinnig erscheinen allerdings m chte der Master dem Slave oftmals mitteilen welches Datum z B Register er lesen m chte Hier ist also ein vorheriger Schreibzugriff n tig Sollten zeitgleich mehrere Ger te versuchen eine Kommunikation zu beginnen und Mas ter auf dem Bus zu werden so werden die beiden oder mehr Ger te diese Kollision er kennen und durch eine Arbitrierung einen einzigen Master ermitteln Im RAPTOR wird ausschlie lich der Gumstix die Master Rolle bernehmen so dass es hier nicht zu Kollisio nen kommen kann Somit w re auch die Idee des Repeated Starts zu vernachl ssigen PG 524 Endbericht 43 HARDWARE RA SDA SDA l Po SCK Startbedingung Stoppbedingung Abbildung 3 3 Start und Stopp Bedingung 26 3 1 4 Be
174. ompasssensors des Controllerboards der Kameras des USB Hubs und der Spannungsversorgungsplatinen Zus tzlich wurden Kom ponenten wie das Gitter der 1 2C Adapter die Status LEDs und der An Aus Schalter angebracht Abschliessend wird die Montage der oberen Platte an den Stangen und die Besfestigung des Laptops an dem Roboter beschrieben Die Ultraschallsensoren Um Hindernisse rechtzeitig erkennen zu k nnen wurden sechs Ultraschallsensoren einge baut Sie nehmen die Positionen Norden S den Westen Osten Nordosten und Nordwes ten ein Diese Betrachtung bezieht sich auf die Front des Roboters Wiederrum fiel die Entscheidung auf L f rmige Metallst cke Nach dem Bohren von weiteren L chern war die Befestigung der Sensoren an den Winkeln und der Winkel an der oberen Ebene m glich Abbildung 3 24 Die Abbildung A 3 zeigt an welche Positionen die Ultraschallsensoren angebracht wurden 76 PG 524 Endbericht KAROSSERIE Abbildung 3 24 Ultraschallsensor an dem Metallst ck Der Kompasssensor Der Kompasssensor ermittelt anhand des Erdmagnetfeldes die genaue Himmelsrichtung in 0 1 Grad Schritten Der Kompasssensor wurde auf einer Platine befestigt Diese Platine wurde dann an die obere Platte geschraubt Die Abbildung A 3 zeigt an welcher Position der Kompass angebracht wurde Das Controllerboard Das Controllerboard wird f r die hohe Anzahl an Sensoren und Aktuatoren ben tigt Auf ihm befinden sich zwei Motortreiber f
175. oren Im Folgenden werden die beiden Modi und deren Pinbelegung n her erl utert Ferner wird auf die Distanzberechnung und die Richtwirkung des Sensors n her eingegangen Modus 1 Wie in Abbildung 2 5 zu sehen ist benutzt der erste Modus seperate Trigger und Echo Pins das hei t es m ssen zwei Ports mit dem Mikrocontroller verbunden werden Der SRFO5 hat einen internen Pull Up Widerstand so dass der Modus Pin unverbunden bleiben kann Ein kurzer High Impuls auf dem Trigger Input von mindestens 10 Mikrosekunden l st den Messvorgang aus Anschlie end berwacht der Mikrocontroller den Echo Pin Die L nge des High Impulses ist proportional zur Entfernung des Objektes Die gemessene Zeit gemessen wird in der Zeiteinheit uS wird durch die Konstante 58 dividiert wodurch die Entfernung in Zentimetern erhalten wird Modus 2 Der zweite Modus besitzt einen gemeinsamen Pin f r das Trigger und Echo Signal siehe Abbildung 2 6 Er hat den Vorteil dass nur ein Pin des Controllerports belegt ist denn die Ausl sung und das Messen des Ergebnisses erfolgt ber den gleichen Port Um diesen Modus zu aktivieren muss der Modus Pin am Ultraschallsensor mit Low GND verbunden werden Nach Senden eines Ausl sesignales ein mindestens 1045 langes High Signal muss der Port auf Input umgeschaltet werden Danach wird das High Signal des Ultraschallsensors abgewartet F r diese Umschaltung stehen mindestens 70045 zur Verf gung Analog zur oberen B
176. oxy amp m_roboter 0 Q On d Ga Listing 4 23 R cksetzfunktion Nachdem der Roboter mit den Proxys verbunden worden ist ist es m glich z B mit der Methode 1 void Roboter setzeMotorGeschwindigkeit 2 double x double y double drehrate Listing 4 24 R cksetzfunktion den Roboter zu steuern 4 6 5 Makefile Das Programm muss schliesslich kompiliert werden Dazu wurde das folgende Makefile geschrieben Aus den Roboter cpp und Main cpp wird die Main bin erstellt all Roboter o Main o g Main o Roboter o o Main bin pkg config cflags playerc pkg config libs playerc Roboter o Roboter cpp g pkg config cflags playerc t c Roboter cpp Main o Main cpp g pkg config cflags playerc c Main cpp clean rm f x o Main bin Mit dem Aufruf Main bin startet die Simulation des programmierten Roboters vorraus gesetzt die Simulationsumgebung Stage wurde wie bereits beschrieben gestartet PG 524 Endbericht 113 SOFTWARE 4 7 Application Programming Interface Ein Application Programming Interface kurz API dient dazu eine standardisierte Schnitt stelle zwischen verschiedenen Programmteilen herzustellen Es werden hierbei Funktions aufrufe sowie deren Wirkung im Gesamtkontext beschrieben so dass Programmierer wel che diese API nutzen einen intuitiveren Zugang zu den gebotenen Funktionalit ten erhal ten Im Fall des RAPTOR wurde entschieden eine API zu kon
177. phase beginnt zun chst wie die Trainingsphase Es wird ein Bild des Bodens erzeugt und anschlie end in ein Histogramm berf hrt Wie bereits erw hnt dient dies der Merkmalsreduktion und somit der Performanzoptimierung Anschlie end wird die eigentliche Klassifikation des Bodenzustandes vorgenommen Hierzu wird das Histogramm des Bodens mit dem gelernten Bodenmodell verglichen Zu diesem Zweck wird das Histo gramm in die Normalverteilungsfunktion des Bodenmodells eingesetzt und wir erhalten PG 524 Endbericht 133 SOFTWARE Abbildung 4 26 Histogramme von 100 Bildern der Bodenkamera Abbildung 4 27 Gelernte Normalverteilung der Bodenbild Histogramme einen Wert der Abweichung Dies wird f r jeden einzelnen Histogrammwert vorgenommen und die Ergebnisse werden akkumuliert Die Betrachtung der Ungleichm igkeit des Bo dens f hrt hier dazu dass in Bereichen des Histogramms wo sich diese Unordnung auswirkt der Fehler bei einer Abweichung des aktuellen Histogramms von dem gelernten Mittelwer thistogramm kleiner ist als wenn in diesem Bereich kaum Unordnung zu erkennen gewesen ist Dieses Vorgehen bewirkt dass nat rliche Schwankungen kompensiert werden und we niger stark in den abschlie enden Fehlerwert eingehen als Abweichungen welche w hrend des Trainings nicht beobachtet wurden Als finaler Schritt in der Klassifikation dient die Einordnung des berechneten Fehlers in eine f r den Menschen verst ndliche Skala Dieses P
178. platine 1 Kugelrad Deoball 1 Loch f r die Webcam 2 Freir ume f r R der 4 Freir ume f r Kabel 1 Freiraum f r Webcam 4 L cher f r Metallstangen 9 00 Freiraum f r Rad Abbildung A 2 Untere Ebene von unten aus gesehen 142 PG 524 Endbericht SKIZZEN DER KAROSSERIE RAPTOR obere Ebene von unten aus gesehen 6 Ultraschallsensoren SRF05 1 Controllerboard p 1 USB Hub 1 Kompass 1PC 1 Webcam 2 Spannungs versorgungsplatinen 1 Stromanschluss 4 Verbindungsstangen 3 Gitterbefestigungen Abbildung A 3 Obere Ebene von unten aus gesehen PG 524 Endbericht 143 HARDWAREKOMPONENTEN RAPTOR obere Ebene von oben aus gesehen 2 Webcams 6 Ultraschallsensoren SRFO5 6 Befestigungen f r SRFO5 1 Notebook Abbildung A 4 Obere Ebene von oben aus gesehen 144 PG 524 Endbericht SCHALTPL NE A 2 Schaltpl ne A 3 Platinenlayouts PG 524 Endbericht 145 HARDWAREKOMPONENTEN 24 MHz 1ur lt lt J OSC OUT LED_CNTL DL9Z SNOW E eet SCK 100nF BS PDPPP D a SC 0 gt and DD Abbildung A 5 Schaltung der Maussensorplatine 146 PG 524 Endbericht PLATINENLAYOUTS 147 me
179. ptplatine Radmotor ler auf der Hauptplatine In Reihe sind die Widerst nde 1kQ und 2kQ geschaltet Die Akku Messung geschieht am Pin PA7 ADC7 des ATMega32 Die Sensoren und die Mikrocontroller brauchen 5V Versorgungsspannung Diese werden ber eine zus tzliche Platine gew hrleistet Der Schaltplan hierf r befindet sich in Abbil dung 3 14 Hierbei sei zu erw hnen dass nicht nur die Hauptplatine mit den 5V Spannung der Platine versorgt wird sondern auch der USB Hub Um die Spannung des Akkumula tors runter zu regulieren benutzt die Projektgruppe den Spannungsregler 7805 Der gleiche Schaltungsaufbau mit dem Spannungsregler 7803 anstelle des Bauteils 7805 kann benutzt werden um die gew nschten 3 3V Spannung f r den Gumstix zu erhalten Da bei der Regelung Hitze erzeugt wird muss diese durch einen K hlk rper abgef hrt werden Die Keramikkondensatoren C3 und C4 besitzen 22pF und haben die Funktion eines Tiefpas ses Der Tiefpass soll daf r sorgen dass die geregelte Spannung am Ausgang der Schaltung sich bei den 3 3V bzw 5V stabilisiert Die Elkokondensatoren C1 mit 10004 F und C2 mit 100n F dienen zum Gl tten des Signals Die Schottky Diode verhindert einen R ckflu des Stroms Leider hat diese Schaltung den Nachteil dass sie nicht gegen Verpolung gesch tzt ist Eine Verpolung kann zur Zerst rung des Spannungsreglers f hren Wenn z B der Elkokon densator am Ausgang der Schaltung sich zu schnell entl dt so entl dt er si
180. r ckt werden Sonst wird nach nur 3 Sekunden der Kernel normal gebootet 4 1 3 Inbetriebnahme Bevor der Gumstix in Betrieb genommen wird muss sichergestellt werden dass eine Strom quelle vorhanden ist die bei einer Spannung ab 3 3V konstant 600mA Gleichstrom lie fert Ab 4V wird jedoch vermehrt Hitze produziert was zu Komplikationen f hren kann wenn der Gumstix nicht hinreichend gek hlt wird Durch die zus tzlichen Ger te wie SD Cardreader und Ethernet hat sich bei geringerer Stromst rke der Gumstix immer wieder nach dem Bootvorgang abgeschaltet 4 1 4 Konfiguration des Betriebssystems Als Erstes muss der vom console vx Zusatzboard bereitgestellte Ethernet Controller und der micro SD Card Slot in Betrieb genommen werden Diese werden in der Datei etc modules aktiviert Hierbei kann auch sofort die Host Funktion der USB Schnittstelle ein gebunden werden Dazu m ssen die jeweils vorhandenen Zeilen durch die folgenden Zeilen ersetzt werden KA MMC support mmc_block pxamci Ethernet support smc911x USB Host support ohci hcd SONO On wm Listing 4 1 etc modules Nach dem n chsten Bootvorgang sollte nun eine micro SD Karte in das Verzeichnis m nt mmc gemountet werden F r die Ethernetnutzung muss in der Datei etc modpro be conf noch folgende Zeilen 82 PG 524 Endbericht GUMSTIX lias eth0 smc9lx lias eth1l smc9lx N m Listing 4 2 etc modprobe conf durch l
181. r lt byteCount zaehler 106 datenregister zaehler uart_wait_and_getc 107 uart_putc datenregister zaehler 108 if adresse lt 99 twi_senden adresse byteCount 109 110 111 return 0 112 Listing B 10 Das Programm des RS232 12C Adapters 168 PG 524 Endbericht Abbildungsverzeichnis 2 1 22 2 3 2 4 2 9 2 6 2 7 2 8 2 9 2 10 2 11 2 12 2 13 2 14 2 15 2 16 2 17 2 18 2 19 3 1 3 2 3 3 3 4 3 5 3 6 3 7 3 8 3 9 3 10 3 11 3 12 3 13 3 14 gumstix verdex XL6P 12 td Kerns 12 Gonseler Deise ic DE Eer Die ee ee e 14 netwinimicros D E 2 38 ats erraten 15 Der Ultraschallse sor SRF05 9 02 2222 u a 2 32 8 83038 2 era 17 Anschl sse f r seperaten Trigger und Echo Pin 9 18 Anschl sse f r gemeinsamen Trigger und Echo Pin 9 18 Zeitdiagramm vom Modus 1 9 uta rara Ro 19 Zeitdiagramm vom Modus 2 9 sio cuadras ds 20 Richtwirkung des Sensors EE 20 Der Mikroschalter MBF5B 13 oaaae 21 Anschl sse des Kontaktsensors L 21 Der Eichtsensor CNY RE ENEE E 22 Steckerbelegung des CNY70 31 sa aria a 22 Bestandteile des optischen Maussensors 3 2222222222 24 Aufbau und Funktionsweise der Optik des optischen Maussensors 3 24 Pinbelegung des Kompasssensors 9 2 2 22222 25 Ein ATMega32 in in PDIP Bauform 2 9 16 u nz e ka ra rc 29 Logitech SweetPea QuickCam Express 18 3l Philips SPC 900 NC 24 2 es vu 22a ade en 33 A
182. rbeitet auch in geschlossenen R umen korrekt was insbesondere f r den Staubsau gerroboter wichtig ist Die Ausgabe der Ergebnisse kann entweder als PWM Signal oder ber einen I C Bus abgefragt werden Im Folgenden werden die beiden Betriebsarten und die Pinbelegung des Kompasses n her erl utert CMPSO3 Kompassmodul Pin 9 GND Masse Pin 8 Nicht belegt Pin 7 50 Hz Wechselspannung Takteingang bei 50 Hz einfach unbelegt lassen Pin 6 Nur bei Kalibrierung notwendig fur jede Himmelsrichtung auf GND ziehen Pin 5 nicht belegt Pin 4 Ergebnis PWM Pin 3 12C SDA Norden e a E n EE un were er n rn nm n e Pin 2 12C SCL PIN 1 5V Abbildung 2 16 Pinbelegung des Kompasssensors 9 Modus 1 Das PWM Signal an Pin 4 gibt den Kompasswert 0 bis 359 9 Grad in Form eines High Impules aus Die L nge des High Impules kann zwischen 1 Millisekunde und 36 99 Milli sekunden liegen Demnach entsprechen 0 1 Millisekunden 1004 s einem Grad Es muss somit nur die Signall nge gemessen werden danach ist eine Umrechnung sehr einfach Modus 2 Der T C Bus wird an den Pins 2 und 3 SDA und SCL angeschlossen CMPS03 besitzt keine Pullup Widerst nde wie sie f r den C Bus notwendig sind Das Masterboard am I C Bus sollte demnach diese 1 C Leitungen mit ca 5k bis 47k Widerst nden mit 5V PG 524 Endbericht 25 GRUNDLAGEN verbinden Wird der C Bus bei CMPS03 nicht g
183. rd vorausgesetzt er ist eingeschaltet Wird diese Option ausgew hlt erscheint im unteren Bereich der HTML Seite eine Tabelle in der alle ein gestellten Termine angezeigt werden Dar ber befinden sich mehrere Auswahlboxen mit denen die Termine hinzugef gt werden k nnen Das L schen eines Termins ist ebenfalls m glich Durch Dr cken des Buttons Auftr ge abschicken werden die Aufgaben in der PG 524 Endbericht 119 SOFTWARE Datei aufgaben txt abgespeichert Diese Datei kann dann vom Hauptprogramm eingele sen werden damit die Aufgaben zu den angegebenen Zeiten ausgef hrt werden Der letzte Modus lautet Kein Modus und bringt den Roboter zum Stillstand Die bergabe der vom Benutzer eingegebenen Daten der Web Schnittstelle geschieht ber ein HTML Formular welches die Daten per HTTP bertragungsmethode GET an den Webserver sendet Die Daten werden in der Umgebungsvariable QUERY_STRING gespeichert auf die das CGI Programm Webinterface html zugreifen kann In der Me thode checkQuery wird der String je nachdem was f r eine Eingabe im Webinterface stattgefunden hat ausgewertet und verarbeitet Bei einer Modus nderung wird die Modus Datei entsprechend gesetzt Au erdem wird sichergestellt dass auch genau dieser Modus im Webinterface angezeigt wird Je nach Modus ndert sich auch die HTML Seite dyna misch So wird ausschlie lich beim Modus Aufgabenplaner die Tabelle zum Erzeugen
184. rd beschrieben in welchen Bereichen vorgefertigte Softwareprojekte wie Buildroot oder Player Stage zum Einsatz kamen und an welchen Stellen eigene Softwa rekomponenten wie die Odometrie oder die Sensordatenfusion erstellt werden mussten Es wird jedoch nur einen detaillierter berblick ber die verwendete und implementierte PG 524 Endbericht 33 GRUNDLAGEN Software vorgestellt Die Realisierung der Software befindet sich im weiteren Verlauf dieses Dokumentes siehe Kapitel 4 2 2 1 Buildroot Bei Buildroot handelt es sich um eine Skriptsammlung die bereitgestellte Projekten wie Kernel Programme oder Treiber vereinigt Sowohl ein Betriebssystem als auch ein Datei system lassen sich exakt auf die Anforderungen des eingebetteten Systems mittels Buildroot erstellen Neben der Bereitstellung des Betriebssystems und des Dateisystems k nnen auch noch Bootloader und diverse Cross Compiler von Buildroot bereitgestellt werden Buildroot erleichterte es das Potential des Gumstix voll auszusch pfen Es konnte auf ein vollwertiges Linux Betriebssystem zur ckgegriffen werden und vorherige Erfahrungen in diesem Bereich waren auf die Arbeit in der Projektgruppe anwendbar So konnten grund legende Probleme schnell und effizient gel st werden 2 2 2 Player Stage Um die st ndig weiterentwickelten Programme unter einer standardisierten Umgebung testen zu k nnen ohne einen einsatzf higen Roboter zu haben wurde ein Simulationspro gr
185. rieben Dabei wird auf die gewonnenen Erfahrungen und die eingesetzten Ger te sowie Materialien n her eingegangen 3 3 1 Layout Zum Erstellen des Layouts der Platinen wurde das Programm EAGLE Einfach Anzuwen dender Grafischer Layout Editor der Firma CADSoft 10 benutzt Die Software besteht aus mehreren Komponenten Layout Editor Schaltplan Editor Autorouter und einer er weiterbaren Bauelementedatenbank Einige Bibliotheken wie beispielsweise der Baustein CNY70 Lichtsensor mussten hinzugef gt werden Der Autorouter erzielt nicht immer das gew nschte Ergebnis so dass manuelle Verbesserungen vorgenommen werden m ssen Zus tzlich ist darauf zu achten dass die Leiterbahnbreiten nicht zu klein die Abst nde zwischen verschiedenen Leiterbahnbreiten gro genug und eine ausreichende Lochgr e der Pads vorhanden ist 56 PG 524 Endbericht HERSTELLUNG VON PLATINEN 3 3 2 Belichtung Das Layout wird zun chst auf eine transparente Folie gedruckt Danach kann die Platine ohne Abziehen der Schutzfolie auf die richtige Gr e zugeschnitten werden Mit der be druckten Seite nach unten kann das Layout auf die Platine ohne Schutzfolie gelegt werden Bei zweiseitigen Platinen werden die beiden Layoutfolien zuerst bereinander gelegt und anschliessend mit Tesafilm an den Seiten fixiert Die zurechtgeschnittene Platine kann zwi schen die Folien geschoben werden Das Layout und die Platine wird auf die Glasplatte des Belichtungsg
186. roblem konnte die Projektgruppe lei der aus Zeitgr nden nicht mit der Sorgfalt angehen welche w nschenswert gewesen w re Es wurde daher darauf verzichtet eine an den jeweiligen Boden angepasste Einordnung der Ergebnisse vorzunehmen Statt dessen wurde manuell eine Skala erzeugt die auf Er fahrungen w hrend der Funktionstests beruht Die weitere Entwicklung in diesem Bereich sollte zun chst zum Ziel haben diese Erstellung der Skala zu automatisieren und somit zu verl ssiger zu machen Es k nnte damit ein gro es Ma an Verbesserung erzielt werden weil gerade die Einordnung in eine Skala von der Unordnung der Bodenstruktur abh ngt Auch wenn diese Unordnung bereits in der Normalverteilung ber cksichtigt wird f hrt ein stark chaotischer Boden dennoch dazu dass nat rliche Schwankungen einen Fehlerwert produ zieren k nnen der als Verschmutzung klassifiziert werden kann Insgesamt l t sich aber 134 PG 524 Endbericht HAUPTPROGRAMM sagen dass gute Ergebnisse mit dem zur Zeit exisiterenden Ansatz erzielt werden konnten Die Erkennung beschr nkt sich zwar auf die Erkennung von sogenanntem Partydreck wie beispielsweise Chips Gummib rchen und Smarties aber dieses wird ohne die nderung des Bodenzustandes erreicht was eine gro e Verbesserung gegen ber bestehender Systeme darstellt 4 11 Hauptprogramm Das Hauptprogramm dient dazu die restliche Software des Roboters zu starten und zu verwalten Es wird umgehend nach
187. root a Ze deer is e tt A a EE Bee ee 2 2 3 Application Programming Interface 2 2 Bahnplan ne Asa te ee ee ae berg 2 2 9 E meea Para a ed rasen Be Eee 2 2 6 Hauptprogramm acto ts Et ee Er ee 2 2 7 Odometrier zur 222 ee e Bu Ar u ran tra E 2 2 8 Kartenerstellung 29 rte ete dy ee 2 2 9 Robotersteuerung pisa a o e Dee a A ds s 2 2 10 Schmutzerkennung 2 5 eeh en aa er 2 2 11 Sensordatenfusion oa a a 2 2 12 Umgebungsmodell 2 2 13 Follow Modus e e 2 0 eT ware 2 ww a na ta 2 2 14 Webinterface e 3 Hardware CO oO CO OO Y 11 11 16 19 21 23 25 27 29 30 33 34 34 35 35 36 36 36 36 36 37 37 38 38 38 41 Inhaltsverzeichnis 3 1 Inter Integrated Erreger ra A e N 41 3 1 1 Verwendung im Roboter ie 42 Ze 4 Raguet a Kuna een 41 L2 br A EE 42 3 1 3 G ltigkeit von Daten iia 8 O EN 42 3 1 4 Best tigung von Daten picar era ge rg 44 NEE 45 3 1 6 Daten bertragung ec pics er a El 46 3 1 7 Clock Stretching Kuala BEE ES ae 47 3 2 NE ir ll de ado E Dd E o E e is 47 3 2 1 Programmierhardware Col ar il a a ae a ee 3a 47 3 2 2 Inbetriebnahme des ATMega32 50 3 2 3 Ansteuerung der verwendeten Hardware 53 324 PC A er Bene a aa e ata 56 3 3 Herstellung von Platinen ia ars ea aa 56 Sl Dayout sss Ee ae rare Ze kg E e 56 O a EE en a 57 dos ci e id Es a Era Be el 57 Bolo Atem EK 57 3 3 5 S ubern und Versiegeln rar teaser da 57 38 0 DOS
188. rs 13 2 1 4 Lichtsensoren Ein Lichtsensor ndert bei der Einwirkung von Licht seine elektrischen Eigenschaften Der Reflex Optokoppler CNY70 siehe Abbildung 2 12 der Firma Vishay 31 wird f r den Staubsaugerroboter vielf ltig eingesetzt Wie in den folgenden Abschnitten beschrieben dient er der Projektgruppe als Radencoder und Abgrundsensor In der Zeichnung 2 13 ist dargestellt dass der CNY70 in seinem w rfelf rmigen Geh use eine Infrarot LED als Sender und einen Infrarot Fototransistor als Empf nger besitzt Damit kann auf kurze Entfernung das reflektierte Licht der IR LED durch den IR Fototransistor gemessen wer den Die Menge des reflektierten Lichts bestimmt ob der Fototransistor mehr oder weniger PG 524 Endbericht 21 GRUNDLAGEN leitend wird Die Reichweite des Sensors betr gt nur wenige Millimeter St rungen durch Fremdlichteinstrahlung sind eine m gliche Fehlerursache Abbildung 2 12 Der Lichtsensor CNY70 31 Top view Marking aerea 25 10930 Abbildung 2 13 Steckerbelegung des CNY7O 31 Radencoder Mit Hilfe seiner beiden Radencoder kann der RAPTOR die zur ckgelegte Wegstrecke be stimmen eine bestimmte Strecke geradeaus fahren sowie sich um einen bestimmten Win kel drehen Auf der Innenseite der R der sind Encoderscheiben aufgeklebt Auf ihnen sind insgesamt 30 schwarze und 30 wei e Streifen im Wechsel kreisf rmig angeordnet Ein Ra dencoder besteht aus ein
189. rundsensoren F r die Abgrunddetektion werden ebenfalls Lichtsensoren vom Typ CNY70 verwendet Wie bei den Radsensoren der Hauptplatine m ssen die Sensoren sehr nah am zu messenden Gegenstand sein In diesem Fall m ssen sie sehr nah am Boden angebracht werden Die drei Lichtsensoren befinden sich auf Zusatzplatinen ber Kabel werden diese mit den 40poligen Stecker der Hauptplatine verbunden Die Vorwiderst nde der Lichtsensoren betragen auch hier 1000 die PullUp Widerst nde 47k0 Die drei Abgrundsensoren sind mit den Pins PAO ADCO DAT ADC1 und PA2 ADC2 des ATMega32 verbunden PG 524 Endbericht 67 HARDWARE 3 4 12 Maussensor F r die korrekte Ermittlung der abgefahrenen Strecke muss der optische Maussensor sehr nah am Boden angebracht werden Aus diesem Grund wurde der Maussensor auf einer eigenen Platine untergebracht Als Grundlage f r die Schaltung diente der Schaltplan vom c t Bot 8 welcher entsprechend modifiziert wurde Im Anhang befindet sich der neue Schaltplan A 5 des Maussensors Die Verbindung zum Mikrocontroller erfolgt ber einen vierpoligen Stecker welcher Anschl sse f r 5V Ground SDIO Datenleitung und SCK Taktleitung bereitstellt An die beiden Pins OSC IN und OSC OUT des Sensorchips wird der Quarz angeschlossen welcher den Takt f r die Bildaufnahmen vorgibt Die 5V Leitung wird an den VDD Pin des Chips gef hrt au erdem speist sie ber einen Vorwiderstand von 1009 die Leuchtdiode Der zweit
190. s dass die Aufl sung der von der Logitech Webcam erzeugten Bilder nicht ausreichend hoch ist f r eine befriedigende Bodenanaylse weshalb sp ter zus tzlich eine zweite Kamera Philips SPC 900 NC speziell f r die Analyse der Bodenstruktur in den Roboter integriert wurde Logitech SweetPea Quickcam Express Abbildung 2 18 Logitech SweetPea QuickCam Express 18 PG 524 Endbericht 3l GRUNDLAGEN Laut Herstellerangaben gelten als minimale Systemvoraussetzungen e Pentium III 700 MHz oder schneller e 128 MB Arbeitsspeicher e 200 MB freier Festplattenspeicher e 28 8 KBit s Internetverbindung Rein faktisch w rde das Gumstix Board des Roboters den Systemvoraussetzungen der Logitech Webcam nicht gen gen allerdings muss bedacht werden dass diese Systemvoraus setzungen zumeist f r den Privatanwender in Videokonferenzen oder Online Chats Echt zeitumgebung gelten Der Roboter hingegen ben tigt primitivere Funktionalit ten wie der regelm igen Aufnahme von Einzelbildern somit ist die Rechenleistung des Gumstix Boards mehr als ausreichend dimensioniert Die Standardaufl sung der Einzelbilder be tr gt 320 x 240 Pixel Theoretisch k nnte die Aufl sung laut Herstellerangaben durch Grafikinterpolation verdoppelt werden diese M glichkeit wurde aus Komplexit tsgr nden aber nicht in Anspruch genommen Die Farbqualit t der erzeugten Bilder ist schlechter als wenn sie unter einem Windows System erzeugt w rden Das ist a
191. s High Pegels ist proportional zur Entfernung des Objekts Mit einer Zeitmessung l sst sich die Distanz beispielsweise in Zentimeter berechnen Wird kein Echo empfangen senkt der Ultraschallsensor den Pegel nach 30 Millisekunden auf Low Bis zu 20 Messungen pro Sekunde sind mit diesem Ultraschallmodul m glich das hei t alle 50 Millisekunden ist eine Messung m glich Wichtig ist dabei dass die Zeit des Echo Impules m glichst genau ermittelt wird Je genauer dies geschieht desto akkurater ist die Entfernungsmessung Abschlie end ist noch zu erw hnen dass die restlichen f nf Pins auch Programmier Pins genannt ausschliesslich bei der Herstellung dazu dienen den Flash Speicher des Chips PIC16F630 zu programmieren Das bedeutet dass keiner dieser Pins verbunden werden darf SRFOS Timing Diagram Mode 1 Trigger pulse 10u5 Mininum Trigger pulse input to SRFOS 8 cycles off sonic burst Ultrasonic burst UT transmitted from SRFOS Echo pulse 100uS to 25mS Times out after 30mS if no object detected Echo pulse output from SRFOS to users controller Abbildung 2 7 Zeitdiagramm vom Modus 1 9 Richtwirkung des Ultraschallsensors Die Richtwirkung des SRFO5 ist dem Datenblatt des Herstellers entnommen und ist in der Grafik 2 9 zu sehen Die Ultraschallwellen breiten sich konisch aus Die Richtung ist nicht nderbar 2 1 3 Kontaktsensoren Die Ultraschallsensoren k nnen ein Hindernis erst ab einem Minde
192. s PWM Signal wird den beiden EN Eing ngen des Motortreibers angelegt und durch die Tr gheit der Motoren kann bei entsprechender Pulsbreite die Geschwindigkeit reguliert werden 3 4 9 Stromversorgung Der Akku Kung Long der gleichnamigen Firma 17 ist ein wartungsfreier Blei Gel Akku mit einer Spannung von 12V und 4 5Ah ber eine Steckverbindung ist der Akku mit der Hauptplatine direkt verbunden und liefert die Spannung f r die Motoren Ist die Akku leistung fast verbraucht sollte der RAPTOR ausgeschaltet werden um Sch den an den Bauteilen zu vermeiden Hierf r befindet sich f r die 12V ein zus tzlicher Spannungstei PG 524 Endbericht 65 HARDWARE Si Hi mISO PB6 42 ur MOSDPBS gt lt TXD gt PD1 RXD PDO Z A 7 Z 2 2en ucca HE OR AA 00 Ss ps 4 2 5 E cams oce pea i 2 1A ar gt lt PING INT2P82 k Mot ar vH crerxcopse Pi Mot GND 3 27 men pn Pi o lt TOSCDPC7 et 5 SS 12 5 TOSCIPCE 27 E Ls GNO2 GND4 a croppes L lt rooypc 2S Bank SA 2v ay HL emseca E 4 io 2t Z 2A ze H2 soaypc 22 g 8 a scLypce H22 vec2 3 4En L Can 24 12U 293 p21 12 2930 aceros 28 campos S 0C18 PD4 guten L anrern2 H 114 MEGA32 P MOTORA AORTA OTORA_ANET MOTORB_RORT MOTORR ANRTI Abbildung 3 13 Realisierung der Hau
193. s Roboters vorgestellt das die Programmierung der Gitterkarte beinhaltet Anschlie end wird die Sensordatenfusion vor gestellt gefolgt von der Odometrie Des Weiteren wird erkl rt wie die Kartenerstellung im RAPTOR funktioniert Ferner wird die Simulation mit Player Stage gezeigt gefolgt von der Beschreibung des API Entwurfs F r eine bessere Interaktion zwischen Benutzer und dem Roboter dient das Webinterface Die Realisierung wird ebenfalls in diesem Kapitel beschrieben Die Robotersteuerung umfasst den Follow Modus die Bahnplanung und die Routenfahrt Dabei ist der Follow Modus eine zus tzliche Besonderheit die den RAPTOR von gew hnlichen Staubsaugerrobotern unterscheidet Der Abschnitt Schmutzerkennung beschreibt wie schmutzige Stellen auf dem Boden mittels einer Bodenkamera direkt er kannt werden k nnen Abschlie end wird die Funktion des Hauptprogramms beschrieben 4 1 Gumstix Der Gumstix besitzt im Auslieferungszustand eine Menge Funktionen jedoch sind nicht al le f r die Nutzung des Roboters wichtig Zum einen m ssen zus tzliche Komponenten wie der 1 C Bus eingebunden werden zum anderen die Funktionen der Erweiterungsboards wie die Nutzung von LAN oder des Micro SD Slots aktiviert werden Da entsprechende Si cherheitsma nahmen bez glich der Stromversorgung nicht vorgenommen wurden ist beim Einsatz der Gumstix kaputt gegangen Ersatzweise wurde ein Notebook bereitgestellt wel ches die Funktionen des Gumstix bernom
194. s bei einer eckigen Route der Fall ist Hier muss sich aber noch zeigen dass der Rechenaufwand an dieser Stelle gerechtfertigt ist Eine wei tere Optimierung kann w hrend der Sch tzung der Entfernungen erreicht werden indem nur vielversprechende Felder ausgewertet werden die mit einer hohen Wahrscheinlichkeit die optimale Route beschreiben Dies ist aber wieder eine Optimierung die gerechtfertigt sein muss Es kann durchaus sein dass die Performanz der durchgef hrten Berechnungen nicht weiter ins Gewicht f llt und die Arbeit an anderer Stelle sinnvoller ist 4 10 Schmutzerkennung Die Erkennung von Verschmutzungen im Haushalt ist ein Problem welches mit der heuti gen Technik als nicht l sbar gilt Dies basiert zum einen auf der Anzahl unterschiedlicher 130 PG 524 Endbericht SCHMUTZERKENNUNG Darstellung 0 2 99 39 2211122334543221100099888889900012345666566777889900012345678901234567899012345678901234567890 11000112 10099988777778899901234555455666778899012345678901234567789012345678901234567890 0099900 9988877666667788901234544344555667789012345678901234566678901234567890123456789 998889 87776655555667 44332334445566 45678901234455678901234567890123456789 88777 666554444455 e 322122333445 5678901223345678901234567890123456789 7766 5594333334 1101122233 789000112234567890123456789012345678 6655
195. sache Rechnung dass es Werte gibt die sich nicht ndern Der Roboter wird nicht pl tzlich schrumpfen und die R ume sich auch nicht ausdehnen Da her k nnen mit Hilfe von Konstanten die Berechnungen zur Routenplanung durchgef hrt werden Hierf r muss aus den beiden Konstanten die Anzahl der freizuhaltenden Felder berechnet werden die den Abstand vom Zentrum des Roboters zu den Objekten im Raum darstellen Ist dies geschehen kann dies bei der Sch tzung der Entfernungen ber cksich tigt werden F r diesen Vorgang wird folgender Algorithmus umgesetzt der sich an dem Bereichswachstumsverfahren 19 orientiert weise Startfeld die Entfernung 1 zu lege Startfeld auf Stack for alle Felder auf dem Stack do hole TOS gt aktuelles Feld for alle Nachbarn des aktuellen Feldes do wenn Nachbarfeld nicht belegt and Nachbarfeld nicht zu nah an Objekt do weise Nachbarfeld sein Entfernung zu lege Nachbarfeld auf Stack end end end R 40O000 DOC on EH N Listing 4 33 Entfernungssch tzung Die Entfernungssch tzung kann hier auf vielf ltige Art und Weise erledigt werden Es wurde dabei Wert auf die Verwendung von simplen und schnellen Berechnungen gelegt Als Nachbarn werden die acht Nachbarfelder und nicht wie beim Bereichswachstumsver fahren nur die vier Nachbarn in den Himmelsrichtungen betrachtet Die Nachbarn in den vier Himmelsrichtungen bekommen hierbei die Entfernung des aktuellen Feldes 1 Die and
196. se default IWlerror TWSR default switch return 0 1 lt lt TWINT 1 lt lt TWINT Listing B 9 Ausschnitt aus raptwi c PG 524 Endbericht 165 MIKROCONTROLLERPROGRAMMIERUNG 1 2 3 4 9 6 T 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 uint8_t twi_senden uint8_t adresse uint8_t byteCount uint8_t zaehler 0 TWCR 1 lt lt TWEN 1 lt lt TWEA 1 lt lt TWSTA 1 lt lt TWINT Startsignal und trigger while TWCR 1 lt lt TWINT warte auf Anforderung if IWSR 0xf8 TW_START TWIerror IWSR TWDR adresse lt lt 1 0 Adressauswahl schreiben TWCR 1 lt lt TWEN 1 lt lt TWEA 1 lt lt TWINT TWSTA wird geloescht Daten Adresse senden while TWCR 1 lt lt TWINT warte auf Anforderung if TWSR 0xf8 TW_MT_SLA_ACK TWIerror TWSR while zaehler lt byteCount TWDR datenregister zaehler Registerauswahl TWCR 1 lt lt TWEN 1 lt lt TWEA 1 lt lt TWINT Daten Register senden while TWCR amp 1 lt lt TWINT warte auf Anforderung if TWSR 0xf8 TW_MT_DATA_ACK TwIerror TWSR zaehler TWCR 1 lt lt TWEN 1 lt lt TWINT 1 lt lt TWSTO uint8_t tw
197. st tigung von Daten Ein Datenpaket besteht immer aus 8 Bit Nachdem der Sender diese 8 Bit bermittelt hat folgt noch ein weiterer SCK Impuls in diesem Impuls greift der Sender nicht schreibend auf die SDA Leitung zu statt dessen obliegt es der Verantwortung des Empf ngers den SDA Pegel auf GND zu ziehen nat rlich wieder bevor auf der SCK Leitung die anstei gende Flanke erscheint das ACK Bit Acknowledge ist in diesem Falle ein Bit wie jedes andere auch Dieses ist dann die Best tigung dass der Empf nger die Daten erhalten und gespeichert hat Abbildung 3 4 stellt solch ein Szenario dar Wenn der Empf nger den SDA Pegel ebenfalls HIGH l sst so ist das f r den Sender ein Zeichen dass der Empf nger die Daten nicht oder nicht richtig erhalten hat Wie in diesem Falle zu verfahren ist ist von der Software abh ngig Allerdings tritt dieser NACK Fall Not ACK Not Acknowledge nicht nur bei Fehlern auf sondern auch wenn der Empf nger keine weiteren Daten erhalten will Dieser Fall tritt beispielsweise bei dem im RAPTOR verwendeten Kompassmodul auf Nachdem es adressiert und Register 2 ausgew hlt wurde sendet das Modul nun nacheinander die Re gister 2 3 4 usw Da allerdings nur Register 2 und 3 relevant sind sollte nach dem zweiten ausgelesenen Byte ein NACK gesendet werden Nat rlich ist auch die danach gesendete Stoppbedingung ein eindeutiges Zeichen f r das Ende der Kommunikation allerdings kann das NACK sinnvoll sein w
198. stabstand von 10cm messen Zudem haben sie eine Fehlerrate In einigen Szenarien kann es dazu kommen dass die Sensoren ein Hindernis nicht erkennen F r diesen Fall hat die Projektgruppe sich entschieden den Staubsaugerroboter mit f nf zus tzlichen Mikroschaltern auch Schnapp schalter genannt zu versehen Die Entscheidung fiel auf den Schalter MBF5B der Firma PG 524 Endbericht 19 GRUNDLAGEN Trigger pulse input to SRFOS and Echo pulse output to users controller Ultrasonic burst transmitted from SRFOS Abbildung 2 8 Zeitdiagramm vom Modus 2 9 Abbildung 2 9 Richtwirkung des Sensors 9 SRFOS Timing Diagram Mode 2 Trigger pulse Echo pulse 100uS to 25m8 Times 10uS Mininum out after 30mS if no object detected DREES A 8 cycles off sonic burst Colour Codes Blue Users controller drivesthe TriggerfEcho pin Red SRF05 drives the Triggerfecho pin 20 PG 524 Endbericht HARDWARE Hartmann 13 siehe Abbildung 2 10 Die Abbildung 2 11 zeigt eine Zeichnung des Schal ters mit seinen Anschl ssen Der Kontakt ist in Ruhestellung zwischen COM und NC oder NO geschlossen Durch Druck auf den Bet tiger wird der Schaltvorgang ausgel st Dabei wird von Kontakt NC auf NO umgeschaltet Der Kontaktabstand ist kleiner als 3mm Abbildung 2 10 Der Mikroschalter MBF5B 13 Type M B Zusatzbet tiger Actuator Bet tiger Plunger Abbildung 2 11 Anschl sse des Kontaktsenso
199. steuerung der LEDs befinden sich ebenfalls im Anhang unter Listing B 4 Maussensor Der Maussensor verwendet einen eigenen internen Controller Die Kommunikation mit diesem Controller erfolgt ber einen Bus und ein definiertes Protokoll Die im RAPTOR verwendete Platine zur Ansteuerung des Maussensors hat bereits die Kontakte SDA und SCL was sehr analog zum 1 C Bus aussieht Tats chlich ist das Protokoll bis auf einige Kleinigkeiten sehr hnlich e Es ist kein Bus sondern eine Direktverbindung e Fs ist keine Hardware Adressierung n tig e Auf die Registeranwahl vom Controller aus folgt sofort die Antwort des Sensors ohne dass ein Restart n tig w re e Das Bit f r die Auswahl der Datenrichtung ist invertiert e Die 5V Default Spannung auf dem Bus wird vom Controller vorgegeben Damit l sst sich die Platine nicht direkt an den C Bus anschlie en Auf der anderen Seite bedeutet das dass zwei beliebige Pins am Mikrocontroller verwendet werden k nnen Der zur Abfrage verwendete Quelltest Listing B 5 wurde in groben Z gen der Web seite von Roboternetz de 26 entnommen musste jedoch noch ein wenig korrigiert und abgewandelt werden 54 PG 524 Endbericht ATMEGA32 Kontaktsensoren Die Kontaktsensoren haben hier eine Sonderbewandnis weil sie nicht ausgelesen werden sondern der Controller sofort auf eine Kontaktmeldung reagieren muss Im Quelltext wird dies dadurch sichergestellt dass ein Kontakt einen In
200. sting B 2 zur Messung der Impulsbreite wird ein Timer Counter des Mikrocontrollers verwendet Da auch bei ma ximalen Vorteiler ein berlauf dieses 8 Bit Z hlers nicht verhindert werden kann werden hier die berl ufe gez hlt Um bei nicht angeschlossenen Ultraschallsensoren oder einem Fehlverhalten derselben nicht in einer Endlosschleife zu langen wird nach einem Timeout automatisch ein Fehlerwert 0 zur ckgegeben diesen geben die Sensoren im Normalbetrieb niemals zur ck Akku Messung W hrend des Betriebes wird fortw hrend die Spannung des internen Akkus ber einen Spannungsteiler gemessen damit kann ein zu niedriger Akkustand fr hzeitig erkannt und eine Wechsel bzw eine Aufladung vorgenommen werden bevor eine extrem niedrige Span nung die Komponenten oder gar den Akku selbst sch digt Die Atmega Baureihe verf gt ber einen integrierten Analog Digital Wandler dieser wird bei der Akkumessung verwendet Der dazugeh rige Quelltext befindet sich im Anhang siehe Listing B 3 Abgrundsensoren Dieselbe Routine die zur Messung der Akkuspannung eingesetzt wird wird auch zur Abfra ge der Abgrundsensoren verwendet der Pegel dieser Sensoren schwankt je nach Untergrund und Lichtverh ltnissen so dass eine digitale Messung nicht m glich ist Akku LED Wenn ein gef hrlich schwacher Akkustand erkannt wird leuchtet eine nach au en sicht bare rote Leuchtdiode auf Da diese LED an der oberen Platte des Roboters befestigt ist w
201. struieren um hardwarenahe und hardwareferne Programmteile voneinander zu trennen Dies hat mehrere Gr nde Zum einen ben tigen die Entwickler der h heren Funktionen keine Kenntniss ber die genaue Ansteuerung der Hardwarekomponenten Zum anderen kann zu Testzwecken der eigentliche Roboter durch einen Simulator ersetzt werden Dies ist m glich weil eine API zwar Funk tionsaufrufe definiert aber nicht deren konkrete Implementierung So ist es ohne weiteres m glich die Befehle entgegenzunehmen und entweder an reale Hardware oder simulierte Hardware weiterzuleiten A A I2C Player Stage Abbildung 4 19 Ein Darstellung der API Konkret wurde bei der Entwicklung eine u erst komplexe Implementierung der definier ten API vorgenommen Wie auf Abbildung 4 19 zu erkennen ist besteht sie aus mehre ren Teilen welche die Anfragen untereinander weiterreichen Wird eine Funktion der API aufgerufen wird diese Anfrage zun chst von dem Modul Thread Safe APT entgegenge nommen Diese sorgt nun in einem ersten Schritt daf r dass keine zwei Threads gleichzei tig auf die API zugreifen k nnen Hierf r werden sogenannte Mutexe gesetzt welche als Sperre f r gleichzeitige Zugriffe dienen Sollte also gerade ein Thread eine API Funktion nutzen und eine zweite Anfrage kommt bevor die Erste abgearbeitet wurde wird die Zweite solange aufgehalten bis die Erste vollst ndig bearbeitet wurde Dieses Vorgehen wird immer benutzt und ist somit
202. t s mtliche Operationen und Vorbereitungen vorzunehmen die das Datenpaket verlangt Da selbst das Auslesen des Datenpaketes durch den Softwarefluss geschehen muss k nnte selbst die Abfrage des I C Busses an sich verz gert werden In der Praxis sollte die C Kommunikation z gig abgewickelt werden Zu diesem Zweck k nnen 1 C Ereignisse auch Interrupts ausl sen 3 2 ATMega32 Wie weiter oben schon angef hrt wird im Roboter der Mikrocontroller ATMega32 von Atmel Abbildung 3 5 verwendet Dieser soll an dieser Stelle etwas genauer betrachtet werden Da seine technischen Details zu ausf hrlich zum Auflisten sind wird eher auf die Bereiche eingegangen die f r den RAPTOR relevant sind Um sich genauer mit dem Mikrocontroller zu besch ftigen ist ohnehin eine umfangreiche Lekt re des Datenblattes 5 und der Anleitungen im Netz und aus B chern unumg nglich 3 2 1 Programmierhardware Auch wenn die Programmierung des Mikrocontrollers in system erfolgen kann wird dazu Programmierhardware ben tigt Es gibt auf dem Markt eine Auswahl an Ger ten und es PG 524 Endbericht 47 HARDWARE XCK TO PBO rl PB1 INTZ AINO PB2 PAO ADCO PA1 ADC1 PA2 ADC2 OCO AIN1 PB3 PA3 ADC3 55 PB4 PA4 ADC4 MOSI PB5 PAS ADC5 MISO PB6 PAG ADC6 SCK PB7 PA7 ADC7 RESET AREF VCC GND GND AVCC XTAL2 PC7 TOSC2 XTAL1 PC6 TOSCI RXD PDO PCS TDI TXD PD1 PC4 TDO INTO PD2 PC3 TMS INT1 PD3 PC2 TCK
203. t DATAREG_STATUS_RADENC 27 if datenregister DATAREG_STATUS 160 PG 524 Endbericht 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 ol 52 93 54 595 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 1 lt lt DATAREG_STATUS_RADENCIGNORE Radencoder zu ignorieren nichts machen else motor_stopp uint8_t radencoder_disable GICR amp 1 lt lt INTO 1 lt lt INT1 externer InterruptO und Interrupt 1 deaktiviert uint8_t radencoder_enable GICR 1 lt lt INTO 1 lt lt INT1 externer Interrupt0 und Interrupt 1 aktiviert uint8_t radencoder_tickdown uint8_t registerMSB uint8_t registerLSB uintl6_t radenc radenc datenregister registerMSB x 256 datenregister registerLSB radenc if radenc 0 radencoder_ablauf datenregister registerMSB radenc 256 datenregister registerLSB radenc 256 uint8_t radencoder_tickup uint8_t registerMSB uint8_t registerLSB uint16_t radenc der aufwaerts zaehlende Radencoder radenc datenregister registerMSB x 256 datenregister registerLSB radenc datenregister registerMSB radenc 256 datenregister registerLSB radenc 256 SR INTO_vect Interrupt Routine fuer Radencoder PD2 ist INTO
204. t sim l t sich sein Verhalten virtuell testen Er besitzt die F higkeit seinen Standort zu bestimmen und erstellt eine Karte seiner Umgebung Mit seinem Maussensor wertet er seine Ausrichtung aus Durch seinen Radencoder l sst sich die zur ckgelegte Entfernung bestimmen Mit Hilfe seiner Infrarotsensoren erkennt er Hin dernisse und erstellt eine metrische Rasterkarte seiner Umgebung Zus tzlich besitzt der Roboter eine Abgrunddetektion Der Funktionsumfang des Projektes c t Bot umfasst das eigenst ndige Erkunden der Umgebung Slalom fahren und das Einsammeln von Golfb llen die an eine bestimmte Position gebracht werden Mit der entsprechenden Programmierung ist der Roboter allerdings auch in der Lage komplexere T tigkeiten auszuf hren Zu den beliebtesten Serviceroboter geh ren die Staubsaugerroboter Je nach Ausstat tung und Saugleistung gibt es sie in unterschiedlichen Preisklassen zu kaufen Die Roboter werden immer leistungsf higer und mittlerweile statten die Hersteller diese auch mit ei nem Treppensensorsystem aus das verhindert dass der Roboter Treppen herunterf llt Weiterhin fahren die meisten Roboter ihre Ladestation eigenst ndig an wenn der Akku leer ist Einige Firmen bieten ferner eine Absaugstation zur Entleerung des Filters an Zur Hinderniserkennung dienen entweder Drucksensoren am Geh use oder Ultraschallsensoren EINLEITUNG Ein Ersatz f r herk mmliche Staubsauger sind diese Roboter noch nicht Deshalb gibt
205. t stellt das Webinterface alle erfassten Sensordaten des Roboters dar darunter auch die von der Front und Bodenkamera aufgenommenen Bilder Des Weiteren ist ein Bild der internen Karte zu sehen welches durch die Kartenerstellung erzeugt wurde auf welcher die Position des Roboters abgebildet ist Dar ber befindet sich 38 PG 524 Endbericht SOFTWARE ein Men mit dem der Modus des Roboters in Routen Bahn und Aufgabenplanung gesetzt und ge ndert werden kann Soll der Roboter sich in keinem Modus befinden und somit zum Stillstand gebracht werden kann Kein Modus ausgew hlt werden Sobald die Routenplanung aktiviert ist ist es m glich dem Roboter per Klick auf die Karte neue Ko ordinaten zu bergeben welche er daraufhin anf hrt Au erdem besitzt der Roboter eine terminbasierte Aufgabenverwaltung Der Benutzer kann ber das Webinterface Aufgaben zu bestimmten Zeiten bzw Perioden konfigurieren und den Roboter automatisch dazu veranlassen die Bahnplanung zu starten mit der ein Raum komplett abgefahren wird PG 524 Endbericht 39 GRUNDLAGEN 40 PG 524 Endbericht 3 Hardware Mit Hilfe der Grundlagen aus dem zweiten Kapitel spezialisiert sich dieses Kapitel auf die Realisierung der Hardware des autonomen Staubsaugerroboters Im Folgenden werden Einzelheiten zum 12C Bus erl utert Ferner erfolgt ein berblick ber die Implementierung des Mikrocontrollers ATMega32 Bevor die Realisierung der Hauptplatine d
206. t wird i d R kleiner als 4 5V wird der Linux Kernel des Gumstix nicht vollst ndig gebootet weshalb immer eine ausreichend hohe Versorgungsspannung anzulegen ist Jedoch darf sie aus Sicher heitsgr nden wiederum nicht zu hoch ausfallen e Die WLAN Funktionalit t vom netwifimicroSD EU kann nicht korrekt benutzt wer den Vermutet werden neben Treiberproblemen auch evtl Hardware Fehler Proble matisch ist hierbei auch die Tatsache dass Support und Erfahrungsberichte seitens Hersteller und Privatanwendern im Internet nicht vorzufinden waren e Ein C Anschlu war auf allen drei Boards nicht direkt vorzufinden wobei die Schnittstellen in der Produktbeschreibung vorhanden sind Dieser Umstand konn te aber durch Neul ten von Pins des console vx Boards behoben werden e Die gumstix Boards besitzen keinerlei vorgefertigte Schutzschaltungen gegen erh hte beabsichtigt oder unbeabsichtigt auftretende Str me und Spannungen Gerade bei einem komplexen Projekt wie der Staubsaugerroboter es mit der Kombination aus Sensoren Aktoren und externen Stromquellen ist f hrt dies immer wieder zu mas siven Problemen und Gefahren f r die gumxstix Boards im schlimmmsten Fall zur vollst ndigen Zerst rung der Boards 2 1 2 Ultraschallsensoren Um Hindernisse rechtzeitig erkennen zu k nnen hat sich die Projektgruppe entschieden sechs Ultraschallsensoren f r ihren Staubsaugerroboter zu benutzen Die Sensoren befinden sich an den folgenden Positio
207. tdaten gelernt wird Zum zweiten die Klassifikationsphase in der das erworbene Wissen auf reale Daten angewendet wird 4 10 1 Training Das Training eines Klassifikationssystems ben tigt bei komplexeren Aufgaben meist eine sehr hohe Rechenleistung Es werden eine Unmenge an Trainingsdaten verwendet welche die Realit t in m glichst guter Art und Weise abbilden Im Falle einer Schmutzerkennung ist dies wie bereits weiter vorne erw hnt eine fast unl sbare Aufgabe Um diesem Pro blem zu begegnen wurde bei der Entwicklung des RAPTOR ein Trick angewendet Da eine Abbildung aller B den und Verschmutzungsarten in Form von Trainingsdaten nicht als M glichkeit zur Verf gung stand wird bei der Schmutzerkennung diese Trainingsphase in den laufenden Betrieb des RAPTOR integriert Dies ist m glich weil nur der aktu ell befahrene Boden analysiert wird und somit alle anderen Bodenbel ge von vornherein ausgeschlossen werden k nnen Dies stellt aber auch eine Anforderung an den Benutzer Das Training muss n mlich mit einem sauberen Boden absolviert werden denn es wird ein internes Modell dieses Bodens erstellt welches sp ter mit dem dann aktuellen Zustand verglichen wird Zu Beginn des Trainings wird ein Bild des Bodens erzeugt Auf Abbildung 4 25 ist zu erkennen wie ein solches aussieht Im n chsten Schritt wird von jedem Farbkanal 132 PG 524 Endbericht SCHMUTZERKENNUNG ein Histogramm erzeugt 14 Dieses Histogramm wird nun in einer
208. tehen die aktu ellen X und Y Werte in Registern die ber den seriellen Port abgefragt werden k nnen PG 524 Endbericht 23 GRUNDLAGEN S e HDINS 2200 Clip A lt HLMP ED80 xx000 ADNS 2610 Sensor lt Customer supplied PCB Customer supplied base plate with recommended aligament features per IGES drawing Abbildung 2 14 Bestandteile des optischen Maussensors 3 Sensor Clip Lens Light Pipe Base Plate e Surface A Abbildung 2 15 Aufbau und Funktionsweise der Optik des optischen Maussensors 3 24 PG 524 Endbericht HARDWARE 2 1 6 Kompasssensor Die Verwendung einer Karte f r die Navigation setzt eine zuverl ssige Positionsbestimmung des Roboters im Raum voraus Ein Maussensor liefert zwar die abgefahrene Strecke kann aber insbesondere auf glatten oder spiegelnden Oberfl chen ungenau sein Aus diesem Grund hat sich die Projektgruppe entschieden die Fahrtrichtung des Roboters zus tzlich ber einen Kompasssensor zu bestimmen Ein passendes Modul mit der Bezeichnung CMPS03 wurde bei der Firma Devantech 9 gefunden Im Vergleich zu Kompasssensoren anderer Hersteller zeichnet sich der CMPS03 durch geringen Preis fertigem Aufbau des Moduls und Einfachheit des Auslesens der Daten aus Dieses Modul ist speziell f r die Bed rfnisse von Robotern gestaltet worden Es ermit telt anhand des Erdmagnetfeldes die genaue Himmelsrichtung in 0 1 Grad Schritten Das Modul a
209. terrupt ausl st woraufhin sofort die Motoren gestoppt werden Da dieses Signal sehr wichtig ist und zuverl ssig erkannt werden muss wird hier sicherheitshalber kein interner PullUp Widerstand des Atmels verwendet sondern ein externer PullUp Widerstand eingesetzt Der Quelltext zur Konfiguration und Nutzung des Interrupts befindet sich im Anhang unter Listing B 6 Die eigentliche Aktivierung aller konfigurierter Interrupts per sei geschieht jedoch im Hauptprogramm Manchmal ist es notwendig die Motoren auch anzusteuern wenn ein Kontakt erkannt wurde dies ist beispielsweise der Fall wenn bei der Behebung der Kollision durch R ckw rts fahrt erwartungsgem erneut die Kontake ausl sen Dies ist jedoch ein absoluter Sonderfall und wird nur in Ausnahmef llen eingesetzt Radencoder Auch die Radencoder m ssen sofort bei Signalankunft behandelt werden ansonsten k nn ten Impulse w hrend das restliche Programm l uft verloren gehen Daher sind auch die Radencoder so an den Mikrocontroller angebunden dass sie bei Pegelwechsel einen Inter rupt ausl sen welcher dann sofort bearbeitet wird Listing B 7 dokumentiert die Ansteuerung der Radencoder Hierbei ist zu beachten dass jeder Radencoder Tick quasi mehrfach gez hlt wird e Urspr nglich waren die Radencoder als reine Countdown Z hler konzipiert Wenn eine vorher eingestellte Anzahl an Ticks abgefahren ist werden die Motoren ge stoppt Somit k nnen Streckenl ngen
210. treiber aus um die Rad und B rstenmotoren zu betreiben Die zwei A Eing nge pro Kanal bestimmen durch unter schiedliche Polarit t die Drehrichtung des Motors bei zwei gleichen Signalen LOW oder HIGH stoppt der Motor Zudem gibt es pro Kanal noch einen EN Eingang wodurch erst bei gesetztem HIGH Signal ein Stromfluss entsteht der den Motor vorantreibt Zur Span nungsversorgung besitzt der Baustein zwei Eing nge VCC1 und VCC2 VCCI liefert den Strom f r den Baustein selber w hrend durch den VCC2 Eingang eine externe Spannungs versorgung der Motoren realisiert werden kann Diese Funktionalit t wird ausgenutzt um den Motor mit den durch den gew hlten Akku maximal m glichen 12V zu betreiben Im Folgenden wird n her auf die Realisierung der Motoren auf der Hauptplatine einge gangen B rsten Die vorderen beiden B rsten haben eine festgelegte Motordrehrichtung die rechte B rs te dreht gegen den Uhrzeigersinn die linke B rste im Uhrzeigersinn Damit drehen beide B rsten nach innen um den Schmutz in die Richtung der Saug ffnung zu bef rdern Ab bildung 3 12 zeigt wie zum Festlegen der Drehrichtung die Eing nge 1A und 2A f r den linken Motor und 3A und 4A f r den rechten Motor geschaltet werden Somit ist es nicht mehr notwendig diese per Software zu steuern Ein weiterer Vorteil ist dass daf r keine zus tzlichen Pins am ATMega32 belegt werden Die Pins 1Y und 2Y werden mit Hilfe einer Steckverbindung ber Kabel an den
211. tzt jedoch einen integrierten Baustein USART f r serielle Kommu nikation er kann also einfach mit dem COM Port eines PCs verbunden werden Dennoch ist der direkte Anschluss nicht m glich Zwar verwendet der ATMega auch das RS232 Protokoll er nutzt dabei jedoch andere Pegelwerte RS232 und TTL Pegel Der serielle Port des PCs verwendet das RS232 Protokoll mit RS232 Pegeln e Ein logisches HIGH entspricht etwa 10V e Ein logisches LOW entspricht etwa 10V Auf der anderen Seite arbeitet der ATMega32 wie auch die meisten anderen ICs mit TTL Pegeln Transistor Transistor Logik PG 524 Endbericht 51 HARDWARE e Ein logisches HIGH entspricht P5V e Ein logisches LOW entspricht ON Damit ATMega und PC trotzdem miteinander kommunizieren k nnen muss ein Pegel wandler verwendet werden Der MAX232 ist ein Standardbaustein f r diese Aufgabe Verdrahtung des MAX232 Damit der Pegelwandler ordnungsgem funktioniert sind noch einige Kondensatoren n tig die genaue Beschaltung l sst sich in Abbildung 3 8 ablesen Abbildung 3 8 Verbindung zwischen ATMega und PC Anschluss am Controllerboard Da Debug Ausgaben allenfalls tempor r von Nutzen sind wurden auf den verwendeten Boards die Pegelwandler plus ihre Beschaltung nicht fest eingebaut Statt dessen wird eine vierpolige Steckleiste Tabelle 3 2 verwendet ber die ein Pegelwandlerboard kurzfristig angeschlossen werden kann Pin Belegung TxD AVR RxD PC R
212. u lassen Die erste M glichkeit ist im Buildroot den gcc und g compiler hinzu zu f gen und die Programme auf dem Gumstix zu kompilieren Die zweite L sung w re ein Cross Compiling Dazu wird im gleichen Verzeichnis in dem sich der Ordner gumstix buildroot befindet ein neuer Ordner angelegt und die Quelldateien des Programms in diesem Ordner eingef gt Als N chstes muss ein Makefile angelegt werden welcher den Inhalt aus Listing 4 8 enth lt In der ersten Zeile m ssen noch die Quelldateien hinzugef gt werden welche jeweils durch ein Leerzeichen getrennt sind In die dritte Zeile wird Namen der gew nschten Datei geschrie ben Sollte der eigene Quellcode komplexer sein und m ssen Bibliotheken hinzugef gt oder Include Pfade gesetzt werden so wird das Makefile um die entsprechenden Parameter er weitert Wenn alles stimmt kann der Kompiliervorgang mittels des Befehls make gestartet werden Es kann sein dass zu Beginn ein paar Fehlermeldungen auftauchen dass bestimm te o und oder bin Dateien nicht gefunden werden konnten Dies k nnte darin liegen dass zur Sicherheit bei jedem Kompiliervorgang alle o und bin Dateien gel scht werden Es PG 524 Endbericht 85 SOFTWARE kann bei minimalen nderungen vorkommen dass der Cross Compiler keine nderungen in den Quelltextdateien erkennt und nicht kompiliert Dies wird durch das Entfernen der o und bin Dateien erzwungen Die so entstandene Datei muss anschlie end nur noch
213. unabh ngig von der weiteren Implementierung der API Da es sich um eine Kapselung jeder einzelnen Funktion auf die immer gleiche Art und 114 PG 524 Endbericht APPLICATION PROGRAMMING INTERFACE Weise handelt wurde auf einer sehr abstrakten Ebene programmiert Der Gro teil der Thread Safe APT wurde in Pre Compiler Quelltext geschrieben was dazu f hrt dass der eigentliche Quelltext erst beim Kompiliervorgang erzeugt wird Dies hat zum Vorteil dass schnell neue Funktionen in die API aufgenommen werden k nnen indem das entsprechende Pre Compiler Macro benutzt wird Als Beispiel f r dieses Vorgehen dient im Folgenden die Funktion readSonar welche als Parameter die Angabe des gew nschten Ultraschallsen sors erwartet und den Messwert von diesem zur ckgibt Es wird das Pre Compiler Macro THREAD _SAFE_FUNCT1 verwendet Dieses wird f r Funktionen mit einem Parameter benutzt Die Angaben in den Klammern geben den Datentyp des R ckgabewertes den Funktionsnamen und den Datentyp des Parameters an 1 THREAD_SAFE_FUNC1 int readSonar int Listing 4 25 Pre Compiler Macro einer Funktion in der Thread Safe API Aus dieser einzelnen Zeile wird folgender Quelltext generiert l int thread_safe_api readSonar int para_name 2 1 3 if pthread_mutex_lock m mutex 0 4 cerr lt lt FEHLER API_Mutex Lock fehlgeschlagen lt lt endl 5 int rueckgabe real_api readSonar para_n
214. und die Befestigung der R der Auf der oberen Ebene ist beispielsweise das Controllerboard der USB Hub die Kameras sowie einige Sen soren wie der Kompasssensor und die Ultraschallsensoren angebracht F r den Aufbau der zwei Ebenen haben wir uns f r zwei runde Aluminiumplatten mit einem Durchmesser von 30cm entschieden und diese vom Institut f r Spanende Fertigung an der Technischen Uni versit t Dortmund herstellen lassen Die beiden Platten werden durch vier Metallstangen mit einem Durchmesser von 0 5cm verbunden Damit steht das Grundger st des Roboters Die Radkonfiguration sieht zwei R der und ein Kugelrad vor die an die untere Ebene montiert werden Der Durchmesser der R der betr gt jeweils 10cm und die Breite 2 5cm Sie werden auf den entgegengesetzten Seiten der Mittelachse der Kreisscheibe angebracht Dadurch kann sich der Roboter auch auf der Stelle drehen Das Kugelrad hat nur die Funk tion des St tzrades das im Gegensatz zu den zwei R dern nicht angetrieben wird Da die R der und Motoren sehr viel Platz auf der unteren Platte einnehmen wurden die meisten Komponenten auf der oberen Platte befestigt Um die Ecken eines Raumes gut s ubern zu k nnen wurden zwei kleine B rsten mit einem Durchmesser von 5cm gekauft Diese befinden sich vorne an der unteren Platte F r den Fall dass der Roboter nicht rechtzei tig bremst und doch gegen einen Hinderniss f hrt wurde eine Sto stange an der untere Platte des Roboters angebracht Hi
215. ung verwendet werden k nnen auf der anderen Seite aber auch auf verschiedene hilfrei che Zusatzfunktionen umgeschaltet werden k nnen So ist es beispielsweise m glich an bis zu vier verschiedenen Ausg ngen ein PWM Signal bereit zu stellen ohne diese Ausg nge st ndig softwaregesteuert umschalten zu m ssen Zun chst wurde im RAPTOR lediglich ein einzelner ATMega32 eingesetzt Im Laufe der Projektgruppe wuchsen jedoch die Anforderungen an die Hardware so dass bei einer sp teren Version des Controllerboards zwei Mikrocontroller dieses Typs eingesetzt werden Die Verteilung der Funktionen auf die Mikrocontroller erfolgte nach Anbringung der dazu n tigen Aktoren respektive Sensoren Beispielsweise werden die Motoren Radencoder und der Maussensor ber den gleichen ATMega32 angesteuert weil sie alle auf der unteren Platte des RAPTORs liegen Die Ultraschallsensoren hingegen werden von einem anderen ATMega32 angesteuert sie sind an der oberen Platine befestigt Urspr nglich sollten die beiden Mikrocontroller auf seperaten Boards agieren welche dann auch direkt an der dazugeh rigen RAPTOR Ebene befestigt werden dabei w ren nur sehr wenige Kabel zur Verbindung der beiden Platten n tig gewesen Aus Platzgr nden wurde diese Idee jedoch verworfen und k nnte allenfalls in einer noch sp teren Version umgesetzt werden Weitere technische Details zum Mikrocontroller selbst befinden sich in der Hardwarebe schreibung und in den Programmierbeispi
216. unteren Ebene angebracht Ein Bumper ganz vorne die restlichen 4 jeweils zu beiden Seiten der B rstenmotoren Die Sto stange wurde vor dem Bumper an der unteren Platte befestigt Zus tzlich dienen zwei Federn dazu die Stange nach einem Zusammensto mit einem Hinderniss in ihre urspr ngliche Position zu bringen Die Skizze A 1 zeigt an welcher Position die Bumper und die Sto stange angebracht sind Befestigung der Abgrundsensoren Um Abgr nde wie beispielweise Treppen oder Tischkanten zu erkennen wurden drei Licht sensoren angebracht Einer wurde vorne an der unteren Platte angebracht die anderen beiden jeweils vor einem Rad mit einem Abstand von 3mm zum Boden Die Abbildung A 2 zeigt an welcher Position die Lichtsensoren angebracht worden sind Befestigung der Radencoder Mit Hilfe der Radencoder kann der Roboter die zur ckgelegte Wegstrecke bestimmen oder eine bestimmte Strecke geradeaus fahren F r den Aufbau wurde an jedem Rad eine Taktscheibe angebracht Eine Scheibe besteht aus 24 schwarzen und 24 wei en Streifen die kreisf rmig angeordnet sind Auf jede Taktscheibe ist ein Lichtsensor gerichtet Die Lichtsensoren z hlen bei einer Raddrehung die Streifen der Taktscheiben Daraus kann die Anzahl der Radumdrehungen und damit auch die zur ckgelegte Distanz berechnet werden 3 6 2 Die obere Ebene In diesem Abschnitt wird die Bearbeitung der oberen Ebene beschrieben Dazu geh rt die Befestigung der Ultraschallsensoren des K
217. von 100 Bildern der Bodenkamera 134 Gelernte Normalverteilung der Bodenbild Histogramme 134 Untere Ebene von oben aus gesehen e 141 Untere Ebene von unten aus gesehen 142 Obere Ebene von unten aus geschen 143 170 PG 524 Endbericht Abbildungsverzeichnis A A Obere Ebene von oben aus gesehen oaoa a a 144 AA Schaltung der Maussensorplatine e war ar Ee EEN 146 A 6 Schaltplan der Hauptplatine e ad za wer rest 147 A 7 Schaltplan des RS232 BC Adapters sc 2er 0 esse 148 A 8 Layout der Maussensorplatine 149 A 9 Layout der Oberseite der Hauptplatine 150 A 10 Layout der Unterseite der Hauptplatine 2 2 2 2 nn nenn 151 PG 524 Endbericht 171 Abbildungsverzeichnis 172 PG 524 Endbericht Tabellenverzeichnis 2 1 Registerbelegung des Kompassmoduls e 26 3 1 Die Pinbelegung verschiedener Stecker 2 2 22 49 3 2 Die Pinbelegung des RS232 Boardsteckers 52 173 Tabellenverzeichnis 174 PG 524 Endbericht Literaturverzeichnis H 10 11 12 13 14 15 16 Bewegungserkennung in Bildfolgen eim mehrstufiger Ansatz mit einem Geleitwort von H Niemann amp Harald Kirchner Wiesbaden Deutscher Universitaets Verlag 1993 3000 K RCHER ROBOCLEANER RC http www karcher de de Produkte Privat Home_Cleaning Robocleaner 12691010_ Deta1linfs htn AGILENT TECHNOLOGIES http www agilent com ATMEL http www atmel
218. wendungen reichen diese 114 Adressen nicht aus Es gibt daher neben der M glichkeit mehreren Slaves die gleiche Adresse zu geben inzwischen auch eine erweiterte 10 Bit Adressierung Da im RAPTOR nur vier Teilnehmer und nur drei Slaves am Bus betrieben werden sollten wurde eine Einarbeitung in diesen Bereich nicht als notwendig angesehen Da von einem Datenbyte nur die ersten 7 Bit f r die Adresse ben tigt werden wird mit dem achten Bit die Datenrichtung ausgew hlt e Ist das Bit gesetzt so wird lesend auf den Slave zugegriffen Der Master befindet sich im Master Receiver Modus der Slave wird in den Slave Transmitter Modus geschaltet e Ist das Bit nicht gesetzt so wird schreibend auf den Slave zugegriffen Der Master PG 524 Endbericht 45 HARDWARE befindet sich im Master Transmitter Modus der Slave wird in den Slave Receiver Modus geschaltet Das neunte Bit ist dann wie schon erw hnt das ACK Bit Hiermit best tigt der Slave dass er seine Adresse empfangen hat und einsatzbereit ist 120 sieht auch eine M glichkeit vor allen Slaves am Bus eine Nachricht zukommen lassen General Call Hierbei senden dann alle Slaves ein ACK In manchen Beispielquelltexten f llt auf dass dort als Adresse ein Wert ber 127 steht obwohl nur eine 7 Bit Adressierung verwendet wird selbst im Kompass Datenblatt steht geschrieben der Kompass h tte die Adresse 192 Da die Datenrichtung mit der Slave Adresse als ein Byte
219. wird Zum besseren Verst ndnis folgt eine Liste mit der Beschreibung der Pinbelegung F r weitere Details des Bausteins wird hier auf den Abschnitt 3 2 verwiesen Die 32 I O Pins k nnen in acht verschiedene Bereiche eingeteilt werden 1 Analog Digital Wandler e PAO bis PA7 ADCO bis ADC7 sind Eingabepins f r analoge Messungen 2 Analog Komparator e PB2 AINO ist ein externer Eingang des Analog Komparators INT2 ist eine externe Interrupt Leitung e PB3 AINI folgt analog zu AINO OCO kann als Ausgang f r Z hlerO verwendet werden Beispiel PWM Modus 3 SPI Schnittstelle e PB4 SS geh rt zum SPI Interface dieser wird ben tigt um den richtigen Slave am Bus zu w hlen e PB5 MOSI geh rt zum SPI Interface dieser Datenausgang als Master oder Dateneingang als Slave wird bei In System Programmierung ISP verwendet e PB6 MISO geh rt zum SPI Interface dieser Dateneingang als Master oder Datenausgang als Slave wird bei ISP verwendet e PB7 SCK geh rt zum SPI Interface dieser Bustakt vom Master wird bei ISP verwendet 4 Timer und PWM e PBO TO kann als Taktgeber f r die Z hler 0 und 1 verwendet werden TCK als externer Taktpin f r synchrone USART Ubertragung e PB1 T1 kann als Taktgeber f r die Z hler 0 und 1 verwendet werden e PD4 PD5 OCIA OCIB k nnen als Ausg nge f r den Z hlerl verwendet werden beide Pins sind an einem Z hler es sind aber dennoch verschiedene Signale m glich Beispiel PWM e
220. xD AVR TxD PC GND P5V zur Speisung des Pegelwandlers Aj N Tabelle 3 2 Die Pinbelegung des RS232 Boardsteckers Ausgabe im Programm Um Daten w hrend des Programmablaufes auszugeben m ssen die USART Register des Mikrocontrollers direkt angesprochen Vor der ersten Kommunikation ist eine Initialisie rung der Baudrate und anderen Werten wie Stoppbit und Parit tskontrolle n tig Zur 52 PG 524 Endbericht ATMEGA32 Vereinfachung wurden diese Methoden in eine eigene Datei siehe Listing B 1 ausgeglie dert Verbindung am PC Am PC wird nun das bevorzugte Terminalprogramm verwendet beispielsweise minicom unter Linux oder HyperTerminal unter Windows Dabei ist zu beachten dass bei Fluss kontrolle weder Hardware noch Software eingestellt ist 3 2 3 Ansteuerung der verwendeten Hardware Im Folgenden soll dokumentiert werden wie die im RAPTOR verwendeten Sensoren und Aktoren vom Mikrocontroller angesprochen und ausgelesen werden k nnen Ultraschallsensoren Wie schon in Abschnitt 2 1 2 dokumentiert muss zun chst ein Trigger Impuls ausgesen det und anschlie end die L nge eines Echo Impuls gemessen werden Um Pins zu sparen werden die Ultraschallsensoren im zweiten Modus betrieben dies hat zudem den Vorteil dass ein bestimmter Ultraschallsensor allein durch einen Pin am Controller vollst ndig identifiziert werden kann Die Programmroutinen befinden sich im Anhang unter Li
221. ytes ben tigt aber der zur ckgegebene Wert ist deutlich intuitiver sowie noch Register f r Kalibrierung und andere Informationen Um die aktuelle Ausrichtung als Dezimalgrad zu erhalten wird zun cht eine 2 Auswahl des Registers an das Kompassmodul gesendet und anschlie end eine lesende Daten bertragung gestartet 46 PG 524 Endbericht ATMEGA32 SendeStartBedingung SendeAdresseMitSchreibeModus SchreibeDaten 2 SendeRepeatedStart SendeAdresseMitLeseModus LeseDaten 2 Byte SendeStoppBedingung NSNOOPrWMnNnHM Listing 3 1 Kommunikation mit dem Kompassmodul 3 1 7 Clock Stretching An einem C Bus m ssen Komponenten mit unterschiedlicher Geschwindigkeit arbeiten k nnen daher musste eine M glichkeit gefunden werden den Bus f r langsamere Teilneh mer anzuhalten Diese M glichkeit findet sich beispielsweise im Clock Stretching Wenn der Slave an einem gewissen Punkt in der bertragung nicht bereit f r das n chste Datenbyte ist dr ckt er die SCK Leitung auf GND bis er wieder bereit ist Somit wird verhindert dass der Master den n chsten SCK Impuls sendet zumindest wenn der Master Clock Stretching unterst tzt Der ATMega32 unterst tzt Clock Stretching Wenn beispielsweise ein Datenpaket einge troffen ist wird ein entsprechendes Flag gesetzt Die SCK Leitung wird erst dann wieder freigegeben wenn das Programm es explizit erzwingt Der Programmierer hat somit ausrei chend Zei

PG524-RAPTOR: Endbericht - Lehrstuhl 12

Contents

Download Pdf Manuals

Related Search

Related Contents