Meanwhile: Motor Fehlersuche 1

Wie bisher berichtet, trat in der Zwischenzeit immer noch das Problem auf, dass bei gleichzeitiger Ansteuerung aller vier Motoren (was natürlich immer der Fall ist, das es ja ein Allrad-Roboter ist) immer mal wieder eines der Räder sich nicht dreht. Das Phänomen stellte sich mit allen Motoren reproduzierbar aber immer an verschiedenen Rädern / Motoren und immer zu unterschiedlichen Zeitpunkten auf.

Um herauszufinden, ob die Bits auch richtig vom Microcontroller gesetzt werden, wurden kurzerhand zwei Sieben-Segement-Anzeigen „missbraucht“ um die verschiedenen Stati anzuzeigen. Dargestellt werden hier die vier PWM-Bits (oben und unten) sowie die zwei Bits pro Motor, also acht Segmente. Hier das Video zur Dokumentation dazu:

Wie man sieht, ist hier als erstes ein Fehler aufgezeigt, der bei der Umstellung auf die neuen seriellen Befehle kopiert wurde: Beim „vorwärts“ fahren, werden die gleichen Bits gesetzt wie beim „links“ fahren. Das wurde natürlich als erstes nach diesem Video beseitigt – zeigt aber auch wie praktisch eine einfache Analyse mit direkter Anzeigt mit einfachen LEDs hier schnell Ergebnisse bringt.

Hier noch mal die 7-Segment-Anzeige und die Bedeutung der Segmente im Detail:

 

Fortsetzung hier…

Zwischenschritt: Analyse von Motorverhalten

 Beim Umstellen der seriellen Funktionen auf ASCII-Klartext-Anweisungen anstatt binärer Daten, stellte sich heraus, dass die Motoren nicht immer gleich auf die selben Anweisungen reagierten. Um sicher zu gehen, dass es kein Hardwarefehler ist – und weil ein Programmfehler nicht feststellbar war – wurde kurzerhand ein kleiner Analysestecker gebaut und alle Verbindungen insgesamt aufgetrennt um jedes elektrische Modul für sich sauber zu testen. Und so sah der Test dann aus:

  

Wie mah sieht zeigt die grüne LED den Zustand des betreffenden Portbits des Atmel an. Zum einfacheren Testen wurden einfach ein paar LEDs mit je einem 1,5 k Ohm Vorwiderstand gegen Masse auf den betreffenden Pfostenverbinder gelötet:

  

Das funktionierte offenbar wie gewünscht. Anschließend wurden umgekehrt die Eingänge der Motorcontrol-Boards jeweils per Drahtbrücken auf high gesetzt um zu sehen, ob die Motorcontrol-Boards beide ordentlich funktionieren. Das Wichtigste dabei: Eine ordentliche und aufgeräumte Testumgebung! 

  

Spaß beiseite. Hintergrund dieser wilden Verkabelung ist natürlich, dass das Board "vor Ort" also in der Originalumgebung "im Roboter" getestet werden soll, also mit der gleichen Spannungsversorgung etc. Also wurde die Platinen nur soweit gelöst, dass man an die betreffenden Stecker ordentlich ran kommt und etwas unter die Platinen gelegt, damit es keine Kurzschlüsse gibt.

Nun wurden endlich auch die letzten Stecker und Kabel bei der Gelegenheit beschriftet – wo sowieso schon mal alles auseinander gebaut war:

    

Ergebnis: Interessanterweise wurde kein Fehler gefunden und nach dem Zusammenbau funktionierte alles wie gewünscht – ohne was geändert zu haben. Irgendwie seltsam… 

Meanwhile: checking of the motor behavior

 After changing the serial method to transceive ASCII clear text instructions instead if binary data, I found out that that the motors do not react the same when using identical instructions. To ensure that this is not due to a hardware error – and since it does not look like a software error too – I built a small analysis connector which disconnects all connections at all to test every electrical module  seperately. This is how the test looked like:

 

As you can see the green LED shows the state of the corresponding Atmel port bit. For easier testings I simple connected some series resistors of 1.5 k Ohm in line with some LEDs connected to the common ground – with 7-segmend-LEDs, to be more precise. These were than directly soldered on the board connecter:

 

This stuff worked as expected. After this the input ports from the motor control boards were set to high (one after another) to check of these boards work as expected. The most important thing when testing things like this: a wel organised and tidy working environment! 

 

To be honest the reason for this wild flying wires here are was that I had to test this directly at and close to the robot. Since I wanted to have a realistic test case with the original power supply etc. This is why I unmounted the PCBs only this far that I was able to connect all relevant connectors and not resulting in a short circuit.

Using this opportunity I finally labeld the last connectors and cables with this DYMO stuff – since at least anything was disassembled at this moment:

   

Result so far: No error found. After reassambling everything, all motors worked like they should – allthough nothing was changed. Strange…. 

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 Motoren per Joystick

Hier nun ein recht neues Video, bei dem die Ansteuerung der Motoren getestet wird:

Wie man sieht, bleibt hier gelegentlich noch der ein oder andere Motor stehen bzw. dreht sich erst gar nicht. Ursache dafür scheint ein kurzer Spannungabfall am Atmel zu sein, der nacheinander die verschiedenen Port-Bits für das Motorcontrol-Board setzt. Da er beim Spannungseinbruch sich neu startet, „kommt“ er nicht bis zum letzten Bit, was gesetzt werden soll. Als Folge dessen, werden nun alle Boards ihre 5V Spannungsversorgung über den 24V-Akku erhalten. Dieser ist nicht so großen Belastungen (Schwankungen) ausgeliefert, wie die 12V-Akkus, an denen die Motoren hängen.

Die Motoren scheinen kurzzeitig bis zu 8A Strom zu „ziehen“. Höhere Werte konnten mangels ausreichendem Netzteil noch nicht getestet werden…