Balance-Roboter-Simulator: Invertiertes Pendel-PID

Steuerung

Start, Pause und Zurücksetzen steuern die Schleife. Anstoßen gibt einen Impuls wie ein Finger, und Kreis an/aus schaltet beide Regler ab, damit du die ungeregelte Strecke fallen siehst.

Die direkteste Steuerung ist der Roboter selbst: Ziehe den Aufbau auf einen beliebigen Winkel und lasse los. Welche Pose du hinterlässt, dort übernimmt der Regler — ohne Scharfschalten, und die Verstärkungs-Schieber wirken sofort auf die laufende Simulation. Stelle die D-Verstärkung im Balancezustand auf null, und er beginnt noch in derselben Sekunde zu taumeln.

Das Menü Abstimmung lädt vier Voreinstellungen: eine, die funktioniert, und drei, die auf die drei Arten scheitern, wie echte Balancierer scheitern.

Fokussiere die Zeichenfläche und nutze Leertaste, S, L, R und F für dieselben Funktionen per Tastatur.

Theorie

Einen Roboter auf zwei Rädern zu halten heißt, ein invertiertes Pendel aufrecht zu halten. Der Schwerpunkt sitzt über der Achse, die Vertikale ist also ein Gleichgewicht wie ein Bleistift auf der Spitze: mathematisch real, physisch hoffnungslos ohne ständige Korrektur. Jede Neigung erzeugt ein Schwerkraftmoment, das weiter neigt. Je weiter, desto schneller.

Der Roboter hat genau eine Art, diesem Moment zu begegnen — er kann die Achse bewegen. Räder vorwärts zu beschleunigen schiebt die Basis zurück unter den Schwerpunkt und dreht den Aufbau zur Vertikalen zurück. Darum fühlt sich die Korrektur zunächst invertiert an: Um nicht nach vorn zu fallen, musst du vorwärts fahren, so wie du die Hand unter einen Besen bewegst, den du balancierst, statt davon weg.

Das gibt dem Roboter eine harte Grenze. Jenseits von etwa 35° übersteigt die nötige Horizontalbeschleunigung das, was die Räder liefern können, bevor der Aufbau den Boden berührt — keine Verstärkung hilft dann. Die gestrichelten Linien in der Spur markieren diese Grenze.

Algorithmus

Der Regler ist kaskadiert — zwei PID-Kreise, einer speist den anderen.

Der innere Kreis läuft schnell und hält einen Neigungswinkel. Er vergleicht den Messwinkel mit einem Ziel und kommandiert Motormoment:

error   = measured_angle − target_angle
motor   = Kp·error + Ki·∫error + Kd·d(measured)/dt

Beachte: Der Fehler ist gemessen minus Ziel, nicht lehrbuchmäßig Ziel minus gemessen. Einen Vorwärtsfall zu fangen heißt, die Räder vorwärts zu treiben — positive Neigung muss also positiven Motorbefehl erzeugen. Dieses Vorzeichen ist der häufigste Grund, warum ein erster Balance-Roboter beim Einschalten sofort auf den Boden knallt.

Der äußere Kreis läuft langsamer und hält eine Position. Er kann die Motoren nicht kommandieren — die sind vergeben — und kommandiert stattdessen ein Neigungsziel für den inneren Kreis:

target_angle = Kp_pos·(desired_position − position) − Kd_pos·velocity

Liegt er hinter seiner Wunschposition, fordert er eine kleine Vorwärtsneigung an; der innere Kreis treibt die Räder, um diese Neigung zu halten, und der Roboter fährt vorwärts. Die Neigung ist bewusst auf wenige Grad geklemmt. Ein äußerer Kreis, der große Winkel fordern dürfte, gäbe dem inneren ein unhaltbares Ziel — beide Kreise verlören zugleich.

Der Integral-Anteil zählt hier mehr als in den meisten Kreisen, denn er schluckt die Differenz zwischen der Vertikalen, die die IMU meint, und der echten Vertikalen. Darum muss das Integral aufhören aufzuintegrieren, solange die Motoren sättigen — sonst läuft es während eines Sturzes hoch, den es nicht verhindern kann, und bekämpft danach die Erholung.

Quellcode

// Inner loop: tilt → motors. Runs every 5 ms off a timer, not in loop().
float angleError = angle - tiltTarget;          // measured minus target
angleIntegral   = constrain(angleIntegral + angleError * dt, -3, 3);
float command   = Kp * angleError
                + Ki * angleIntegral
                + Kd * gyroRate;                // rate straight from the gyro

command = constrain(command, -255, 255);
if (fabs(angle) > FALL_ANGLE) command = 0;      // past saving; cut the motors
driveMotors(command, command);

// Outer loop: position → tilt target. Runs ten times slower, and may only
// ever ask for a small lean.
if (++slowTick >= 10) {
  slowTick = 0;
  float positionError = 0 - wheelPosition;
  tiltTarget = constrain(KpPos * positionError - KdPos * wheelVelocity,
                         -0.12, 0.12);          // radians, about ±7°
}

Zwei Details übertragen sich direkt aus diesem Simulator. Nimm den D-Anteil aus der Gyrorate statt den Winkel zu differenzieren: Das Gyroskop misst diese Rate direkt und ohne das Rauschen, das Differenzierung verstärkt. Und schalte die Motoren jenseits des Rückholwinkels ab, statt den Regler weiter kämpfen zu lassen — das schont die Getriebe und macht den Fehler offensichtlich statt heftig.

Hardware

Der Sensor ist ein MPU6050 mit Beschleunigungssensor und Gyroskop, denn keiner allein taugt. Der Beschleunigungssensor kennt unten, wird aber von der Eigenbewegung überlagert; das Gyroskop verfolgt Drehung sauber, driftet aber binnen Sekunden. Ein Komplementärfilter fusioniert beides zu einem Winkel, der stabil und schnell ist.

Motoren müssen untersetzt genug für Drehmoment und schnell genug zum Fangen sein — N20-Getriebemotoren um 200 U/min sind üblich, getrieben von einem TB6612FNG, dessen geringer Dropout zählt, wenn die Schleife tausendfach pro Sekunde kleine Korrekturen fordert.

Baue es echt im Balance-Roboter-Projekt oder beginne mit dem Neigungs-Tutorial, wenn die IMU neu für dich ist.

Annahmen und Unterschiede zur Hardware

Das Modell ist ein 2D-invertiertes Pendel mit einer Neigungsachse, starren Gliedern, ohne Schlupf und einer IMU, die wahren Winkel und Rate nur mit der eingestellten Drift und dem Rauschen meldet. Ein echter Balance-Roboter spürt Motormoment, das mit der Batteriespannung schwankt, Encoder-Quantisierung, IMU-Montageoffset und Temperaturdrift — und er kann auch seitlich fallen, ein Freiheitsgrad, den dieses Labor ganz entfernt. Kaskadierte PID-Struktur und Gyro-D-Ableitung übertragen sich direkt, doch Montage-Trim, Filterabstimmung und Fallwinkel-Abschaltung müssen am physischen Chassis neu gefunden werden.

Schaltplan

Zwei Verdrahtungsregeln entscheiden, ob dieser Roboter läuft.

Die Motorbatterie erreicht den VM-Pin des Treibers und nichts sonst. Motorstrom darf nie durch den Arduino fließen, und jede Masse — Board, Treiber, IMU, Batterieminus — muss verbunden sein, sonst haben die Steuersignale keine gemeinsame Referenz, und der Fehler bleibt stumm statt offensichtlich.

Der Encoder wird aus der Logik versorgt, nicht aus der Motorschiene. Den Encoder an die Motorversorgung zu hängen zerstört ihn oder füllt die Zählung mit Schaltrauschen. Lege Encoder-Kanal A zudem auf einen interruptfähigen Pin; ihn aus loop() zu pollen verliert Impulse, und verlorene Impulse heißen: Der äußere Kreis verliert langsam die Roboterposition.