RoboCup 2014: Überarbeiteter Roboter Teil 1: Hardware

Wie schon im letzten Beitrag von kurz nach den deutschen Meisterschaften, die jetzt schon fast drei Monate her sind, erwähnt, haben wir uns in letzter Zeit intensiv mit einer überarbeiteten Version unseres Roboters beschäftigt. Wir haben aus unseren Fehlern gelernt:

  • Keine LEGO Teile mit einem Selbstbau kombinieren:
    Wir dachten, wir hätten mit den LEGO Teilen insofern einen Vorteil, dass man sehr flexibel ist und einfach Teile auswechseln kann, beim Wettbewerb vielleicht bei anderen Teams fragen könnte, aber das (zum Glück) nicht nötig. Man ist mit den recht großen und klobigen LEGO Teilen eher recht unflexibel. Außerdem sind die LEGO Motoren nicht so robust, wie eigentlich gedacht – Nach zwei Jahren Betriebszeit kann da schon mal ein Motor kaputt gehen (indem er einfach von jetzt auf gleich blockiert).
  • Alles durchplanen:
    Wir haben bei unserem letzten Roboter nicht von Anfang an alles berücksichtigt und den Roboter bzw. nur die Aluminiumteile auf Papier geplant. Wenn man etwas erweitern möchte, muss bzw. mussten wir „aufstocken”, also unschön noch einen riesen Sensorkopf oben drauf setzen, weil einige Sensoren nicht eingeplant waren. Dieses Mal haben wir alles mit CAD durchgeplant – dazu später mehr.
  • Sollte eigentlich selbstverständlich sein, dazu hatten wir aber letztes Jahr, wie man gesehen hat (und wir auch gefühlt haben) keine Zeit mehr:
    Jeden Fall berücksichtigen und immer vom schlimmsten Fall ausgehen. Wenn einmal etwas schief läuft, kann es immer wieder passieren, d.h. jeden Fehler, egal, wie klein oder wie groß er ist, ernst nehmen.

Es hab da noch ein paar Kleinigkeiten, auf die hier nicht näher eingegangen wird.

Jetzt endlich zum neuen Roboter: Der alte Roboter war ja nicht komplett „falsch” (wie im Video zu sehen). Im Gegenteil, vieles hat sehr gut funktioniert! Problem war, dass wir vor den deutschen Meisterschaften zu wenig Zeit hatten, ein Eingriffsprogramm zu entwickeln (insgesamt waren wir bis Ende 2012, also zwei Monate vor dem ersten Wettbewerb, mit der Hardware beschäftigt). Natürlich darf auch das beim Wertungslauf nicht passieren, aber wie gesagt: Immer vom schlimmsten Fall ausgehen. Anfangs, direkt nach dem Wettbewerb, haben wir die Schuld auf die relativ Leistungsschwache Elektronik geschoben und wollten unbedingt auf was schnelleres umsteigen (Mikrocontroller mit ARM Kern (32bit), wir benutzen einen AVR (8bit) – Vor allem Speicherplatz und Geschwindigkeit waren verlockend, aber auch der sinnvolle Einsatz von C++. Außerdem sind ARMs zeitgemäß und werden immer öfter eingesetzt). Wir haben uns jedoch letztlich dagegen entschieden, wobei natürlich der finanzielle Aspekt keine kleine Rolle gespielt hat.
Bei guter Programmierung ist das System egal. 😉

Bei der Mechanik und speziell beim Fahrwerk musste aber unbedingt etwas passieren. Der alte Roboter war, da er komplett „handgefertigt” war, mehr oder weniger krumm und schief. Das hat es unmöglich (da eben (für uns) unberechenbar) gemacht, den Roboter 100%ig zuverlässig durch das Labyrinth fahren zu lassen. Deshalb haben wir uns wie gesagt für die Planung am Computer via CAD entschieden. Basismaterial, also das Chassis, sollte aus Plexiglas bestehen: Billig, leicht zu bearbeiten, extrem robust. Das Plexiglas sollte aber nicht von Hand bearbeitet, sondern Lasergeschnitten werden. Preislich macht das fast keinen Unterschied. Dafür hat man dann ein perfektes Ergebnis.

Plexiglasplatten halb transparent – unten Chassis (6mm Stärke) zur Aufnahme der Motoren und sämtlicher Elektronik, oben die „Bumperplatte” (3mm Stärke), die zur Begrenzung des Roboters und zum Befestigen der Sensoren und der Bedieneinheit dient.

Probleme hatten wir auch mit dem Schwerpunkt des Roboters, was mit den LEGO Motoren aus Kunststoff zusammenhing. Für den neuen Roboter nutzen wir „richtige“ Metallmotoren – vier Stück an der Zahl (das Konzept mit dem Allradantrieb hat sich bewährt, auch bei anderen Teams). Dabei werden später zwei Motoren pro Seite parallel angeschlossen, damit die alte Elektronik weiterverwendet werden kann. Der Akku befindet sich später zwischen den Motoren – so weit wie möglich unten.

Vier Motoren, griffige Räder, ein Akku in der Mitte

Wie oben bereits erwähnt, sollte die Elektronik und das Sensorkonzept vom letzten Jahr weiterverwendet werden. Die Elektronik hat allerdings nun zwei Schwachstellen:

  1. Wir haben letztes Jahr vergessen, quasi das gesamte „Power Management” mit auf die Platine zu setzen, dazu zählen eine Sicherung (deshalb ist uns bei einem Kurzschluss des Akkus schon einmal eine Leiterbahn verbrannt, die wir zum Glück überbrücken konnten) und der Spannungsteiler zum Messen der Akkuspannung.
  2. Die Aufteilung der zwei Motoranschlüsse auf vier Motoren
Platinenansicht

Platinenansicht auf 1. Ebene: Von links n. rechts: IMU – Mainboard – Power Unit

Deshalb haben wir uns dazu entschieden, für ein paar € dafür eine eigene Platine zu erstellen. Es ist zwar möglich, das Ganze irgendwie fliegend aufzubauen, aber da zu erwarten ist, dass so oder so viele Kabel verlegt werden müssen, macht das ein Debugging bei fehlerhafter Hardware später schwierig bis unmöglich. Auf der Platine befinden sich die oben erwähnten Einheiten. Da wir die Motoren parallel schalten, müssen sich die Motoren auf einer Seite gleich schnell drehen, weshalb auch nur ein Encoder pro Seite ausgewertet werden muss.

Power Unit – rohes Platinenlayout

Das Sensorkonzept hat uns sehr gut gefallen und sollte gleich bleiben: Pro Seite zwei Sensoren (einer vorne, einer hinten) zum Ausrichten, dann noch pro Seite ein Sensor in der Mitte zum Geradeausfahren bzw. Erstellen der Karte. Die IMU hat auch sehr gut funktioniert und wird weiter benutzt. Genau so das Display, dazu im nächsten Artikel aber mehr.

Roboter: Komplettansicht. Die vier Kegel stellen den Öffnungswinkel der Wärmesensoren dar.

Die nötigen Teile für den Roboter sind bereits bestellt, wahrscheinlich wird die Hardware also gegen Ende der Sommerferien (ca. 2 Wochen) stehen.
Lediglich der Sensor zur Erkennung der schwarzen Flächen fehlt noch. Wir haben schon eine Idee parat, dazu aber mehr, wenn es so weit ist.

CAD-Software