Funktionieren bei Euch Kompass und Baro vernünftig ?
- Themenstarter Joachim08
- Beginndatum
LOL, welchen Kollateralschaden verursachst Du denn, wenn es nicht so vielversprechend läuft? SCNR.
Ich habe auch gerade wieder mal im Garten getestet. Habe mal die YAW Werte runtergeschraubt, wie von Rob empfohlen. Macht eigentlich keinen großen Unterschied.
Was ich aber mal ausprobiert habe ist die PID Werte für Roll und Pitch rauf auf 5 und gleichzeitig den Level Wert rauf auf 9.
Dann habe ich den Kopter mal ordentlich durch heftige Roll und Nickausschläge ins Schwingen gebracht und er hat sich so aufgeschaukelt, dass er mit einem Rückwärtssalto runtergekommen ist. Ein Propeller war zu tauschen.
Danach die PID Werte wieder runter auf 3 und Level runter auf 5.
Danach wieder ein Testflug im Garten. Der Kopter schwebt jezt absolut sanft dahin. Er reagiert etwas träger auf Roll und Nick, aber noch im erträglichen Rahmen. Dafür gibt es keine Chance mehr ihn so aufzuschaukeln. Habe heftig am rechten Knüppel gerührt aber sobald ich den Knüppel los lasse levelt er sich sofort wieder aus, ohne auch nur einmal zurückzuschwingen.
So werde ich ihn jetzt lassen. Er fliegt sich nun absolut gutmütig.
Am Baro habe ich nichts mehr geändert. Schalte ich auf Alt Hold, dann bleibt er mal eine Zeit lang konstant und sinkt dann etwa 2m runter, um sich nachher wieder auf der Ursprungshöhe ein zu pendeln.
Mir reicht das mal so. Interessant war für mich heute die Erfahrung mit dem Aufschaukeln und wie ich das komplett weg bekommen habe.
Eventuell probiere ich P für Roll und Nick noch etwas rauf zu drehen, um ihn noch eine Spur reaktiver zu bekommen, aber wenn das zu Lasten der "Sanftheit" geht, dann lasse ich es.
Ich habe auch gerade wieder mal im Garten getestet. Habe mal die YAW Werte runtergeschraubt, wie von Rob empfohlen. Macht eigentlich keinen großen Unterschied.
Was ich aber mal ausprobiert habe ist die PID Werte für Roll und Pitch rauf auf 5 und gleichzeitig den Level Wert rauf auf 9.
Dann habe ich den Kopter mal ordentlich durch heftige Roll und Nickausschläge ins Schwingen gebracht und er hat sich so aufgeschaukelt, dass er mit einem Rückwärtssalto runtergekommen ist. Ein Propeller war zu tauschen.
Danach die PID Werte wieder runter auf 3 und Level runter auf 5.
Danach wieder ein Testflug im Garten. Der Kopter schwebt jezt absolut sanft dahin. Er reagiert etwas träger auf Roll und Nick, aber noch im erträglichen Rahmen. Dafür gibt es keine Chance mehr ihn so aufzuschaukeln. Habe heftig am rechten Knüppel gerührt aber sobald ich den Knüppel los lasse levelt er sich sofort wieder aus, ohne auch nur einmal zurückzuschwingen.
So werde ich ihn jetzt lassen. Er fliegt sich nun absolut gutmütig.
Am Baro habe ich nichts mehr geändert. Schalte ich auf Alt Hold, dann bleibt er mal eine Zeit lang konstant und sinkt dann etwa 2m runter, um sich nachher wieder auf der Ursprungshöhe ein zu pendeln.
Mir reicht das mal so. Interessant war für mich heute die Erfahrung mit dem Aufschaukeln und wie ich das komplett weg bekommen habe.
Eventuell probiere ich P für Roll und Nick noch etwas rauf zu drehen, um ihn noch eine Spur reaktiver zu bekommen, aber wenn das zu Lasten der "Sanftheit" geht, dann lasse ich es.
@Intruder @Helste: Ändert bloss nichts! Das ist nur ein reiner Versuchscode mit dem der Copter schlechter fliegen wird! Das ist nur was zum codebasteln. Zum fliegen ist der Code noch nicht geeignet.
@DeaconBlues: Der Faktor für die Negativwerte ist ja eine gute Idee! Damit kann man den bestehenden Code vielleicht noch wirkungsvoll pimpen. Ich suche immer noch nach einer radikalen Lösung: Datenfilter, neuer/geänderter Baro Pid Kontroller.
LG
Rob
@DeaconBlues: Der Faktor für die Negativwerte ist ja eine gute Idee! Damit kann man den bestehenden Code vielleicht noch wirkungsvoll pimpen. Ich suche immer noch nach einer radikalen Lösung: Datenfilter, neuer/geänderter Baro Pid Kontroller.
LG
Rob
So Jungs, Ihr werdet mir hier langsam ein wenig zu spannend, um mich nicht mit einzuklinken. Ich hab mich eben mal durch die letzten 15 Seiten gelesen und denke, dass ich alles mitbekommen habe.
De facto fliegt das Wookong nach Abschluss des Reviews von meinem X8 wieder runter. MultiWii kriegt zumindest die Regelung mit Gyro und ACC auf einem (Flyduino) Mega mit FreeIMU 0.4 besser hin. Es gibt einfach zu viele Gründe, die gegen das WKM im professionelleren Einsatz sprechen und mal ehrlich: Der Baro und die GPS-Funktionen werden bei MultiWii ja wohl noch hinzukriegen sein.
Den Code für das Promini ums Verrecken klein zu halten, halte ich für überflüssig. Das Ding hat eh irgendwann ausgedient. Der Mega ist spätestens seit HW-PWM in meinen Augen deutlich überlegen und andere Microcontroller rücken auch immer mehr ins Licht. Es wäre ein Leichtes, dem Promini in Zukunft bestimmte Features wegen des begrenzten Speichers vorzuenthalten und es endgültig als Einsteiger-Controller zu behandeln. Ich habe eh nicht verstanden, warum man da noch so ein Hickhack macht, um ja noch einen Hexa oder Octo mit dem Mini fliegen zu können.
Ende der Woche müssen noch Pressefotos vom Copter gemacht werden und bis dahin muss das WKM drauf bleiben, weil es zumindest für die breite Öffentlichkeit momentan imagefördernder als der Flyduino-Turm ist. Danach steige ich in die Tests mit ein.
Was vielleicht für den Code noch ein wichtiger Anhaltspunkt sein könnte: Naza und WKM können tatsächlich so sauber die Höhe halten, wie es in den Werbevideos zu sehen ist. Das WKM allerdings aufgrund der Druckausgleichsbohrung nur bei Windstille. Allerdings bin ich mir nach den vielen Testflügen sehr sicher, dass das große Geheimnis in der Z-Achse des ACC steckt: Langsame Höhenveränderungen werden erst ab einem gewissen Höhenunterschied wahrgenommen und von der Regelung verarbeitet. Kommt es jedoch zu einer plötzlichen Höhenveränderung (Böen oder mit dem Finger auf den Copter drücken), wird selbst bei einem Zentimeter Höhenunterschied schon sehr deutlich nachgeregelt. Naza und WKM wehren sich hartnäckig gegen jede noch so kleine Höhenänderung, sofern sie eine gewisse Beschleunigung haben. Ich kann mir beim besten Willen nicht vorstellen, dass der MS5611 dafür die einzige Datenquelle ist.
De facto fliegt das Wookong nach Abschluss des Reviews von meinem X8 wieder runter. MultiWii kriegt zumindest die Regelung mit Gyro und ACC auf einem (Flyduino) Mega mit FreeIMU 0.4 besser hin. Es gibt einfach zu viele Gründe, die gegen das WKM im professionelleren Einsatz sprechen und mal ehrlich: Der Baro und die GPS-Funktionen werden bei MultiWii ja wohl noch hinzukriegen sein.
Den Code für das Promini ums Verrecken klein zu halten, halte ich für überflüssig. Das Ding hat eh irgendwann ausgedient. Der Mega ist spätestens seit HW-PWM in meinen Augen deutlich überlegen und andere Microcontroller rücken auch immer mehr ins Licht. Es wäre ein Leichtes, dem Promini in Zukunft bestimmte Features wegen des begrenzten Speichers vorzuenthalten und es endgültig als Einsteiger-Controller zu behandeln. Ich habe eh nicht verstanden, warum man da noch so ein Hickhack macht, um ja noch einen Hexa oder Octo mit dem Mini fliegen zu können.
Ende der Woche müssen noch Pressefotos vom Copter gemacht werden und bis dahin muss das WKM drauf bleiben, weil es zumindest für die breite Öffentlichkeit momentan imagefördernder als der Flyduino-Turm ist. Danach steige ich in die Tests mit ein.
Was vielleicht für den Code noch ein wichtiger Anhaltspunkt sein könnte: Naza und WKM können tatsächlich so sauber die Höhe halten, wie es in den Werbevideos zu sehen ist. Das WKM allerdings aufgrund der Druckausgleichsbohrung nur bei Windstille. Allerdings bin ich mir nach den vielen Testflügen sehr sicher, dass das große Geheimnis in der Z-Achse des ACC steckt: Langsame Höhenveränderungen werden erst ab einem gewissen Höhenunterschied wahrgenommen und von der Regelung verarbeitet. Kommt es jedoch zu einer plötzlichen Höhenveränderung (Böen oder mit dem Finger auf den Copter drücken), wird selbst bei einem Zentimeter Höhenunterschied schon sehr deutlich nachgeregelt. Naza und WKM wehren sich hartnäckig gegen jede noch so kleine Höhenänderung, sofern sie eine gewisse Beschleunigung haben. Ich kann mir beim besten Willen nicht vorstellen, dass der MS5611 dafür die einzige Datenquelle ist.
@r0sewhite:
Das klingt logisch.
Die Z-Achse des Beschleunigungssensors für schnelle Änderungen in Z zum Ausgleich zu nutzen.... Geht ja in X und Y auch wunderbar.... Wenn du das so sagst, ist es fast schon komisch, dass das noch nicht drin ist...
Programmieren kann ich leider nicht, aber neue Codes testen geht immer
Viele Grüße
Martin
Das klingt logisch.
Die Z-Achse des Beschleunigungssensors für schnelle Änderungen in Z zum Ausgleich zu nutzen.... Geht ja in X und Y auch wunderbar.... Wenn du das so sagst, ist es fast schon komisch, dass das noch nicht drin ist...
Programmieren kann ich leider nicht, aber neue Codes testen geht immer
Viele Grüße
Martin
Hi,
nun, es macht durchaus Sinn den Promini zu erhalten, da das ganze MWC Projekt darauf basiert OpenSource und günstigst einen Controller zu hinzustellen. Ich stimme dir zu, dass erweiterte Features, wie GPS, etc, nicht mit Gewalt auf den 328 gepresst gehören...was allerdings auch nur in einem Seitenprojekt passiert, aber das ist alles hier Offtopic.
Was den Barometer anbelangt, kann ich ausser dem Versprechen das alles auf einem MS5611 und BMA Board zu testen, diesen Input aus dem MK Forum liefern:
http://forum.mikrokopter.de/topic-24396-1.html
Ich denke es würde Sinn machen, aus dem Code zu lernen. Weil hier wird genau das gemacht, was Tilman beschreibt.
ACC-Z wird zur Kompensation mit verwurstet.
Danke auf jeden Fall, dass sich endlich jemand an diesem Thema engangiert! Der Baro ist in der heutigen release Version schlicht untauglich.
Cheers,
Micha
nun, es macht durchaus Sinn den Promini zu erhalten, da das ganze MWC Projekt darauf basiert OpenSource und günstigst einen Controller zu hinzustellen. Ich stimme dir zu, dass erweiterte Features, wie GPS, etc, nicht mit Gewalt auf den 328 gepresst gehören...was allerdings auch nur in einem Seitenprojekt passiert, aber das ist alles hier Offtopic.
Was den Barometer anbelangt, kann ich ausser dem Versprechen das alles auf einem MS5611 und BMA Board zu testen, diesen Input aus dem MK Forum liefern:
http://forum.mikrokopter.de/topic-24396-1.html
Ich denke es würde Sinn machen, aus dem Code zu lernen. Weil hier wird genau das gemacht, was Tilman beschreibt.
ACC-Z wird zur Kompensation mit verwurstet.
Danke auf jeden Fall, dass sich endlich jemand an diesem Thema engangiert! Der Baro ist in der heutigen release Version schlicht untauglich.
Cheers,
Micha
[Ironiemodus an] Nein das kann nicht sein. Jemand im Multiwiiforum hat mit vorgestern geschrieben, das die Barofunktion die beste sei die auf dem Markt exisitiere... [Ironiemodus aus]
Die Probleme die wir hätten wären nur Einzelfälle und es gäbe hunderte zufriedene User.
Da kann ich nur lachen..... und mich lieber fernhalten.
Die Probleme die wir hätten wären nur Einzelfälle und es gäbe hunderte zufriedene User.
Da kann ich nur lachen..... und mich lieber fernhalten.
Hi!
Es hat sich was getan!
Der Code den ich hier (http://fpv-community.de/showthread....o-vern%FCnftig&p=149896&viewfull=1#post149896) als Beta hatte, hatte einen entscheidenen Fehler! Der Pidkontroller wurde jetzt alle 10ms (MS) bzw. alle 14ms(BMP) mit neuen Werten gefüttert, was ihm offensichtlich nicht bekommt, er braucht seine 25ms. Ist auch eigentlich logisch, ein PID Kontroller muss ja auch einen definierten Zeitraum überblicken.
Lösung: Die Daten werden jetzt weiterhin mit voller Geschwindigkeit in diesen magischen (ich verstehe ihn nicht), aber gut funktionierenden 40-Werte-Filter gefüttert, so dass kein Wert unberücksichtigt bleibt ("glatte Kurve"). Der Baro PID Kontroller macht nach dem Einschalten der Stromversorgung zunächst 4 sec Pause (ist so im Originalcode - muss einen Vorteil haben), um sich dann - wie gewohnt - alle 25ms (40Hz) neue Werte zu ergattern. EstAlt habe ich aus Kompatibilitätsgründen auch in dieser 40 Hz Schleife gelassen.
Der Code aus dem Post http://fpv-community.de/showthread....o-vern%FCnftig&p=149896&viewfull=1#post149896 wurde jetzt also dem entsprechend geändert.
Der Faktor zur Limitierung des Sinkwertes, wie von DeaconBlues ausprobiert, ist (noch) nicht implementiert, da ich das noch nicht testen konnte.
Hier kommt jetzt die modifizierte Version "Dev_20120504"
Die aktuelle Dev nehme ich mir auch noch zur Brust und wird nachgeliefert. (EDIT: erledigt)
Das Ausprobieren geschieht natürlich auf eigene Gefahr, aber ich bin mir zu 99,9% sicher, dass euer Copter nicht durch meine Codeänderung in den Boden geht. Den Finger zur Sicherheit aber auf dem Baroschalter haben!
Aktuell stürmt und regnet es hier - kann also wenig praxistesten (Garage).
Todo: Jetzt kommt die Relativsteuerung zur Gaskanalmitte dran! Könnte klappen.
ACC Z und GPS mit einbeziehen: Kann ich nicht
PID Kontroller ggf verbessern: Kann ich nicht
LG
ROB
P.s.: Dieser Beitrag wird noch durch "EDIT"s verändert werden!
Warum die dev_20120504 - weil dort noch der alte, bewährte Timercode läuft. Ich bin bei den neueren Versionen etwas skeptisch.
Config.h - sind bei den jetzigen Mods nicht verändert worden.
Alt PID Einstellung:
http://www.multiwii.com/forum/viewtopic.php?f=17&t=1564#p12824
http://fpv-community.de/showthread....PID-Kontroller&p=143353&viewfull=1#post143353
Vor dem Flashen einer neuen Revision: File/examples/clear_eeprom. Nach dem Flashen ACC kalibrieren und die bereits erflogenen PIDS wieder einstellen - speichern.
Wenn die Barokurve zunächst wieder hackelig erscheint - einmal copter neu "hochfahren" (Strom aus/an) - warum, weiss ich nicht.
@Rosewhite:
Das sehe ich genau so! Arduino pro mini,wmp und bmp085 haben sich eigentlich überlebt. Beim Googeln nach BMP085, ACC usw sind mehrere
Dinge zu Tage getreten: Von Leuten, die sich sehr mit der Materie auskennen (z.B http://www.pitlab.com/autopitlot-articles/37-comparison-of-pressure-sensors.html) wird konstatiert, dass sich der BMP auf Grund seiner Trägheit und seines Rauschverhaltens noch nicht mal für ein anständiges Variometer eignen würde. Andere haben mit BMP085 mit Kalmanfilter u/o moving average Filter und den ACC Werten (berechneter Z Vektor) auch keine bahnbrechenden Erfolge gehabt. Eine MWII Steuerung mit MS Baro und erhöhter Auflösung der ACC Werte könnte so gut wie der Naza werden und zu dem noch besser fliegen.
@martinez: " Es gab Versuche auf der Multiwii z.B Alexmos.
@aileroned Ich hoffe, dass ich jemanden mit mehr Sachkenntnis und Erfahrung mit meinen Versuchen motivieren kann.
Es hat sich was getan!
Der Code den ich hier (http://fpv-community.de/showthread....o-vern%FCnftig&p=149896&viewfull=1#post149896) als Beta hatte, hatte einen entscheidenen Fehler! Der Pidkontroller wurde jetzt alle 10ms (MS) bzw. alle 14ms(BMP) mit neuen Werten gefüttert, was ihm offensichtlich nicht bekommt, er braucht seine 25ms. Ist auch eigentlich logisch, ein PID Kontroller muss ja auch einen definierten Zeitraum überblicken.
Lösung: Die Daten werden jetzt weiterhin mit voller Geschwindigkeit in diesen magischen (ich verstehe ihn nicht), aber gut funktionierenden 40-Werte-Filter gefüttert, so dass kein Wert unberücksichtigt bleibt ("glatte Kurve"). Der Baro PID Kontroller macht nach dem Einschalten der Stromversorgung zunächst 4 sec Pause (ist so im Originalcode - muss einen Vorteil haben), um sich dann - wie gewohnt - alle 25ms (40Hz) neue Werte zu ergattern. EstAlt habe ich aus Kompatibilitätsgründen auch in dieser 40 Hz Schleife gelassen.
Der Code aus dem Post http://fpv-community.de/showthread....o-vern%FCnftig&p=149896&viewfull=1#post149896 wurde jetzt also dem entsprechend geändert.
Der Faktor zur Limitierung des Sinkwertes, wie von DeaconBlues ausprobiert, ist (noch) nicht implementiert, da ich das noch nicht testen konnte.
Code:
#define BARO_TAB_SIZE 40
#define UPDATE_INTERVAL 25000 // 40hz update rate (20hz LPF on acc)
#define INIT_DELAY 4000000 // 4 sec initialization delay
void getEstimatedAltitude(){
uint8_t index;
static int16_t BaroHistTab[BARO_TAB_SIZE];
static int8_t BaroHistIdx;
static int32_t BaroHigh,BaroLow;
static uint32_t deadLine = INIT_DELAY;
int32_t temp32;
int16_t last;
if (newbaroalt==1) // Update only, if new values are available
{
newbaroalt=0; // Reset Boolean
//**** Alt. Set Point stabilization PID ****
//calculate speed for D calculation
last = BaroHistTab[BaroHistIdx]; // Do the magic
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; // Maintain old timing (40Hz)for PID calculation
deadLine = currentTime + UPDATE_INTERVAL;
EstAlt = BaroHigh*10/(BARO_TAB_SIZE/2);
newestalt=1; // Indicate, new EstAlt RDY
BaroPID = 0; // Calculate new PIDs
//D
temp32 = D8[PIDALT]*(BaroHigh - BaroLow)/BARO_TAB_SIZE;
BaroPID-=temp32;
temp32 = AltHold - EstAlt;
if (abs(temp32) < 10 && abs(BaroPID) < 10) BaroPID = 0; //remove small D parametr to reduce noise near zero position
//P
BaroPID += P8[PIDALT]*constrain(temp32,(-2)*P8[PIDALT],2*P8[PIDALT])/100;
BaroPID = constrain(BaroPID,-150,+150); //sum of P and D should be in range 150
//I
errorAltitudeI += temp32*I8[PIDALT]/50;
errorAltitudeI = constrain(errorAltitudeI,-30000,30000);
temp32 = errorAltitudeI / 500; //I in range +/-60
BaroPID+=temp32;
}Die aktuelle Dev nehme ich mir auch noch zur Brust und wird nachgeliefert. (EDIT: erledigt)
Das Ausprobieren geschieht natürlich auf eigene Gefahr, aber ich bin mir zu 99,9% sicher, dass euer Copter nicht durch meine Codeänderung in den Boden geht. Den Finger zur Sicherheit aber auf dem Baroschalter haben!
Aktuell stürmt und regnet es hier
- kann also wenig praxistesten (Garage).Todo: Jetzt kommt die Relativsteuerung zur Gaskanalmitte dran! Könnte klappen.
ACC Z und GPS mit einbeziehen: Kann ich nicht
PID Kontroller ggf verbessern: Kann ich nicht
LG
ROB
P.s.: Dieser Beitrag wird noch durch "EDIT"s verändert werden!
Warum die dev_20120504 - weil dort noch der alte, bewährte Timercode läuft. Ich bin bei den neueren Versionen etwas skeptisch.
Config.h - sind bei den jetzigen Mods nicht verändert worden.
Alt PID Einstellung:
http://www.multiwii.com/forum/viewtopic.php?f=17&t=1564#p12824
http://fpv-community.de/showthread....PID-Kontroller&p=143353&viewfull=1#post143353
Vor dem Flashen einer neuen Revision: File/examples/clear_eeprom. Nach dem Flashen ACC kalibrieren und die bereits erflogenen PIDS wieder einstellen - speichern.
Wenn die Barokurve zunächst wieder hackelig erscheint - einmal copter neu "hochfahren" (Strom aus/an) - warum, weiss ich nicht.
@Rosewhite:
Das sehe ich genau so! Arduino pro mini,wmp und bmp085 haben sich eigentlich überlebt. Beim Googeln nach BMP085, ACC usw sind mehrere
Dinge zu Tage getreten: Von Leuten, die sich sehr mit der Materie auskennen (z.B http://www.pitlab.com/autopitlot-articles/37-comparison-of-pressure-sensors.html) wird konstatiert, dass sich der BMP auf Grund seiner Trägheit und seines Rauschverhaltens noch nicht mal für ein anständiges Variometer eignen würde. Andere haben mit BMP085 mit Kalmanfilter u/o moving average Filter und den ACC Werten (berechneter Z Vektor) auch keine bahnbrechenden Erfolge gehabt. Eine MWII Steuerung mit MS Baro und erhöhter Auflösung der ACC Werte könnte so gut wie der Naza werden und zu dem noch besser fliegen.
@martinez: " Es gab Versuche auf der Multiwii z.B Alexmos.
@aileroned Ich hoffe, dass ich jemanden mit mehr Sachkenntnis und Erfahrung mit meinen Versuchen motivieren kann.
Hallo Freunde,
betrifft zwar nicht direkt das Thema dieses Fadens, aber da ihr euch mit dem Code bzw. Text beschäftigt, ich habe hier etwas gefunden. Es ist ein kostenloses Programm zum vergleichen und ändern/verschieben von zwei Texten parallel. Es ist dabei völlig egal ob es sich um richtigen Text (TXT) handelt oder sonst was. Ihr könnt also damit z.B. die Config.h mit einer anderen Config.h Datei vergleichen. Man sieht sofort wo darin Abweichungen sind. Das Pgm. heist WinMerge und ist kostenlos hier runter zu laden:
http://winmerge.org/
Gruß Paraglider58
betrifft zwar nicht direkt das Thema dieses Fadens, aber da ihr euch mit dem Code bzw. Text beschäftigt, ich habe hier etwas gefunden. Es ist ein kostenloses Programm zum vergleichen und ändern/verschieben von zwei Texten parallel. Es ist dabei völlig egal ob es sich um richtigen Text (TXT) handelt oder sonst was. Ihr könnt also damit z.B. die Config.h mit einer anderen Config.h Datei vergleichen. Man sieht sofort wo darin Abweichungen sind. Das Pgm. heist WinMerge und ist kostenlos hier runter zu laden:
http://winmerge.org/
Gruß Paraglider58
