Halihallo.
Ich habe mir grad mal den source vom Brugi angesehen (auf der Suche nach einem besseren IMU Teil). Mangels Hardware kann ich da natürlich nichts über die Funktion sagen. Durch das Herumgefummel mit GPS und dem mwii controller denke ich, dass man eventuell den "D" Teil der Regelung verbessern könnte. Mit dem moving average von der mwii und dem freq. cut/pt1 Element vom Arducopter in Kombination auf dem "D" Anteil habe ich gute Erfahrungen gemacht.
Hier das getD
https://github.com/Crashpilot1000/SummerGames2.5/blob/master/src/navigation.c#L322
Hier die Berechnung (einmal berechnen, oder als Festwert wie hier:
http://code.google.com/p/multiwii/source/browse/trunk/MultiWii/GPS.ino#39) des Freq. Cut
GPSDpt1freqCut = 1.0f / (2.0f * M_PI * (float)cfg.gpspt1cut);
In dem Fall dürfte ein "gpspt1cut" von 15Hz ok sein.
Wie gesagt, es ist nur eine Idee. Vielleicht bringts auch etwas beim Brugi.
Vielleicht könnte man dadurch höhere P & I Werte "fahren" ohne Aufschwingen ("Zittern").
LG
Rob
Edit:
Mal abgesehen davon, müsste nicht bei dem "D" durch die Zeit geteilt werden statt der Multiplikation hier:
http://code.google.com/p/brushless-gimbal/source/browse/trunk/_BruGi/_BruGi.ino#209
->
Code:
int32_t out = (Kp * error) + *errorSum + Kd * (error - *errorOld) * DTms;
also etwas in der Richtung: (siehe
http://en.wikipedia.org/wiki/PID_controller#Derivative_term)
Code:
int32_t out = (Kp * error) + *errorSum + Kd * (error - *errorOld) / DTms;
Natürlich müsste man dann das Kd anders skalieren und ggf. das Vorzeichen neu bewerten. Oder man schenkt sich das Deltatime komplett für I und D, wenn die Ausführungszeit ausreichend konstant ist.
Ich habe hier mal etwas zusammengestellt (die Änderungen sind mit "Crashpilot" markiert):
https://github.com/Crashpilot1000/BruGi170PIDidea