Wie es aussieht, ist der fit-PC2 von gestern auf heute gestorben. Er lässt sich zumindest nicht mehr einschalten. Somit wird es erstmal ruhig ums Blog…
Analyse der fit-PC2 Probleme – Teil 3 (vor fit-PC-Tod)
Bei der abschließenden(?) Suche der USB-Probleme wurde noch einmal rekapituliert:
- Das Problem besteht, wenn das Atmel-Board mit dem fit-PC2 verbunden ist.
- Das Problem besteht nicht, wenn das Atmel-Board mit einem anderen Gerät verbunden ist (Linux-Laptop oder iMac).
- 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:
Analyse der fit-PC2 Probleme – Teil 2 (vor fit-PC-Tod)
Auf der Suche der USB-Probleme, genauer, warum die USB-Verbindung offensichtlich verloren geht, geht es hier nun weiter. Wie man hier sieht, geht zeitweise die USB-Verbindung zwischen PC und Atmel-Board verloren:
Bei der vorangegangenen Analyse wurde bereits klar, dass das Problem nicht auftritt, wenn das Atmel-Board an ein anderes Gerät als den fit-PC2 angeschlossen wird, also z.B. an den iMac oder ein anderes Linux-Laptop. Um alles auszuschließen, wurden erst alle Stromversorgung extern aufgeteilt; also jede Spannung wurde durch ein eigenes Netzteil angeschlossen (5V, 12V und 24V):
Dieses brachte leider noch keine Änderung: Nach mehreren Motor Ein- und Ausschaltvorgängen, ging die USB-Verbindung wieder verloren. Nach weiteren Tests fiel auf, dass ein wichtiger Hinweis aus dem Wiki von roboternetz.de vernachlässigt wurde: Und nie vergessen Motoren zu entstören!
Solle es also daran liegen? Streuen die Motoren so viele Störungen Richtung fit-PC? Also, "kurz mal eben" alle Motoren und deren Kabel ausgebaut, ausgetauscht (die Kabel) und gemäß Wiki entstört:
Ja, Entstören wurde leider sträflich versäumt in der Vergangenheit. Und das Ergebnis? Leider nichts! Der oben gezeigte Fehler tritt noch immer auf. Fortsetzung folgt…
Test der direcs Software auf dem fit-PC
Analyse der fit-PC2 Probleme, Update der direcs-remote GUI
Seit langer Zeit gibt es im Blog nicht viel Neues. Dieses liegt vor allem daran, dass es Probleme mit dem fit-PC in Verbindung mit dem Atmel-Controller gibt – scheinbar zumindest. Als erstes stellte sich heraus, dass aufgrund des unter Debian fehlenden Intel-Grafikkarten-Treibers die Performance der GUI so miserabel war, dass diese (eben mangels passenden Treibers) vollständig "in Software gerendert" wurde. Was das bedeutet, kann sich jeder vorstellen: Der größte Teil der CPU-Zeit steht nicht für das eigentliche direcs-Programm zur Verfügung, sondern wurde für den X-Server und/oder die KDE-Oberfläche "verbraucht".
Nach dem Entfernen der kompletten GUI zeigte sich auch, dass für das direcs-Programm auf dem 1,1 GHz-Rechner natürlich genug CPU-Power zur Verfügung hat; trotz diverser parallel laufender Threads für die Sensoren, den Laserscanner, das Netzwerk, den Joystick usw.
In der System-Konsole sah man nun endlich auch, dass derzeit offenbar ein ganz anderes Problem vorliegt. Denn nach Analyse der bisher selbst gedrehten Videos, war schnell klar, dass der fit-PC bisher nie im Einsatz auf dem Roboter war, um diesen – also das Atmel-Board – direkt anzusteuern. Zum Testen wurde in der Vergangenheit immer der Entwicklungungs-PC bzw. -Mac genutzt.
Das Ergebnis von heute sieht also derzeit so aus: direcs auf dem Bot im Konsolen-Modus (ohne GUI) gestartet; wartet auf Befehle (per Joystick oder über das WLAN). Danach wird direcs-remote gestartet (derzeit noch im Teststadium):
Wie man sieht, werden über WLAN vom fit-PC z.B. Spannungswerte der Akkus übertragen und in der GUI angezeigt sowie ein Heartbeat (grüne GUI-LED rechts oben), an dem derzeit lediglich erkennbar ist, dass der SensorThread auf dem Roboter läuft und Daten ausliest bzw. übermittelt.
Klickt man nun links unten auf den "foward" Button (blauer Pfeil nach oben), wird über WLAN der Befehl "forward" an den Roboter gesendet und nun passiert folgendes (was erst in der Konsole sichtbar wurde, da Systemmeldung):
Und hier gilt es nun zu Analysieren, woran es liegt. Denn wird der Roboter z.B. an den Mac oder an ein anderes Linux-Laptop angeschlossen, tritt dieses Problem nicht auf:
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.
Atmel flashen unter Mac OS X über USB
Unter Mac OS X wollte das flashen des Atmel erst nicht klappen. Für alle, die das gleiche Problem – sei es unter Linux, als auch unter Mac OS X – auch schon einmal hatten, hier nun die Lösung. Zum flashen über USB wurde das USB AVR Lab mit der Standardfirmware (ab Werk) von www.ullihome.de genutzt. Beim Nutzen des avrdude zum flashen (hier installiert via Macports), stellte sich heraus dass dieser nicht aktuell genug war, auch meinen Atmel Atmega 2560 zu unterstützen. Der avrdude wurde also wieder per Macports wieder entfernt. Komfortabel wurde nun die sehr aktuelle Version des avrdude (zurzeit V5.10-1) (mit ebenfalls aktuellerem avr-gcc) mittels des CrossPack Paketes auf dem Mac installiert.
Zum Programmieren (flashen) über den USB-Port ist nun folgender Befehl nötig:
avrdude -p m2560 -c usbasp -P usb -e -U flash:w:FILENAME.hex
Der manuelle compile und link Vorgang für ein C-Programm für den Atmega sieht übrigens wie folgt aus. Konfortabler geht dieses natürlich per Makefile.
avr-gcc FILENAME.c -c -o FILENAME.o -Os -g -mmcu=atmega2560
avr-gcc FILENAME.o -o FILENAME.elf -mmcu=atmega2560
avr-objcopy -j .text -j .data -O ihex FILENAME.elf FILENAME.hex
Sollte folgende Fehlermeldung erscheinen:
avrdude: Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
avrdude: error: could not find USB device "USBasp" with vid=0x16c0 pid=0x5dc
muss das Ganze als root ausgeführt werden. also per "su" oder "sudo" bzw. "sudo -s".
Settings Dialog angepasst
Neben ein paar anderen Punkten in der GUI wurde der Settings Dialog angepasst. Er ist nun übersichtlicher und weist den neuen "Robot Slot" mit der Durchfahrtsweite aus. Also die Weite, durch die der Bot mindestens passen muss. Derzeit erfolgt das (in der Logikeinheit) nur anhand eines Winkels. Hier erst einmal der neue Settings Dialog (etwas unspektakulär):
.png)
Die Logik muss nun noch dahingehend angepasst werden, dass diese Durchfahrtsweite (in cm) auch aktiv genutzt wird. Berechnet und angezeigt wird sie jedenfalls bereits in der GUI.
Serielle Probleme gelöst (Mac und Linux)
Lange hat sich nichts getan, da berufliche Dinge vorgehen (und damit auch Freizeit ohne Arbeit am Mac nötig waren).
In der Zwischenzeit wurden endlich alle(?) seriellen Probleme gelöst: Der neue Laserscanner S300 funktioniert nun am Mac (mit einem Standard-USB-Wandler) und unter Linux (Debian). Letzteres jedoch nur mit dem Original USB-Wandler von Keyspan! Ein Vorteil bei dem vielen Debuggen: Der Sourcecode für das öffnen, lesen und schreiben am Mac und unter Linux sind nun endlich wieder identisch! Keine unschönen #ifdefs mit Ausnahmen oder ähnlichem (openAtmelPort). Das Ganze funktioniert ebenfalls alles auch mit dem Atmel-Board.