Baro Code Änderungen

bigbretl

Erfahrener Benutzer
servus fdietsch,
mich hat immer gestört, dass man PosH zwar übersteuern kann, aber nach auslassen der Knüppel der Copter wieder zur alten Pos flog. Auf meine Anregung hin hat dann Roberto einen "Position Hold Override" (er nannte ihn dann Bigbretl-Mode) code eigefügt, der das PosH bei einem definierten Knüppelausschlag (wert kann selber bestimmt werden) auf Nick oder Roll das PosH ausschaltet und nach einer selber definierbaren Zeit (bei mir 0,3 sek) Ruhestellung des Knüppels in Mittelstellung, das PosH wieder einschaltet und somit diese Pos als neue PosH erkennt. Man kann somit ständig mit PosH fliegen und wenn du dir ne Kippe anzünden willst, lässt du einfach die Knüppel los. Für die Möglichkeit auf die vorherige Pos zurückfliegen zu wollen sehe ich keine Verwendung und wenn er zurück zur Startposition soll nimmt man einfach RTH.
In der Multiwii 2_1, welche von Roberto mit dem Barocode geändert wurde ist dieser Mode enthalten. Du brauchst ihn nur aktivieren, die Blinde Zone und Blinde Time, sind voreingestellt.
In der neuen dev wurde dies in ähnlicher weise eingearbeitet und kann bei //#define AP_MODE 20 // aktiviert werden.

Gruß bigbretl
 

fdietsch

Erfahrener Benutzer
Danke bigbretl,

Hab da noch einen Gedanken, Bei Wind treibts doch immer ein wenig von der Theoretischen GPSPposition ab. Außerdem braucht der WK(Wiikopter) immer erst mal einen Moment bis er sich an die GPS Position gewöhnt hat. Wenn man nun Hold aus und einschaltet (durch betätigen der Stics) ist zum einen immer erst mal ein Moment nötig bis er Wiider Holdet und er steht immer auf einschaltkoordinate + Windofset.
Man könnte doch statt aus und einschalten lieber den zu Holdenten GPS Punkt verschieben sozusagen GPS Koordinaten + Steuerbewegung(*Magnetischer Ausrichtung) Und die mit der Größe des Stickausschlages bestimmt man die GPS Fluggeschwindigkeit.
Ich hoffe ihr versteht wie ich es meine.
 

Roberto

Erfahrener Benutzer
fdietsch: Ich verstehe, Du willst quasi die GPS Koordinaten "fliegen" und der Copter folgt dann. Coole Sache eigentlich, aber direkt einen dicken Haufen Probleme mehr.

LG
Rob
 

fdietsch

Erfahrener Benutzer
Genau die Gps koordinaten sozusagen per stick vorgeben und der Kopter folgt.
Das mit den Haufen Problemen ignorier ich mal gekonnt. Der Vorteil wäre daß das Positionsgesuche beim ein und ausloggen wegfällt und er auch bei Wind an der Position bleibt wo man Ihn haben will .
 
@ watz: Sorry, Du bist hier grade untergegangen. Das klingt eher nach einem ACC Problem bei Dir. ... Acc Z - Wirkrichtung in der Gui überprüfen
Rob
... und Roberto hatte recht. Hätte ich nieeieieie gedacht; da mein Copter ja recht gut fliegt, wie bei YouTube zu sehen ist.
Habe eben einfach mal ACC Z invertiert und jetzt bleibt er ganz ok stehen, werden wohl mit den richtigen PIDs noch was besseres bekommen.
 

Roberto

Erfahrener Benutzer
Danke, Watz für Deine Info!!

Kannst Du vielleicht eben noch Deine Mwii Hardware angeben, damit wäre anderen vielleicht geholfen. Zuletzt hatten wir das Problem mit einem ADXL und verdrehter Z Achse, der sich im normalen "level" Flug vollkommen unschuldig verhielt.
LG
Rob
 
... der ACC - Z hat jetzt sogar eine Funktion

Kannst Du vielleicht eben noch Deine Mwii Hardware angeben ...
Meine aktuelle Konfiguration sieht so aus:
MultiWii 2.1 auf LZ Midi 3.2, X525 V3 Rahmen, XXD 2212 KV1000 Motoren, 10x4.5x2 Propeller, Hobbywing 20A ESC, Graupner MX-12 Junior 2,7 Ghz Fry Sky

.... genau wie in meiner Signatur halt, habe "nur" einen Flieger,
da ich keinen Modellbauhintergrund habe und bisher auch nie ein RC-Fluggerät hatte.

Habe also die LZ Midi Steuerung von Wolle, in einer fast aktuellen Version.
Bei der Wirkrichtung der Sensoren waren wir uns im Forum nie einig.
Einige Einstellungen waren für meine Hardware auf jeden Fall falsch.
Da mir einer aus dem Forum mit der gleichen Hardware auch diese Konfig bestätigt hatte,
fühlte ich mich auf der sicheren Seiten. Nur das Baro wollte halt nicht soooo super.

Was mich im übrigen sehr wundert ist, dass die Z-Achse des ACC bisher so wenig Bedeutung für die Flugstabilität hatte. Erst mit Deinem Baro-Code scheint die Software viel mehr aus der "MultiWii-Hardware" herauszuholen. Tolle Leistung; Danke dafür.
Mit dem Programmieren hab' ich's selbst nicht so ...
Versuche nur ein gnädiger Anwender zu sein.
 

Roberto

Erfahrener Benutzer
AUA! Danke, Watz für die Info!

Deine Signatur hatte ich natürlich nicht gesehen... wie beim Einkaufen, man steht vor dem Regal und sieht das Gesuchte direkt vor den Augen nicht!

Was mich im übrigen sehr wundert ist, dass die Z-Achse des ACC bisher so wenig Bedeutung für die Flugstabilität hatte.
Mich auch - da müsste ich mir nochmal die mwii-Codeteile Anschauen für den Level Modus. Wahrscheinlich fällt das Acc-z da unter den Tisch, oder bei verdrehtem Vorzeichen: über den Tisch :).

Ich habe mir mal die Anleitungen von Wollez angeschaut, da sind die Wirkrichtungen der Einzelsensoren für die config.h abgedruckt. War das ein Druckfehler in der Anleitung, oder ein Übertragungsfehler? Letztendlich ist die Interpretation der Werte Vereinbarungssache.
Wie dem auch sei, ich mache noch einen Hinweis über den Downloadlink.

LG
Rob

EDIT: Info zur LZ Midi 3.2 ist über dem Downloadlink ergänzt, und eine Liste mit bekannten Fehlern/Problemen ist hinzugefügt. (http://fpv-community.de/showthread.php?14199-Baro-Code-%C4nderungen&p=224135&viewfull=1#post224135)
 
Zuletzt bearbeitet:
Hallo Roberto,


beobachte eure Einträge schon lange. Habe auch ein Quadro mit der MultiWII und einem Baro vom Typ MS5611.
Habe mir die Finale Verion schon mal gezogen und alles eingestellt. Nun meine Frage zum Baro Modus. Ich soll ja mit dem Modus 1 anfangen. Ist dann diese Einstellung ok?

/*** AltHold Common Variables ***/
/***********************************************ONLY CHANGE IF REALLY NEEDED*/
//#define ALT_HOLD_THROTTLE_NEUTRAL_ZONE XX // Barologic1 XX is set to 20 and with Barologic2 XX is set to 50 per default
//#define MaxThrbaro (MAXTHROTTLE-50) // This is default uncomment to change
//#define MinThrbaro (MINTHROTTLE+10) // This is default uncomment to change
/***********************************************ONLY CHANGE IF REALLY NEEDED*/

/*** AltHold Common Variables SPECIAL ***/
/***********************************************ONLY CHANGE IF REALLY NEEDED*/
/* AccBaroLPF is off per default. ONLY USE THIS IF YOU HAVE VIBRATION PROBLEMS OR IF YOU HAVE MPU6050
Use at least AccBaroLPF 75 (75%) when you use MPU WITHOUT "MPU6050 Low pass filter setting"
Possible values: 0% up to 100% (strongest filter+delay), values probably useful >50%. Good combination for MPU seems to be: MPU6050_LPF_42HZ and AccBaroLPF 50 */
//#define AccBaroLPF 50
/* Visualize uncorrected RAW Accz Values in Debug0 (incl. Hardwarefilter - normally already activated with 20-25%, in case of mpu please activate at least MPU6050_LPF_42HZ)
and resulting vertical value in Debug1 incl. softwarefilter ("AccBaroLPF"), if activated */
//#define AccBaroDebug
/***********************************************ONLY CHANGE IF REALLY NEEDED*/

/*** BAROLOGIC 1 (DEFAULT) ***/
#define Barologic1 // Defines Old Style This is default
/***********************************************ONLY CHANGE IF REALLY NEEDED*/
//#define Softcount 5 // Defines how long in 100ms (5=500ms) the variobrake is applied during downmovement
//#define AltHoldBlindTime 5 // Time in 100ms after wich a new hight is locked. Softcount + AltHoldBlindTime should be 1 sec ("10")
/***********************************************ONLY CHANGE IF REALLY NEEDED*/

Gruß
Fridtjof
 
Zuletzt bearbeitet:

Roberto

Erfahrener Benutzer
@ Helipilot01: Willkommen hier im Forum!

Du hast hier leider nur die Hälfte gepostet. Wenn Du nur Barologic1 haben willst, und deswegen "#define Barologic1" definierst, muss Barologic2 auskommentiert sein, also so: "//#define Barologic2". Alternativ kannst Du auch alles auskommentieren, dann wird automatisch Barologic1 verwendet. Das würde dann so aussehen:
Code:
    /*** AltHold Common Variables ***/
    /***********************************************ONLY CHANGE IF REALLY NEEDED*/
    //#define ALT_HOLD_THROTTLE_NEUTRAL_ZONE XX  // Barologic1 XX is set to 20  and with Barologic2 XX is set to 50 per default
    //#define MaxThrbaro (MAXTHROTTLE-50)        // This is default uncomment to change
    //#define MinThrbaro (MINTHROTTLE+10)        // This is default uncomment to change
    /***********************************************ONLY CHANGE IF REALLY NEEDED*/
    
    /*** AltHold Common Variables SPECIAL ***/
    /***********************************************ONLY CHANGE IF REALLY NEEDED*/
    /* AccBaroLPF is off per default. ONLY USE THIS IF YOU HAVE VIBRATION PROBLEMS OR IF YOU HAVE MPU6050
       Use at least AccBaroLPF 75 (75%) when you use MPU WITHOUT "MPU6050 Low pass filter setting"
       Possible values: 0% up to 100% (strongest filter+delay), values probably useful >50%. Good combination for MPU seems to be: MPU6050_LPF_42HZ and AccBaroLPF 50 */
    //#define AccBaroLPF 50
    /* Visualize uncorrected RAW Accz Values in Debug0 (incl. Hardwarefilter - normally already activated with 20-25%, in case of mpu please activate at least MPU6050_LPF_42HZ)
       and resulting vertical value in Debug1 incl. softwarefilter ("AccBaroLPF"), if activated */
    //#define AccBaroDebug
    /***********************************************ONLY CHANGE IF REALLY NEEDED*/

    /*** BAROLOGIC 1 (DEFAULT) ***/
    //#define Barologic1                         // Defines Old Style This is default
    /***********************************************ONLY CHANGE IF REALLY NEEDED*/
    //#define Softcount 5                        // Defines how long in 100ms (5=500ms) the variobrake is applied during downmovement
    //#define AltHoldBlindTime 5                 // Time in 100ms after wich a new hight is locked. Softcount + AltHoldBlindTime should be 1 sec ("10")
    /***********************************************ONLY CHANGE IF REALLY NEEDED*/

    /*** BAROLOGIC 2 ***                            Change Altitude relative to throttlestick center ***/
    /* !! WARNING !!
       - When in Barologic2 YOU CAN NOT TURN OFF REGULATION COMPLETELY, use an Armswitch
       - DO NOT use together with "#define MOTOR_STOP" because they keep on running (see above)
       - DO NOT Start or Land in Altholdmode (can flip on ground)
       - DO small movements around Throttlestickcenter and WAIT for reaction to get used to it

       ENTERING ALTHOLD:
       Turn ON the baroswitch IN THE AIR and althold is engaged, before you can change the hight the controller waits till you reach the the central neutral zone
       with the throttlestick.
       
       EXITING ALTHOLD (DEFAULT):
       Turn OFF the baroswitch IN THE AIR and althold KEEPS ON RUNNING UNTIL YOU REACH THE CURRENT VIRTUAL THROTTLE WITH YOUR THROTTLESTICK - then you take over.
  
       EXITING ALTHOLD WITH #define Rapid_Exit_Barologic2:
       Turn OFF the baroswitch IN THE AIR and althold is disengaged immediately. So the current throttlestickposition is the real gas immediately.
       This is recommended when tuning althold mode "pid"
    */
    //#define Barologic2                           // Defines Althold relative to Throttlemiddleposition. Logic: Change targethight. For Safety: Do NOT land in this mode
    /***********************************************ONLY CHANGE IF REALLY NEEDED*/
    //#define Rapid_Exit_Barologic2              // Leave this commented to do Softexit.
    //#define Barologic2SpeedFASTER
    //#define Barologic2SpeedFASTEST
    /***********************************************ONLY CHANGE IF REALLY NEEDED*/
LG
Rob
 
Hi,
bin grade rein. Bei 4°C Copter fliegen ist nicht so fetzig... Nur gut das man mit aktiviertem Baro und PosHold die Hände in die Taschen stecken kann. Also, Barologic 1 mit Standard Werten funktioniert super. Er tut das was er soll, die Höhe halten. Zwei Sachen sind mir noch aufgefallen. Da bräucht ichg noch nen Tip ob das mit PID Tuning abzustellen ist oder ebend noch ne Eigenheit der Software:

1. beim aktivieren sackt er noch leicht durch, ca 0,5-1m
2. beim Fahrtaufnehmen verliert er auch noch Höhe.
Alles beides nicht groß störend und es lässt sich problemlos aussteuern bzw kann man sich drauf einstellen. Nur wenn das noch Eigenheiten der SW sind dann kann ich mir hier längere Tuningsessions sparen.
Nochmal einen großen Dank an Rob und die ganze Community.

Gruß Jan

PS:
Flydumega mit Freeim 0.43, 45cm Quad X
 

FireN

trägt sonst keine Brille!
kannst ja mal die baromod 2 probieren, ein video dazu gibts von mir ein paar seiten vorher, bei mir sackt er nur beim hin und her fliegen leicht ab (20-30 cm)

mfg
 
... War das ein Druckfehler in der Anleitung, oder ein Übertragungsfehler?
Letztendlich ist die Interpretation der Werte Vereinbarungssache. ... LG Rob
Bezogen auf meine Hardware meines LZ war es wohl ein "Fehler" in der Beschreibung.
Wolle war sich aber voll sicher, dass er super mit dieser Config fliegen kann.
Wie die genau ausschaut ist ja für Euch auch egal ....
Nicht alle im Forum waren, betreffend der Sensoren, der gleichen Meinung.

Denke, dass es unterschiedliche Revisionen der Hardware gibt.
Die Chinesen haben da ggf. mal was anders gelötet.
Mein FC kam wohl ganz frisch aus China, ggf. mit einer anderen
Sensorausrichtung als im Handbuch beschrieben (ob HW-Version V3.0, 3.1 oder 3.2mod kann ich nich' sagen).

Hatte 3 Tage lang auf die Kurven geschaut, neu Compiliert und
hochgeladen und in den Foren gesucht, um die Werkrichtungen zu ergründen.
NajJa, das Teil fliegt schon recht klasse, auch wenn noch der BOSCH-Baro am Werk ist.
Wolle hat ja jetzt sein LZ Midi 4.0 am Start, welches viele neue Sensoren verwendet.
Würde mir dann halt nur noch mehr Speicherplatz Wünschen.

Um es noch einmal zusammenzufassen. Die Möglichkeiten des ACC in Z-Richtung wurden
wohl bisher von der MultiWii 2.1 nicht so recht gewürdigt.
Ohne Baro Fliegt mein Copter genauso gut wie; bevor ich die Z-Achse des ACC gedreht habe.
Dummer Weise gibt es beim ACC-Z ja auch Ausschläge in beide Richtungen.
Meine aktuellen PIDs sind ausgehend vom Standard etwas höher.
Für P habe ich statt 4, 8 oder 8,5 genommen. Auch I ist etwas höher.

Das es wirklich so is' kann ja auch jeder selbst testen.
Ohne Baro den Kopter über'n Kopf halten und bei mittlerer Drehzahl
nach oben und unten schwingen lassen.
Eigentlich sollte er der Bewegung entgegenwirken, was er jedoch nicht tut ...
P.S. auch JAW finde ich schlecht repräsentiert ;-) Nick & Roll ist immer Super!
P.P.S.gleich geht's zum Grünkohlessen für alle und Horrorwichteln für die Frauen ... freu!
 

Roberto

Erfahrener Benutzer
@staroman:
...
Er tut das was er soll, die Höhe halten. Zwei Sachen sind mir noch aufgefallen. Da bräucht ichg noch nen Tip ob das mit PID Tuning abzustellen ist oder ebend noch ne Eigenheit der Software:
1. beim aktivieren sackt er noch leicht durch, ca 0,5-1m
2. beim Fahrtaufnehmen verliert er auch noch Höhe.
...
Zu1: Die "aktuelle" Höhe, die Dein Copter erkennt, hinkt der tatsächlichen Höhe immer etwas nach (BMP grössere Latenz als MS). Ich habe den Softwarefilter schon knapp bemessen um möglichst zeitnah zu sein. Beim aktivieren des Althold kann natürlich nur die bekannte Höhe verwendet werden. Der einzige Parameter, der die Zielhöhe berücksichtigt (und kennt), ist das "P".
Zu2: Das hat mehrere Gründe. Da das Barometer zu langsam für den Ausgleich im Gradeausflug ist, wird das Accelerometer dafür verwendet (Anmerk: hat NICHTS mit den "level" Pids zu schaffen!). Es gibt 2 Bezugssysteme. Das erste bist Du (Erde = "earth frame") und das andere ist der Copter. Das ACC mit seinen 3 Achsen sitzt fest im Kopter. Wenn der Copter nicht mehr waagerecht steht, entspricht die Sensor-Acc Z Achse nicht mehr der interessanten Erd-Lotrechten. Es wird daher aus allen 3 Acc Achsen die Beschleunigung zur Senkrechten berechnet, d.h. das ist dann das errechnete ACCZ. Das kannst Du Dir mit "#define AccBaroDebug" in debug1 auch anzeigen lassen (debug0 zeigt den rohen Sensor accz Wert an). Wenn der Copter jetzt auf Tour geht, messen die ACC eben auch mehr oder weniger die auftretende Horizontalbeschleunigungen und das Ergebnis für die reine Vertikalbeschleunigung wird verfälscht. Deswegen habe ich einfach einen Kippwinkel abhängigen Faktor definiert, der bestimmt, wie stark die errechneten Accwerte in die Gesamt-Z-Beschleunigungssumme über die Zeit (= Geschwindigkeit) eingehen kann. Das ist Mathematisch sicher nicht korrekt, hat sich aber im Flug bewährt :) (Bei der APM wird noch über einer mathematisch korrekten Lösung gebrütet, die Arduino umsetzbar ist und im Simulator funktioniert.)
Was kannst Du machen? Zum einen sollte Dein ACC möglichst zitterfreie Werte liefern, also in Deinem Fall "#define MPU6050_LPF_42HZ" ggf. kannst Du noch den Software LPF zuschalten: "#define AccBaroLPF 50" zum anderen kannst Du auch noch das "D" verwenden. Das "Alt D" ist nämlich speziell dafür gedacht. Es ist der Gas-Kippwinkel-Ausgleich, d.h. je mehr Du den Copter verkippst, desto mehr Gas wird schon mal gegeben, um den zu erwartenden Höhenverlust schon vorher auszugleichen.
Wie gesagt:
1. Dafür sorgen, dass Dein ACC gute Werte liefert, sonst kann man alles vergessen. (ggf Kurven anzeigen lassen)
2. Dann im Schweben das P hochdrehen, so dass die Höhe auch richtig gehalten wird. P ruhig etw. zu hoch, also nicht wie sonst, wo man das P eher etwas erniedrigt, wenn man denkt, dass es passt.
3. Dann die Variometerbremse "I" anpassen, bis Oszillationen minimiert/weg sind. Das "I" macht die Luft dicker, als wenn der Kopter in "Öl" fliegen würde
4. Das Abfallen im Flug mit "D" kompensieren. Ganz bekommt man es sicher nicht weg, aber es dürfte schon recht erträglich sein. Übrigens: auch der Naza "sackt".
5. Barologic2 ausprobieren :)

@watz:
Danke, für Deine ausführliche Rückmeldung!
...Hatte 3 Tage lang auf die Kurven geschaut,...
Da gab es mal einen Film "Männer, die auf Kurven starren" ! Tja, mit der Wollez - Hardware kenne ich mich nicht so aus (bis auf sein GPS :) ! ), vielleicht schreibt er hier auch noch einen Kommentar.
Jetzt läuft es auf jeden Fall bei Dir, und das freut doch!

Dummer Weise gibt es beim ACC-Z ja auch Ausschläge in beide Richtungen.
Deswegen: Alle anderen Kurven abschalten und die Verstärkung hochdrehen.

LG
Rob

P.s: Das ist schon fast eine Anleitung und wird gleich verlinkt :).
 
Zuletzt bearbeitet:

merlin4

Erfahrener Benutzer
Ich habe jetzt auch mal auf Kurven gestarrt.. :D .
Ausgangsbasis: ich habe momentan mein Crius AIO in Bearbeitung (also mit MPU6050) unter Verwendung der MultiWii_dev_r1232_NewBaroPID (da funktioniert mein GPS).

Ich habe jetzt #define AccBaroDebug aktiviert und unter Verwendung von
MPU6050_LPF_42HZ und
#define AccBaroLPF
folgende Ergebnisse erzielt, die ich aber in ihrer Bedeutung nicht wirklich verstehe (die angezeigten Kurven sind die ersten beiden Debug-Felder).
------------------------------------
Variante 1:
//MPU6050_LPF_42HZ
//#define AccBaroLPF
LPF_0.jpg
------------------------------------
Variante 2:
#define MPU6050_LPF_42HZ
#define AccBaroLPF 50
LPF_1.jpg
------------------------------------
Variante 3:
#define MPU6050_LPF_42HZ
#define AccBaroLPF 100
LPF_2.jpg
------------------------------------

Wie muss/darf ich jetzt diese Ergebnisse interpretieren? Ich vermute mal, dass ein deckungsgleicher Verlauf der Kurven optimaler ist.
Aufgefallen sind mir auch die Spitzen im positiven Bereich, die nie deckungsgleich sind (dagegen bei den unteren Spitzen schon).

Was empfehlt ihr mir denn hier? Wie sollte ich weiter vorgehen. Wie sieht eine optimaler Kurvenverlauf aus?

LG
Holger
 

Roberto

Erfahrener Benutzer
Hi, Merlin!

Wie muss/darf ich jetzt diese Ergebnisse interpretieren? Ich vermute mal, dass ein deckungsgleicher Verlauf der Kurven optimaler ist.
Genau!

Du hast Die Funktionsweise des LPF sehr schön dargestellt. Zum einen schwächt er die Stärke des Nutzsignals ab (Amplitude/Ausschlag) zum anderen kommt es zu einer zeitlichen Verzögerung (Kurvenversatz). Der Sinn dieses Filters ist, noch bestehende Motorvibrationen aus dem Regelsignal (Kurve debug1) zu entfernen. Deswegen sollten die Motoren laufen, damit man sieht was ggf. überhaupt zu bekämpfen ist (z.B das "Gewitter", das Martinez in seinen Videos hatte). Die Wirkung von MPU6050_LPF_42HZ kann man dabei nicht unmittelbar erkennen, da dieser Filter direkt im ACC chip ausgeführt wird, d.h die Vergleichsdaten sind nicht zugänglich.
Bei Deiner MPU würde ich mit "#define MPU6050_LPF_42HZ" den Baro testen, nur wenn es dabei Probleme geben sollte, dann würde ich den #define AccBaroLPF 50 ergänzen. Wenn es dann noch Probleme geben sollte, würde ich nochmal die mechanischen Ursachen angehen, bevor ich den AccBaroLPF weiter erhöhen würde.

LG
Rob
 
Zuletzt bearbeitet:

merlin4

Erfahrener Benutzer
Hi Roberto,

danke für deine Erläuterungen - und vor allem für den Hinweis zu den laufenden Motoren! Die liefen bei mir vorher nicht, das überlege ich mir immer mindestens 3 mal, bevor ich den Heli mit laufenden Propellern an den PC lasse (schlechte Erfahrungen will man ja immer selber sammeln).

Zum Unterschied jetzt mal die Kuven in max. Verstärkung (und Kopter steht ruhig am Boden):

//#define MPU6050_LPF_42HZ
//#define AccBaroLPF 50
LPF_0_max.jpg

und
#define MPU6050_LPF_42HZ
//#define AccBaroLPF 50
LPF_1_max.jpg

Diese Version will ich dann bei nächster Gelegenheit mal testen.

Zusätzliche Frage: geht die (untere) Kurve noch ruhiger oder bin ich bereits auf einem guten Weg?

LG
Holger
 

Roberto

Erfahrener Benutzer
geht die (untere) Kurve noch ruhiger oder bin ich bereits auf einem guten Weg?
Die Kurve ist PERFEKT, v.a bei 10 Facher Verstärkung! So lassen. AccBaroLPF sollte nicht nötig sein.
Wenn Du noch einen AccBaroLPF hinzu nehmen solltest, würde, wie Du auf Deinem Bild "Variante2" sehen kannst, die Amplitude kleiner, d.h. wenn Du bereits einen P Wert erflogen hättest, müsstest Du diesen dann etwas höher ansetzen (das "I" auch).

LG
Rob

Edit: Ich habe einen Link zu Deinen Beiträgen und Bildern über dem Download eingefügt (http://fpv-community.de/showthread.php?14199-Baro-Code-%C4nderungen&p=224135&viewfull=1#post224135)
 
Zuletzt bearbeitet:
FPV1

Banggood

Oben Unten