Test der RGB-LEDs mittels PWM

 Nachdem die Motoren des Roboters erfolgreich mit dem noch recht neuen STM-Board über PWM angesteuert wurden, musste nun noch ein Test mit den RGB-LEDs erfolgen. Hier war nicht die Frage, ob PWM funktioniert, sondern viel mehr, ob die 3,3 Volt Pegel einwandfrei mit den Optokopplern funktionieren. Die Optokoppler sind nämlich hier nötig, da die RGB-LED-Streifen mit 12 Volt angesteuert werden. Das Ergebis war aber erfreulich:

  

Übrigens die im Bild verwendeten Kabel zum Verbinden des STM-Boards habe ich bei Watterott bestellt.

Und wen es interessiert, wie die LED-Streifen angesteuert werden:

Unterbodenbeleuchtung

 Unterbodenbeleuchtung…? fragt sich sicher der ein oder andere. Inspiriert durch iRobots AVA Roboter fiel die Entscheidung, zwischendurch (um mal was zu bauen, was funktioniert ;-) ) eine RGB-Beleuchtung für den Roboter direcs1 zu entwickeln.


Quelle: http://www.botjunkie.com

Die Idee die dahintersteckt ist, verschiedene Zustände leicht signalisieren zu können; z.B. "rot=Hindernis" oder "grün=freie Fahrt". Zum Ansteuern von den ausgewählten RGB-LED-Streifen wurden sechs Optokoppler (4N33 813) auf die vorhandene Steuerplatine gelötet – gar nicht so einfach bei der Verkabelung:

  

Die Optokoppler sind erforderlich um die LEDs zu schalten, die direkt an 12V angeschlossen werden können:

   

Nun galt es, die flexiblen LED-Streifen – die übrigens bei Pollin bestellt wurden – auf der Unterseite des Roboters zu montieren. Durch die Klebestreifen, die an den Streifen bereits dran sind, ist dieses sehr simpel. Auch kann die Meterware ca. alle 10 cm einfach mit der Schere geteilt werden. Praktisch. Hier die Fotos dazu:

    

Nicht ganz so einfach gestaltete sich das Verlegen der Anschlusskabel für die LED-Streifen am Bot. Aber lösbar:

     

Nun noch das Ganze für den zweiten Streifen:

 

Und so sieht der erste Test aus:

        

Wie man sieht, sind hier alle Farbkombinationen möglich, wenngleich erst einmal nur die offensichtlisten genutzt werden sollen wie "grün=freie Fahrt" oder "rot=Hindernis". Praktisch dabei: Es wurden die PWM-Anschlüsse des Atmel-Boards genutzt, so dass hier auch verschiedene Helligkeiten möglich sind. An diesen Portbits waren früher einmal Servos angeschlosssen. Darum existiert auch noch jeglicher Code in der Software zur Ansteuerung, nur dass eben sich nicht Servos drehen, sondern LEDs heller oder dunkler werden.

Und so sieht das Ganze dann im Betrieb aus (hier leider nur Fotos, bei denen nur eine Seite beleuchtet ist):

      

Motor Fehlersuche Finale

Wie es aussieht, weisen die Motorcontrol-Boards einen Defekt auf. Hier wurde nun eines der Boards bereits gegen ein neues ausgetauscht. Und *tusch* hier das Ergebnis:

 

Motor Fehlersuche Teil 4 und 5

Im letzten Video zeigte sich, dass anscheinend immer 12 Volt bei den Motoren ankommen, zumindest per Messgerät gemessen. Nun erfolgt der gleiche Test erneut, also mit Betrachtung der Portbits über die 7-Segement-Anzeige (die offenbar immer okay sind). mit angeschlossenen Messgeräten aber zusätzlich mit angeschlossenen Motoren. Hier das Ergebnis:

Ofenbar verhält sich das Motorboard anders, wenn die Motoren anschlossen sind und schaltet die 12 Volt nicht immer / nicht mehr korrekt. Um nun noch als letzte Fehlerursache die Motoren auszuschließen, wurde als nächstes das Ganze noch einmal mit einem Motor im Austausch getestet – mit dem Scheibenwischermotor im Vordergrund:

Das Finale ist nah…

PS.: Leider war es im Video etwas dunkel und man erkennt die Spannungen auf den Messgeräten nicht wirklich. Sorry.

 

Motor Fehlersuche Teil 3

Als nächstes galt es festzustellen, ob vielleicht die 12 Volt nicht durch die Motorcontrol-Boards nicht korrekt „geschaltet“ werden. Dazu wurden nun je Motor ein Messgerät angeschlossen und parallel die Ports über die 7-Segement-Anzeige beobachtet. Aber seht selbst:

Das Ergebnis ist noch nicht wirklich erklärbar. Anscheinend funktionieren die Motorcontrol-Boards korrekt. Die Motoren an sich waren aber okay. Fortsetzung folgt…

Motor Fehlersuche Teil 2

Bei der weiteren Analyse wurde nun die 7-Segement-Anzeige zu Signalisierung der Portbits parallel zum Motorboard it den Motoren angeschlossen. Wie man sieht, werden die Bits korrekt gesetzt, aber trotzdem bleibt gelegentlich ein Motor stehen:

Fortsetzung folgt…

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… 

GUI weiter verbessert und aufgeräumt

 Langsam war es an der Zeit, die GUI weiter zu verbessern und auch so in der Darstellung dahingehend anzupassen, dass sie auf dem MacBook Pro mit einer Auflösung von 1680×1050 noch gut dargestellt wird. Vorab das Ergebnis:

Im Wesentlich wurde auf der rechten Hälfte der Bereich Odometrie entfernt und ein Teil der Daten in das rechts oben angezeigte Bereich State eingefügt. Die Buttons zum Zurücksetzen der gefahrenen Strecke (derzeit per Hardware noch in Planung) sind in das Menü bzw. die Toolbar gewandert. Zusätzlich wurde ein Fehler in der Darstellung des Heartbeat-Plot korrigiert. Auch wurden fast alle Icons in höherer Auflösung hinterlegt und einige gegen leichter identifizierbare ausgetauscht – so z.B. das Reset-Icon, welches nun durch das orange 2-Pfeil-Icon dargestellt wird.

Ebenfalls entfernt wurden die großen Schaltflächen zur Anzeige der einzelnen Motoren-Status. Diese werden nun im State Bereich angezeigt – und zwar grafisch per GUI-LED und anhand des echten Roboter-Fotos in der Draufsicht.

Die LEDs zeigen entsprechend den jeweiligen Status der vier Motoren an:  Aus (grau), im Uhrzeigersinn (grün), entgegen dem Uhrzeigersinn (rot). Und so sieht das im Detail aus:

      

Kleine GUI Verbesserungen

 Nach diversen Aktualisierungen im Programmcode sollte auch etwas für die Optik getan werden. Zur leichteren Erkennbarkeit wurden weitere "LEDs" hinzugefügt:

Diese zeigen den Status diverser Module an:

  • Der Heartbeat blinkt im Rhythmus der Antworten vom Atmel-Board durch Abfrage des Sensorthreads. Sie leuchtet konstant rot, wenn der Roboter nicht als angeschlossen erkannt wurde.
  • Die Compass-LED zeigt an, ob das Compass-Modul mit dem Atmel-Board physisch verbunden ist.
  • Die Camera-LED leuchtet (derzeit), wenn mittels OpenCV eine angeschlossene Kamera erkannt wurde.
  • Die Joystick-LED ist grün, wenn ein Joystick angeschlossen ist.
  • Die Network-LED soll einmal anzeigen, wenn eine Kommunikation über WLAN mit direcs-remote stattfindet (welches wichtige Status.-Werte des Roboters remote anzeigt).
  • Eine hier noch nicht dargestellte weitere Laser-LED zeigt an, ob der Laserscanner erkannt wurde.

Als weitere Verbesserung wurden die Plot-Bereiche mit Gitternetzlinien versehen, was nicht nur eine leichtere Lesbarkeit bewirkt, sondern insgesamt einen professionelleren Eindruck macht: 

Um auf einen Blick noch schneller den Status des Roboters darzustellen, wurde ein weiterer Plot-Bereich hinzugefügt, der im Prinzip den wechselnden Status der Heartbeart-LED darstellt:

Und so sieht das ganze dann vollständig im Betrieb aus:

 

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….