T-962 kein schlechter SMD-Reflow-Ofen – zumindest nach Hack

SMD-Bauteile lassen sich grundsätzlich selbst von Hand einlöten, aber hier sind meines Erachtens nach gewisse Grenzen. Die Teile und Pinabstände werden immer kleiner, und besonders kleine und damit leichte Teile schiebt man beim Einlöten mit einem Lötkolben leicht weg – kein einfacher Vorgang also.

Auf der Suche nach einem bezahlbaren Hobby-Reflow-Ofen stieß ich auf den T-962 bzw. T962. Ein ziemlich günstiger Ofen aus China, den man bequem und trotz der Ferne sehr schnell Singapur bei Ebay bestellen kann. Für unter 180 € erwarb ich einen solchen Ofen, der innerhalb von 3 Werktagen (offenbar aus einem Lager aus Deutschland) geliefert war!

So, wie der Reflow-Ofen out-of-the-box geliefert wird, sollte er auf keinen Fall in Betrieb genommen werden!

Warum?
T-962 kein schlechter SMD-Reflow-Ofen – zumindest nach Hack weiterlesen

[2102 Aufrufe]

recopter3 – Das Projekt! (ein autonomer Mikrokopter)

So, nun ein paar weitere Details und Fotos zu recopter3, die teils schon Anfang August stattfanden. Ziel ist es, einen mehr oder weniger autonom fliegenden Mikrokopter zu bauen.

Mehr oder weniger deshalb, weil zur Sicherheit erst einmal mit einigen Funktionen, wie z.B. „nicht gegen Hindernisse fliegen“ gestartet wird. Auch ist vorerst geplant den Kopter manuell zu starten. Und, das wichtigste: Jederzeit in der Lage zu sein, die Automatik zu unterbrechen und wieder volle Kontrolle über das Fluggerät erlangen zu können!

Um dabei auch ein bisschen Spaß zu haben, werden noch ein paar extra Gadgets an Board sein, wie z.B. Lautsprecher und die Servo-Augen, vom alten Roboter mrs1.

Vor allem aber, wird mit dem Ansteuern der Gadgets gestartet, da ein autonomer Kopter nicht „mal eben so“ von Grund auf selbst zu entwickeln ist und das ganze ja auch noch Spaß machen soll. Außerdem hat sich der Funfaktor von einem „Lärm machenden Gefährt“ durchaus bewährt, sprich, kam gut bei Laien an.

Ein Überblick über die zu verbauenden Teile
Ein Überblick über die zu verbauenden Teile

recopter3 – Das Projekt! (ein autonomer Mikrokopter) weiterlesen

[1749 Aufrufe]

Es tut sich was…

Wie sich beim letzten Fahrversuch zeigte, „plant“ der Roboter seine Ausweichmanöver noch nach den altern Laserscannern, die alle nicht mehr als 180° auflösten. Nach ersten Untersuchungen des obstacleCheckThread zeigte sich, dass hier ein wenig mehr zu aktualisieren war. Ein Grund dafür war, dass der jetztige Laserscanner einen Bereich von 240° abdeckt. Damit sieht er aber auch „nach hinten“. Beim Prüfen, ob ein Hindernis vor dem Roboter liegt, soll er natürlich die Objekte hinter sich ignorieren. 

Da der bisherige obstacleCheckThread offenbar auch noch ein paar Fehler enthielt, wurde er vollständig neu entwickelt. Folgende hier farbing markierten Hindernis-Situationen galt zu prüfen:

Nach einer weiteren Analyse konnten die zu prüfenden Punkte optmiert werden. Die hier grau dargestellten waren nicht mehr nötigt:

Nach vielen Tests und vielen Versuchen sieht das Ganze nun so aus (im Simulationsmodus):

Die gelben Linien stellen hier die Bereiche dar, der bei der Hindernisprüfung ignoriert werden sollen. Die Winkel sind natürlich per ini-Datei konfigurierbar. Als nächstest wird eine Testfahrt erfolgen, die zeigen soll, ob nun alles wie gewünscht funktioniert.

Und hier das Ganze noch einmal als vollständiger Screenshot:

[404 Aufrufe]

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

[536 Aufrufe]

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:

[8 Aufrufe]

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!

[790 Aufrufe]