Baro Code Änderungen
- Themenstarter Roberto
- Beginndatum
Mahlzeit!
Tja, da ist das Problem.
Ich habe mich selbst schon darum gebeten, und so ballaststoffreich ist die Kost leider nicht. Ohne die Funktion zu beeinträchtigen, sehe ich ein Einsparungspotential im Bereich von 40 Bytes. Es ist aber durch weiteren Fortschritt, nicht zu vermeiden, dass auch die Originalversion immer länger werden wird. Mit GPS wird es auf dem Promicro einfach zu eng.
Mögliche Alternativen:
1. Wie angeführt: Aufrüsten
2. Teile des Mwii Codes auf den freien Speicher des I2C-GPS-Arduinos auslagern. Diese Möglichkeit erscheint mir aus mehreren Gründen eher theoretisch.
OT START
Wenn man sich ganz unten im Hauptprogramm der Multiwii den Abschnitt "PITCH & ROLL & YAW PID" anschaut, wird eigentlich klar, wie sehr am Limit die ganze Sache vom Speicher und von der Rechenleistung schon seit längerem läuft. Die ganze PID Schleife für die Fluglage basiert auf der Annahme einer festen Cycletime. D.h. die tatsächlich vergangene Zeit wird nicht berücksichtigt. Dieses würde speicher- und zeitintensive Fliesskommaberechnungen nach sich ziehen, die offensichtlich nicht mehr zu leisten sind. Im Umkehrschluss muss man sich auch nicht wundern, wenn man seinen Copter mit mehr Sensorik/Funktionen ausstattet (Durchlaufzeit erhöht sich), dass dann die PIDs für Roll/Pitch/Yaw ggf. angepasst werden müssen. Wäre es nicht eigentlich sinnvoller, ausgehend von einer festen Durchlaufzeit, diese dann auch festzulegen? Dann könnten sich Änderungen in der Ablaufzeit nicht auf die Regelung auswirken. Mit dem Nunchuk war Die Cycletime bei ca. 6ms d.h. einer Updaterate von 167Hz. Wenn man die Cycletime z.B auf >= 5ms festsetzt, würden viele Hardwarekonfigurationen auf konstante 200Hz kommen. Den Gedanken werde ich einem Praxistest unterziehen.
Unter dem Gesamtaspekt ist es m.E mehr als verwunderlich, dass nicht auf eine potentere Plattform umgestiegen, und ein Schnitt gemacht wird. Anregungen/Alternativen haben wir, durch Jürgens Hinweise, reichlich
. D.h. Eine Version für die neue Plattform und eine "Light" Version für bestehende Arduino Setups, soweit möglich. Ich kann mir das nur durch finanzielle Abhängigkeiten erklären, einen logischen Grund sehe ich nicht.
OT ENDE
Zurück zum Thema Baro. In Planung sind 3 Varianten des Höheänderns, die dann über die config.h ausgewählt werden:
1.: Wie bisher ("final3"), überarbeitet
2.: Stickmitte/Höhensteigrate Baro&Acc gesteuert ("NazaStyleTest" - überarbeitet), sehr weich.
3.: Stickmitte/Gassteigrate ohne Baro&Acc, müsste auch wieder "einrasten" können ("Derjunior" hat mich auf die Idee gebracht) vielleicht in 3 Stufen (config.h): Normal, Hart, Knallhart.
Hoffentlich wird das Wetter am WE besser....
LG
Rob
Tja, da ist das Problem.
Ich habe mich selbst schon darum gebeten, und so ballaststoffreich ist die Kost leider nicht. Ohne die Funktion zu beeinträchtigen, sehe ich ein Einsparungspotential im Bereich von 40 Bytes. Es ist aber durch weiteren Fortschritt, nicht zu vermeiden, dass auch die Originalversion immer länger werden wird. Mit GPS wird es auf dem Promicro einfach zu eng.
Mögliche Alternativen:
1. Wie angeführt: Aufrüsten
2. Teile des Mwii Codes auf den freien Speicher des I2C-GPS-Arduinos auslagern. Diese Möglichkeit erscheint mir aus mehreren Gründen eher theoretisch.
OT START
Wenn man sich ganz unten im Hauptprogramm der Multiwii den Abschnitt "PITCH & ROLL & YAW PID" anschaut, wird eigentlich klar, wie sehr am Limit die ganze Sache vom Speicher und von der Rechenleistung schon seit längerem läuft. Die ganze PID Schleife für die Fluglage basiert auf der Annahme einer festen Cycletime. D.h. die tatsächlich vergangene Zeit wird nicht berücksichtigt. Dieses würde speicher- und zeitintensive Fliesskommaberechnungen nach sich ziehen, die offensichtlich nicht mehr zu leisten sind. Im Umkehrschluss muss man sich auch nicht wundern, wenn man seinen Copter mit mehr Sensorik/Funktionen ausstattet (Durchlaufzeit erhöht sich), dass dann die PIDs für Roll/Pitch/Yaw ggf. angepasst werden müssen. Wäre es nicht eigentlich sinnvoller, ausgehend von einer festen Durchlaufzeit, diese dann auch festzulegen? Dann könnten sich Änderungen in der Ablaufzeit nicht auf die Regelung auswirken. Mit dem Nunchuk war Die Cycletime bei ca. 6ms d.h. einer Updaterate von 167Hz. Wenn man die Cycletime z.B auf >= 5ms festsetzt, würden viele Hardwarekonfigurationen auf konstante 200Hz kommen. Den Gedanken werde ich einem Praxistest unterziehen.
Unter dem Gesamtaspekt ist es m.E mehr als verwunderlich, dass nicht auf eine potentere Plattform umgestiegen, und ein Schnitt gemacht wird. Anregungen/Alternativen haben wir, durch Jürgens Hinweise, reichlich
. D.h. Eine Version für die neue Plattform und eine "Light" Version für bestehende Arduino Setups, soweit möglich. Ich kann mir das nur durch finanzielle Abhängigkeiten erklären, einen logischen Grund sehe ich nicht.OT ENDE
Zurück zum Thema Baro. In Planung sind 3 Varianten des Höheänderns, die dann über die config.h ausgewählt werden:
1.: Wie bisher ("final3"), überarbeitet
2.: Stickmitte/Höhensteigrate Baro&Acc gesteuert ("NazaStyleTest" - überarbeitet), sehr weich.
3.: Stickmitte/Gassteigrate ohne Baro&Acc, müsste auch wieder "einrasten" können ("Derjunior" hat mich auf die Idee gebracht) vielleicht in 3 Stufen (config.h): Normal, Hart, Knallhart.
Hoffentlich wird das Wetter am WE besser....
LG
Rob
Das dürfte dort schon längst bekannt sein. Wenn man mit Logik nicht weiter kommt, steckt nach meiner Erfahrung irgend eine Interessengruppe dahinter.
"die auswahlsache mit config.h gefällt mir" - Danke!
So kann man sich dann, je nach Bedürfnis und Zweck die passende Variante auswählen. Na, mal sehen, ob das alles so lüppt, wie gedacht.
LG
Rob
EDIT: Jetzt habe ich, in der Wohnung (!Risiko!), den "PITCH & ROLL & YAW PID" Kontroller mit konstanten 200Hz laufen lassen (5ms), macht einen sehr guten Eindruck. Vor allem steht das Heck besser (bei der etwas verbogenen Schüssel). Genaueres über Wirkung und Nebenwirkung kann man natürlich nur im Freiflug testen. Der Ansatz scheint vielleicht doch nicht so abwegig zu sein.
"die auswahlsache mit config.h gefällt mir" - Danke!
So kann man sich dann, je nach Bedürfnis und Zweck die passende Variante auswählen. Na, mal sehen, ob das alles so lüppt, wie gedacht.
LG
Rob
EDIT: Jetzt habe ich, in der Wohnung (!Risiko!), den "PITCH & ROLL & YAW PID" Kontroller mit konstanten 200Hz laufen lassen (5ms), macht einen sehr guten Eindruck. Vor allem steht das Heck besser (bei der etwas verbogenen Schüssel). Genaueres über Wirkung und Nebenwirkung kann man natürlich nur im Freiflug testen. Der Ansatz scheint vielleicht doch nicht so abwegig zu sein.
@Jürgen: "nun wie ich das sehe, hast du ja auch noch keinen auf der Basis STM32 " Genau, 1 weil ich sie noch nicht brauche, und 2. weil ich auch noch nicht genau weiss, wie die nächste Mwii Hardwarebasis aussehen wird.
@JinGej: Genau! Jürgen macht den Generalimporteur und beglückt uns hier mit kostenlosen Naze32 Testexemplaren......
Von komplett neu ist das meilenweit entfernt, ich überlege mir nur etwas, stelle es zur Diskussion, und wenns' geht wirds auch getestet.
In diesem Sinne, es regnet grad nicht.
LG
Rob
@JinGej: Genau! Jürgen macht den Generalimporteur und beglückt uns hier mit kostenlosen Naze32 Testexemplaren......
Von komplett neu ist das meilenweit entfernt, ich überlege mir nur etwas, stelle es zur Diskussion, und wenns' geht wirds auch getestet.
In diesem Sinne, es regnet grad nicht.
LG
Rob
Testergebnis:
Wenn man mich lässt....
Die Variante "3" (http://fpv-community.de/showthread.php?14199-Baro-Code-%C4nderungen&p=210777&viewfull=1#post210777) ist absolut gefährlich und so, wie ich mir das dachte, ein Schuss in den Ofen. Ich könnte da noch einen "Fliesskomma" - Anlauf wagen.
Die Minimaländerung mit der fixen Ausführungszeit des Roll/Pitch/Yaw Kontrollers hat echt Wunder gewirkt. Das muss in die nächste Version, z.B als Option, unbedingt rein. Mein Kopter fliegt deutlich besser, mit nur 5ms (200Hz) die dieses Zeitgegrissel zwischen 3.x und 4.x ms der Hauptregelung vom Hals hält. Vorher hatte ich immer Heckdrift, die ich auf die schlechte, mechanische Ausführung meines Copters zurückgeführt hatte - WEG. Das kommt mir so ähnlich wie mit den Mikrorucklern bei den Dual-Grafikkarten vor. Lieber eine fixe, langsamere Rate, als maximale Geschwindigkeit und "Stotterer" am laufenden Band.
Ich denke, wenn das Wetter einigermassen mitspielt, gibt es eine neue Version. Nach dem Rückschlag mit Punkt 3, plane ich jetzt allerdings nur noch 2 Modi: aus der "3final" und dem Nazatest (überarbeitet).
LG
Rob
Wenn man mich lässt....
Die Variante "3" (http://fpv-community.de/showthread.php?14199-Baro-Code-%C4nderungen&p=210777&viewfull=1#post210777) ist absolut gefährlich und so, wie ich mir das dachte, ein Schuss in den Ofen. Ich könnte da noch einen "Fliesskomma" - Anlauf wagen.
Die Minimaländerung mit der fixen Ausführungszeit des Roll/Pitch/Yaw Kontrollers hat echt Wunder gewirkt. Das muss in die nächste Version, z.B als Option, unbedingt rein. Mein Kopter fliegt deutlich besser, mit nur 5ms (200Hz) die dieses Zeitgegrissel zwischen 3.x und 4.x ms der Hauptregelung vom Hals hält. Vorher hatte ich immer Heckdrift, die ich auf die schlechte, mechanische Ausführung meines Copters zurückgeführt hatte - WEG. Das kommt mir so ähnlich wie mit den Mikrorucklern bei den Dual-Grafikkarten vor. Lieber eine fixe, langsamere Rate, als maximale Geschwindigkeit und "Stotterer" am laufenden Band.
Ich denke, wenn das Wetter einigermassen mitspielt, gibt es eine neue Version. Nach dem Rückschlag mit Punkt 3, plane ich jetzt allerdings nur noch 2 Modi: aus der "3final" und dem Nazatest (überarbeitet).
LG
Rob
Hey,
okay dann heißt es für mich wohl mit der bestehenden Hardware erstmal leben (was sehr ärgerlich ist, da ich das MultiWii Board grad erst geholt habe...) und werde mal abwarten was sich über den Winter so ergibt...
Irgendwie denke ich grad an meinen alten Leitspruch: "Wer billigt kauft, kauft zwei mal..."
Wobei weder das MutliWii Board und schon gar nicht die Software billig ist, aber hätte man ein teureres kommerzielles System gekauft, hätte man vieles ohne plötzliche Überraschungen...
Aber ich bleibe am Ball und vielleicht gibt es ja doch noch irgendeine abgespeckte Version...
okay dann heißt es für mich wohl mit der bestehenden Hardware erstmal leben (was sehr ärgerlich ist, da ich das MultiWii Board grad erst geholt habe...) und werde mal abwarten was sich über den Winter so ergibt...
Irgendwie denke ich grad an meinen alten Leitspruch: "Wer billigt kauft, kauft zwei mal..."
Wobei weder das MutliWii Board und schon gar nicht die Software billig ist, aber hätte man ein teureres kommerzielles System gekauft, hätte man vieles ohne plötzliche Überraschungen...
Aber ich bleibe am Ball und vielleicht gibt es ja doch noch irgendeine abgespeckte Version...
JinGej: Bislang sind mir nur Englische Seiten über den Weg gelaufen mit Naze Infos. Da die Hardware unterschiedlich ist, müssen quasi die "Treiber" für die Sensoren neu geschrieben werden. Das ist hier: http://code.google.com/p/afrodevices/source/browse/#svn/trunk/afrowii schon zu einem grossen Teil erledigt. Das schöne an einer Hochsprache wie C ist, dass sich die Hauptroutinen eigentlich kaum ändern und grossteils übernommen werden können. Der "Compiler" (http://www.st.com/internet/mcu/subclass/1521.jsp) übernimmt die Übersetzung in die Assemblersprache des jeweiligen Chips. Deswegen ist das Verbessern des original Arduino Multiwii nicht vergebens. Wenn im Hauptprogramm ein Barowert angefordert wird, muss natürlich auf dem Naze32 etwas anderes als auf einem Arduino passieren (Treiber, s.o). Wenn es so weit ist, werde ich mich mit der Materie auch noch genau auseinandersetzen. Jürgen, als Naze - Besitzer, hat da vielleicht was parat.
LG
Rob
LG
Rob
Hi!
Hoffentlich wird nicht sowas: http://hackaday.com/2012/10/03/finally-an-arm-powered-arduino/ die nächste Mwii Basis. Soweit ich das sehe hat der, wie der STM32F103 (Naze32) auch, keine FPU. Naja, abwarten und Tee trinken.
Mittlerweile ist der Fehler in der Umsetzung von "Punkt 3" gefunden. Bei dem Regen sehe ich allerdings schwarz für einen Testflug. In der Wohnung funktioniert das vorher "absolut gefährliche" jetzt zumindest zuverlässig ungefährlich. Ob es sich bewähren kann, wird sich noch zeigen müssen. Die Multiwii Timings habe ich mir auch noch mal genauer angeschaut. Die Multiwii Hauptpidsteuerung läuft jetzt auf einer, wenige Microsekunden genauen und konstanten Zeitbasis. Die Cycletime wackelt natürlich ausserhalb des Microsekundenrahmens, da sie jetzt nach dem Pidkontroller bestimmt wird, und seine Ausführungszeit schwankt.
So weit so gut und so schlecht das Wetter........
@FireN: Schon am Basteln??
LG
Rob
Hoffentlich wird nicht sowas: http://hackaday.com/2012/10/03/finally-an-arm-powered-arduino/ die nächste Mwii Basis. Soweit ich das sehe hat der, wie der STM32F103 (Naze32) auch, keine FPU. Naja, abwarten und Tee trinken.
Mittlerweile ist der Fehler in der Umsetzung von "Punkt 3" gefunden. Bei dem Regen sehe ich allerdings schwarz für einen Testflug. In der Wohnung funktioniert das vorher "absolut gefährliche" jetzt zumindest zuverlässig ungefährlich. Ob es sich bewähren kann, wird sich noch zeigen müssen. Die Multiwii Timings habe ich mir auch noch mal genauer angeschaut. Die Multiwii Hauptpidsteuerung läuft jetzt auf einer, wenige Microsekunden genauen und konstanten Zeitbasis. Die Cycletime wackelt natürlich ausserhalb des Microsekundenrahmens, da sie jetzt nach dem Pidkontroller bestimmt wird, und seine Ausführungszeit schwankt.
So weit so gut und so schlecht das Wetter........
@FireN: Schon am Basteln??
LG
Rob
