Funktionieren bei Euch Kompass und Baro vernünftig ?

ronco

Erfahrener Benutzer
Danke für das feedback :)

ja die PID's müssen erhöt werden .. aber wollte das nicht vorrausetzen da es mit zu hohen schnell probleme geben kann ..

mein kleiner fängt bei P 2.3 an zu "jojon" .. deshalb ist es gut wenn man sich da langsam rantastet..

generell kann die einbindung vom acc ja nur das schwingen innerhalb der baro auflösung reduzieren .. es hatt ja kein orientierungs punkt..

gruß

Felix
 

helste

Erfahrener Benutzer
Ich kann ja mal noch weiter an den PID Werten feilen. Ich denke mal, dass P bei 3 passen wird. Gehe ich da noch höher,m fängt er an Jojo zu spielen.
Ich könnte höchstens noch I und D bearbeiten. Da bin ich mir aber nicht so sicher, was das Verstellen dieser Werte bewirken soll bzw. wird. Könnte einfach mal einen Wert in beide Richtungen verstellen und schauen, ob man einen deutlichen Unterschied merkt und was anders wird.
 

ronco

Erfahrener Benutzer
.. das ist immer scwierig zu erklären ;)

in diesem fall ist:

- P die stärke mit der gegen ein abweichen der höhe angegangen wird
- I die dauer(abkling kurve) der reaktion
- D quasi die korrektur (in diesem fall auch durch ACC Z beeinflusst) .. ist schwer zu sagen .. irgentwie die trägheit der reaktion

hoffe das hilft :D

[edit]
hab grade mal mit 3.0/30/30 getestet .. und das geht echt gut! hatte wohl zuviel schiss D zu erhöhen :D
[/edit]

gruß

felix
 

upapa

Erfahrener Benutzer
hab noch ein paar fehler (meinerseits) behoben und das ganze etwas angepasst..
hier die aktuelle version:
http://www.speedshare.org/download.php?id=4EAF06DB1
Hi ronco,
danke für deine Modifikation.
Habe sie mit vier LiPo-Füllungen bei meinem Quad mit Crius SE-FC (Acc BMA180, Baro BMP085) getestet.
Dabei wurden für ALT die P-Werte zwischen 1.5 und 7.0 und bei D zwischen 10 und 50 in verschiedenen Kombinationen probiert. Im Vergleich zu Robertos Modifikation war eine passende Kombination nicht so einfach zu finden. :)
Letztendlich bin ich bei einer ähnlichen PID-Variante wie helste gelandet. ALT = 3.2, I = 0.030 und D= 35. Dennoch scheint das Regelverhalten längst nicht so sanft und in einem so engen Höhenkorridor wie bei Robertos Mod.
Regelrecht gefährlich (naja ;-) ) kann der Einsatz der Baro-Regelung in Bodennähe werden. Berührt der Copter aufgrund der Höhenschwankung kurz den Boden, katapultiert die Regelung den Copter wie eine Rakete in den Himmel (soweit ich es nachvollziehen konnte, weitgehend unabhängig von den PID-Werten). Kein Wunder, dass vistauser seinen Copter Indoor an die Decke gesemmelt hat... Sicherer scheint es, die Regelung erst ab mind. 2...3 m Flughöhe in Betrieb zu nehmen.
Dieses Verhalten zeigten Robertos Modifikationen nicht. Da war auch gefahrloses Schweben in 50 cm Höhe mit Baro-Regelung problemlos möglich.
Mein Fazit:
Robertos Mod bleibt vorerst in seinem gutmütigen Regelverhalten (zumindest bei meinem Copter) unerreicht.
(Ich will aber nicht ausschließen, dass ich bei deinem Mod noch nicht die richtigen PID-Werte gefunden habe...)
Trotzdem Respekt und vielen Dank für dein Engagement für MultiWii und Co!

upapa
 

ronco

Erfahrener Benutzer
Hi upapa,

so hatte es sich bei mir noch nicht gezeigt.. ist aber möglich da in dieser variante die acc z werte eine weile summiert werden .. und wenn das acc beim aufprall stark ausschlägt kann sich da ein dicker haufen zusammen summieren .. werde da mal einen max wert einbauen .. also das der "haufen" nicht zu groß werden kann .. was im flug ja nicht passieren wird.

auch dir danke für die testergebnisse .. sowas hilft !

gruß

Felix
 

helste

Erfahrener Benutzer
Felix, das von upapa beschriebene Verhalten beim kurzen Auftippen auf dem Boden hatte ich auch. War aber nicht wirklich in einem Bereich, wo man Schwierigkeiten hat damit klar zu kommen. Er hat dann einfach wie ein Gummiball nach oben beschleunigt.
Es macht aber sowieso nur Sinn in einer sicheren Höhe den Baro zu aktivieren. Ich gehe da immer auf mindestens 4-5m. Da kommt es dann auch nicht dazu, dass der Kopter mal bei einer etwas größeren Schwankung gleich auf den Boden durch schlägt.
 

Roberto

Erfahrener Benutzer
WOW!

Hier gibt es echte Fortschritte von Ronco bei der Datenfusion von Baro und ACC!
Ich habe mir natürlich auch die letzte Ronco Version bei speedshare gezogen und konnte natürlich nicht die Finger vom Code lassen. Die Datenfusion von Ronco ist einfach megageil. Keine Ahnung wie die Version fliegen wird, aber es ist definitiv ein Fortschritt.
@upapa: Es kann durchaus sein, dass meine älteren Versionen vorteilhafter erscheinen, aber Ronco/Marbalon's Ansatz hat viel Potential, und sollte unbedingt weiter verfolgt werden.
Meine Änderungen:
1. Bei Initialisierung wird die Bodenhöhe aus 100 verschiedenen Barowerten bestimmt (dauert 3 Sec) und die Höhe auf 0 gesetzt (getGroundAlt() ). D.h. Die Barokurve bezieht sich jetzt auf die Starthöhe. Das ist momentan noch egal, aber wenn eine Failsavelandung oder ein Flugkorridor programmiert werden soll, haben wir das schon mal.
2. getEstimatedAltitude() wird bei jedem Durchlauf ausgeführt. Ein neuer BaroPid wird nur berechnet, wenn es neue Barodaten gibt. Deswegen ist die Timingabfrage aus den alten Versionen überflüssig und entfernt. Bei BMP085 wird der Code alle 30ms ausgeführt.
3. Daher ist Baro_update() unter Sensors verändert, Timingprobleme bei der Sensorabfrage, soweit von mir erkennbar, sind behoben (wie bei meinen anderen Versionen).
4. Ich habe wieder ACCZ = accADC[YAW] verwendet, da mein BMA020 mit "gesmoothten" Werten nichts zu bringen scheint.
5. Da jetzt endlich ein echter PID Kontroller für den Baro vorliegt, ich aber nicht auf eine Abschwächung der berechneten negativen Werte verzichten wollte (war bei meinen Versionen das "I") habe ich unter IMU/getEstimatedAltitude() ein "#define DroppingPercent 20" eingefügt. D.h. wenn eine Abwärtskorrekturbewegung errechnet wird, wird diese nur zu 20% an die Motoren weiter gegeben. Hier kann jeder seine eigenen Werte probieren. 20% ist nur ein Vorschlag.
6. Die ALT Defaultwerte im EEprom sind auf 0 gestellt, damit niemand einen Raketenstart hat und Bruch macht.

Wegen des Wetters bin ich diese Version IN DER WOHNUNG NUR MIT P "geflogen" (P=3), I und D habe ich auf 0 gelassen. Es hat erstaunlich gut funktioniert.
Die config.h ist nicht verändert. Es ist die Version "release_candidate_2_1_r976".

VERSUCH AUF EIGENE GEFAHR! SCHNELLER FINGER AM BARO-AUS-SCHALTER!!!

LG

Rob

P.s.: Ich bin schon sehr gespannt, wie er draussen fliegt!
 

Anhänge

ronco

Erfahrener Benutzer

Roberto

Erfahrener Benutzer
@Ronco: He,He, marbalon hat jetzt auch eine Abschwächung der negativen Werte drin! Wie doch alle zum gleichen Ergebnis kommen... Das entspricht haargenau meinem DroppingPercent, nur er nimmt 80% (0.8).
@Helste: Ich beneide Dich jetzt schon, hier siehts mit fliegen eher trübe aus.
LG
Rob
 

ronco

Erfahrener Benutzer
soo..

hab grade mal deine version getestet.. geht .. aber ist bei mir (mit meinem kleinen 2s copter indoor) viel zu sanft :(

also mit marbalons "purem" code komme ich mit etwas PID tuning auf so 70cm genauigkeit .. was schon recht gut ist für das BMP085 (ich mein das hätte so 50cm auflösung) .. mit deinem code schwankt er zwar langsamer aber dafür innerhalb von 2 metern.

werde noch weiter rumprobieren ..

was ich auch bald mal machen werde ist ein lipo spannungsausgleich .. bei mir macht es viel aus wenn der lipo frisch ist und dann nach 5 minuten auf sein normales level fällt .. werde mal sehen .. müsste ja mit vbat gehen :D

gruß

Felix
 

Roberto

Erfahrener Benutzer
Vielleicht liegt es daran:

Im Original stand:

deltaHistTab[deltaHistIdx] = constrain(BaroAlt - lastAlt,-120,+120);

Ich habe es geändert in:

deltaHistTab[deltaHistIdx] = constrain(BaroAlt - lastAlt,-10,+10);

Weil so pro Durchlauf +-10cm Änderungen möglich sind d.h. bei 33Hz -> +-3,3m/s , das erschien mir mehr als ausreichend.
Vielleicht benutzt er fast das ganze Byte, damit sein Filter schneller reagiert? Denn eine Höhenänderung von fast +-40 m/sec halte ich für eher unwahrscheinlich.

LG
Rob
 

funkjan

Erfahrener Benutzer
Hallo,

verfolge jetzt auch seit einiger Zeit Euer Höhensensortuning und fliege bis jetzt (und das erstemal bei Wii Copter mit aktiviertem Höhensensor und es funktioniert :) ) mit Robertos Variante MultiWii_dev_20120606_NewBaroPID2

Ist die immer noch aktuell oder gibt es außer der ganz neuen Co-Produktion "RoncoRob Beta" noch eine andere für einen "Normaluser" (also leider kann ich bestenfalls gut beschriebenes nachmachen als inhaltlich was beizutragen)beherrschbare, die sich lohnt?

Und da ja glaube ich vor allem für BMP085 geschrieben, gab es doch eine Anpassung für die größere Genauigkeit des MS5611 (die ich im thread blöderweise nicht mehr finde)?

Und zuletzt eine schon fast unverschämte Bitte - in anderen foren ist doch meistens im Eröffnungsthread so der Stand der Dinge (also eigentlich meine obigen Fragen) zusammengefasst - ich würde es ja machen, aber blicke zu wenig wirklich durch - würde glaube ich vielen helfen und dem thread hier die immer wieder gleichen Fragen ersparen.

In jedem Fall - vielen Dank für Euer Engagement von einem der einfach nur gern fliegt :)

Gruß

Jan


P.S.: etwas off-topic - gab es eigentlich irgendwo (auch rcgroups) mal einen guten thread zum PID Tuning/setting des MPU6050 - habe den Eindruck dort viel höher in den Werten gehen zu können/müssen als beim ITG3200, da aber relatives Neuland bin ich etwas hilflos und wäre für linktipps dankbar
 

Roberto

Erfahrener Benutzer
Bin heute natürlich wieder nicht zu fliegen gekommen - wenigstens rettet mich mein mqx.
Soll ich älteren Versionen für die neue Final 2.1 umsetzen, bis das neue Projekt so weit ist?
Ich dachte da an folgende Versionen:
MultiWii_dev_20120606_NewBaroPID2b
MultiWii_release_candidate_2_1_r949NewBaroPID

Lg

Rob

@funkjan: Die 20120606_NewBaroPID2&B rechnen mit 30 cm Auflösung. Die 2_1_r949NewBaroPID hat diese 30cm Quantisierung nicht. Du kannst die MultiWii_release_candidate_2_1_r949NewBaroPID (http://fpv-community.de/showthread....o-vern%FCnftig&p=167487&viewfull=1#post167487) probieren.

"...im Eröffnungsthread so der Stand der Dinge.." Genau, da liegt noch echt Arbeit vor Joachim08 :) :) !!
"..MPU6050 - habe den Eindruck dort viel höher in den Werten gehen zu können/müssen..." nimm die Werte nicht zu ernst, grade die MPU liefert unter MWII deutlich unterschiedliche Werte, je nachdem ob sie als stand alone, oder verbaut in einer IMU läuft. Die Werte werden nicht alle mathematisch exakt heruntergerechnet auf einen gemeinsamen Nenner, so dass es natürlich zu Unterschieden von config zu config kommen muss. Das hat aber nichts mit der tatsächlichen Flugleistung zu tun.

LG

Rob
 

funkjan

Erfahrener Benutzer
Bin heute natürlich wieder nicht zu fliegen gekommen - wenigstens rettet mich mein mqx.
Soll ich älteren Versionen für die neue Final 2.1 umsetzen, bis das neue Projekt so weit ist?
Ich dachte da an folgende Versionen:
MultiWii_dev_20120606_NewBaroPID2b
MultiWii_release_candidate_2_1_r949NewBaroPID

Ja mach' das bitte - denn dort sollte in der GUI doch dann auch abspeichern der Werte klappen? - geht bei mir in der 20120606 nicht.


@funkjan: Die 20120606_NewBaroPID2&B rechnen mit 30 cm Auflösung. Die 2_1_r949NewBaroPID hat diese 30cm Quantisierung nicht. Du kannst die MultiWii_release_candidate_2_1_r949NewBaroPID (http://fpv-community.de/showthread....o-vern%FCnftig&p=167487&viewfull=1#post167487) probieren.
musste man nicht die Quantisierung manuell von 30cm für BMP085 auf 10cm für MS5611 ändern in der MultiWii_dev_20120606_NewBaroPID2b
und braucht/soll man das bei der MultiWii_release_candidate_2_1_r949NewBaroPID nicht mehr oder wieso soll die jetzt für den MS5611 bessre Ergebnisse liefern?


"...im Eröffnungsthread so der Stand der Dinge.." Genau, da liegt noch echt Arbeit vor Joachim08 :) :) !!
hatte der Arme sich angeboten :) hört sich so an


"..MPU6050 - habe den Eindruck dort viel höher in den Werten gehen zu können/müssen..." nimm die Werte nicht zu ernst, grade die MPU liefert unter MWII deutlich unterschiedliche Werte, je nachdem ob sie als stand alone, oder verbaut in einer IMU läuft. .

FreeIMU 0.4.3 - ja aber was machst Du, wenn Du was nicht besser weisst - mal so schauen wie's den anderen so geht - und von da aus eigene erfliegen - war eben nur erstaunt wie hoch ich in den P Pictch u. Roll Werten gehen konnte und erkenne gar keinen rechten Unterschíed - da meine mit ITG3200/BMP085 von fast default bei einem leichten 40cm Quad (Keda 20-50S) gut liefen , habe ich da nie groß rumprobiert und bin ahnungslos - habe vorhin dann mal wieder gegen FreeIMU 0.4.3 (MPU6050) gegen die 0.3.5 (ITG3200/BMP085) gewechselt, um zu lernen wie sich Erhöhung von P Pitch/Roll so anfühlt bzw. aussieht - erwarte wobeln auch im rate mode - kenne ich bisher nur aus Level mode und beim schnellen Abfangen mit Gas (zum Vergleich und dann zurück zur MPU6050 - soll ja besser sein - obwohl ich den Eindruck habe, damit spricht der gleiche Copter schlechter auf's Gas an - also lahmer - kann sowas sein?

sorry verlasse eindeutig das Thema!


Danke Rob für Deine Arbeit (und die aller anderen Inputgeber) - RIESIG!



Jan
 

funkjan

Erfahrener Benutzer
Habe noch eine Frage - wie macht Ihr es (oder man es richtig?), wenn Ihr eine neue Version probiert?

-Jedesmal erst "EEPROM clean" , dann die neue und alle Werte in der GUI neu einstellen und bleiben einem dabei die Gelernten Gaswege (da im Sender) und Schalterzuordnungen erhalten?

- oder ohne vorheriges löschen

Danke

Jan
 
@funkjan
Ja EEPROM Clean ist gut vor dem flashen. Die Ganzen PID Werte werden gelöscht und auch die Schalterzuordnungen. Gasweg bleibt gleich, das ist ja in dem IC vom Regler gespeichert.

Bei mir ist das 10DOF IMU GY-86 MPU6050+HMC5883l+MS5611 von Flyduino mit Multiwii 2.1rc1 verbaut.
Hab keinerlei Erfahrung mit Mag und Baro.
Der Baro funktioniert bei mir, wenn auch sehr ungenau... der Copter fliegt ca. 1,5m hoch und wieder runter^^
Kann wohl daran liegen das ich noch keine Watte oder ähnlichen Schutz auf den Baro Sensor geklebt habe.


Aber was bei mir garnich funzt ist der Kompass. In der Gui wenn ich den Copter Drehe, ändert sich auch die Pfeilrichtung vom Kompass. Wenn ich aber im Flug per Schalter den Kompass reinhau, passiert 0,nix.
Habs mehrfach probiert.

Kann es an meinem Aufbau liegen. Die Regler und die Hauptleitung zum Akku liegt 2-3cm unter der Platine siehe Pics im Anhang.

Gibts die Finale 2.1 Multiwii schon angepasst, für bessere Höhenregelung?
 

Anhänge

upapa

Erfahrener Benutzer
Soll ich älteren Versionen für die neue Final 2.1 umsetzen, bis das neue Projekt so weit ist?
Ich dachte da an folgende Versionen:
MultiWii_dev_20120606_NewBaroPID2b
Hi Roberto,

das wäre prima. :)
Habe neben meinem (inzwischen fast schon altehrwürdigen) Crius_SE mittlerweile auch meinen Crius_AIO_Pro (heute Erstflug) fertiggestellt. So kann ich hier die MODs mit BMP085 und MS5611-01BA01 testen...

upapa
 
FPV1

Banggood

Oben Unten