Themen:

AVR, avr-gcc, CAN, CPLD, Elektronik, Mikrocontroller, MSP430, PIC, Roboter, Schaltungen, Sensoren, Software, Testboards

Peter

Tags: Roboter
Stand: 1. August 2006, 22:12
bisher keine Kommentare

Peter ist die Weiterentwicklung meines ersten Roboters und beseitigt eine ganze Menge seiner Schwächen. Vor allem die höhere Ausführungsgeschwindigkeit aufgrund des verwendeten AVR Controllers von Atmel anstatt der C-Control hat einige Verbesserungen gebracht.

Außerdem besitzt dieser Roboter wesentlich schnelle Motoren als sein Vorgänger und ist dadurch wesentlich spritziger und wendiger. Er besteht aus mehreren Ebenen von runden Aluminium Platten. Im Moment ist es nur eine, kann aber im Prinzip beliebig erweitert werden. Das ganze Chassis ist durch diese Bauweise sehr stabil.

Funktion Wert
Abmessungen (L/B/H): 200 x 200 x 150 mm
Gesamtgewicht: ca. 1kg
Prosessor: AT90S8535
Sensoren: GP2D12 auf Schrittmotor
Antrieb: 2x RB 35 Getriebemotoren
Geschwindigkeit: k.a. (aber schon schnell)
Spannungsquelle: 10 Zellen 1700mAh NiMH (insgesamt 12V)
Max. Dauerbetrieb: k.a.

Außerdem ist der GP2D12 jetzt im Gegensatz zu meinem ersten Roboter vorne auf einem Schrittmotor gelagert und kann so auch kleinere Gegenstände sicher erkennen. Der Schrittmotor wird vermutlich demnächst durch ein Servo ersetzt, da ein Servo das Problem der Positionierung nicht hat. Soll heißen, dass man bei einem Schrittmotor erst einmal feststellen muss, wo genau er sich befindet. Daher sollte im Betrieb ab und zu die Position überprüft werden, damit keine falschen Informationen entstehen. Wir wollten das zuerst durch einen Kontakt lösen. Der Schrittmotor würde dann bei der Initialisierung sich solange in eine Richtung drehen, bis der Kontakt geschlossen ist. Leider hat das nicht zuverlässig geklappt, da Schaltpunkt des Kontakts zu ungenau war. Daher musste man immer vor dem Einschalten den Schrittmotor in die Mittelstellung drehen. Natürlich keine Optimale Lösung.

Die Motoren sind RB 35 Getriebemotoren von Conrad. Diese haben sich recht gut bewährt, da sie schnell und kraftvoll genug waren. Um die Motoren zu befestigen haben wir die Befestigungswinkel benutzt die zu den Motoren angeboten wurden. Im Nachhinein war das aber keine gute Entscheidung, da die Winkel zum einen recht teuer waren und dann überhaupt nicht gepasst haben. Ich musste sie erst um ein ganzes Stück aufweiten bis die Motoren sich befestigen ließen. Ein Problem war eine ganze Weile die Befestigung der Räder die direkt auf den Motorwellen sitzen sollten. Wir haben dann schließlich einfach zwei Holzscheiben genommen, Modellbaureifen darüber gezogen und zur Befestigung zwei Zahnräder daran geklebt. Über den Flansch des Zahnrades kann man die Konstruktion dann an der Welle des Motors befestigt werden.

Gesteuert wird Peter im Moment noch komplett durch einen AT90S8535 von Atmel gesteuert. Das soll aber demnächst geändert werden. Von der Konzeption her war Peter aber als eine Multiprozessorplattform geplant.
Die meisten Sensoren sind an den Motorcontroller angeschlossen. Dieser werte diese dann aus und schickt die Daten an den Zentralrechner. Der erstellt dann aus den Informationen in dem RAM eine Karte der Umgebung. Nach dem er die Sensorinformationen ausgewertet schickt er wiederum dem Motorcontroller einen Nachricht und sagt ihm wo hin er fahren soll.

Als Zentralrechner sollte zuerst ein AT90S8515 mit 32KByte externem RAM zum Einsatz kommen. Allerdings wurde die Planung später zugunsten eines ATmega128 mit 512 KByte angepasst, da wir damit rechneten das die Informationen für die Karte wahrscheinlich schnell die 32 KByte überschreiten würden. Außerdem hätte man mit dem ATmega auch noch sehr viel mehr Programmspeicher zur Verfügung gehabt (128 kByte statt der 8 kByte des AT90S8515), sodass die Programme auch ein bisschen größer werden können. Das Ganze wurde dann allerdings aus Zeitgründen nie verwirklicht, da ein Multiprozessorsystem wesentlich mehr Aufwand bedeutet hätte und uns diese leider nicht zu Verfügung stand, da Peter zum Teil auch für die Projektphase im Informatikunterricht der Stufe 11 gebaut wurde und so zu einem bestimmten Zeitpunkt fertig sein musste. “Zum Teil” soll heißen das wir eigentlich schon vorher an ihm gebaut und programmiert hatten und ihn dann einfach als Projekt missbraucht haben. Warum soll man was anderes machen wenn man dadurch auch in den Informatik Stunden am Roboter weiter bauen darf? Das einzige was wir zusätzlich machen mussten war eine Präsentation zu erstellen. Und so haben wir dann auch 15 Punkte für das Projekt bekommen. Was will man mehr?

Das Programm das im AT90S8535 ausgeführt wurde sah so aus, dass der Roboter solange geradeaus fährt bis er auf ein Hindernis trifft. Dabei schwenkt er ständig vorne den Infrarotsensor. Wenn er jetzt ein Hindernis erkennt dreht er sich solange von ihm weg bis er es nicht mehr sieht und setzt dann seine Fahrt fort. Mit diesem vom Prinzip her sehr einfachen Programm lässt sich schon eine erstaunliche Autonomie erreichen. Der Roboter konnte selbst in sehr engen Räumen fahren und erkannte aufgrund des Schenkens des Infrarotsensors selbst schmalste Hindernisse.
Das Programm wurde erst in Assembler geschrieben, dann aber doch noch einmal komplett neu in C für den AVR-GCC Compiler entwickelt, da es sich als relativ schwierig herausstellte zu zweit ein Assemblerprogramm zu schreiben. In C war das dann einfacher, da man dort wesentlich strukturierter Programmieren kann.

Wir haben Peter mittlerweile wieder aufgegeben zugunsten unseres neusten Projektes. Es hat sich gezeigt, dass zum einen das Schwenken des Distanzsensors mit einem Schrittmotor keine so gute Lösung war (jedenfalls in der Form in der wir es verwirklicht hatten), da man keine Rückmeldung über die Position des Schrittmotors bekam. Das heißt man müsste am Anfang und nach bestimmten Zeitabschnitten feststellen, wo sich der Schrittmotor befindet. Das ganze war uns dann aber zu kompliziert, sodass beim nächsten Projekt ein Servo zum Einsatz kommen wird.

Controllerboard

Außerdem war der Antrieb nicht sonderlich gelungen, da wir zum einen an der Hinterseite eine ganze Menge zusätzliches Gewicht anbringen mussten, da der Roboter ohne beim Anhalten immer nach vorne kippte. Und das obwohl schon der Akku in der hinteren Hälfte seinen Platz hatte. Das andere Problem war die geringe Bodenfreiheit. Der Roboter hat es zum Beispiel nicht geschafft über eine Teppichkante zu kommen, da er hinten ständig mit dem Möbelgleiter hängen blieb.

Das Hauptargument das gegen eine Erweiterung von Peter gesprochen hat war dann letztendlich die schlechte Raumaufteilung die wir vorgenommen hatten, so dass wir nur noch wenig Platz für Erweiterungen hatten. Außerdem waren die Platinen relativ schlecht geätzt und weigerten sich so ab und zu das zu machen was sie sollten. Daher wurde Peter wieder zerlegt und die Sensoren und Motoren in einem neuen Roboter weiterverwendet.

Zum Anfang

Deine Meinung:

  • Textformatierung ist mit Markdown möglich.
  • HTML wird entfernt.
  • Kommentare werden moderiert und sind daher eventuell nicht sofort sichtbar.
  • Irrelevante Kommentare werden gelöscht.