Zweiter Test mit ARM-Board

Hier der zweite Test mit dem frisch gelöteten ARM-Board mit dem STM32F4 STMicroelectronics und dem komplett neu geschriebenen Code. Die Software läuft hier komplett auf dem Roboter unter Linux, so wie er später selbstständig „durch die Gegend“ fahren soll:

 

Erster Test mit ARM-Board

Hier nun endlich der erste große Test mit dem frisch gelöteten ARM-Board mit dem STM32F4 STMicroelectronics und dem komplett neu geschriebenen Code. Es ist eigentlich selbsterklärend:

Nicht im Video gezeigt ist das Abfragen der Werte der A/D-Wandler. Hier werden die beiden Akku-Spannungen überwacht, also die 12 und die 24 Volt. Die Abfrage erfolgt wie im Video zum Beispiel mit dem Befehl *s7# (Sensor 7). Die Antwort lautet dann z.B. *4095* bei einem vollen Akku (13,2 Volt). Nett, oder?

 

Neues STM32F4 Discovery Board

Wie auch in der aktuellen Ausgabe meines Robotik-Podcasts Robotiklabor berichtet, gibt es mit dem derzeitigen Atmel-Board ja immer Probleme mit der Kommunikation über die serielle Schnittstelle, genauer, dem USB-Port. Um hier auch einmal neue Wege zu gehen, wurde mir das STM32F4 Board von STMicroelectronics empfohlen.

Bestellt wurde es vorgestern bei Watterott für schlappe 16,66 EUR zzgl. Versand – kaum vergleichbar mit dem derzeitigen Atmel 2560-Board, welches ca. 60 EUR kostete. Nach etwas Ärger mit DHL erreichte mich das Board glücklicherweise dann doch bereits heute, so dass ich hier schon einmal ein erstes Video zeigen möchte:

STM-Board – Erster Test

Hier noch ein Auszug der STMicroelectronics-Seite mit den Hauptmerkmalen des Boards:

  • STM32F407VGT6 microcontroller featuring 32-bit ARM Cortex-M4F core, 1 MB Flash, 192 KB RAM in an LQFP100 package
  • On-board ST-LINK/V2 with selection mode switch to use the kit as a standalone ST-LINK/V2 (with SWD connector for programming and debugging)
  • Board power supply: through USB bus or from an external 5 V supply voltage
  • External application power supply: 3 V and 5 V
  • LIS302DL, ST MEMS motion sensor, 3-axis digital output accelerometer
  • MP45DT02, ST MEMS audio sensor, omni-directional digital microphone
  • CS43L22, audio DAC with integrated class D speaker driver
  • Eight LEDs:
    • LD1 (red/green) for USB communication
    • LD2 (red) for 3.3 V power on
    • Four user LEDs, LD3 (orange), LD4 (green), LD5 (red) and LD6 (blue)
    • 2 USB OTG LEDs LD7 (green) VBus and LD8 (red) over-current
  • Two push buttons (user and reset)
  • USB OTG FS with micro-AB connector
  • Extension header for all LQFP100 I/Os for quick connection to prototyping board and easy probing

Und noch ein paar Fotos:

   

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…