Schlagwort: Konsole

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…

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: