Verkabelung und erster Motortest des Hexakopters

Angekommen auf dem aufgeräumten Schreibtisch, ;-) ist es an der Zeit mal zu sehen, ob die Ebay No-Name ESCs gut funktionieren. Hierzu wurde für das bekannte STM32F4 Discovery-Board Code geschrieben, der die erforderlichen Signale an den ESC sendet. Die „Befehle“, also die Geschwindigkeit, wird hier über die USB/serielle Schnittstelle und ein Terminmalprogramm vom Mac zum STM32F4-Board gesendet. Dieses gibt dann per PPM (ähnlich PWM) die Signale an den ESC. Der ESC ist die mit gelbem Schrumpfschlauch überzogene Platine unten in der Mitte auf dem Bild.

 

Das Video dazu gibt es auch hier!

Die ESCs wurden zuvor noch mit Goldsteckern versehen. Um diese ordentlich löten zu können (dafür braucht man schon mal 400° an der Lötstation!), ist ein Loch in einer Holzleiste sehr hilfreich. Anfassen möchte man die Stecker beim Löten eher nicht! ;-)

  

Nun alles verkabelt…

Und „Gib ihm!“. Okay, natürlich nur soviel, dass er nicht abhebt. Die „Geschwindigkeit“ der Motoren, werden simpel im Terminal-Programm eingegeben.

 

 

Video gefällig? Bitte sehr!

Und hier noch einmal als Stillleben… (lustig, drei L)

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:

 

Heute über 47 commits!

Es geht voran um die Tests zusammen mit dem neuen ARM-Board und der vorhandenen direcs-Software laufen zufriedenstellend. Wie es aussieht, wird der Roboter einwandfrei erkannt und auch das „Lesen“ der Sensorwerte (A/D-Wandler bzw. Akkuüberwachung) funktionieren wie gewünscht.

Für die Ansteuerung der RGB-LEDs wurde eine komplett neue Klasse erstellt um die alten Servo-Funktionen nicht mehr zu nutzen. Hier ein Überblick über die Änderungen allein von heute:

 direcs-avrsim/src/simulationThread.cpp |    4 +
 direcs-avrsim/src/simulationThread.h   |    1 +
 direcs/bin/direcs.ini                  |   18 ++
 direcs/src/circuit.cpp                 |   15 +-
 direcs/src/circuit.h                   |    2 +
 direcs/src/direcs.cpp                  |  317 +++++++++++++++++---------------
 direcs/src/direcs.h                    |   21 ++-
 direcs/src/direcsSerial.cpp            |   21 ++-
 direcs/src/direcsSerial.h              |    8 +-
 direcs/src/gui.h                       |   12 +-
 direcs/src/inifile.cpp                 |    6 -
 direcs/src/interfaceAvr.cpp            |   31 ++--
 direcs/src/interfaceAvr.h              |   16 +-
 direcs/src/motor.cpp                   |   85 +++++----
 direcs/src/motor.h                     |   13 ++
 direcs/src/rgbLed.cpp                  |  183 ++++++++++++++++++
 direcs/src/rgbLed.h                    |  138 ++++++++++++++
 direcs/src/sensorThread.cpp            |   56 +++---
 direcs/src/sensorThread.h              |    8 +-
 direcs/src/servo.cpp                   |    9 +-
 direcs/src/servo.h                     |    1 +
 direcs/src/src.pro                     |    4 +-
 test/src/test.cpp                      |  166 +----------------
 test/src/test.h                        |   24 +--
 24 files changed, 711 insertions(+), 448 deletions(-)
 create mode 100644 direcs/src/rgbLed.cpp
 create mode 100644 direcs/src/rgbLed.h

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?

 

Letzter Schritt vor Atmel-Austausch?

Nachdem nun bereits PWM sicher auf dem Atmel-Nachfolger STM32F4 funktioniert, wurde als nächstes der AD-Wandler implementiert. Hier galt es den Spannungsteiler anzupassen, damit das STM-Board nicht mehr als 3,3 Volt an den Eingangs-Pins erhält – und natürlich überhaupt den Code für den AD-Wandler für den ARM-Prozessor zu implentieren. Eine Besonderheit dabei ist DMA (Direct Memory Access).

Der STM32F4-Prozessort unterstützt mehrere DMA-Streams mit jeweils mehren Kanälen. Das bedeutet, man gibt in seinem Sourcecode unter anderem eine Speicheradresse innerhalb der CPU an, die sozusagen direkt mit dem Inhalt einer Variable verbunden wird. Das heißt, man aktiviert zum Programmstart einmalig die AD-Wandlung die danach kontienuierlich im Hintergrund läuft, ohne Interrupt, while-loops oder ähnliches. Der aktuelle Wert der Analog-Digital-Wandlung liegt jederzeit abrufbereit in der gewünschten Variable. Und durch DMA auch noch ohne die CPU zu belasten! Man kann sich an dieser Stelle durchaus fragen, warum Leute noch Atmel-Prozessoren verwerden…

Ach so, die Wandlung wird auf dem Roboter benötigt, um die Akku-Spannungen zu überwachen. Das heißt, die 24 Volt und die 12 Volt gehen „in den Spannungsteiler hinein“ und landen dann zum Messen am Pin des STM42F4-AD-Wandlers.

Hier wie immer die Fotos der Tests. Als erstes das übliche Steckbrett mit einer der zu überwachenden Spannungen (hier 24 Volt):

Hier das „Ergebnis“ wie es „in den Port“ des AD-Wandlers rein geht (wie gesagt, nicht mehr als 3,3 Volt!):

 
In diesem Bild sieht man, dass es 2,85 Volt für den AD-Wandler ergibt. Hintergrund ist, dass zwei 12 Volt-Blei-Gel-Akkus eine Spannung >24 Volt aufweisen. Darum wurde der Spannungsteiler so gewählt, dass maximal 25 Volt am Eingang anliegen, welches im Programm dann dem Dezimalwert 4095 entspricht.

Als letztes noch die verwendete Schaltung (leider etwas unscharf) mit Z-Diode zum Schutz des Ports:

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:

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.

Serielle Übertragungen vom STM-Board zum Computer über USB

Es geht voran mit dem STM32F4-Discovery Board!

Um es vorweg zu nehmen: Die folgende serielle Übertragung geschieht nicht über die bereits auf dem STM-Board verbauten USB-Ports. Nach Studium diverser Threads im Internet erwarb ich ein neues IC, welches in der Lage ist, den seriellen Port des ARM-Prozessors (USART) in einen USB-Port zu wandeln. 

Das Ganze ist auf einem sogenannten Breakout-Board von Sparkfun gleich praktisch fertig verlötet, man muss nur noch Stiftleisten hinzufügen. Zum Einsatz kommt hier der Baustein FTDI232R, der keine weiteren Bauteile mehr benötigt und auch gleich mit den 3,3 Volt Logiklevel des STM-Boards klar kommt. Entgegen dem Datenblatt von FTDI müssen bei der Verbindung zwischen dem Breakoutboard drei Leitungen verlötet werden: TX mit RX und RX mit TX und natürlich die gemeinsame Masse, GND. Wer will könnte auch noch gleich zwei Hardware flow control Leitungen mit anschließen – beide Boards unterstützen dieses. So sieht die Testverbindung dann mit den Steckern aus:

 

Hier das Breakout-Board mit dem FTDI-Chip und der USB-Buchse (rechts, mit oranger Schutzfolie) noch einmal im Detail:

  

Und so wird das Ganze dann zum Testen angeschlossen: Das schwarze USB-Kabel, welches zum STM-Board führt, dient hier nur zum flashen des selbigen und zur Stromversorgung. Das transparente USB-Kabel, welches zum FTDI-Board geht, ist das Kabel, welches dann zum PC oder Mac geht. Wird dieses dann angeschlossen, erscheint z.B. unter Linux und Mac OS X ein Device namens /dev/tty.xxxxx bzw. /dev/ttyUSBx. Beim Mac enthält „xxxxx“ gleich eine einmalige Seriennummer. Bestellt hattee ich das Board übrigens bei Watterott (ca. 14 EUR).

  

Hier sind beide Boards dann mal zum Testen am „PC“ des Roboters angeschlossen:

 

Später sollen dann die Daten vom PC des Roboters zum STM-Board (über den FTDI-Chip) und zurück fließen. Diese Aufgabe übernimmt derzeitnoch ein Atmel-Board mit einem Atmega 2560. Tipp: Auf dem STM-Board gibt es diverse USART, wovon aber einige bereits z.B. durch den vorhandenen USB-Port belegt sind! Ich habe mich daher für den noch freien USART2 entschieden.