Motortest mit STM-Board über die serielle Schnittstelle

 Mittlerweile wurde der Sourcecode vervollständigt, um alle vier Motoren per PWM und mit den jeweiligen Portbits anzusteuern. Hierzu die Fotos wo die Ansteuerung über den seriellen Port erfolgt:

Hier im linken Bild rechts unten sieht man die (rote) Platine, welche die USB-Verbindung zum steuernden Rechner darstellt. Von hier aus werden (gerade in einem Terminal-Programm) die seriellen Befehle gesendet. Das USB-Kabel am STM-Baord dient nur zur Stromversorgung (und zum Flashen):

   

PWM Ergänzung

 Hier noch ein paar ergänzende Fotos zum hier beschriebenen PWM-Test mit dem STM32F4 DISCOVERY Board:

    

Kleiner Tipp noch für das Testen: Es schadet nicht, die verschiedenen Spannungen an den Kabeln zu beschriften.

 

Abschließend möchte ich hier noch ergänzen, dass es mir nicht gelungen ist, die Timer 1 und Timer 8 (TIM1 & TIM8) sowie die Timer 9 bis 14 bei gleichem Sourcecode dazu zu bewegen, die gleiche PWM-Frequenz auszugeben. Aus einem mir noch nicht klaren Grund, waren diese Timmer immer doppelt so schnell. Es funktionierte nur mit den „General-purpose timers (TIM2 to TIM5)“ einwandfrei. Die erste Vermutung, dass es teils 32-Bit- und teils 16-Bit-Timer bestätigte sich nicht. Wenn jemand einen Tipp hat, gerne als Kommentar hinterlassen!

Erste Tests mit dem STM-Board und dem Roboter

 Die Arbeit mit dem STM-Board macht Fortschritte: Beim letzten Update wurde der Code für das ARM-Board derart aktualisiert, dass 2 Bits als Ausgänge definiert wurden. Diese wurden in fliegender Verdrahtung mit einander verbunden, so dass die Eingänge des Motorcontrol-Boards direkt am STM32F4-Board angeschlossen wurden. Interessant ist hierbei, dass das Motor-Board – entgegen den 3,3 Volt des STM-Boards –  5 Volt-Logik aufweist. Das geht jedoch in dieser Richtung, da die 3,3 Volt (HIGH) am Ausgang auch als HIGH vom Motorcontroll-Board akzeptiert werden weil sie innerhalb der Spezifikation liegen. Und so sieht das Ganze dann aus:

Nun wurde das das STM-Board per USB mit dem MacBook verbunden, ein Terminal-Programm gestartet, welches Befehle an das STM-Board sendet:

   

 

 
Und: Es fuktioniert! Der Motor 1 dreht in beide Richtungen entsprechend der seriellen Befehle – wie zuvor mit dem Atmel-Board. Und im Sourcecode wurden lediglich die neuen ARM-Ports angegeben und die Befehle zum Bit-Setzen und -Löschen angepasst. Als nächstes muss geprüft werden, wie bei dem ARM-Board PWM funktioniert, damit z.B. die Motorgeschwindigkeit Richtung Motorcontrol-Board „gesendet“ werden kann.
 
Das Gute an dem Motorcontrolboard: Die benötigte PWM-Spannung Vpwh kommt hier ebenfalls mit 3,3 Volt klar (min. 3,25 Volt). Die Versorgungsspannung des verwendeten Motortreiber ICs VNH2SP30-E benötigt jedoch mindestens 5,5 Volt und maximal 16 Volt – aber diese stehen auf dem Bot ja ohne weiteres zur Verfügung.

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…

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…

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…