Baro Code Änderungen

R

Roberto

Erfahrener Benutzer
#21
#21
Letzte Beta vor der Autobahn....

Ich habe die Alphaversion von oben noch bearbeitet. Grundlegend sind die beiden Versionen gleich. M.E ist es jetzt etwas besser.
Config.h ist noch nicht verändert. Eeprom clear sollte zwischen den beiden Versionen nicht erforderlich sein. Eine ACC Kalibration in der Gui kann allerdings nicht schaden!
Die Default Alt PIDs sind auf P 10,0 // I 0,030 // D 80 geändert. Den Althold - Funktionsbereich habe ich auf fast 90 Grad erweitert, d.h. Althold bleibt bis zu einem fast senkrecht stehenden copter eingeschaltet. Allerdings sollte man es im Althold modus zusammen mit dem Acromodus nicht übertreiben. Eine kritische Flugsituation habe ich beim Testen nicht produzieren können, Loopings im Altholdmode würde ich jedoch nicht emfehlen. Es ist als Sicherheitsmaßnahme (Altholdabschaltung) zu verstehen, wenn irgendetwas den copter auf den Rücken wirft (Propellerbruch etc).
Wenn jetzt keine Horrormeldungen mit anderen Sensoren kommen, baue ich die "Final" zusammen. Für die Final habe ich folgendes geplant:
1. Integration des PH / Bigbretl mods
2. Änderung der Config.h:
- Eine normale config.h kann man weiter verwenden d.h. es werden dann einfach Standardwerte gesetzt also PH Mod aus etc
- Geplante, zusätzliche Parameter:
#define AltHoldBlindTime 800000 (Zeit in microsec, die gewartet wird bevor eine neue Höhe für althold def. wird)

#define PositionHoldOverride
#define PosHoldBlindTime 300000
#define BlindZonePitch 30
#define BlindZoneRoll 30

LG

Rob
 

Anhänge

R

Roberto

Erfahrener Benutzer
#22
#22
Hi!
Die "Final" mit den Veränderungen (s.o) ist jetzt fertig. D.h. es ist das Althold der Beta aus dem letzten Post mit dem PositionHoldOverride - Bigbretl mod für GPS und den Änderungen der config.h bzw. der Bereitstellung der Parameter in der Config.h. Es funktioniert weiterhin, seine bestehende Config.h zu nehmen, dann werden einfach die Standardwerte genommen und Bigbretl nicht eingeschaltet. Ich würde diese Version gerne im Hauptthread hochladen, aber es wäre schön, wenn ich vorher noch eine Rückmeldung über die Funktion der alpha oder beta mit anderen Sensoren hätte!

LG
Rob
 
upapa

upapa

Erfahrener Benutzer
#23
#23
Roberto hat gesagt.:
Ich würde diese Version gerne im Hauptthread hochladen, aber es wäre schön, wenn ich vorher noch eine Rückmeldung über die Funktion der alpha oder beta mit anderen Sensoren hätte!
Zum Vergrößern anklicken....
Hi Roberto,
habe jetzt mal zur Abwechslung meinen CriusSE-Copter (BMA180, BMP085) mit der Vario3BETA bestückt. Konnte aus Zeitgründen leider nur ein Grobtuning vornehmen. Bin bei ALT bei P=8.5, I=0.022 und D=50 gelandet und kann Erfolg melden: :) Die Höhe wird gut gehalten, insbesondere auch bei Horizontalbeschleunigung (am Ende schwingt er etwas über). Die Regelung insgesamt ist leicht ruckelig. Kann aber auch daran liegen, dass die optimalen PID-Werte bei meinem Test noch nicht erreicht wurden.

upapa
 
J

JinGej

Gast
#24
#24
warum wird alt-hold nicht wie beim NAZA über steig/sink-rate gemacht? knüppelmitte=0 nach oben von 0,x bis 6m/s, nach unten das gleiche. das kann das NAZA genial, es sollte doch auch für die MultiWii möglich sein das zu programmieren.
 
R

Roberto

Erfahrener Benutzer
#25
#25
@Upapa: Danke für Deinen Test!!!! Stimmt, es ist mini ruckelig, da bin jetzt noch dran. Liegt am fehlenden LPF.
@JinGej: Das wäre jetzt möglich zu programmieren. Klar funktioniert das beim naza gut mit der Knüppelmitte. Spätestens, wenn Du zwischen Acro und Attimode umschaltest, wirst Du die Vorteile unserer Lösung erkennen. Aber Steig und Sinkratensteuerung muss ich noch angehen für eine FailsaveAutolandung.

LG
Rob

EDIT: 19Uhr: Das Rucklige ist jetzt weg! Der Testflug im kurzen "Regenloch" war erfolgreich.
Version 3 lade ich gleich im Hauptthread hoch. EDIT 2030: http://fpv-community.de/showthread....o-vern%FCnftig&p=200133&viewfull=1#post200133
 
J

JinGej

Gast
#26
#26
Roberto hat gesagt.:
@JinGej: Das wäre jetzt möglich zu programmieren. Klar funktioniert das beim naza gut mit der Knüppelmitte. Spätestens, wenn Du zwischen Acro und Attimode umschaltest, wirst Du die Vorteile unserer Lösung erkennen. Aber Steig und Sinkratensteuerung muss ich noch angehen für eine FailsaveAutolandung.
Zum Vergrößern anklicken....
ja, das stimmt mit dem umschalten, aber bei multiwii lässt sich das besser anpassen mit minthrottle im sketch als bei naza, da gibts ja nur 3 stellungen
...und... cool, dass das damit gehen kann und du das angehst - danke :)
 
R

Roberto

Erfahrener Benutzer
#27
#27
@JinGej: Mein letzter Steigratentest vor Wochen war ein Raketenstart im Wohnzimmer mit 3 1/2 schwarzen Kreisen an der Decke! Das dürfte mit der ACC Integration jetzt anders ausgehen.... Bevor die Zeigefinger - Zuschriften kommen: Ja, ich bin ein Vollpfosten, sowas testet man nicht im Wohnzimmer! Das Wetter war schlecht, der Copter klein, die Selbstüberschätzung nach dem Handtest gross und ich wollte ein Ergebnis...Egal - wer kennt einen guten Anstreicher ? - ROTFL - Aber für die Unverbesserlichen (wer damit wohl gemeint ist...- lol) wird es mit 80%iger Sicherheit noch einen zuschaltbaren NAZA-Modus geben. Was mich eigentlich sehr erfreut und zugegeben, auch wurmt ist, dass die Acc Integration eigentlich schon durch Alexmos FAST erledigt war und jetzt in den multiwii thread so aufbereitet wird, das ich es auch kapiere und das meine bisherigen Versuche nur knapp gescheitert sind. Die eigene Blödheit nervt mich allerdings nicht so sehr wie die VERMUTUNG, dass andere, kommerzielle Projekte (Rabbit, DJI und co) aus der open source Arbeit ihren finanziellen Nutzen ziehen, ohne etwas an Code an die Allgemeinheit zurück zu geben. Meine rein persönliche, nicht beweisbare Meinung: Es kann mir keiner erzählen, dass komerzielle multirotor flightcontrols im luftleeren Raum aus dem Boden gestampft werden, ohne dass auf die jahrelange opensource (Flug-/trail&error-) Erfahrungen von Multiwii und Arducopter zurückgegriffen wird.

LG
Rob
 
J

JinGej

Gast
#28
#28
Roberto hat gesagt.:
@JinGej: Mein letzter Steigratentest vor Wochen war ein Raketenstart im Wohnzimmer mit 3 1/2 schwarzen Kreisen an der Decke!
Zum Vergrößern anklicken....
aaaahahahahaa!! DAS kenn ich....

Roberto hat gesagt.:
die VERMUTUNG, dass andere, kommerzielle Projekte (Rabbit, DJI und co) aus der open source Arbeit ihren finanziellen Nutzen ziehen, ohne etwas an Code an die Allgemeinheit zurück zu geben
Zum Vergrößern anklicken....
tja, so sind sie... die chinesen.... traurig aber wahr
 
R

Roberto

Erfahrener Benutzer
#29
#29
******************************************************************
EDIT: WARNUNG: Insbes durch den Hinweis von UPAPA: Es kann dadurch allerdings auch schlechter werden!!
******************************************************************

Hi!
Da meine Nazastyle Versuche bislang alle mehr oder weniger in die Hose gingen, gibt es als Nebenprodukt jedoch eine weichere Änderung des Höhehaltens über den Gasknüppel (ist jetzt etwas mehr "Gummi" drin). Ich habe es mit folgenden config.h Einstellungen getestet:
#define ALT_HOLD_THROTTLE_NEUTRAL_ZONE 20
#define AltHoldBlindTime 500000

Versucht mal das hier:
In dem Hauptprogramm von MultiWii_2_1_NewBaroPIDVario3 (ca. Zeile 962) das hier löschen:
Code: 
  #if BARO
    Baro_update();                                                                                               // Do Baro every time!
    getEstimatedAltitude();
    if (currentTime >= ThrTime){                                                                                 //  Get ThrottleRate in Ticks/sec Upmovement=+ Polling at 10Hz
     ThrTime = currentTime+100000;
     ThrottleRate = (rcCommand[THROTTLE]-LastThrottle)*10;
     if (abs(ThrottleRate) < 150) ThrottleRate = 0;
     LastThrottle=rcCommand[THROTTLE];}

    if (rcOptions[BOXBARO]){           // New Logic: When User exceeds neutral zone and stops fiddeling with throttle, then after 1 second a new Althold is defined
      if (abs(rcCommand[THROTTLE] - initialThrottleHold)<ALT_HOLD_THROTTLE_NEUTRAL_ZONE && HightChange==0){
       rcCommand[THROTTLE] = initialThrottleHold + BaroPID;
       rcCommand[THROTTLE] = constrain(rcCommand[THROTTLE],MINTHROTTLE+1,MAXTHROTTLE-50);}
      else {
       HightChange=1;
       if (ThrottleRate==0 && AltHoldBlindTimer==0) AltHoldBlindTimer = currentTime+AltHoldBlindTime;}
      if (ThrottleRate !=0) AltHoldBlindTimer = 0;
      if (currentTime >= AltHoldBlindTimer && AltHoldBlindTimer !=0) f.BARO_MODE = 0;                            // Set new ref hight
     }
  #endif
Und durch das hier ersetzen:

Code: 
  #if BARO
    Baro_update();                                                                                               // Do Baro every time!
    getEstimatedAltitude();
    if (rcOptions[BOXBARO])
     {
      int16_t ActualThr=rcCommand[THROTTLE];
      if (currentTime >= ThrTime){                                                                 // 10Hz Loop Get ThrottleRate in 10Ticks/sec Upmovement=+
      ThrTime = currentTime+100000;
      ThrottleRate = (ActualThr-LastThrottle);
      if (abs(ThrottleRate) < 15) ThrottleRate = 0;
       else AltHoldBlindTimer=0;
      if (abs(ActualThr-initialThrottleHold)>ALT_HOLD_THROTTLE_NEUTRAL_ZONE) HightChange=1;
      LastThrottle=ActualThr;}

      if (HightChange==0) rcCommand[THROTTLE] = initialThrottleHold+BaroPID;
       else{
        rcCommand[THROTTLE] = ActualThr+constrain(BaroPID,-ALT_HOLD_THROTTLE_NEUTRAL_ZONE,ALT_HOLD_THROTTLE_NEUTRAL_ZONE);
        if (ThrottleRate==0 && AltHoldBlindTimer==0) AltHoldBlindTimer = currentTime+AltHoldBlindTime;}
      if (currentTime >= AltHoldBlindTimer && AltHoldBlindTimer !=0) f.BARO_MODE = 0;
      rcCommand[THROTTLE] = constrain(rcCommand[THROTTLE],MINTHROTTLE+1,MAXTHROTTLE-50);
     }
  #endif
Funktionsweise: "Baropid" wird einfach bei der Höhenänderung mit der alten Höhe im Rahmen der "ALT_HOLD_THROTTLE_NEUTRAL_ZONE" weiter verwendet.

Viel Spass beim Testen!

LG

Rob
 
FireN

FireN

trägt sonst keine Brille!
#30
#30
Hey,
ich hab mich extra hier angemeldet weil ich durch Google zufällig auf das Thema hier kam (habe MS Baro Probleme)
sobald mein neuer Rahmen ankommt werde ich das Testen und Rückmeldung geben ;)

Gute Arbeit! :)

MfG
 
R

Roberto

Erfahrener Benutzer
#31
#31
@FireN:
Herzlich willkommen im Forum!
Das Du Dich extra hier angemeldet hast wegen der Barogeschichte, und mir auch noch Deinen ersten Post schreibst, geht natürlich runter wie Öl! Danke. Aktuell bin ich mit der Throttlegeschichte noch dran. Das Ziel ist eigentlich, das Ändern der Zielhöhe so weich und sicher wie möglich zu machen. Aktuell kann es beim Höheändern noch etwa ruppig nach unten gehen. Immerhin funktionierts in der "final" jetzt schon besser als mit dem originalen "3 Zeiler". Aber dat machen wa schon.
Im offiziellen Multiwiicode gibt es auch deutliche Fortschritte. Wie dem auch sei, die nächste offizielle Multiwiiversion wird in diesem Bereich jedoch eine deutliche Verbesserung aufweisen.

LG
Rob
 
J

JinGej

Gast
#33
#33
so, also, die deutlichste änderung, die die vorläufige r1143 aufweißt ist, dass der code nun nicht mehr in meinen promicro passt :(
und ich glaube auch nicht, dass sich das bis zur 2.2 drastisch ändern wird, es sind immerhin ca 2000bytes zuviel
 
JUERGEN_

JUERGEN_

Generation 60++
#34
#34
JinGej hat gesagt.:
so, also, die deutlichste änderung, die die vorläufige r1143 aufweißt ist,
dass der code nun nicht mehr in meinen promicro passt :(
und ich glaube auch nicht, dass sich das bis zur 2.2 drastisch ändern wird,
es sind immerhin ca 2000bytes zuviel
Zum Vergrößern anklicken....
PROMINI war Gestern.

Heute gibts NAZE32. :D
 
R

Roberto

Erfahrener Benutzer
#35
#35
Hi!
Es ist schon traurig, dass manche ESC mehr als 4 mal soviel Rechenleistung haben als der Promini.
Ich glaube auch so langsam ist Schluss mit der Prominisache - soll man jetzt noch den Bootloader killen um noch einen LED Streifen ansteuern zu können? Kann man den NAZE auch hier in EU/DE kaufen?
@JinGej: Fast 2K am Ziel vorbei - das ist schon ein Wort. Ich bin in letzter Zeit kaum noch zu etwas gekommen. Zu der Gasmittegeschichte habe ich mir etwas überlegt, das vom Prinzip her ungefährlicher ist als die orig. Naza Lösung beim Umschalten. Na, mal sehen, ob ich das umsetzen kann.

EDIT: Prinzipiell ist ein neuer PID Kontroller für den Gaskanal fällig, wie z.B beim Arducopter. Noch mehr Parameter? Ich suche nach einem einfacheren Weg....

LG
Rob
 
R

Roberto

Erfahrener Benutzer
#37
#37
@Jürgen:
Was spricht eigentlich gegen den STM32F4? Den gibt es in der Geschmacksrichtung: 1MB FLASH und 192KB RAM.
Der Preis ist doch auch Ok (verglichen z.B damit: http://www.navstik.com/index.php/default/home-page-products/navstik-module.html) und zusammen mit meiner Freeimu 0.3.5MS könnte ich mir eines von diesen Boards auch gut vorstellen: http://www.watterott.com/de/STM32F4Discovery http://www.watterott.com/de/FEZ-Cerb40. Dein Board ist natürlich unschlagbar preiswert und hat direkt ACC & Gyro dabei - sonst sehe ich auf Anhieb keinen Vorteil. Für mich scheint es eher nachteilig zu sein: zu gross, Flash & Ram begrenzter, onboard IMU irrelevant - da Freeimu zum Einsatz kommt. Wie siehst Du das?

LG
Rob
 
JUERGEN_

JUERGEN_

Generation 60++
#38
#38
Roberto hat gesagt.:
Was spricht eigentlich gegen den STM32F4?
Den gibt es in der Geschmacksrichtung: 1MB FLASH und 192KB RAM.
Der Preis ist doch auch Ok (verglichen z.B damit ....
Zum Vergrößern anklicken....
:D
na du wirst lachen. ich habe schon 2 St. davon, und bin gerade dabei PX4 / NuttX RTOS zu studieren.
irgendwann soll ja auch die PX4FMU hier eintreffen. :)

für den kleinen brauchst du ja auch noch nen ST-LINK .

das ist dir sicher nicht entgangen ? -> https://github.com/lilvinz/OpenPilot/wiki/What-this-is-about

:)
 
R

Roberto

Erfahrener Benutzer
#39
#39
Es gibt wieder was zu berichten.
Nach diesem positiven Feedback von "Derjunior" http://fpv-community.de/showthread....o-vern%FCnftig&p=204516&viewfull=1#post204516 bin ich erstmal sprachlos gewesen - ein herzliches Dankeschön an dieser Stelle!

Auf der offiziellen Seite hat sich auch etwas getan. Mittlerweile gibt es die 2te Dev Version, nachdem es mit der ersten Dev Abstürze in dem neuen "Horizont" Modus gab. Mahowik's Änderungen fliessen in die aktuellen Devs ein. Seine aktuelle Version ist hier: http://www.multiwii.com/forum/viewtopic.php?f=8&t=2371&start=190#p23792. Natürlich habe ich sie mir angeschaut. Unser Bigbretl modus (GPS Position Hold override) hat übrigens, in abgespeckter Form, auch Einzug gehalten: Immer wenn Nick&Roll wieder in die Mitte kommen, wird eine neue GPS Position definiert. In unserer Version wurde erst nach einer einstellbaren Verweildauer in Stickmitte (Vorseinstellung 0.3 Sek) eine neue "PH" bestimmt, um nicht mitten in eine Steuerbewegung hinein einen einsetzenden PH Modus zu haben. Die Vereinfachung spart natürlich ordentlich Speicherplatz, daher würde es mich interessieren, ob diese Vereinfachung genau so gut funktioniert (habe kein GPS). Das Ändern der Höhe bei Althold in Bezug auf die Stickmitte ist aus Alexmos Urversion (http://code.google.com/p/multiwii-alexmos/) übernommen worden. Zu dem sei es jetzt möglich eine RTH Höhe anzugeben. Bei Durchsicht des Codes stehe ich dem etwas skeptisch gegenüber, da der Alt Pid Kontroller in seinem Einfluss deutlich begrenz ist, kann eigentlich auch nicht eine Höhe in angemessenem Rahmen von jedem Copter auch angesteuert werden.
Inzwischen bin ich auch nicht untätig gewesen. Meine ALT "PID" Geschichte habe ich mir, auch unter diesem Aspekt, zur Brust genommen und einige Änderungen durchgeführt. Die Flughöhe wird jetzt vorwiegend über Beschleunigungswerte errechnet und durch den Baro der auftretende Rechenfehler/Drift korrigiert. Dadurch bekommt man jetzt eine kontinuierliche Höhe, ohne "Baroausleseloch". Als Nebeneffekt gibt es eine deutlich ruhigere "Altkurve" in der Gui, die jedoch noch prompt reagiert. Das Althold - Höheändern in Bezug auf die Stickmitte ist im Prinzip (Aussentest steht aus) erledigt (da wird sich JinGej freuen!). Allerdings ist die Lösung aufwändiger und anders als der Alexmos/Mahowik Ansatz. Zum einen bestehen 2 Zeitsteuerungen und zum anderen ist das Höheändern bei Althold, unabhängig von der Knüppelneutralzone, weich. Die Zeitsteuerung hat folgenden Sinn: Bei Einschalten des Althold wird plötzlich die Gasknüppelmitte zur Referenz, d.h. es kann zu Durchsacken oder Steigflug kommen. Aktuell habe ich es jetzt so gelöst, dass beim Einschalten des Baromodus sofort die Höhe gehalten wird, aber der Gasknüppel für 1 Sek nicht berücksichtigt wird. Dadurch hat der Pilot genug Zeit den Knüppel in die mittige Neutralzone zu fahren (das fehlte mir immer beim Naza). Beim Ausschalten des Baromodus wird allerdings sofort der anliegende Gaswert durchgegeben, damit im Notfall schnell reagiert werden kann. Die 2te Zeitsteuerung beschäftigt sich mit der Änderungsrate, d.h es kann eine maximale Steig/Sinkrate in cm/sec angegeben werden. Bislang konnte ich alles nur in der Wohnung testen (funktioniert). Der entscheidene Freiflug steht aus, und durch die Änderungen im Kern kann es durchaus zu Problemen/Verschlechterungen kommen. Ich hoffe nicht, dass wir doch noch einen Throttle PID Kontroller brauchen (z.B Arducopter).
Stay tuned

LG
Rob
 
Um antworten zu können musst du eingeloggt sein.
FPV1

Banggood

Oben Unten