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…

Austausch der Festplatte (HDD) gegen eine SSD – Vergleich der Bootzeiten im Video

Leider war die Festplatte auf dem Roboter kurz davor das zeitliche zu segnen – brachte sie doch in hohem Maße Fehlermeldungen. Da auf lange Sicht ohnehin geplant war, der Harddisk die hohen mechanischen Belastungen auf dem fahrenden Bot nicht zuzumuten, wurde diese nun gegen eine 2,5″ SSD namens „OCZ AGILITY 2“ ausgetauscht (Modell ACZSSD2-2AGTE60G). 60 GB sind für das Linux System mehr als ausreichend, so das dieses Größe gewählt wurde.

Interessant sind hierbei natürlich auch die nun extrem kürzeren Bootzeiten, der SSD. Um das einmal aufzuzeigen wurde ein kurzes Video gedreht, in dem das sehr schön zu erkennen ist:

Es handelt sich hierbei wohlgemerkt um ein Debian Squeeze out-of-the-box mit einigen zusätzlichen Programmen, mit einem Standard-Kernel

 

Kleines Spielzeug…

Der Weihnachtsmann war da und hat ein bisschen neue (Robotik?)Hardware mitgebracht:

Mal sehen, was man da noch so schönes mit anstellen kann… :-)

PS.: Damit halbwegs noch was zu erkennen ist, bitte das Video auf Vollbild stellen. Links unten sind bei den „erkannten“ Objekten dezent rote Rahmen um sie herum zu erkennen. Leider wurde die beim Umwandeln twas „wegoptimiert“. Aber mit etwas Mühe sind sie zu sehen. Leider ist das Original-Video irgendwie verschütt gegangen. Sorry…

Fahrtest mit Akkus

Hier nun der nächste Fahrttest, dieses Mal mit vollem Gewicht – also allen vier 12 Volt-Akkus. Wie es aussieht scheint das Gesamtgewicht des Roboters damit zu hoch zu sein, denn das Querfahren funktioniert nicht wie gewünscht. Das wird eine gewisse Herausforderung, denn eigentlich werden alle vier Akkus für die beiden Stromversorgungen (24V und 12V) benötigt.

Interessant sicher auch der Strom, der von den drei(!) Netzteilen als Picture-in-Picture im Video angezeigt wird:

 

Fahrtest ohne Akkus

Nach diversen Hardwareproblemem scheint es nun etwas voran zu gehen. Hier ein neues Video, bei denen der Roboter noch an einer externen Stromversorgung angeschlossen ist – die Akkus sind noch nicht „montiert“. Die Steuerung erfolgt zum Testen über die USB-Verbindung am Mac (nicht im Bild).