Gimbal "Taktik"

Hi Leute,

obwohl kleine Gimbals mittlerweile zu günstigen Preisen auf den üblichen China-Märkten rumfliegen möchte ich gerne selbst einen Gimbal bauen und programmieren. Dass der Preis mit hoher Wahrscheinlichkeit die fertigen Gimbals übersteigen wird ist mir bewusst. Hierbei interessiert mich mehr das "Wie" als das "fertige Produkt".

Meine Ausgangssituation

Für die ersten Versuche habe ich einen 1-Achs-Gimbal mit Servoantrieb gezeichnet. Es fehlen noch die Anschlussmaße vom Motor. Sobald der da ist, werden die kurz nachgetragen und das ganze kann gefräst werden.

Die Software

In vielen Videos habe ich ein "Zittern" und ruckeliges Verhalten der DIY Gimbals bemerkt.
Sofern es nicht an Strommangel lag, wird das wohl auf einen Software- bzw. Regelfehler zurückzuführen sein.

Hier ein paar Gedanken von mir..

Um ein ruckartiges Steuern zu verhindern kann man die Geschwindigkeit des Servos abhängig von dem Differenzwinkel (IstWinkel-SollWinkel) gestalten. z.B. durch lineare, quadratische, potenz-Funktionen..

Damit dürfte auch schon ein wenig Zittern vermieden werden denke ich, da bei kleinen Differenzwinkeln eben nicht voll beschleunigt korrigiert wird.

Meine Fragen an euch:

Ist das ganze mit dem Motor handlebar? Hab bislang noch nicht mit Servos gearbeitet und ehrlichgesagt ein wenig wild drauf losgekauft...

Was haltet ihr von den Ideen? Das ganze wird schwierig bei Modellbauservos die einen 180° Winkelbereich haben, da die Geschwindigkeit fix ist..
Der ausgesuchte kann wohl dauerhaft drehen.. So stehts zumindest in den Reviews..

Kann man da zur Not mit linearer Interpolation arbeiten?

Habt ihr weitere Ideen / "Taktiken"?

Viele Grüße
l00py

Hallo, glücklicherweise kann man im Internet herausfinden, was "Gimbal" ist: Beispielsweise Lageausgleich einer Kamera für Drohnen. Damit weißt Du auch, wieviel ich von diesem Thema weiß.

l00py:
Das ganze wird schwierig bei Modellbauservos die einen 180° Winkelbereich haben, da die Geschwindigkeit fix ist..

Wenn Du den Sollwert von Winkel a nach b veränderst, dreht der Servo mit seiner maximalen Geschwindigkeit. Durch mehrere kleinere Winkelveränderungen kannst Du die Geschwindigkeit beim Drehen verringern. Nur die maximale Geschwindigkeit ist fix.

Dein 360°-Servo verhält sich da nicht anders, allerdings fehlt ihm die Rückmeldung über die Position, da verhält er sich wie ein normaler Motor. Solche Servos werden beispielsweise für Seilwinden verwendet und haben den Vorteil der gleichen Ansteuerung wie normale Servos. Für Dich und die Lageregelung ist der nur dann sinnvoll, wenn Du die Position anderweitig erfaßt. Das Drehmoment wäre auch noch zu berücksichtigen, also welche Masse Du beschleunigen willst.

Die Arduinos können prima Servos, Schrittmotoren und DC-Motoren ansteuern, ob das auch schnell genug möglich ist, steht auf einem anderen Blatt.

Woher weißt Du, welchen Winkel die einzelnen Achsen der kardanischen Aufhängung (gimbal) einnehmen sollen?
Die Ermittlung dieser Werte, und eine ungeeignete Nachreglung der Motoren (Regelfehler, Überschwingen...), kann zu Zittern führen.

Die einfachste Lage-Stabilisierung ist eine mechanische, mit einem Kreisel. Ob die anwendbar ist, kommt drauf an, was genau Du erreichen möchtest.

Hi,

danke schonmal für eure Antworten!

Für Dich und die Lageregelung ist der nur dann sinnvoll, wenn Du die Position anderweitig erfaßt. Das Drehmoment wäre auch noch zu berücksichtigen, also welche Masse Du beschleunigen willst.

Die Position wird über einen Beschleunigungssensor erfasst. Dort stell ich für jede Achse einen 0-Punkt, welcher “gehalten” werden soll…

Zumindest ist das der bisherige Plan!

Punkto Drehmoment…

Die Mechanik wird aus Carbon 2mm Plattenmaterial und 2,5-4er Carbonrohr gefertigt. Für den Test kommt eine Gopro ähnliche Kamera darauf. Die ganze Konstruktion ist so ausgelegt, dass die Kamera im Ruhezustand im Schwerpunkt hängt. Die Servos sollten so Unterstützung durch die Schwerkraft bekommen. Sollte das Drehmoment nicht reichen muss halt was größeres her…

Woher weißt Du, welchen Winkel die einzelnen Achsen der kardanischen Aufhängung (gimbal) einnehmen sollen?
Die Ermittlung dieser Werte, und eine ungeeignete Nachreglung der Motoren (Regelfehler, Überschwingen…), kann zu Zittern führen.

Die einfachste Lage-Stabilisierung ist eine mechanische, mit einem Kreisel. Ob die anwendbar ist, kommt drauf an, was genau Du erreichen möchtest.

Kreisel ist leider zu schwer und zu groß… Aber gute Idee…!

Die Winkel werden über einen Beschleunigungssensor gemessen.

Wenn ich den Sensor ruhig in der Hand halte zittern die Werte minimal. Hab da mal ein Bild angehangen.
Hier müssten die Werte geglättet werden denke ich.

Dachte an eine Funktion die grob so aussieht.

Wenn die Differenz zum Vorherigen Wert größer als Filterwert(z.B.1 oder 2) ist, dann nehme neuen Wert, sonst halte den alten.

Für weitere Ideen und Anregungen bin ich offen und würde euch bei Interesse auch weiter auf dem Laufenden halten!:slight_smile:

Viele Grüße

l00py

l00py:
Die Position wird über einen Beschleunigungssensor erfasst. Dort stell ich für jede Achse einen 0-Punkt, welcher "gehalten" werden soll..

Dann hast Du schon mal das Problem, daß jede Nachjustierung in einer Achse eine weitere Beschleunigung ergibt, die zum Fehlersignal addiert wird. Ich bin mir nicht sicher, ob man das mit einem einfachen PID Regler überhaupt in den Griff kriegen kann, da der Verlauf dieses zusätzlichen Störsignals vom dynamischen Verhalten der Stellmotoren abhängt (Ansprechzeit, Beschleunigung, Einschwingzeit...). Da ist ein Jitter fast unvermeidbar, umso mehr je schlechter die Mechanik ist (Reibung...).

Bei meinem Modelheli hab ich zur Heckstabilisierung einen Kreisel mit "Heading hold", da bleibt das Heck immer in Position. Es gibt Stabilisierungssysteme die machen das in allen Achsen. Da musst du mal schauen, was die für Sensoren haben.

Smartphones haben ja auch Lagesensoren, die immer wissen, wo sie hinschauen. Das wird was ähnliches sein.

l00py:
Die ganze Konstruktion ist so ausgelegt, dass die Kamera im Ruhezustand im Schwerpunkt hängt. Die Servos sollten so Unterstützung durch die Schwerkraft bekommen.

Trotzdem muß die Masse der Kamera beschleunigt werden. Frag mal die Astronauten der ISS, warum sie beim Ausladen von Versorgunggütern trotz Schwerelosigkeit ins Schwitzen kommen.

Grundsätzlich solltest Du auch über Schrittmotoren mit Getriebe als Alternative nachdenken.

DrDiettrich:
Dann hast Du schon mal das Problem, daß jede Nachjustierung in einer Achse eine weitere Beschleunigung ergibt, die zum Fehlersignal addiert wird. Ich bin mir nicht sicher, ob man das mit einem einfachen PID Regler überhaupt in den Griff kriegen kann, da der Verlauf dieses zusätzlichen Störsignals vom dynamischen Verhalten der Stellmotoren abhängt (Ansprechzeit, Beschleunigung, Einschwingzeit...). Da ist ein Jitter fast unvermeidbar, umso mehr je schlechter die Mechanik ist (Reibung...).

Hm.. hatte den Ansatz verfolgt, dass wenn die Beschleunigung bei 0 gehalten wird, dass sich die Kamera dann nicht bewegt. Hab ich da einen Denkfehler?
Integriert man die Beschleunigung 2 mal, so hat man den Weg.
Ist die Beschleunigung 0, so ist der Weg auch 0?

ElEspanol:
Bei meinem Modelheli hab ich zur Heckstabilisierung einen Kreisel mit "Heading hold", da bleibt das Heck immer in Position. Es gibt Stabilisierungssysteme die machen das in allen Achsen. Da musst du mal schauen, was die für Sensoren haben.

Smartphones haben ja auch Lagesensoren, die immer wissen, wo sie hinschauen. Das wird was ähnliches sein.

Guter Tipp, danke!

agmue:
Trotzdem muß die Masse der Kamera beschleunigt werden. Frag mal die Astronauten der ISS, warum sie beim Ausladen von Versorgunggütern trotz Schwerelosigkeit ins Schwitzen kommen.

Grundsätzlich solltest Du auch über Schrittmotoren mit Getriebe als Alternative nachdenken.

Richtig..
Schrittmotoren würde ich nur als Notlösung einsetzen wollen, da die elektrischen Komponenten teurer und aufwendiger sind.. Aber wenns nicht anders geht..

Einige nutzen auch Brushlessmotoren.. Aber auch da bräuchte man einen ESC? - so heißt das glaube ich..

l00py:
Einige nutzen auch Brushlessmotoren.. Aber auch da bräuchte man einen ESC? - so heißt das glaube ich..

Da wir im Arduino-Forum sind:
ESC = electronic speed controller
BL = Brushlessmotor

Hier habe ich gerade was gelernt: "BL-Steller sind erheblich aufwändiger im Aufbau. BL-Motoren sind im Grunde dreiphasen-Wechselstrom-Motoren. Deswegen muss der Steller die Spannung der drei Phasen getrennt aufbereiten. Zudem muss die Elektronik für die korrekte Kommutierung sorgen, damit überhaupt eine Drehzahl gestellt werden kann."

Das erinnert mich an die H-Brücke für Schrittmotoren, der der Arduino auch ein "Ballett" von HIGHs und LOWs geben muß.

Bei Brushlessmotoren im Modellbau denke ich an Propeller, also Highspeed, bei Schrittmotoren eher an langsame und gezielte Bewegungen.

l00py:
Schrittmotoren würde ich nur als Notlösung einsetzen wollen, da die elektrischen Komponenten teurer und aufwendiger sind.. Aber wenns nicht anders geht..

Der hier ist wahrscheinlich nicht Deine Qualitätsklasse, läßt sich direkt von Arduino ansteuern und bewegt bislang zuverlässig mein Kohlekranmodell, das von der Masse einer größeren Digitalkamera entsprechen könnte. 360/(64*64) = 0,088 Grad pro Schritt. Wäre zur "Not" einen Gedanken wert.

agmue:
Der hier ist wahrscheinlich nicht Deine Qualitätsklasse, läßt sich direkt von Arduino ansteuern und bewegt bislang zuverlässig mein Kohlekranmodell, das von der Masse einer größeren Digitalkamera entsprechen könnte. 360/(64*64) = 0,088 Grad pro Schritt. Wäre zur "Not" einen Gedanken wert.

Viel zu langsam, es ist kein Schrittmotor notwendig, sondern schnelle untersetzte Motore. Die Rückmeldung erfolgt ja über die Sensoren. Brushless sind state of the art, aber früher hat man das mit normalen superschnellen Modellbau Servos gemacht. Die hatten Glockenanker DC Motoren.

Hallo,

danke erst einmal für eure Antworten! Vermutlich werde ich dann auf eine eurer Alternativen umsteigen, da der Servo doch sehr laut ist. Aber zuvor möchte ich gerne den Servo ans Laufen bringen.. :slight_smile:

Ich melde mich erst jetzt, da ich in der letzten Woche mit zwei Problemen zu kämpfen hatte:

Kabelgewirr
Für die ersten Versuche, so dachte ich, steck ich das kurz zusammen und dann läufts...
Denkste.. Wackelts kurz hier nen bisschen.. Stecker raus. Hier nen Wackler und dort auch.
Natürlich verstärkt dadurch, dass ich den Sensor samt Steckbrett bewegte...

Hier habe ich mir dann durch einen kleinen Aufbau geholfen:

Klappt schon besser.. aber immer noch nicht..!

Stromprobleme?

Ja.. ich schätze es liegt am Strom. Der Sensor alleine funktioniert top.
Der Servo alleine auch!

Wenn beide zusammen laufen, zeigt der Sensor nur noch Müll an.
Externe Stromversorgung dran. Läuft garnix mehr. Durch den gepulsten Strom scheinbar zu wenig Power.. Werde mich jetzt nach nem alternativen Netzteil umschauen. Vllt. nen ATX-PC Netzteil..

Wollte euch nur auf dem neusten Stand halten, nicht dass ihr denkt, dass das Projekt schon im Sande verlaufen ist..! :stuck_out_tongue:

Kondensatoren in der Spannungsversorgung nahe den Verbrauchern wären einen Versuch wert.

agmue:
Kondensatoren in der Spannungsversorgung nahe den Verbrauchern wären einen Versuch wert.

Gibts da ne Faustregel zum bestimmen von C?

l00py:
Gibts da ne Faustregel zum bestimmen von C?

Ich kenne da nur eine: Bastelkiste auf und 4,7 bis 10 µF probieren, die finde ich da immer. Ist ja auch nur ein Versuch.

Danke,
aus Mangel an Kondensatoren hab ich dann doch ein PC-Netzteil genommen…

Das ganze sieht jetzt so aus…

In dieser Einstellung übersteuert er zwar nicht, jedoch ist er auch nicht sehr agil…!

Wenn ich die “Cut-Offs” agiler verlege, fängt der Gimbal an mega zu übersteuern.

Gibt es Ideen, wie ich das vermeiden kann?

#include <Servo.h>

Servo myservo;

//Variablen
double pos = 90;    // variable to store the servo position

//Pins of Sensor
int x_axis = 10;

//Values of Sensor
int x_value = 0;

//Zeropoints
int x_zero = 0;

//Difference
int x_diff;

void setup() {
  myservo.attach(2); 

  Serial.begin(9600);
  delay(2000); //Zeit zum Ausrichten nach Einschalten
  myservo.write(90);
  delay(200);
  read_sensor();
  x_zero = x_value;
  Serial.println(x_zero);
}

void loop() {
  programm1();
  //test_sensor();
}

void test_sensor() {
  Serial.println(analogRead(x_axis));
  delay(100);
}


void programm1() {

  x_value = analogRead(x_axis);

//Differenz bestimmen
      if (x_zero - x_value < 0) {
        x_diff = x_value - x_zero;
      }
      else
      {
        x_diff = x_zero - x_value;
      }

//Nah dran
      if (x_diff < 34) {
    
        if (x_zero - x_value > 4) {
          pos = pos - 0.1;
          //Serial.println("klein1");
        }
    
        if (x_value - x_zero > 4) {
          pos = pos + 0.1;
          //Serial.println("klein2");
        }
      }
  else //Weiter weg
      {
        if (x_zero - x_value > 7) {
          pos = pos - 0.8;
          //Serial.println("groß1");
        }
    
        if (x_value - x_zero > 7) {
          //Serial.println("groß2");
          pos = pos + 0.8;
        }
    
        
      }
  myservo.write(pos);
}

void servotest() {
  myservo.write(0);
  delay(2000);
  myservo.write(180);
  delay(2000);
}

void read_sensor() {

  x_value = analogRead(x_axis);
}

Wie willst Du erreichen, daß die Beschleunigung 0 bleibt? Immerhin mußt Du 2 Beschleunigungen berücksichtigen, die von der Schwerkraft durch Schieflage, und die von der Drehung mit dem Motor zur Korrektur der Schieflage.

l00py:
In dieser Einstellung übersteuert er zwar nicht, jedoch ist er auch nicht sehr agil..!
Wenn ich die "Cut-Offs" agiler verlege, fängt der Gimbal an mega zu übersteuern.

Willkommen in der Regelungstechnik! Wenn bei einem PID-Regler der I-Anteil zu groß ist, nähert sich der Istwert dem Sollwert asymptotisch. Ist der D-Anteil zu groß, bekommst Du ein Überschwingen.

Das derzeit zu beobachtende Regelverhalten hat aber keinen Aussagewert, da die Masse der Kamera fehlt. Mit Kamera sollte sich das Regelverhalten auf jeden Fall ändern. Die Trägheit der Kameramasse bremst den Servo bei jeder Bewegung. Ich freue mich auf Dein Video mit Kamera.

DrDiettrich:
Wie willst Du erreichen, daß die Beschleunigung 0 bleibt? Immerhin mußt Du 2 Beschleunigungen berücksichtigen, die von der Schwerkraft durch Schieflage, und die von der Drehung mit dem Motor zur Korrektur der Schieflage.

Vielleicht bin ich auf dem Holzweg weil alle Gimbals Girosensoren nutzen…
Dennoch bin ich der Annahme, dass mir das zu Gute kommt, denn so dürfte sich die Geschwindigkeit selbst ein wenig regeln. Immerhin möchte er ja die Ausgangsbeschleunigung(Erdgravitation) erreichen.

Werde es demnächst aber definitiv auch mit einem Kreisel probieren…!

agmue:
Willkommen in der Regelungstechnik! Wenn bei einem PID-Regler der I-Anteil zu groß ist, nähert sich der Istwert dem Sollwert asymptotisch. Ist der D-Anteil zu groß, bekommst Du ein Überschwingen.

Das derzeit zu beobachtende Regelverhalten hat aber keinen Aussagewert, da die Masse der Kamera fehlt. Mit Kamera sollte sich das Regelverhalten auf jeden Fall ändern. Die Trägheit der Kameramasse bremst den Servo bei jeder Bewegung. Ich freue mich auf Dein Video mit Kamera.

Eieieieiei da werd ich mich wohl erst ein wenig reinlesen müssen…!
Das Video mit der Kamera kommt leider frühestens am Wochenende, da ich erst dann die Aufhängung fräsen kann…


Neues Video (immer noch ohne Kamera :frowning: ) mit folgendem Code:

void loop() {

  if (stopvar == false) {
    programm1();
  }
  find_max_x_diff();
  //test_sensor();
}
void find_max_x_diff() {
  if (x_diff > x_diff_max)
  {
    x_diff_max = x_diff;
  }

  if (millis() > 10000 and millis() < 10100)
  {
    Serial.println(x_diff_max);
    stopvar = true;
  }

}
void programm1() {

  x_value = analogRead(x_axis);

  //Differenz bestimmen
  if (x_zero - x_value < 0) {
    x_diff = x_value - x_zero;
  }
  else
  {
    x_diff = x_zero - x_value;
  }

  //Regeln
  if (x_zero - x_value > 2) {
    pos = pos - 0.1 * abs(x_diff);
    //Serial.println("groß1");
  }

  if (x_value - x_zero > 2) {
    //Serial.println("groß2");
    pos = pos + 0.1 * abs(x_diff);
  }

  myservo.write(pos);
  delay(22);  'Damit der Sensor nachkommen kann..
}

find_max_x_diff() soll mir helfen objektiv zu beurteilen ob meine “Wertespielerein” das ganze zum Positiven oder Negativen beeinflussen…

Statt einer Asymptote nutze ich derzeit eine Gerade 0.1*abs(x_diff)

Ein wenig besser ist es ja schon. Hoffe, dass sich das mit der PID-Regelung einspielt!

P.S.: Während dem Post noch kurz was ausprobiert… Statt einer Linearen- nun eine Parabelfunktion genutzt. Schon besser…!

Also wenn ich das richtig interpretiere, müsste bei Bewegungen des Brettes der Servoarm in der Horizontalen verharren? Dann fehlt dem Servo in dem Video aber noch ordentlich Speed. Frag mal Tim den Heimwerkerkönig von Binford nach mehr Power ;D ;D ;D