Funktionieren bei Euch Kompass und Baro vernünftig ?

Roberto · Jun 3, 2012

@Martinez
Es gibt mehrere Probleme bei dem Orig MWII Code.
Wie dieser Code suggeriert:

Code:

#define UPDATE_INTERVAL 25000    // 40hz update rate (20hz LPF on acc)
void getEstimatedAltitude()

werden alle 25ms neue Werte besorgt und verarbeitet.
Das ist definitiv falsch. Es werden bestenfalls alte Werte, mit dem gleichen Ergebnis ausgewertet.
Wenn man die Zeit misst, die vergeht, bevor tatsächlich eine neue Berechnung mit neuen Werten möglich ist vergehen 94-100ms! D.h. die tatsächliche Updaterate ist nur 10 HZ! Die Messung basiert auf dem BMP085. Das ist im Prinzip auch nicht weiter tragisch, kein Fehler und hat mehrere Gründe: Zum einen wird der Baro und der getEstimatedAltitude Code nicht bei jedem Durchlauf ausgeführt, zum anderen wird bei dem BMP m.E zu häufig eine neue Temp.Korrektur durchgeführt/ausgelesen.

Jetzt kommt, wie ich finde, der Hammer:
Die gemessene Höhe (mit BMP getestet) ist abhängig davon, ob der RC Sender eingeschaltet ist!!!! Bei der alten original - Hackelkurve war das schlecht zu sehen, aber vorhanden! Mit der neuen Kurve konnte ich es deutlich bei dem BMP085 sehen! Ich habe es so reproduzierbar festgestellt:
-Mod 5b
-Kurve mit ausgeschaltetem Sender beobachten, dann RC Sender einschalten, warten und beobachten, RC Sender ausschalten, beobachten, usw.
Ich habe es mit PPM und getrennten Kanälen getestet.
Wie kann die gemessene Höhe von dem RC Sender (FrSky 2,4 GHZ) beeinflusst werden? Wie kann der RX Code den Barocode beeinflussen? Ich vermute Übles. Wenn Ihr Zeit habt, schaut mal bitte, ob das bei euch auch so ist (z.B MS)

LG
Rob

DerCamperHB · Jun 3, 2012

Sollte evtl für FS Auto landen der Baro automatisch deaktiviert werden, wenn Signal fehlt?
Oder hast du evtl eine SOllwertvorgabe angesehen, bzw wird diese in der GUI angezeigt, nicht die tatsächlich gemessene

Roberto · Jun 3, 2012

@DerCamperHB
Die Gui zeigt EstAlt an. Failsave ist in der config.h (Dev 20120528)deaktiviert. Merkwürdig, merkwürdig....

DerCamperHB · Jun 3, 2012

Deaktivierte Optionen und Anzeigenamen müssen ja nicht immer was mit der Wirklichkeit übereinstimmen

Roberto · Jun 3, 2012

Da hast Du wahrscheinlich Recht!
Ich kann das Problem nicht genau lokalisieren, aber das Abschalten des Failsafes scheint tatsächlich einen Einfluss zu haben.
Aktuell schlägt sich das Problem "nur" in einer schlechteren Genauigkeit und grösseren Schwankungen des Baros nieder. Deswegen mache ich erst mal weiter.
Den Variometercode habe ich jetzt fertig. Ein grobes Variometer mit +- 35cm/sec Totzone und einer Updaterate von ca 450ms funktioniert schon mal mit dem BMP085. Mal sehen, ob man damit wenigstens in groben Zügen das relative Steigen und Sinken oder eine Autolandung hin bekommt.

LG
Rob

P.s.: Das Multiwiiforum kommt nicht aus den Hüften (http://www.multiwii.com/forum/viewtopic.php?f=8&t=1777). Es gab jedoch einen Tip zur Realisierung einer Baroautolandung (http://www.multiwii.com/forum/viewtopic.php?f=8&t=1356#p12323).

helste · Jun 3, 2012

Rob, wie würdest Du denn die zu erwartende Genauigkeit in der Höhenregelung mit dem BMP085 einschätzen? Wenn ich teste und das Teil schwankt innerhalb von 4m und das ist das was man erwarten kann und nicht mehr, dann macht es ja keinen Sinn, wenn ich nach Fehlern suche, wo keine sind.
Wenn das aber deutlich genauer gehen sollte, dann muss ich prüfen, woran es liegen kann, dass es nicht genauer geht.
Bei Windstille geht es schon etwas besser, aber da bleibt der Kopter auch auf Höhe, wenn ich nur eine gute Position mit dem Gashebel finde. Da bleibt er (beim Schweben zumindest) sogar genauer auf Höhe als mit zugeschaltetem Baro.

Dann würde mich noch interessieren, wie man beim PID Tuning am besten vor geht. Da fehlt mir komplett der Plan.
Mit welchen Werten fange ich am besten an und bei welchem Verhalten gehe ich mit welchem Parameter in welche Richtung?
Bei den PID Werten für die Fluglage habe ich das schon durchblickt und da kriege ich es auch hin, aber für Höhe habe ich da keine wirklich vernünftige Anleitung gefunden.

Roberto · Jun 3, 2012

@Helste
Die räumliche Auflösung des BMP liegt bei ca 30cm, die zeitliche Auflösung ist jedoch das Problem. Es muss viel gemittelt werden.
Ausserdem scheint der mwii code in diesem Punkt verbesserungswürdig zu sein, da er nur alle 100ms einen neuen Wert liefert.
Wenn ich dann noch sehe, dass es ohne Funke ein besseres Signal zu geben SCHEINT (berechtigter Einwand von CamperHB), bin ich natürlich dran. 4m Varianz sind schon nicht schlecht, aber 1m müsste man m.E noch "wegprogrammieren" können. Also ehrlich, bei der PID Einstellung fehlt mir auch noch der Plan. Ich mache es z.Zt noch wie in der Anleitung: Alles auf 0, D erhöhen bis es pendelt, dann P hoch. Mit I spiele ich nacher herum. Ich glaube die Auflösung der P und D Parameter zu erhöhen, ist keine schlechte Idee und bereits umgesetzt. Nur der Test fehlt noch.

LG

ROB

Joachim08 · Jun 3, 2012

Ich bin mir nicht sicher , ob die Weise wie die Höhenregelung aktiviert wird die richtige ist.
Ich zitiere mal aus dem Wiki von http://www.mikrokopter.de/ucwiki/Höhensensor?highlight=(höhenregler)

"Der Höhenregler wirkt wie ein Dach. Wenn man den Sollwert auf einen Schalter der Funke legt, wird der beim Umlegen des Schalters der aktuelle Höhenwert als Sollwert übernommen. Die Höhenregelung wirkt als Abschwächung auf den Gaswert, der an der Funke eingestellt ist, wenn der MK den Sollwert übersteigt. Ist der Gaswert der Funke höher als das Schwebegas, so kann der MK die Höhe halten. Nach unten kommt man immer, indem man das Gas an der Funke unter das Schwebegas zieht. Nach oben begrenzt die Höhenregelung das Gas. Man muss also mehr Gas geben, als ohne Höhenregelung zum Halten der Höhe nötig wäre. "

Wäre das nicht eigentlich die logischere Weise die Höhe zu halten ?
Beim Multiwii verstehe ich nicht, daß er plötzlich um mehrere Meter absackt und eigentlich keine Gegensteuerung mit Erhöhung der Motordrehzahl erfolgt.
Wenn man mit dem Gasknüppel die Höhe vorgibt fehlt da doch immer ein wenig "Reservegas" oder nicht ? Jedenfalls merke ich nach dem Umlegen des Schalters für die Höhe nichts. Beim MK wird nach umlegen des Schalters noch ca. 10 % Gas dazugemischt um Regelreserve zu haben.

Oder fehlt es da vielleicht an Rechenleistung ?

Grüße

Joachim

helste · Jun 3, 2012

Ich war gerade mal eben im Garten Junior wollte den kleinen umgebauten Quad bei Dunkelheit ausprobieren, weil er ja Licht dran hat. Habe das gleich genutzt und nochmal getestet. Es war absolut windstill. Habe den Quad auf ca. 5-6m Höhe gestellt und dann den Baro zugeschalten. Das sah sehr gut aus. Hat die Höhe in einem Korridor von ca. 1-2m gehalten. Dann bin ich so den Garten rauf und runter geflogen (einfach volles Programm Nick nach vor und dann wieder zurück). Dabei wurde die Höhe gut beibehalten.
Irgendwann zwischendurch ist er mal etwas weiter runter und ich musst Gas nachschieben, damit er mir nicht den Bambus stutzt.
Danach bin ich wieder auf die gleiche Höhe, aber mit abgeschaltetem Baro. Habe einfach den Gashebel so eingestellt, dass er die Höhe hält. Da stand er super stabil in der Höhe und schwankte so gut wie gar nicht. Jedenfalls weniger als 0,5m.
O.k., am Stand ist klar, aber was passiert ohne Baro, wenn ich vorwärts fliege. Also Nick nach vor und volles Geschäft den Garten rauf. Den linken Daumen immer am Gashebel um im Notfall den Bambus zu retten;-)
Interessanterweise hat er aber keine Höhe verloren, zumindest nicht entscheidend. Am Rückweg genauso nicht. Ich bin dann ein paar mal hin und her, aber kein Problem mit der Höhe. Irgendwie merke ich da eigentlich keinen wirklichen Unterschied zum Alt Hold Modus, außer, dass er da eher mehr schwankt, weil er ja die Barowerte verarbeitet. Irgendwie komisch.
Morgen kann ich nicht fliegen, weil ich den ganzen Tage unterwegs bin. Dienstag Abend geht es weiter.

DeaconBlues · Jun 4, 2012

Samstag hab ich den Versuch gemacht, mir mit drei LEDs, die mir die Abweichung meines Copters zur Sollhöhe angezeigt haben, die Regelung im Flug zu kontrollieren. Mit den eingestellten Regelparametern (und der Modifikation im Sinkflug das Pid abzuschwächen) war der Copter fleissig am regeln und folgte in etwa der Druckfläche (+-1,0m). Bei dem Rückseitenwetter das herschte, mit frischen Wind und den Verwirbelungen in der Stadt, war es böig und turbulent.

Während der Copter für sich aus gesehen relativ in Ruhe war, tanzte er vor mir in einen Bereich von ca 6m. Das heißt das, die Regelung für sich funktioniert. Das von mir aus beobachtete Pendeln des Kopter kannn damit den Druckänderungen des Wetter zugerechnet werden. Ein Mittelwert über eine längere Zeit schwächt bestimmt diesen Efekt ab, würde aber auch zum Verzögern der Regelung führen.

Bodennah macht eine Höhenregelung über Baro damit wenig Sinn. Bei eine Höhenregelung über Baro in größerer Höhe, wo eine Änderung der Höhe von ein paar Metern kaum auffällt, sieht dieses anders aus.

Alternativ zur BaroHöhe bietet sich bodennah (je nach Sensor vieleicht 3 - ? m) eine Höhenmessung über Ultraschall an, in größerer Höhe geht natürlich auch die GPS-Höhe an. (ich werde mal probieren wie zuverlässig diese anzeigt, vermutlich ist das LSB größer 1m)

Gruß DeaconBlues

BMP085

Roberto · Jun 4, 2012

@Joachim08
@DeaconBlues
@Helste

Ich bin am verzweifeln mit dem Code und dem Wetter.
Der Baro PID Regler scheint eine Katastrophe zu sein.
Der Versuch die Baroausleserate/Updaterate zu erhöhen hat funktioniert (von 100ms auf 35ms Latenz->28Hz).
Die Mittelwertberechnung ergibt Kraut und Rüben mit dieser Rate!
D.h. neue Werteberechnung und neuer PID Kontroller -> ich bin am Boden zerstört.
@Joachim: So lange dass nicht funktioniert, brauchen wir uns um das wie keine Sorgen zu machen.
@Helste: Deine Beobachtungen decken sich mit meinen Feststellungen.
@DeaconBlues: Kannst Du einen gleitenden MW Filter für die MWII programmieren?

LG

ROB

Andi · Jun 4, 2012

Sonar /Ultraschall ist ja schon im Wii Code ,soll ab unter 3m die Reglung übernehmen, hab ein SRF08 Sonar drin http://www.nodna.de/Produkte/Sensor.../Devantech-SRF08-Ultraschall-Sensor--617.html
Aber irgendwie merke ich noch nichts , evt. muss ich mit den Werten noch mehr rumspielen.
Mit GPS Hold hielt er sauber die Höhe bei sehr wenig Wind , pendelte dafür seitlich um die 2m um die Hold Postition.

(flyduino Mega mit GPS und Drotek "IMU 10DOF-MPU6050+HMC5884+MS5611" und SFR08 Sonar ; Software neuste Multiwiifiles von 31.5.2012)

Andi

DeaconBlues hat gesagt.:

DeaconBlues · Jun 4, 2012

Hi Roberto,

ein Mittelwert wird in der Routine getEstimatedAltitude erzeugt, EstAlt ist ein gemittelter Höhenwert. Setz den Wert BARO_TAB_SIZE von 40 auf 200 (5 sek) und alles wird glatter. Aber Änderungen der Höhe werden dann natürlich sehr spät wahrgenommen. Zum schnellen Reagieren einer Steuerung dann nicht mehr so richtig zu gebrauchen.

Alles gebastele von mir an der Sensorausleseroutine sowie an der getEstinateAlt haben nicht viel gebracht. Das Baro pendelt um 1m. Damit werden wir uns wohl anfreunden müssen. Auch in der Sensorausleseroutine war gewisses Potential zu sehen, hat aber auch nicht viel gebracht. Ob OSS 2 oder 3, unnütze Warterei entfernt usw.

Auch das Wetter hat Einfluß auf den Druck, nicht nur Zyklone und Hochdruckgebiete (die uns das Wetter gestallten) sondern das Microklima sorgt lokal für ständig für Änderungen des Drucks. Ich denke auch das Änderungen der Windgeschwindigkeit Änderungen des Drucks hervorrufen. (war da nicht was mit Bernoulli?) Je nach Wetter sind dann große Sprünge möglich.

Zum Vergleich. Mein Flugvario (Bräuniger Competion GPS) hat auch pendelnde Höhe wenn ich am Boden stehe. 2 bis 3m sind da schon drinne. Die Zeiten zum mitteln sind dort aber um einiges höher angestetzt. Mein Garmin 76CSX verhält sich vom Baro her genauso. Die GPS Höhe werde ich noch mal austesten. Aber von der Natur der Sache her wird dort auch kein genauer Wert angezeigt werden, kleinste Einheit ist ein Meter in der Anzeige.

Ob sich aus den Sensordaten des ACC und des Gyros Lageänderungen in der Z-Achse ableiten lassen die man auswerten kann und dieses mit in die Regelung der Höhe mit einbauen kann, könnte ich mir vieleicht vorstellen, doch leider fehlt mir die mathematische Reife um mit den 3D Vektoren gescheit umzugehen. Oder habe ich den Baum im Wald nicht gesehen.

Ich habe mir erst mal ein SRF08 bestellt, vieleicht bastele ich mir aber auch ein HC-SR04 USchall an den Copter und probiere damit weiter.

Gruß DeaconBlues

bigbretl · Jun 4, 2012

Servus,
ich verfolge schon die ganze Zeit eure Fortschritte. Nur kann ich leider noch keine qualifizierten Beiträge dazu leisten und den neuen Sketch konnte ich noch nicht testen. Die geglättete Barolinie ist jedoch schon vielversprechend. Wenn ich Ergebnisse dazu beitragen kann kommen diese auf jeden Fall. Ich will jetzt für die Bodennähe den Sonar mit einbinden. Von Andi habe ich dann schon Hilfe bekommen. Nur habe ich keine Ahnung wo ich ihn auf dem Flyduino Mega anschließen soll, da ich nicht weiß ob er für I2C oder serial vorgesehen ist. Hier mal der Sensor: http://www.goodluckbuy.com/ultrasonic-wave-detector-ranging-module-distance-sensor.html
In der config.h finde ich auch nichts zum aktivieren des Sensors.
Ich habe übrigens den Schaumstoff nicht direkt über den Sensor gelegt, sondern die gesamte "Etage" des Sensorboards am Rand mit leicht verdichteten Schaumstoff umrandet. Dabei hatte ich Schwankungen von ca. 3 m.
Gruß bigbretl

DeaconBlues · Jun 4, 2012

Hi BigBretl,

so ein Teil habe ich auch liegen. Der Sensor misst bis ca 3m Abstand. Du brauchst 2 frei I/O Pins. Ansteuerung und auslesen ist einfach, wenn du Zeit hast. Hast du aber nicht. Also InterruptRoutine. In der Version von Alex Mos (gehe ein paar Einträge zurück, Roberto hatte einen Link eingesetzt) ist dieser Sensor verbaut. Mit einer entsprechenden InterruptServiceRoutine. Er nutzt A2 als Trigger und Pin12 zum einlesen. Seine Version ist für einen ProMini, er sagt für Mega hat er die ISR-Routine nicht eingebunden, bzw kontrolliert ob es passt. Ich muß für mich auch erst einmal die Datenblätter wälzen. (Mega)

Gruß DeaconBlues

Roberto · Jun 4, 2012

@DeaconBlues
Dieser Mini Taskscheduler im Mainthread ist auch merkwürdig. Wenn man z.B kein Sonar oder GPS oder Magnetometer hat, wird jeweils ein kompletter Durchlauf ohne Baro verbraten. Das war in der orig 2.0 anders. Bei BMP085/Sensors habe ich auch verschiedene Timings durch. Diese magischen 5ms am Ende scheinen wichtig für die Funktion zu sein (im Datenblatt nicht gefunden!) Die Temp Kalibration nur alle Sekunde (1Hz) durchzuführen bringt auch nicht wirklich was. Aktuell SCHEINT mir die optimale Lösung für den BMP085 OSS = 3, timings etwas schneller (4,5 ms Temp; 25,5ms Baro), und alles raus aus dem "Taskscheduler", was nicht verbaut ist. Damit komme ich auf eine Updaterate von 20Hz (50ms/Cycle).
Alexmos Code funktioniert leider nicht mit meiner Sensorkombi (BMA020,orig WMP,BMP).

LG
ROB

martinez · Jun 4, 2012

wenn ich die letzten Beträge hier durchlese, wird mir ja fast schwindelig....

Im Ernst, ihr habt es echt drauf!!! Weiter so und nicht aufgeben

Ich drücke alle Daumen die ich habe, dass die ganze Arbeit pralle Früchte trägt.

Leider bin ich heute wieder nicht dazu gekommen, bei mein Quad die PID Werte der ALT zu optimieren.
So ein s****ß Wetter, starker Wind gepaart mit Regen

Viele Grüße an die Programmierer und an die Codetester

Martin

Roberto · Jun 6, 2012

@martinez:
"Im Ernst, ihr habt es echt drauf!!!".
Ich leider nicht, sonst wäre das Problem gelöst!

@DeaconBlues
Wie sind Deine Erfahrungen mit der "Modifikation im Sinkflug das Pid abzuschwächen" ?

In der Zwischenzeit war ich nicht untätig.
Der Stand der Dinge:

1. Die Auslesegeschwindigkeit von netto 10Hz (100ms) habe ich auf 33Hz steigern können (

0ms) für den BMP. Deswegen gibt es auch keine Bügeleisenkurve mehr. Der Baroauslesecode (BMP&MS) hat eine deutliche Macke, er bezieht seine Zeit von der Variablen "currentTime". Diese wird jedoch nur einmal pro Durchlauf (ca. 4ms) aktualisiert. D.h. die Baro_update() kann nach meiner Auffassung nicht richtig funktionieren, da die Wartezeit (z.B 4,5 ms nach dem Temp Auslesen) dann zu kurz ausfällt, da diese 4,5ms einfach zu currentTime dazu addiert werden, und leider schon eine unbestimmte Zeit unbemerkt von "currentTime" verstrichen ist. Der Sensor wird ggf. zu schnell belagert, was zu Datenfehlern führen kann.
Alternativ kann man micros() benutzen um die tatsächliche Programmlaufzeit in Mikrosekunden zu bekommen. Vorschlag:

Code:

void Baro_update()
{
 if (micros() < bmp085_ctx.deadline) return; 
 TWBR = ((16000000L / 400000L) - 16) / 2;                                // change the I2C clock rate to 400kHz, BMP085 is ok with this speed
 switch (bmp085_ctx.state)
 {
  case 0: 
   i2c_BMP085_UT_Start(); 
   bmp085_ctx.deadline=micros()+4500-1; 
   bmp085_ctx.state++;
   break;
  case 1: 
   i2c_BMP085_UT_Read(); 
   i2c_BMP085_UP_Start(); 
   bmp085_ctx.deadline=micros()+13500-1; 
   bmp085_ctx.state++;
   break;
  case 2: 
   i2c_BMP085_UP_Read(); 
   i2c_BMP085_Calculate(); 
   BaroAlt = (1.0f - pow(pressure/101325.0f, 0.190295f)) * 4433000.0f; //centimeter
   newbaroalt=1;
   bmp085_ctx.state=0;
   break;
 } 
}

2. ACC & Baro
Es ist mir gelungen, schnelle Auf- und Abbewegungen mit dem ACC deutlich zu unterdrücken. Der Code ist nicht besonders kompliziert, aber IN DER HAND sehr wirkungsvoll. Praxistest steht wg d. Wetters aus.
Prinzip: In der Zeit ohne neue Barowerte (20-30ms) werden dauernd die Z Beschleunigungen relativ zur Ruhe (1 G Erdbeschleunigung) gemessen und nur die Extremwerte gespeichert (AccZLowest,AccZHighest). Ein Mittelwert ist nicht so gut, da z.B am Ende einer Beschleunigung die Werte negativ werden. Ich habe mir folgendes überlegt:
A. Wenn man die maximale Negativbeschleunigung als Absolutbetrag von der maximalen Positivbeschleunigung abzieht, sollte die Vorzugsrichtung (bei horizontalem copter) zu erkennen sein d.h. +/- steigen/sinken.
B. Wenn man jetzt die Gesamtamplitude (also einfach beide Absolutwerte addiert) nimmt, hat man die Stärke der Veränderung.
Wenn man A*B*Skalierungsfaktor von den "BaroPIDs" abzieht, kommt das gut hin.
Umsetzung:
Die Schwierigkeit liegt natürlich in der Einstellung des Skalierungsfaktors. Man will nicht immer neu kompilieren müssen um den Wert eben schnell zu ändern. Da ich in der GUI das D von YAW nicht benutze, habe ich es dafür zweckentfremdet. Jetzt kann man über das "D" bei "YAW" in der GUI oder dem LCD diesen Faktor einstellen. Ich skaliere noch um den Faktor 40. D.h. bei 20 kommt die Hälfte des errechneten Wertes durch, bei 40 alles, und bei 80 das doppelte. Setzt man D auf 0 kommt kein ACC Z mehr in die "BaroPIDs". Das echte D von YAW wird im Code auf 0 gesetzt. Die Lösung ist natürlich "dreckig". Ausserdem habe ich die Funktion auf den Levelmode begrenzt d.h. auf einen möglichst horizontal liegenden copter, weil ich den resultierenden Vektor bei Schieflage nicht berechnen kann.

3. Steuerverhalten / Neue Höhe
Das Kämpfen mit dem Throttlestick gegen die BaroPID und den ACC Z müsste jetzt weg/reduziert sein. Der BaroPID müsste jetzt leicht zu übersteuern sein. Variometerfunktion ist nicht umgesetzt.

4. Irgend etwas aus dem RC Code stört weiterhin empfindlichst die Barokurve. Mittlerweile glaube ich fast, dass es ein Hardwareproblem mit meinem Setup ist.

Bei erfolgreichem Praxistest gibts hier natürlich einen Download!

LG

ROB

P.s.: Hoffentlich funktionierts auch in der Luft!

Aktueller Stand der getEstimatedAltitude().
Diesen Code NICHT so einbauen, da im Hauptprogramm noch das YAW D jeweils gerettet werden bzw. auf 0 gesetzt werden muss.

Code:

///////////////////////////////////////////////
//Crashpilot1000 Mod getEstimatedAltitude ACC//
///////////////////////////////////////////////

#define UPDATE_INTERVAL 20000                                   // Means: Dont be faster (next Gen Sensors?) than this, because ACCZ needs values
#define BARO_TAB_SIZE   40                                      // 40 Values for moving average
//#define PIDVEL 30                                             // Strength of ACCZ IS DEFINED BY YAW D in the GUI! DIRTY HACK

void getEstimatedAltitude()
{
  uint8_t index;
  static uint32_t deadLine;
  static int16_t BaroHistTab[BARO_TAB_SIZE];
  static int8_t BaroHistIdx;
  static int32_t BaroHigh,BaroLow;
  static int16_t AccZLowest,AccZHighest;                        // ACCZ extremes
  int32_t temp32;
  int16_t last;
  last = accADC[YAW]-acc_1G;                                    // So UPacc is +, DWNacc is -
  if (last > AccZHighest) AccZHighest=last;                     // Set new ACC Extremes
  if (last < AccZLowest) AccZLowest=last;                       // Every run till next calc, at least while UPDATE_INTERVAL

  if (newbaroalt==1)                                            // Update only, if new Baro-values are available
   {
    newbaroalt = 0;                                             // Reset Boolean
    last = BaroHistTab[BaroHistIdx];                            // Do Baro Moving Average & calculate speed for D calculation
    BaroHistTab[BaroHistIdx] = BaroAlt/10;
    BaroHigh += BaroHistTab[BaroHistIdx];
    index = (BaroHistIdx + (BARO_TAB_SIZE/2))%BARO_TAB_SIZE;
    BaroHigh -= BaroHistTab[index];
    BaroLow  += BaroHistTab[index];
    BaroLow  -= last;
    BaroHistIdx++;
    if (BaroHistIdx == BARO_TAB_SIZE) BaroHistIdx = 0;
    if (currentTime < deadLine) return;                         // Break, if too fast
    deadLine = currentTime + UPDATE_INTERVAL; 
    EstAlt = BaroHigh*10/(BARO_TAB_SIZE/2);
    newestalt=1;                                                // Indicate, new EstAlt RDY
 
    BaroPID = 0;                                                // Calculate new PIDs
    //D
    temp32 = conf.D8[PIDALT]*(BaroHigh - BaroLow) / BARO_TAB_SIZE;
    BaroPID-=temp32;
    temp32 = AltHold - EstAlt;
    if (abs(temp32) < 10 && abs(BaroPID) < 10) BaroPID = 0;     //remove small D parameter to reduce noise near zero position
    //P
    BaroPID += conf.P8[PIDALT]*constrain(temp32,(-2)*conf.P8[PIDALT],2*conf.P8[PIDALT])/100; 
    BaroPID = constrain(BaroPID,-150,+150);                     //sum of P and D should be in range 150  
    //I
    errorAltitudeI += temp32*conf.I8[PIDALT]/50;
    errorAltitudeI = constrain(errorAltitudeI,-30000,30000);
    temp32 = errorAltitudeI / 500;                              //I in range +/-60
    BaroPID+=temp32;                                            // BaroPID +/-210
    // ACCZ
    if (rcOptions[BOXACC]){
      temp32 = AccZHighest-abs(AccZLowest);                     // temp32 is neg when dropping
      last =abs(AccZHighest)+abs(AccZLowest);                   // "last" stores the Amplitude
      temp32 = temp32*last;                                     // Bigger Amplitude, bigger Correction
      BaroPID -= (int32_t)conf.D8[YAW]*(temp32)/40;             // conf.D8[YAW] Is scalefactor for ACCZ, if it is = 40 then this is 1:1 Passthrough
      BaroPID = constrain(BaroPID,-310,+310);                   // +/- 100 (for ACC Z)
     }
    AccZHighest=0;                                              // Reset Values anyway
    AccZLowest=0;
   }
}

PPS: Hier http://code.google.com/p/multiwii/downloads/detail?name=MultiWii_dev_20120606.zip&can=2&q=
ist die neu MultiWii_dev_20120606.zip, die vor allem das Magnetometer verbessert. (Leider nicht Baro...)

Andi · Jun 6, 2012

@bigbretl , Sonar kannste momentan knicken (mit offiziell DEV )der code für z.b SRF08 Sensor I2C (Deiner hat kein I2C Anschluß ,aber da wird auch was dafür gebastelt) ist drin spuckt in der GUI sauber ein Wert aus ,aber es ist kein Code vorhanden der die Wert für die Steuerung benutzt.Alexmos aus dem Multiwii Forum hat eine Software Version wo das anscheinend über ein 2. Arduino eingebunden wird.Irgendwie steig ich da nicht ganz durch , ansatt man eine Sonarlösung mal fertig macht wursteln 3 oder mehr an einer eigenen Lösungen.

@Roberto
Hast Du dir das mit dem Sonar auch mal angesehen , die Werte wären ja vorhanden man müsste sie nur mit einbinden bzw. ein eigenen nur Sonarmodus ohne Baro. Hab mir das von Alexmos angesehen , aber das übersteigt meine fähigkeiten das so einzubinden das es auf Mini und Megaboards läuft.

Andi

martinez · Jun 6, 2012

@Rob:

Das hört sich ja alles sehr abenteuerlich an

Wahnsinn, dass mit dem ACC Z geht ganz schön in die Mathematik....

Haben wir hier nicht ein "Mathe/Physik-Profi"?

Leider bin ich noch nicht wieder zum fliegen gekommen

mal sehen was die nächsten Tage bringen...

Ich werde dann auch mal die neue DEV 20120606 auf mein Copter aufspielen....

Viele Grüße

Martin

Funktionieren bei Euch Kompass und Baro vernünftig ?

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Benutzer

Erfahrener Benutzer

Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer