HaBuRo6 Framework, Quelle Github

Das ESP32 Wifi Balancing Robot Framework besteht aus drei Software-Modulen.

PD/PI-Regler: Control.cpp & Control.h.
Sechsachsiger Bewegungssensor, Gyroskop und Beschleunigung: MPU6050.cpp & MPU6050.h.
Steuerung für zwei Schrittmotoren: Motors.cpp & Motors.h & Timers.cpp.

Die Software ist aus meiner Sicht gut kommentiert und strukturiert. Ein- und Ausgänge des ESP32 und alle Basisparameter werden in der Datei defines.h definiert. Deklaration der Variablen erfolgt in der Datei global.cpp. global.h (Deklaration extern) sorgt für die Zugänglichkeit der Variablen in den einzelnen Software Modulen.

Der Roboter wird ferngesteuert. Die Firma Bluino Electronics stellt eine Applikation für das Betriebssystem Android zur Verfügung. Google Play Store sorgt für die Installation. Details zur Bluino-App findest du hier.

Visual Studio Code mit der Extension PlatformIO ist meine Entwicklungsumgebung (IDE). Das hat zur Folge, dass der Inhalt der Datei: esp32_wifi_balancing_robot.ino in eine neue Datei main.cpp transferiert werden muss.

Das ESP32 Wifi Balancing Robot Framework wurde im Kern vom Spanier Jose Julio (EVO2, Jahr 2017) entwickelt. Seine Webseite „jjrobots.com“ ist noch als Webadresse vorhanden, jedoch wirst du zu einer merkwürdigen Seite geleitet. Suche nicht danach.

Im Jahr 2024 habe ich den HaBuRo3 gebaut. Der PID-Regler erhält als Eingangsgröße den Winkel vom MPU6050 Sensor. Die Ausgangsgröße des Reglers ist die Geschwindigkeit der Motoren. Für die Balancierung ok jedoch für die Fortbewegung war das Ergebnis nicht so gut. Eine wirkliche Verbesserung ist die Software von Jose Julio. Eine PD-Steuerung für die Balancierung und eine zusätzliche PI- Geschwindigkeitsregelung. Quasi eine Kaskadenregelung! Für den HaBuRo3 wurde eine Regler-Bibliothek eingesetzt. Auch kein guter Weg! Jose Julio bildet aus dem MPU6050 Steueralgorithmus und den zwei PD/PI-Reglern einen gemeinsamen Zeittrigger [dt]! Die verwendeten Motoren sind Schrittmotoren vom Typ NEMA17 mit A4988-Treibern und 1/8 Mikroschritten. Wobei hier die Positionierung der Schrittmotoren keine Rolle spielt. Eine präzise Geschwindigkeitsregelung mittels Interrupts (25 kHz) ist die Lösung!

Downloade ESP32 Wifi Balancing Robot Framework von GitHub und integriere es in die Visual Studio Code Entwicklungsumgebung mit der Extension PlatformIO. Starte den Compiler. Die Kompilierung bricht mit Warnungen und einer Fehlermeldung ab, weil der jetzige Compiler eine strengerer Typenprüfung vornimmt und die Software aus dem Jahr 2017 nicht den heutigen Standard entspricht. Wir müssen einige Dinge korrigieren.

Fehler: processOSCMsg was not declared in this scope.
Es fehlt die Deklaration für diese Funktion. Zwei Möglichkeiten gibt es, diesen Fehler zu beheben: Die Funktion processOSCMsg() in den Zeilen 401 bis 486 vor der void loop(), Zeile 272, platzieren.
Der bessere Weg! Die Funktion in Zeile 38 zu deklarieren:void processOSCMsg(void);.

Die Warnungen in der Datei MPU6050.h beheben:
typedef union accel_t_gyro_union in Zeile 434 ändern in union accel_t_gyro_union!

Doppelt definiert: MPU6050_AUX_VDDIO. Beheben: Zeile 16 in der Datei MPU6050.h auf Kommentar setzen: //#define MPU6050_AUX_VDDIO 0x001.

Doppelt definiert: MPU6050_FIFO_EN. Beheben: Zeile 27 in der Datei MPU6050.h auf Kommentar setzen: //#define MPU6050_FIFO_EN 0x023.

MPU6050.cpp Zeile 236: Wire.requestFrom(MPU6050_I2C_ADDRESS, size, true) ändern in Wire.requestFrom(MPU6050_I2C_ADDRESS, size, 1)

Bevor wir den ESP32 Mikrocontroller betanken müssen wir noch zwei Parameter für das WiFi-Netzwerk eingeben. In Zeile 40 musst du die SSID (Service Set Identifier) eingeben. SSID ist der Name deines WLAN-Netzwerks. Nichts geht ohne Passwort! Auch bei deinem WLAN-Netzwerk. Das Passwort wird in Zeile 41 eingetragen.

Die wichtigsten Software Module genauer untersuchen!

Wenn die acht Euro teure Steuerplatine bestückt ist, dann macht es Sinn einzelne Module vorher zu testen. Die nachfolgenden Bilder veranschaulichen, wie ich die Hard- und Software im Vorfeld getestet habe.

Das obige Bild zeigt die Software für den Test der zwei Schrittmotoren. Wie bereits erwähnt geht es nicht um Positionierung, sondern um das Regeln der Geschwindigkeit. Montiere bei diesem Test auch die Räder! Verändere den Speed in Zeile 60/61. Man kann ganz schnell herausfinden bei welcher Geschwindigkeit die Motoren kein Drehmoment mehr liefern, die vom Motortreiber A4988 gelieferten Impulse vom Stepper verschluckt werden und vieles mehr. Messe auch den Strom. Weiterhin ist jetzt auch die Gelegenheit für die zwei Motortreiber A4988 den Strom einzustellen. Im Netz gibt es darüber viele Beispiele. Wenn alles funktioniert dann sorge dafür, dass die Motoren die richte Drehrichtung haben. Vorwärtsfahrt entspricht Drehen im Uhrzeigersinn. Dafür habe ich die Funktion void mov2(void), Zeile 46 bis 57 gefrickelt. Hinweis: In der Datei define.h Zeile 61 ist ein sehr wichtiger Parameter: MAX_ACCEL. Spiele damit!

Sechsachsiger Bewegungssensor, Gyroskop und Beschleunigung MPU6050 unter die Lupe nehmen. Getestet wird hier die Kalibrierung und ist der Neigungswinkel (Pitch, hier nicht x sondern y) plausibel wenn du die Testvorrichtung bewegst. Folgendes Ergebnis muss du erzielen: Positiver Neigungswinkel und Drehrichtung der Motoren im Uhrzeigersinn. Negativer Neigungswinkel und Drehrichtung der Motoren gegen den Uhrzeigersinn.

Hier wird das Servo getestet. Hinweis: Nach dem Einschalten des Roboters richtet sich der Roboter selbstständig auf. Das Servo hat keinen Anteil an diesem Prozess!!

Was macht das ESP32 Wifi Balancing Robot Framework?

Eine kurze Beschreibung.

Diese kurze Beschreibung bezieht sich mit den Zeilennummern auf das originale Projekt Bluino von GitHub Du musst es dir irgendwo archivieren, weil ja das Framework jederzeit geändert werden kann. Ansonsten hast du keinen korrekten Bezugspunkt zu den Zeilen!


Der Roboter wird auf den Boden gelegt (Augen zum Boden) und der Einschalter wird betätigt.
Die Funktion setup(), Start Zeile 59, main.cpp.
Das Servo fährt in die Grundstellung, Zeile 88, main.cpp.

Der MPU6050 Sensor wird initialisiert, Zeile 47 bis 51 und Zeile 91, main.cpp. Der Zustand der MPU6050-Initialisierung wird über den Print-Monitor angezeigt. Zeile 100 bis 110, MPU6050.cpp (WHO_AM_I und error).

Danach wird der MPU6050 Sensor kalibriert, Zeile 50, main.cpp und Zeile 60 bis 98, MPU6050.cpp. Der Print-Monitor visualisiert Gyro calibration... DONT MOVE!

Der ESP32 kontaktiert das WiFi-Netzwerk, Zeile 93 bis 141, main.cpp. Der Print-Monitor visualisiert die IP-Adresse, in meinem Fall 192.168.188.78. Bei Verbindungserfolg leuchtet die boardeigene ESP32-LED (blau).

Es folgt die eventgesteuerte Anforderung GET REQUEST für alle Kommandos, die die Android-Bluino-App bereitstellen muss, Zeile 144 bis 246, main.cpp. Alle Kommandos der Android-Bluino-App werden über den Print-Monitor visualisiert, Zeile 241 – finde ich sehr hilfreich! Beachte: Es ist ein ereignisgesteuerter Prozess der Bibliothek ESPAsyncWebServer.

Jetzt kommen die zwei Stepper ins Spiel. Timerinterrupt wird initialisiert, Zeile 248, main.cpp. Der Roboter liegt immer noch auf dem Boden. Jetzt passieren zwei Dinge: Die Motoren und das Servo zappeln kurz vor und zurück. Zeile 256 bis 267.

Ende Funktion setup(), Zeile 270, main.cpp
Start der Funktion loop(), Zeile 272, main.cpp.

Kommen Kommandos von der Android-Bluino-App? Zeile 275 bis 278, main.cpp.

Daten vom MPU6050 Sensor werden gelesen und mit einem Zeittrigger [dt] verbunden, Zeile 280 und 282, main.cpp. In den Zeilen 290 bis 296 wird der Winkel in die Variable angle_adjusted gespeichert. Diese Variable wird dem PD-Regler als Istwert übergeben, Zeile 327. Weil der Robert immer noch in nahezu (23°) waagerechter Position auf dem Boden liegt, und damit der Winkel größer 56° ist erfolgt jetzt die Abarbeitung in Zeile 387 bis 393. Die zwei Regler erhalten spezielle Parameter und der Roboter richtet sich auf. Nun steht er in senkrechter Position! Dadurch werden die zwei Regler erneut mit user-Werten betankt, Zeile 382 bis 386!

Der Roboter ist in senkrechter Position und wird in Balance gehalten. Ruhig steht er nicht, er tänzelt leicht hin und her. Softwaretechnisch passiert das in den Zeilen 327 bis 350. Die Reaktion auf Fahr- und Kurvenbefehle, Funktion processOSCMsg() werden in diesem Kapitel etwas erläutert.

Die Beschreibung des Roboters ist parallel zum Bau entstanden. Nach einigen Wochen habe ich den Datenstrom zwischen Roboter und der Android-App genauer unter die Lupe genommen. Siehe obiges Bild. Ich möchte die Fernsteuerung auf Bluetooth umstellen, weil ich kein Android (Samsung) Mobilphone habe und ich kann nicht ständig das Handy meiner Frau benutzen. Das geht gar nicht! Zuerst möchte ich es mit der Bibliothek RemoteXY versuchen und später eine eigene Fernsteuerung zusammenstricken.