STM32F103C8 Plattformprojekt mit Display, FATFS, IMU MPU-9250 und Examples

brm · Mrz 26, 2017

habe gerade massig probleme mir der sd karte - 2gb geht und 4g nicht.
habe mir gerade die st treiber dazu angesehen ...

ptr = malloc(sizeof(uint8_t) * BlockSize);

idioten - ein statisch allozierter block macht mehr sinn.
dem dazugehörigen free traue ich nicht - fragmentierter speicher ...
und bei der st saftware ist gehöriges nase rümpfen angesagt.

es würde in zukunft auch sinn machen die sensorfusion aus der datei mpu9250.c herauszulösen.
irgendwie mag ich invensense produkte nicht mehr so ...
und wenn, dann nicht:
// no sample rate divider (0+1), accel: lowpass filter bandwidth 460 Hz, Rate 1kHz, gyro: lowpass filter bandwidth 250 Hz
runter auf 18x hz filter settings - in summe weniger probleme.

schon mal gut, dass beim pid regler ein pt1 element eingebaut wurde.

und tschüss.

nichtgedacht · Mrz 26, 2017

brm hat gesagt.:

Hi

ich hatte mit älteren Versionen auch Probleme die größeren Karten zum Laufen zu bringen. Das war aber ein Initialisierungsproblem. Mit dem Code, wie er jetzt ist, laufen alle meine Karten, auch welche mit 16GB. Komisch, das es bei Dir teilweise nicht geht. An dem malloc liegt es sicher nicht. Wie sollte der Code an der Stelle denn aussehen?
uint8_t block[BlockSize];
ptr = (uint8_t *) &block;
Ok, ist gebongt.

Der Kommentar ist doch Schall und Rauch. Tatsächlich wird mit 2. Parameter zur Zeit 92 Hz Filter für die Gyros ausgewählt. Das funktioniert sehr gut und zum richtigen Fliegen will man nur die Gyros.

Der Level Hold Mode funktioniert noch nicht gut. Es gibt Probleme mit der Stabilität des Reglers. Ich bin dem noch nicht auf den Grund gegangen.

Gruß
Dieter

brm · Mrz 26, 2017

gyros auf 92hz zu beschränken kann ein problem bereiten.
und für kampfschweber sicher kein problem.
ab 250 hz schaltet der gyro auf 8khz um - dann bist du zu langsam beim auslesen.

der 'swing' im level mode geht auf eine schlechte kalibrierung zurück.
acc ein bis zwei sekunden messen und mitteln pro achse.
dann mittels pythagoras im 3d raum die länge des statischen vektors rechnen.
nun hast du die units für 1G.
im gleichen atemzug das rauschen der gyros mitteln und speichern.
das reicht für's erste.

wenn du immer noch problem hast, kannst du eine 6 achsen kalibrierung vornehmen.
anton babushkin hat mal die mathe dazu sauber aufgegleist und im px4 repo abgelegt.

und bei ST code einfach immer gut die nase rümpfen.

nichtgedacht · Mrz 26, 2017

Du meinst also ich sollte den Parameter besser auf 184 Hz setzen? Ich war mit der Agilität und Regelqualität bisher sehr zufrieden auch im Vergleich zu Cleanflight.

Könntest Du mir für den Level Hold Mode Algorithmus und Parameter mal zeigen? Der Fusion Algorithmus hat ja selber noch einen Filter. Den damit zusammen zu bringen übersteigt meine Mathefähigkeiten.

brm · Mrz 26, 2017

der unterschied zwischen 184 und 92hz ist nicht riesig.
primär vibrationsdedingt.
zudem liegt die dynamik bei kleineren koptern höher - also deutlich über 120hz.
mit vibrationen und 84hz habe ich nicht allzu positive erfahrungen gemacht.
fliegt sich unter umständen hakelig ...

meine muttersprache ist nicht direkt deutsch ;-)
was verstehst du unter: level hold mode?
da sprechen wir aneinander vorbei

nichtgedacht · Mrz 26, 2017

Du hattest 92Hz Filter kritisiert als ungeeignet zum Racen. 184Hz findest Du auch niicht viel besser. Die Vibrationen und das Rauschen darf ich gar nicht wegfiltern lassen? Was ist denn Dein konkreter Vorschlag für die beste Lösung? So wie es jetzt ist reagiert er jedenfalls knackig und ohne Überschwingen. Er kann dem hin und her Schwingen des Steuerknüppels folgen wenn man den nur anstößt und loslässt.

Unter Level Hold Mode verstehe ich, dass der Copter die Horizontale zu halten versucht, also der Fusion Algorithmus mit Gyros und Accelerometers den Input für die Regler liefert.

brm · Mrz 26, 2017

der rc input liegt unter 10hz - das ist gaaaanz langsam auch in D

also die horizontale und nicht die vertikale lage.
das ist die kalibration die diesen swing bewirkt.
mache diesen schritt besser - ganz einfach wie oben besprochen - und rechne die gemessene skalierung in m/s.

der vorteil der einfachen kalibrierung ist, dass der vorgang in 2 sekunden vor dem fliegen durch ist.
damit kann eine temperatur korrektur in der ersten fassung entfallen.

nichtgedacht · Mrz 26, 2017

brm hat gesagt.:

Leider gehst Du nicht auf die Fragen aus meinem vorherigen Posting bezüglich Hardwarefilterung ein.

brm hat gesagt.:

Ich verstehe Dich nicht. Von welchem swing redest Du?
In meinem Code gibt es nur eine Kalibrierung der Gyros die dann direkt im IMU Chip abgespeichert wird.
Man sieht danach deutlich im Ergebnis, dass das Rauschen auf die Nulllinie gebracht wurde.

brm hat gesagt.:

Ich habe nicht verstanden, was Du oben ausgeführt hast und hatte um eine Erklärung gebeten.
Aus dem Fusion Algorithmus kommen quaternionen resp Winkel raus. Was hat das mit m/s zu tun?
Im Prinzip funktioniert in diesem Modus ja alles und ich kann die Bewegung des Copters im Raum korrekt
sehen wenn ich die Werte über USB virtual com port in die "Processing" Visualisierungssoftware einspeise.
Nur die Regler vertragen damit keine hohen Gain Werte.

brm hat gesagt.:

[/QUOTE]

einfachen kalibrierung, keine temperatur korrektur? Wovon redest Du da eigentlich ?

Ich finde Deine Antworten nicht wirklich hilfreich.

brm · Mrz 26, 2017

die filterung ist abhängig von den vibrationen und was besser ist hängt von den vibrationen ab.

generell sind filter prinziell wegzulassen.
da steht ein preisschild drauf:
- gebrauchte cpu zyklen zum berechnen / komplexität
- verzögerung
- phasenverschiebung

das möchtest du eigentlich nicht haben.
man kann filtern - je tiefer die frequenzen desto mehr beschneidest du die dynamik.
wenn diese zu stark beschnitten ist beginnt es zu 'rattern'.

fazit: rauf mit den frequenzen!

Code:

                if (channels[rc_mode] < L_TRSH)
                {
                    // attitude hold mode
                    // full stick equals ~250 degrees per second with rate of 8 (2000 / 250)
                    // gy range goes from 0 - 1000 [DPS]
                    diffroll = gy[se_roll] * se_roll_sign * rate[se_roll] - (float) channels[rc_roll] + MIDDLE_POS; // native middle positions
                    diffnick = gy[se_nick] * se_nick_sign * rate[se_nick] - (float) channels[rc_nick] + MIDDLE_POS;

                    // max 334 us
                    //millis[1] = HAL_GetTick();
                    //micros[1] = SysTick->VAL;

                    roll_set = pid(x, scale_roll, diffroll, pid_vars[RKp], pid_vars[RKi], pid_vars[RKd], 5.0f);
                    nick_set = pid(y, scale_nick, diffnick, pid_vars[NKp], pid_vars[NKi], pid_vars[NKd], 5.0f);

                    // max 403 us
                    //millis[1] = HAL_GetTick();
                    //micros[1] = SysTick->VAL;

                }
                else // mode 2 and mode 3 are the same currently
                {
                    // level hold mode
                    // full stick 45 degrees
                    diffroll = ang[roll] * 2000.0f / (M_PI / 4.0f) - (float) channels[rc_roll] + MIDDLE_POS;
                    diffnick = ang[nick] * 2000.0f / (M_PI / 4.0f) - (float) channels[rc_nick] + MIDDLE_POS;

                    roll_set = pid(x, scale_roll, diffroll, l_pid_vars[RKp], l_pid_vars[RKi], l_pid_vars[RKd], 5.0f);
                    nick_set = pid(y, scale_nick, diffnick, l_pid_vars[NKp], l_pid_vars[NKi], l_pid_vars[NKd], 5.0f);
                }

du verwendest einen einfachen pid regler und das erklärt einen teil deiner probleme im level mode.
hier würde ich einen kaskadierten pid regler einsetzen.

Code:

for (j = 0; j < 100; j++)

mit der anzahl von gyro samples kriegst du das rauschen nicht in griff.

und wo bitte realisierst du die accelerometer kalibrierung?
braucht es das nicht?

zuerst mal überlegen was der 'level mode' bewirken soll.
was ist die referenz zum 'level'?
einfach die acc werte lesen und damit die sensor fusion füttern ist ziemlich naiv.

und hier auf der erde reagiert eigentlich alles auf die temperatur - temperatur ausdehnung - schon gehört?
auch der mems chip kann sich diesem phänomen nicht entziehen.
und damit ändern sich die umrechnungsfaktoren.

Code:

Ich finde Deine Antworten nicht wirklich hilfreich.

hängt auch vom wissen ab - kopieren von code ohne zu wissen was man macht reicht nicht ganz.
https://developer.mbed.org/users/kylongmu/code/MPU9250_SPI/file/084e8ba240c1/MPU9250.cpp

nichtgedacht · Mrz 26, 2017

brm hat gesagt.:

Ich lese die Gyros nur mit 200 Hz aus und meine Idee war, dass ich das Low Pass Filtern der Hardware überlasse und dadurch mehr oder weniger unverrauschte Werte erhalte. In Cleanflight war der Filter im Default mal auf 41 Hz gesetzt. Vibrationen und Rauschen sind auf jeden Fall vorhanden. Wenn die Gyros mit höherer Frequenz ausgelesen werden, muss die Filterung in Software erfolgen, oder? Kann dadurch die Regelqualität besser werden? Dieser Teil funktioniert ja auch sehr gut.

brm hat gesagt.:

Ok, Dir erklärt es das vielleicht.
Ich bin gespannt, was Du aus dem Fork von meinem Repository machst.

brm hat gesagt.:

An dieser Stelle wird der Durchschnitt aus 100 Samples gebildet und das Ergebnis der Kalibrierung ist ein Ruhewert der Gyros der das winzige Rauschen ( 0.2 Grad / Sek) genau auf die Nulllinie bringt. Vergleiche mal die Abweichung ohne diese Kalibrierung.

brm hat gesagt.:

Da ich nicht im Level Hold Mode fliege hat mich das bisher nicht so sehr interessiert.

brm hat gesagt.:

Behauptest Du, das 1 Grad Abweichung von der korrekten Schwerkraftrichtung den Fusion Algorithmus stört?
Der weiß doch nicht wo unten ist.

brm hat gesagt.:

Von dem verlinkten Code habe ich zugegeben abgekupfert. Der bezieht sich aber nur auf das Auslesen der Sensoren. Es gibt dort auch keine Kalibrierung der Gyros in Hardware und kein Setzen des Low Pass Filters für ACC. Ich habe also nicht blos abgeschrieben sondern das Datenblatt von Invensense gelesen.

brm · Mrz 27, 2017

nichtgedacht hat gesagt.:

wenn es dich nicht interessiert, dann wundert es mich wieso du die gains höher haben willst.
deinen äusserungen ist zu entnehmen, dass regelungstechnik nie auf deinem stundenplan gestanden ist.

mit oversampling reduzierst du das rauschen und behebst antialasing fehler.
https://de.wikipedia.org/wiki/Antialiasing_(Signalverarbeitung)

200 hz ist bei kleinen racern knapp über über der eigendynamik.
ich ärgere mich mit der naza-m saftware schon über aussetzer in der regelung bei wind.
hier trennt uns einiges.
und ein grad abweichung ist ein horror.
für den ersten prototyp und proof of concept soweit ok, aber danach ...

hier mal was zum lesen: https://github.com/jihlein/BaseFlightPlus/blob/master/src/computeAxisCommands.c
einfach aber effektiv - soviel zum them kaskadierten pid loop.

was mich am fork interssiert, ist die sd-card anbindung.
da ist etwas oberfaul bei mir - aber ich habe es bis jetzt noch nicht gefunden.
ich verwende elm-chan fatfs - wie bei dir. also muss es das ansprechen der neueren sd-karten sein
die mir das problem bescheren ...

donvido · Mrz 27, 2017

brm hat gesagt.:

Mal angenommen eine Temperaturkompensation wäre tatsächlich notwendig, wie würdest du sie umsetzen?
Invensense liefert hier absolut null Information, was die Temperaturabhängigkeit ihrer Sensoren angeht.
Tagelang Messreihen im Kühlschrank und im Backofen aufnehmen? Nein Danke.

nichtgedacht hat gesagt.:

Ist tatsächlich so, dass ein kaskadierter Regler besser funktioniert was die Lageregelung angeht. Er kann nämlich viel schneller auf Störungen reagieren, da der Fehler (die Winkelabweichung) nicht erst entsprechend groß sein muss, damit das System ausreichend reagiert. Wenn der Regler für die Drehraten außerdem stabil ist, reicht ein einfacher P-Regler für die Lageregelung aus.

brm · Mrz 27, 2017

https://github.com/jihlein/BaseFlightPlus/blob/master/src/calibration/gyroTempCalibration.c
im code kannst du rerauslesen wie lange die messung dauert.
du kannst es auch über tage strecken ... vielleucht misst du ja mal die erdrotation

womit realisierst du deinen unterhalt?
nur ein versuch dich einzuschätzen ...

du sagtest doch, dass die gains bescheiden sind.
wenn man das ändern will muss man irgendwo ansetzen ...

donvido · Mrz 27, 2017

brm hat gesagt.:

Die Messung dauert 10 Minuten, weil er darauf wartet, dass sich eine bestimmte Temperatur einstellt. Leider steht da nirgends, in welchem Temperaturbereich er arbeitet. Außerdem finde ich es naiv, einfach (so wie Ihlein) eine lineare Abhängigkeit anzunehmen. Aber vielleicht hat er sich ja mal die Mühe gemacht und eine Kennlinie aufgenommen.

brm · Mrz 27, 2017

donvido hat gesagt.:

nun, was heisst naiv ...
mein physik professor hat schon anno domino gesagt, dass wenn man ein problem hat dieses vereinfachen soll.
wenn man dieses problem auf F = M * A reduziert hat, dann hat man einen fehler gemacht ...
ja, der temperaturverlauf ist nicht ganz so linear wie man es gerne hätte.
nur in gewissen bereichen ist der temp. verlauf linear, d.h. man teilt die temperatur in bänder/zonen ein in dem man vereinfacht rechnet.
in den tiefen der invense doku gibt es datenblätter die mehr über den temp. verlauf besagen.
wer sucht der findet ...
und mit einem stm32-f1 machen komplexe filter keinen spass - der determinismus leidet.

vor mehr als 5 jahren habe ich das thema mit dr. seb madgwick besprochen. er hat mir geraten als aproximation eine einfache lineare kurve kurve zu nehmen. dies sei für den itg-3200 ein muss weil das rauschen problematisch ist.

in der vergangenheit bin ich meistens eine PI-PD kombo geflogen, es wäre ein fehler das pt1 element auf dem d-term wegzulassen.
lately finde ich eine PI-PID kombo netter. obendrauf gibt es einen adaptiven controller der mir sicherstellt, dass die gerechnete propeller differenz des mixers erhalten bleibt.

donvido · Mrz 27, 2017

Hab grad mal die Product Spezification für die MPU-6000 rausgesucht, da stehts tatsächlich drin.
Sensitivity Scale Factor Tolerance 25°C ±3%
Sensitivity Scale Factor Variation Over Temperature ±2%
Nonlinearity: Best fit straight line; 25°C 0.2%

Aber mal ganz unabhängig davon, dürfte das für eine Flugregelung doch eher irrelevant sein.
Bei einer Drehratenregelung ist lediglich wichtig, dass die Gyros vorher genullt werden und bei einer Lagewinkelregelung muss eh der Beschleunigungssensor fusioniert werden, da es auf kurz oder lang sowieso zu einer Integratordrift kommt.

brm · Mrz 27, 2017

nein, es gibt dokumentierte abstürze.
die pixhawk 2 hat aus diesem grund ein heizelement um die imu auf einer konstanten temperatur zu halten.
http://www.proficnc.com/

alles ist relativ - ein heizkopter bleibt max. 8 minuten in der luft.
für fixedwing würde ich das problem ernst nehmen.

der integratordrift ist der tod des flugobjektes.
madgwick und mahony sind in der hinsicht anfälliger.
also integrator erst mal abschalten.

wenn die mems dinger mal vernünftig kalibriert sind reduziert sich das problem mit dem drift.
ohne magnetometer beträgt der drift dann ca. 1 grad pro minute.
für einen kopter ok.

donvido · Mrz 27, 2017

brm hat gesagt.:

Kannst du belegbare Quellen nennen?

brm hat gesagt.:

Aus diesem Grund wird ja auch mit dem Beschleunigungssensor fusioniert.
Was auch immer du mit "integrator erst mal abschalten" meinst

brm · Mrz 27, 2017

donvido hat gesagt.:

man sagt nicht gerne, dass flugkontroller problembehaftet sind ...
die ardupilot jungs haben aber genügend logs die das problem aufzeigen.
und wieso dann hw designen die die imu aufwärmen ?!?
vielleicht mal vorsichtig fragen ...

Code:

eepromConfig.KpAcc = 5.0f;  // proportional gain governs rate of convergence to accelerometer
eepromConfig.KiAcc = 0.0f;  // integral gain governs rate of convergence of gyroscope biases
eepromConfig.KpMag = 5.0f;  // proportional gain governs rate of convergence to magnetometer
eepromConfig.KiMag = 0.0f;  // integral gain governs rate of convergence of gyroscope biases

den integrator deaktivieren meinte ich.

interessant ist, dass geometrische schätzer wie multiwii/starlino weniger anfällig auf gyrodrift ist reagieren.
und ich mache meistens keine temp. kalibration. ich messe die empfindlichkeit des accelerometers bei der einsatztemperatur.
damit erschlage ich einen grossteil der drift problematik.

nichtgedacht · Apr 18, 2017

donvido hat gesagt.:

Hi

Ich bin mal dem Rat gefolgt und habe den Winkelfehler (Diff Sensorfusion - RC-Input ) als Setpoint für den vorhandenen erflogenen Drehratenregler genommen (einfach mit Faktor = 1). In der Hand wird es jetzt stocksteif und dabei stabil. Die Abtastrate habe ich von 200 auf 400Hz erhöht und die die Filterfrequenz ebenfalls verdoppelt.

Morgen wird gutes Wetter werden ...

Gruß
Dieter

STM32F103C8 Plattformprojekt mit Display, FATFS, IMU MPU-9250 und Examples

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer