Autor: Markus Knapp

Schematischer Aufbau direcs1

Auf dieser Seite ist der aktuelle schematische Aufbau des Roboters direcs1 dargestellt:

Stand: 04.04.2011

 

3D-Kompass-Modul-Verbindung wird geprüft und in GUI angezeigt

Beim Testen des Atmelboards außerhalb des Roboter fiel auf, dass es manchmal bei der seriellen Übertragung nach einiger Zeit timeouts gab. Die Ursache lag im Atmelcode für den Micromag 3D-Kompass. Dieser initialisiert beim ersten Start des Atmels das SPI / I²C Protokoll. Danach fragt das direcs-Hauptprogramm den Atmel nach den Kompassdaten. Ist das Kompassmodul aber nun gar nicht mit dem Atmelboard verbunden, so kommt es zu den timeouts, da im SPI-Code auf bestimmte Bitzustände gewartet wird.

Um dieses zu verhindern und hiermit auch eine weitere Sicherheit einzubauen, wird nun beim Abfragen der Kompasswerte jedesmal geprüft, ob ein bestimmtes Portbit gesetzt ist. Dieses Portbit ist durch einen 100k-Widerstand am Atmelboard standardmäßig auf Masse gezogen. Wird das Kompassmodul nun per Falchbandkabel angesteckt, wird diese Leitung vom Kompassmodul aus auf 5V "hoch gezogen". 

Bei der Initialisierung des Atmelboards bzw. der Prüfung ob der Roboter eingeschaltet ist im direcs-Hauptprogramm, wird nun auch zusätzlich abgefragt, ob das Kompassmodul verbunden ist. Dieses wird auch in der GUI grafisch mit einer weiteren LED (rechts oben im Bild) angezeigt.

Atmel-Board gar nicht verbunden (Kompass damit natürlich auch nicht):

Atmel-Board verbunden, Kompassmodul nicht angeschlossen:

Atmel-Board verbunden, Kompassmodul ebenfalls angeschlossen:

 

ASIMO Vorführung im Miraikan in Japan 2010

Hier ein Video der ASIMO-Vorführung. Im Großen und Ganzen sicher nicht sehr aufregend, da die Veranstaltung sich eher an Kinder richtete. Leider ist das Video nur in iPhone (3GS) Qualität, da zum Zeitpunkt der Aufnahme leider keine andere Videokamera verfügbar war.

Man kann aber gut die Bewegungsfreiheiten des von Honda entwickelten Roboters erkennen. An einer Stelle des Videos erkennt er einen vor sich liegenden Fußball und bei Minute 06:00 rennt er sogar ein kurzes Stück. Letzteres ist für einen Roboter in der Tat um so erstaunlicher, da er beim Rennen kurze Zeit nur auf einem Bein läuft und – wie beim Rennen eben üblich – kurze Zeit eben auch gar keinen Bodenkontakt hat. Dieses ist natürlich extrem kurz (80 ms) und im Video nicht so erkennbar aber hier beschrieben (pdf).

(Dauer: 10:58 Minuten)

 

Alle Fotos, die wir parallel vor Ort gemacht haben, findet ihr übrigens hier!

 

Montage des ersten Rad-Encoders

 Um die Zeit nach dem fit-PC-Tod zu überbrücken, wurde der erste zum Testen mal ein Rad-Encoder montiert. Dazu wurde als erstes eines der Räder vollständig mit Achse entfernt:

Wie zeichnet man nun mitten auf der 10mm Stahlachse einen Punkt ein. Gelöst wurde dieses ganz gut, durch ein paar Linien auf einer transparenten Folie. Durch diese wurde dann die Achse angekörnt und ein 2,5 mm Loch hinein gebohrt:

 

 

Normalerweise wäre jetzt das Loch auch in der Mitte gewesen, aber leider drückt sich aufgrund der Härte des Stahls beim Bohren der Werkstoff nach unten womit das Loch dann leider nicht mittig wurde. So oder so sieht das ganze mit 3m Gewinde dann so aus:

    

Macht aber nichts. Mit zwei Unterlegscheiben, längerer Schraube und Mutter wurde nun die Encoderscheibe befestigt:

    

Diese wurde nun auf der Achse montiert, in dem die 3mm Schraube in das neue Gewinde geschraubt wurde. Da der Innendurchmesser der Encoderscheibe größer als 3mm ist, konnte diese recht gut wieder mittig justiert werden:

  

Und so sieht das ganze dann wieder komplett montiert aus. auf dem letzten Bild liegt zu Testzwecken bereits die Gabellichtschranke, die dort später "irgendwie" montiert werden muss:

   

 

 

Analyse der fit-PC2 Probleme – Teil 3 (vor fit-PC-Tod)

 Bei der abschließenden(?) Suche der USB-Probleme wurde noch einmal rekapituliert:

  1. Das Problem besteht, wenn das Atmel-Board mit dem fit-PC2 verbunden ist.
  2. Das Problem besteht nicht, wenn das Atmel-Board mit einem anderen Gerät verbunden ist (Linux-Laptop oder iMac).
  3. Und, ja, und? Das Problem besteht ja auch nicht, wenn der fit-PC2 weiter weg steht. Wie man hier im Video ja sieht.

Ist es also ein Störungsproblem durch irgendwelche Abstrahlungen? Interferenzen? Zum Testen, wurde wieder alles wie im Video angeschlossen und der fit-PC wieder in die Nähe des Roboter gebracht:

Ergebnis? Fehler wieder da:

Aber was sollte hier nun noch stören? Die Motoren waren ja mittlerweile entstört. Da sich "irgendwelche Störungen" schwierig messen lassen, kam der Verdacht auf, dass es vielleicht ein Masse- oder Potentialproblem sein könnte. Also blieb der fit-PC nun an seiner Position und wurde durch ein Stück Pappe provisorisch vom Chassis des Roboters getrennt:

    

Und siehe da: Das Problem trat tatsächlich nicht mehr auf!!

Um nun die leitende Verbindung zwischen fit-PC und Roboter-Chassis endgültig zu trennen, wurde als erstes eine transparente Klebefolie auf der tragenden Aluminiumschiene aufgebracht. Diese Folie ist eigentlich eine Folie um per Laserdrucker Aufkleber herzustellen. Diese wurde hier einfach zweckentfremdet:

Anschließend wurden die Metallschrauben, welche die Aluschiene mit dem fit-PC verbanden noch durch 3mm Kunststoffschrauben und -Unterlegschreiben ersetzt:

Und? Das Ergebnis? Leider unbekannt, denn ohne Vorwarnung lässt sich der fit-PC plötzlich nicht mehr einschalten und scheint einfach so und ohne Vorwarnung defekt zu sein. Wenn alles schlecht läuft, gilt auch die seit genau zwei Monaten offiziell abgelaufene Garantie nicht mehr.  Das ist gerade in Klärung… 

Diverse Kleinigkeiten

 Um zwischendurch mal etwas anderes am Bot zu machen und nicht nur ewige USB-Problemezu analysieren, wurden ein paar kleine Hardware-Anpassungen durchgeführt. So wurde der nach außen geführte Ein-Aus-Schalter mit einer Buchse-Stecker-Verbindung versehen und die Schaltreglerplatine (24V auf 12V) etwas verkleinert, damit sie mehr Platz an den Front-USB-Buchsen des fit-PC2 freigibt:

   

Und endlich endlich wurde mal die Schalter auf dem Control-Panel beschriftet: 

Unterstützung für Joysticks unter Mac OS X fertiggestellt, noch immer Unterbrechungen durch Stromspitzen

 Heute wurde die Unterstützung für Joysticks unter Mac OS C fertiggestellt. Alle Funktionen sind wie unter Linux. Genutzt wurde C++-Code, der die HID-Devices ausliest und prüft, welches HID ein Joystick ist.

Das ist übrigens der verwendete Joystick, na ja, eigentlich ein Gamepad:

 

Erste Tests haben ergeben, dass trotz 10A-Netzteil und "aufgebocktem" Roboter noch immer die Spannung beim "Losfahren" kurz zusammenbricht (Spitzenstrom). Daher wird der nächste Schritt die komplette Überarbeitung des "seriellen Protokoll" sein mit der der PC/Mac Daten mit dem Atmel austauscht. Denn durch den genannten winzig-kurzen Zusammenbruch der Spannung verliert der Atmel kurzzeitig die Stromversorgung und "antwortet" dem PC/Mac nicht mehr. Hier ist also noch so etwas wie ein ACK, Heartbeat o.ä. nötig.