Brushless Gimbal Regelung auf STorM32 Basis

Status
Nicht offen für weitere Antworten.

hdino

Neuer Benutzer
#1
Hallo zusammen,

ich schreibe zur Zeit eine neue Firmware für das STorM32 und hab ein paar Fragen zur Regelung der Brushless Motoren. Mein Versuchsaufbau besteht zur Zeit aus einem GB2208 von T-Motor, an den ein optischer Encoder mit 500 Ticks pro Umdrehung angeflanscht ist. Durch Flankenauswertung lässt sich daher eine Auflösung von 2000 Ticks pro Umdrehung erreichen.

Als Ausgangspunkt habe ich nun einen einfachen P-Regler implementiert, der die Differenz von Soll- und Ist-Wert der Encoderticks als Fehler bekommt und diese auf 0 bringen soll. Dabei wird dieser Fehler auf die aktuelle Lage des Drehfeldes addiert, was dann als Code so aussieht:

Code:
static float angle = 0;
float error = setpointMotor0 - currentPosition;

error *= 1.1; // K_p = 0.5 * K_p,krit  mit  K_p,krit = 2.2 (experimentell bestimmt)
limit<float>(error, -150, 150); // Maximalwert, dem der Motor ohne Rampe folgen kann
angle -= dt*error; // dt ist die Zeit seit dem letzten Aufruf

if (angle > M_2PI)
    angle -= M_2PI;
else if (angle < -M_2PI)
    angle += M_2PI;

constexpr float amplitude = 1537.0f / 2.0f;
phase0 = amplitude + amplitude * sin(angle);
phase1 = amplitude + amplitude * sin(angle + 2.0f/3.0f*M_PI);
phase2 = amplitude + amplitude * sin(angle + 4.0f/3.0f*M_PI);
setMotor0PWM(phase0, phase1, phase2);
Grundsätzlich funktioniert das auch soweit, wie die angehängten Plots zeigen, allerdings ist die Reglerperformance noch durchaus ausbaufähig. Einmal ist das Überschwingen noch sehr stark. Dann sieht man im Plot, in dem auf 90° geregelt wird, dass die Haftreibung ein Problem darstellt. Hier hat sich der Regler eigentlich nach 130 ms eingeschwungen, liegt aber genau einen Encodertick neben dem Zielwert. Bei den Motorstellgrößen sieht man dann auch ganz gut, wie dieser kleine Fehler aufintegriert wird, bis der Motor einen Tick weiterdreht.

Und damit bin ich auch bei meiner eigentlichen Frage: dadurch, dass ich die Position des Drehfeldes regle, habe ich mir ja den eben erwähnten Integrator in die Strecke eingebaut. Wenn ich nun also einen Regler mit I-Anteil verwende (hab mal testweise einen PI-Regler benutzt), fängt das System aufgrund der dann doppelten Integration bereits bei sehr kleinem I-Anteil zu schwingen an. Nun sind bei den meisten Gimbal Controllern aber PID-Regler implementiert, wobei ich mir im Moment nur vorstellen kann, dass damit die Geschwindigkeit des Drehfeldes geregelt wird, was aber auch irgendwie wieder keinen Sinn ergibt. Könnt ihr mir vielleicht einen Tipp geben, was da nun der beste Ansatz ist?

Plots:
90°
posTest90_2_Gesamt.png
45°
posTest45_2_Gesamt.png
15°
posTest15_1_Gesamt.png
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten