Generelles zu Flight Control Firmware Development

Da es im KISS ESC 30A Thread etwas offtopic geworden ist, würde ich gerne die Diskussion und zukünftige Disukssionen gerne hier unterbringen.

Soll nicht spezifisch nur für ein Projekt sein, sondern evtl. Projketübergreifend, oder auch für eigene Entwicklungen.
Themen z.B. Regelung, Filterdng von Sensordaten,...

Mal zum Anfang die Fortführung der Diskussion von hier: http://fpv-community.de/showthread....ESC-18A-2-4S-amp-12A-2-4S&p=864826#post864826

Das stimmt, der FC ist der Master und gibt den clock vor, aber das heist ja nicht das das Device alle Tackte unterstützt die der µC kann.
Ich weiß jetzt nicht welche MPU du nutzt, deswegen hier mal als als Beispiel die MPU60000, die ja auch SPI unterstützt.
Datasheet findest du hier: http://store.invensense.com/datasheets/invensense/MPU-6050_DataSheet_V3 4.pdf

Auf Seite 7/52 steht:
In der Register Map (https://www.olimex.com/Products/Modules/Sensors/MOD-MPU6050/resources/RM-MPU-60xxA_rev_4.pdf) sieht man das die sensor data und interrupt Register direkt hintereinander liegen, das FIFO Register liegt ganz wo anders.
Ich und auch andere Entwickler verstehen das so, das man halt wirklich nur die interrupt und data Register mit bis zu 20MHz auslesen kann. Den Rest nicht.

In Taulabs wird die Konfiguration der MPU z.B. mit einer anderen Clock durchgeführt, und auch wenn später was aus der Konfiguration gelesen wird, wird das mit der langsameren clock gemacht.
Mit der schnellen clock werden nur die Sensor Daten ausgelesen.

ups, habe einfach den takt auf 20mhz eingestellt und fliege damit schon seit längerer zeit.
also mpu-6000 mit der f3 und f4 serie.

gibt dieses weekend sozusagen keinen timeslot für das testen ... :-/

Liest du denn den FIFO aus, oder die normalen Daten Register?

Sowohl Taulabs als OpenPilot hatten z.B. früher auch den FIFO ausgelesen. Das hat aber wohl sebst mit 1MHz manchmal zu Problemen geführt, und dann muste was restet werden etc.

Wenn man das schneller ausliest kommt es evtl. häufiger zu Fehlern. Keine Ahnung ob das mal jemand wirklich getestet hat. Aber gerade bei was fliegendem muss man ja nicht unbedingt Spezifikationen ignorieren

FIFO auslesen macht doch nur wirklich dann Sinn, wenn man den DMP nutzt, und f3 und f4 sollten ja wohl in der Lage sein, schneller zu rechnen, als der DMP, zumal Invensense sich da ja immernoch ganz schön anstellt, was die Programierung angeht.
Also wozu den FIFO?

Hmmm, dmp - habe nicht vor das zu benutzen.
Will nur die Möglichkeiten der MPU nutzen, weil ich der Meinung bin, dass ich nicht genügend datensamples habe.
Auch ist mir dmp zu schlecht dokumentiert. Wahrscheinlich liefert es gute Daten für einen fixedwing.

Gibt es irgendwo ein project für stm?
Will es mal probieren ...

Was den DMP angeht, gibt Invensense ja leider auch nicht wirklich was preis. Wenn du Tempo brauchst, wirst du wohl die Datenregister direkt auslesen müssen. Für STM müsstest du mal den "motion driver" von Invensense checken (musst dich bei denen registrieren), da könnte was für dich dabei sein. Ansonsten für Arduino die I2Cdevlib von Jeff Rowberg. Der hat auch den MPU6050 und den MPU9150 beackert.

also, habe die leserate auf 2khz erhöht und lasse den ekf mit 500hz rasseln.
die werte für roll pitch sind soweit gut.
nur yaw schwingt leicht.
anstelle zu fliegen sitze ich mal aufs radl ...

Und was soll das bringen, wenn du den EFK nur mit jedem 4. Wert fütterst?

der ekf wird mit gesampelten werten gefüttert.
https://de.wikipedia.org/wiki/%C3%9Cberabtastung
ist das verständlich?

habe es mal optimiert.
neu wird im 1 khz takt alles gelesen, d.h. accel, temperatur und gyro werte.
im 2 khz takt nur die gyro daten, da der accelerometer nur im 1khz raster neue daten liefert.
liest man ihn im 2 khz raster aus hat man dupletten.

das flattern vom yaw hat sich auch erübrigt.
ein maxbotic sensor war zunahe drann am magneto.

die daten sehen auf dem tisch besser aus als mit 188hz interne lpf filter aktiviert.

Machst du ne einfache Mittelung der Werte ?
Für Taulabs habe ich erstmal mehrere Varainten für das down-sampling implementiert, um auszutesten welche anti-aliasing Filterung optimal ist.

Dein 2kHz auf 500Hz down-sampling sollte aber auch mit einer einfachne Mittelung schon recht ordentlich sein.

Aber die MPU läuft ja auf 8kHz, und wenn du nur mit 2kHz ausliest ist das ja auch ein down-sampling und Nyquist müsste auch wieder beachtet werden und man bräuchte auch hier eine anti-aliasing Filterung denke ich.

Daher lese ich in Taulabs mit 8kHz aus und machen davon dann ein "sauberes" down-sampling.

Edit:
Deinen letzten Post zu spät gelesen.
Im Prinzip mache ich das auch so, also mit der hohen Frequenz nur den Gyro auslesen.
ACC und Temp mit 1kHz, oder wenn Ausgansfrequenz größer als 1kHz dann mit der entsprechenden Rate und dann evtl. ne Mittelung der Werte.

es ist ein versuch ...
ich mittle die samples - keine filtering ... oder noch kein filtering.
ich hatte da so einige komische artefakte mit pt2 filtern ...
tödlich wird es wenn man diese kaskadiert ... da ist in den taps einfach zuviel energie ... :-/

ich habe im moment ein ekf von tobias nägeli aktiv.
der braucht dutlich mehr cpu zyklen als madgwick.
deshalb sind 8khz sampling für mich wahrscheinlich zuviel.
ein richtiger m7 lässt grüssen ...
probiere es noch mit 4 khz ...

dann mal wieder ein versuch mit madwick...

Mittelung ist ja auch eine Filterung
Eine einfache Mittelung von 4 Samples in Verbidnung mit dem down-sampling von 2kHz auf 500Hz ist ja praktisch ein gleitender Mittelwert (moving average).

Und ich lasse die Regelung ja auch nicht auf 8kHz laufen, sondern lese damit nur den Gyro aus.
Die Regelung läuft dann mit der reduzierten Frequenz.

Bisher habe ich nur Acro und Level als flightmodes getestet, und die arbeiten ja nur mit Gyro und ACC. Für diese Sensor Fusion habe ich allerdings keinen EKF konfiguriert, sondern nen "complementary filter".

Wenn ich z.B. von 8kHz auf 2kHz gehe, habe ich damit so 50-55% CPU load.
Wobei Taulabs ja nicht unbedingt auf absolute Performance, sonder eher auf gute Erweiterbarkeit optimiert ist. Und auch ein RTOS mt entsprechend Overhead nutzt.

schon mal eineb binomial-filter an der stelle probiert?

infaches Beispiel, Länge n=3, du willst für den Index i den Wert berechnen:

Code: Alles auswählen
y = (x(i-1) + 2*x(i) + x(i+1)) / 4;

Das ist quasi die weichere Alternative zum sliding window average:

Code: Alles auswählen
y = (x(i-1) + x(i) + x(i+1)) / 3;

kopiert von: http://www.mindstormsforum.de/viewtopic.php?t=4898

ein rtos braucht man eigentlich nicht.
bringt nur overhead und nicht lesberen code.
raceconditions kann man auch auf die einfache art und weise produzieren.

habe schon gestaunt über freertos ... wobei 8.x schnellere kontextwechsel erlaubt.

@exec
openpilot: was ist da wieder los?
hat der choleriker david wieder mal gewütet?

An x(i+1) ranzukommen wird halt schwer in nem "Echtzeit" System

Ansonsten habe ich als einfachste Variante auch die einfache Mittelung implementiert und alternativ einen CIC filter wo man die Ordnung und den differential-delay Anpassen kann: http://www.embedded.com/design/conf...nderstanding-cascaded-integrator-comb-filters

Ich denke ein RTOS hat Vor- und Nachteile. Wenn man möglichst Resourcen schonend arbeiten will, muss man wohl auf ein RTOS wegen des Overhead verzichten, und alles "fest verdrahten".
Was sich wohl aber eher negativ auf die Erweiterbarkeit und Flexibilität auswirkt.


Was OpenPilot angeht, da bin ich nicht involviert und habe auch nur ein paar Eindrücke von Außen aufgeschnappt.
Taulabs hat sich ja auch von OpenPilot abgespalten weil man sich uneinig war wie offen das ganze seien soll.

Ähnliches hat wohl wieder stattgefunden.
Es wurde meines Wissens nach erst OPNG gegründet, die alles mehr "schließen" wollten. Die haben glaub ich auch die Kontrolle über die Domain und das Forum.
Das passte einigen Entwicklern, vor allem wohl welchen die schon länger dabei sind, nicht. Die haben einen neuen Fork aufgemacht, LibrePilot.

Mein Eindruck ist das ein Großteil der Entwickler die am bestehende Code mitgewirkt haben nicht mehr bei OpenPilot/OPNG dabei sind.
Entweder schon früher zu Taulabs abgewandert, oder jetzt zu LibrePilot.

Zwischen Taulabs und LibrePilot gibt es auch Kontakte und man schaut wie man zukünftig evtl. zusammenarbeiten kann.

ach je
>An x(i+1) ranzukommen wird halt schwer in nem "Echtzeit" System
aber immerhin gibt es für eine berechnungsrunde mehrere samples.
eine indextransformation gefällig?

lol

habe gerade etwas über librepilot gelesen.
wobei david schon ein extrem choleriker ist.
ich denke nicht, das opng richtig produktiv ist.
es geht einfach zu viel zeit in die entwicklung rein.


bin am lesen des cic filter papers...

bei den audio- oder dsp guru's wird man oft fündig
wenn es um signalverarbeitung geht:
https://github.com/audiofilter/spuc/blob/master/spuc/cic.h