Quadrokopter mit STM32F103CBT6

Hallo,

ich hatte dieses Projekt bereits bei mikrocontroller.net und fpv-community.de vorgestellt.
Leider interessiert das dort niemanden. Jedenfalls kamen von dort keine Rückmeldungen.

ich habe hier https://github.com/nichtgedacht/mini-sys ein komplettes
Projekt für OpenSTM32 System Workbench (http://www.openstm32.org) hin
gelegt.

Das Projekt lässt sich auf Knopfdruck installieren und ist für mich die
Grundlage für alles weitere. Der original Code für das LCD stammt wie
der übrige hinzugefügte Code aus den Firmware Repos von STM für den
STM32F4xx und den STM32F1xx soweit es das Display und die SD-Card betrifft.
Diesen Code habe ich stark verbessert, so dass man 1. Display beliebig drehen kann
und 2. mehr der Chip vom Display die Arbeit macht. Da der initiale Code für die
Peripherie der MCU mit CubeMX erzeugt wurde, kann man damit auch weiterhin
die Konfiguration verändern. Dieses Tool und die IDE sind auch für Linux erhältlich
und beide sehr einfach zu installieren und kostenlos.

Als Hardware eignet sich eins dieser billigen Boards "STM32 minimum
development system" oder ein maple mini clone mit STM32F103CB und
eins dieser ST7735 gesteuerten Displays mit 128x160 Pixel und SD Karten Slot
wie z.B das Teil von Adafruit oder ähnliche. Was man noch braucht sind ein
paar Drähte eine Lochrasterplatte, Buchsenleisten und ein ST-Link V2 Debug
Adapter, den man ebenfalls günstig bei ebay bekommt. Damit kann man
den Code bis runter auf Assemblerebene in Einzelschritten ablaufen lassen oder
eben auch die Software einfach nur hochladen.

Als Sensoreinheit verwende ich ein Breakout Platinchen mit einer MPU-9250 IMU.
Darauf sind 3 Gyros, 3 Accelerometer und 3 Magnetsensoren.
Der Empfänger von Jeti hat die Firmware mit Futaba S-Bus. Damit überträgt
das System 16 Känäle digital mit 2000 Steps pro Kanal in 17 ms.

Inzwischen fliegt die Lochrasterplatine als Quadokopter in Racergröße der sich
durchaus zum rumheizen eignet. Dabei benutze ich bisher nur die Gyros
und fliege das Ding, wie bei Racern üblich, wie einen Hubschrauber.

Ich war Heute damit auf einem Modellflugplatz und man hat mir bestätigt, dass
das Teil sehr gut fliegt. Mir persönlich wackelt er in bestimmten Situationen
noch zu stark.

Ich würde mich freuen, wenn ich sich hier jemand findet der das Teil nachvollzieht
und verbessert. Die Hardwarekosten sind ja sehr überschaubar und die Platine ist
an einem Regentag zusammengelötet.

Der Rahmen auf dem Foto ist ein Teil für 8,5€ von Hobbyking. Mit 1000er 3s Akkus
fliegt der Kopter über 10 Min. bis die Spannung unter 10V geht.

Gruß
Dieter


.

nichtgedacht schrieb:

Der Empfänger von Jeti hat die Firmware mit Futaba S-Bus. Damit überträgt
das System 16 Känäle digital mit 2000 Steps pro Kanal in 17 ms.

Zum Vergrößern anklicken....

Ich muss mich hier korrigieren.
Die 16 Kanäle werden als 25 Bytes natürlich in 3ms übertragen. Nur die
Wiederholzeit vom Jetisender ist eben 17ms.

Die Baudrate also Bitrate ist 100000/s.
Da das serielle Protokoll 8E2 ist, also 1 Startbit, 8 Datenbits, 1 even Paritybit, 2 Stopbits
also 12 Bit pro Byte Nutzdaten, haben wir
25 * 12 / (100000 / s ) = 3 ms.

Gruß
Dieter

Ist die serielle Übertragunsrate nicht 125 kBit/s (bzw.. 250kBit/s) und das Datenformat nicht "8N1" ?

Siehe:

http://www.jetimodel.com/en/show-file/642/

Sepp62 schrieb:

Ist die serielle Übertragunsrate nicht 125 kBit/s (bzw.. 250kBit/s) und das Datenformat nicht "8N1" ?

Siehe:

http://www.jetimodel.com/en/show-file/642/

Zum Vergrößern anklicken....

Nein, das hier ist Futaba S-Bus per Jeti Firmware im Jeti Rsat2. Das Jeti eigene EX Bus Protokoll ist natürlich anders.

Gruß
Dieter

Ah, ok. Bei den 2 Stoppbits habe ich automatisch an Jeti gedacht.

Es ist übrigens ein schönes Projekt. Ich hoffe, es bekommt noch die Aufmerksamkeit, die es verdient. Ich fliege leider keine Copter, sonst wäre ich dabei.

Grüße
Bernd

Hi

Die PID Werte der Regler sind jetzt mit der Fernsteuerung im RAM editierbar. Ein Schreiben der Werte in eine der oberen Flashpages ist vorbereitet.
Dann wird man beim Start mit einer Schalterstellung am Sender auswählen können, ob die Defaultwerte oder die aus der Flashseite
ins RAM kopiert und benutzt werden.

Warum spielt eigentlich keiner mit mir :-(

Gruß
Dieter

Hi

Ich habe jetzt das UDI16 (Jeti) resp. SRXL16 (Multiplex) implementiert. Man spart den S-Bus Pegel Inverter und die Auflösung ist doppelt so hoch (max 4095 Schritte)
Der Frame wird auch in 3ms übertragen obwohl hier 35 Bytes gesendet werden statt 25 wie bei S-Bus. Die Baudrate ist eben entsprechend höher. Der Timer wird jetzt mit
4 MHz geclockt und der Autoload-Register-Wert und die Servo-Werte wurden verdoppelt um der höheren Auflösung gerecht zu werden. Die Werte von S-Bus wurden einfach
verdoppelt "<< 1" um sie kompatibel zu machen.

Anbei das Timing der Steuerung, hier noch mit S-Bus. Die erste Zeile sind die SPI Daten die aus der MCU rauskommen. Die zweite Zeile die Daten die rein gehen. Die dritte Zeile
ist clock. Die vierte Zeile ist /chip enable vom IMU.Die fünfte Zeile ist S-Bus auf dem UART. Die sechste Zeile ist ein Servokanal bei Vollgas.

Auf dem vierten Bild kann man erkennen wie die Gyros abgefragt werden. Auf dem SPI Bus werden anschließend sechs 0-Bytes gesendet und damit das Ergebnis aus dem IMU Chip
rausgetackert. Das passiert in jedem 5ms Abschnitt, während das Display nur in jedem vierten Durchgang bedient wird. Die Daten vom RC-Empfänger sind zufällig positioniert da sie
von einem externen Interrupt rein kommen. Man kann im Jeti Sender die Wiederholrate getrost auf 5ms stellen. Da der Sender mit 100Hz sendet werden dann die vom Empfänger zur
FC gesendeten Daten aber nur jedes zweite Mail aktualisiert.

Gruß
Dieter

Hi

Eine neue Platine.
Diesmal mit Plan und besser gestaltet.

Gruß
Dieter

Hallo Dieter,
wo liegen jetzt die Unterschiede / Vorteile deiner Entwicklung?
Wie werden die Werte eingestellt?
Ich habe bis jetzt nur mit Arduino und Wii probiert.

Hallo Bernd,

als wesentliche Unterschiede fallen mir ein:
1. Es ist einfach geschrieben und daher einfach zu verstehen und zu verändern.
2. Man kann mit Lötkolben und Entwicklungsumgebung bewaffnet schnell was Anderes daraus machen und kreativ sein.
3. Es verwendet die HAL Libraries, den CubeMX Codegenerator und eine von STM offiziell unterstützte IDE in Eclipse. (Linux, MAC, Windows) und liegt somit im Trend vom Hersteller der MCU.
4. Es kostet fast gar nichts und hat trotzdem eine leistungsfähige MCU.

Welche Werte meinst Du?
Die default Werte für die PID Regler sind hard coded:
controller.c:
const float const_pid_vars[9] =
{ 0.24f, 1.5f, 0.004f, 0.24f, 1.5f, 0.004f, 1.0f, 1.5f, 0.001f };

Diese lassen sich mit der Fernsteuerung editieren und in einer separaten Flashseite bootresistent ablegen.

Die Zuordnung der Motoren und deren Drehrichtung ist z.Zt. auch in controller.c hard coded.

Die maximalen Drehraten sind in main.c hard coded:
diffroll = gy[x] * 8.0f - (float) channels[1] + MIDDLE_POS;
...

Das entspricht jetzt 250 Grad/Sekunde beim max Knüppelausschlag.
Die Gyrowerte sind ja in Grad/Sekunde und von Knüppelmitte bis Endausschlag
ist die Differenz 2000. Wer es rasanter will muss nur den Faktor ändern.

Schau Dir einfach mal main.c an. von da aus ergibt sich das Verständnis ganz leicht.
In der IDE wird der Text der aufgerufenen function angezeigt, wenn man den
Mauszeiger drüber hält. Die Suche ist auch sehr komfortabel.

Natürlich wäre ein Konfigurationstool ( in Java ?) sinnvoll.
Vielleicht hat ja jemand Lust das zu machen?

Ein Bootloader im Flash, damit man die Firmware ohne Debug-/Programmier-Adapter
über die USB Schnittstelle rein bekommt wäre auch nett, aber ob das den
Aufwand lohnt?

Gruß
Dieter

Nettes Projekt

Nettes Projekt

.. ich wäre auch an Infos zu den restlichen Komponenten interessiert (Schaltplan?)

und warum trägst Du so ein riesiges LCD in mit herum? Weil Du es kannst?

Gruss
Hendrik

Hi Hendrik,

den Schaltplan vom Maple mini gibt es z.B. hier: http://cdn.sparkfun.com/datasheets/Dev/ARM/maplemini.pdf
Der Clone ist insofern anders, als das die ADCs keinen eigenen Spannungsregler haben. Die Randkontakte passen
aber alle.

Kaufen kann man das z.B. hier http://www.ebay.de/itm/STM32F103RCB...589086?hash=item3f56f1395e:g:KfEAAOSwgY9XedZS

Das Sensormodul gbts z.B. hier http://www.ebay.de/itm/MPU9250-9D0F...391710?hash=item281bc2041e:g:cR8AAOSw0fhXigf3
Das Display (ähnlich) z.B. hier http://www.ebay.de/itm/1-8-inch-TFT...480973?hash=item58aa038b0d:g:bWUAAOSwzgRW0~ej

Für die paar Verbindungen war ich bisher zu faul für einen Schaltplan.
Mach Du doch einen. Die Infos sind ja hier beisammen.

Gruß
Dieter

Hi Dieter,

danke, das reicht schon vollauf.

nichtgedacht schrieb:

...Diesmal mit Plan und besser gestaltet....

Zum Vergrößern anklicken....

.. sah so aus, als hättest Du einen Plan.

Gruss
Hendrik

Moin

ich habe jetzt ein Configuration Tool fast fertig.

https://github.com/nichtgedacht/configurator101

Als letztes wollte ich noch eine animierte 3D Darstellung
implementieren.

Was fehlt dann noch bis auf die Verzierungen und etwas Farbe?

Gruß
Dieter

Sehr schönes und gut gemachtes Projekt.

Seit einiger Zeit bin ich von den Mutikoptern allerdings weg, das muss aber nicht so bleiben.

Wie ist den Deine Meinung zu der HAL Lib und CubeMX?
Ich benutze zur Zeit noch die alte STM Lib, aber nur dort wo unbedingt nötig.

Grüße Ingo

ingo_s schrieb:

Wie ist den Deine Meinung zu der HAL Lib und CubeMX?
Ich benutze zur Zeit noch die alte STM Lib, aber nur dort wo unbedingt nötig.

Zum Vergrößern anklicken....

Moin

Ich kann mir nicht wirklich ein Urteil zu HAL und CubeMX erlauben, da ich erst im Frühjahr mit diesem Geraffel angefangen bin und vorher nie mit STM32 zu tun hatte.
Man ist halt relativ weit weg von der Hardware und kommt nur selten direkt mit Registern in Berührung.
Am Anfang hat mich vor Allem die Entwicklungsumgebung in den Wahnsinn getrieben. Die war mal wirklich sehr buggy. Nach zwei drei Updates war das aber wie durch Geisterhand verschwunden.
Auch aus CubeMX wurden Fehler entfernt und es kam sogar ein neues Firmware Repository als ich schon mitten im Projekt war.
Immerhin gibt es das alles zusammen erst seit 2016 für Linux, obwohl es auf Java basiert.
Mich persönlch hat es manchmal genervt wenn die Examples von STM in deren Firmware Repositories und der von CubeMX erzeugte Code nicht zusammen zu passen zu schienen.
Die Dokumentation der HAL Functions war dann auch oft nicht hilfreich und ich musste wohl oder übel die Libs umgraben um einzelne Details zu verstehen.
Der von CubeMX erzeugte Code lässt aber immer genügend Freiheit um ihn sinnvoll nutzen zu können und keinen toten Code mit schleppen zu müssen.
Und, wie man an mir sieht, kann man auch als Anfänger schnell zu funktionierenden und gut getesteten Programmen kommen.

Gruß
Dieter

Prima Idee

Prima Idee

Hallo Dieter,

besten Dank für deine informative Zusammenfassung zu deinem Quadrokopter. Bin gerade dabei mich einzulesen/-arbeiten.
Ist sehr interessant gemacht, aber auch etwas schwer den Überblick zu behalten. Ein Blockschaltbild (oder Skizze) wäre sehr hilfreich um eine einfache Übersicht zu den verdrahteten Komponenten (Pins) zu erhalten. (Hättest du nicht Zeit, Lust und Muse dazu?)

Ich habe mal einen Versuch gemacht, bin mir aber nicht sicher ob es nun so stimmt:

Die "OpenSTM32 SystemWorkbench " habe ich letzte Woche installiert und wundere/verzweifle an den manchmal merkwürdigen Eigenheiten/Verhaltensweisen dieser STM32-Entwicklungsumgebung. Das mir die STM32-MCUs auch neu sind, ist das wohl eine prima Gelegenheit sich in die Thematik einzuarbeiten.

(Ich darf gar nicht daran denken, dass man mittlerweile für weniger als 13 Euronen ein CC3D (Hard-, Firm- und Software) bekommt. )

Holm- und Rippenbruch
Albert

Hallo Albert,

vielen Dank für Dein Interesse an dem Projekt.

Dein Pin Mapping ist korrekt. Es fehlen nur die SWDIO (PA13) und SWCLK (PA14) Pins für den Debug-Adaper Anschluss.
PB5 ist nur für das Display RST. PB7 ist Data/Command für das Display. schaltet also zwischen Daten und Befehlen zum Display um.

Es gibt ja zwei Platinchen mit der MCU die in Frage kommen.
Die größere hat den STM32F103C8T6 mit 64 kB Flash, die kleinere (Maple Mini Clone) den STM32F103CBT6 mit 128 kB Flash
Die kleinere Platine gibt es selten auch mit der 64 kB Flash MCU.
Hier sind sie alle 3 zu sehen:
http://www.ebay.de/itm/STM32F103RC8...hash=item3f70a36766:m:miZHBgOkfhBLMHK68bHuMSQ
Der Maple Mini Clone hat neben dem USB Reset (wichtig) auch einen fetten 3,3V Regler an Bord.
Der einzige Vorteil der größeren Platine (die mit den gelben Jumpern) ist der RTC Oszillator an Bord, den man in diesem Projekt aber nicht braucht.
64 kB werden auch schon leicht überschritten mit Display und SD-Card enabled, daher besser den STM32F103CBT6 wählen.

Bei der größeren Platine mit den gelben Jumpern ist die blaue Leuchtdiode an PC13 angeschlossen, bei dem Maple Mini Clone an PB1.
Bei dem Maple Mini Clone steht PB1 nicht als Randkontakt zur Verfügung.

Ich wollte immer schon mal einen Plan zeichnen, bin aber nie dazu gekommen. Offenbar ist das Mittel der Wahl dafür heute KiCad.

Hast Du nicht Lust Dich in KiCad einzuarbeiten?

Übrigens sind die Sensorplatinchen auch nicht mehr teuer:
http://www.ebay.de/itm/MPU9250-9D0F...391710?hash=item281bc2041e:g:cR8AAOSw0fhXigf3

Damit kann ich mit meiner Flugsteuerung preislich mit den billigsten fertigen mithalten ;-)

Für Probleme mit AC6 (OpenSTM32 SystemWorkbench) und CubeMX kann ich jede Hilfe anbieten, auch per Mail.

Anbei noch einige Illustrationen.

Gruß
Dieter

Hallo Dieter,

vielen Dank für deine schnelle und ausführliche Antwort. Nun sind meine Unklarheiten beseitigt.

Als "Platinchen" werde ich also die "STM32F103CBT6" Variante nehmen (mit dem "B" und nicht mit der "8" in der Bezeichnung), also z.B.:
http://www.ebay.de/itm/STM32F103RC8...658565?hash=item3f70a2d285:g:WXQAAOSwEzxYQprW
oder z.B.:
https://de.aliexpress.com/item/leaf..._1&btsid=6c060f13-4b21-4b0d-8639-711707c2260d
(falls es das gleiche Teil ist und das "R" in der Bezeichnung ein Tippfehler vom Händler ist?).

Danke auch für deine neuen Bilder.
Sieht insgesamt spitzenmäßig gut aus, und die neue Mutter-Platine gefällt mir sehr gut!
Ohne das TFT-Display (Mücken- und Fliegen-Kinoleinwand) macht sich dein Quadrokopter auch viel besser.

Das mit dem KiCAD habe ich jetzt irgendwie verdrängt. Aber mir genügt auch die kurze textuelle Zusammenfassung.
Apropos:



"Auslegearm- und Propellerbruch"
Albert

Ay3.14 schrieb:

Hallo Dieter,

vielen Dank für deine schnelle und ausführliche Antwort. Nun sind meine Unklarheiten beseitigt.

Als "Platinchen" werde ich also die "STM32F103CBT6" Variante nehmen (mit dem "B" und nicht mit der "8" in der Bezeichnung)
...
falls es das gleiche Teil ist und das "R" in der Bezeichnung ein Tippfehler vom Händler ist
...

Zum Vergrößern anklicken....

Moin Albert,

es gibt tatsächlich auch eine R Variante mit 64 Pin Gehäuse.
http://www.st.com/en/microcontrollers/stm32f103rb.html
http://www.st.com/en/microcontrollers/stm32f103cb.html

Die Daten sind gleich.

Aus dem Datenblatt http://www.st.com/content/ccc/resou...df/jcr:content/translations/en.CD00161566.pdf

Das normale Gehäuse in meinem Projekt ist das LQFP-48

Du kommst sonst ins Schleudern, wenn CubeMX die Pins darstellt die nicht zum LQFP-64 passen.

Siehe die PDF Datei im Projekt.

Ist aber nur Kosmetik. RC gibt es gar nicht.
Wahrscheinlich wurde das 48-pin Gehäuse verwendet.

Gruß
Dieter