Servos sind preiswerte kleine Stellmotore, die über ein PWM-Signal (Pulsweitenmodulation) angesteuert werden. Sie besitzen einen Arm, der sich um 180° (oder etwas mehr) drehen läßt. Ein bestimter Duty-Cycle (Puls-Pausen-Verhältnis) entspricht einer bestimmten Winkelstellung.
Es gibt Bibliotheken, um Servos anzusteuern. Wir verwenden die „ESP32Servo“ – Bibliothek.
Im Web haben wir ein Beispielsprogramm gefunden, das gleich noch einen kleinen Webserver mitbringt.
Wir müssen dort das #include von >Servo.h> auf <ESP32Servo.h> abändern und die Zugansdaten unseres WLAN eintragen. Dann können wir vom Browser aus die Position des Arms einstellen.
Webserver
Fast alle IoT (Internet of Things) Geräte bieten heute eine Web-Oberfläche, d.h sie besitzen einen eingebauten Webserver. Das ist nur selten eine „ausgewachsener“ Apache-Server. Viel häufiger sind es ein paar Zeilen Code, die sich auf eine WiFi/WebServer-Bibliothek stützen und eingehende Nachrichten auf Port 80 erkennen. Das Programm bekommt die jeweilige Nachricht übergeben und muss seinerseits eine Antwort (HTTP Response) erzeugen. Steckt in der Nachricht ein Sollwert für den Servo, so wird dieser entsprechend positioniert. Hat sich der Client ohne einen Sollwert gemeldet, so erfährt er einfach die aktuelle Position.
In unserem Beispiel erzeugt der Server den HTML-Code, den er an den Client liefern möchte, einfach direkt per „print“ Anweisung. Alternativ könnte er auch eine „index.html“ Datei ausliefern, aber dann müssen wir auf dem ESP32 ein Dateisystem einrichten (SPIFFS) und das macht die Sache in klein wenig komplizierter (und langsamer).
Was passiert, wenn wir die URL des ESP32 von zwei verschiedenen Rechnern (oder von zwei Browserfenstern) aufrufen? Der jeweils letzte Befehl behält recht – aber der andere Web-Client bekommt eine Veränderung nur mit, wenn er den Dialog aktualisiert. Der ESP32 merkt sich nämlich nicht, von wem er beauftragt wurde, den Motor zu verstellen. Außerdem könnte er als Server einen (ehemaligen) Client gar nicht erreichen: Das (normale) Web-Protokoll setzt immer voraus, dass der Client die Initiative ergreift. Es gibt Tricks, über die ein Client seine Anzeige laufend aktuell halten kann (Hintergrund-Polling, WebSockets), aber darauf verzichten wir hier.
Vorschläge zur Weiterentwicklung
Wie erweitert man das Programm so, dass es zwei Servos ansteuern kann?
Wie schnell kann ein Servo maximal laufen?
Können wir die Arme beider Servos im Takt bewegen? Parallel, gegenläufig, phasenverschoben? Mit ganzzahligem Teilungsverhältnis (z.B. 3:2)?
Wenn es genau sein soll, müssten wir sehr viele sehr kleine Winkeländerungen übertragen. Dabei wird uns irgendwann das Netzwerk bremsen. Besser wäre es, wenn wir einen Befehl für einen ganzen „Winke-Zyklus“ definieren und diesen dann autonom auf dem ESP32 ausführen. Zweckmäßig wäre es allerdings, wenn der Client ihn jederzeit unterbrechen könnte…
Wenn wir an einen Arm einen Faden binden und ein kleines Gewicht herunterhängen lassen: Wie stark können wir das Gewicht ins Schaukeln bringen? Und zwar entweder interaktiv oder durch ein Progamm, das die Bewegungen des Arms geschickt auf die Pendelbewegungen des Gewichts abstimmt.
Wenn wir den Faden durch einen sehr dünnen Stab (Fahrradspeiche) ersetzen: Können wir dann das Gewicht zum Überschlag bringen?
Können wir eine Rückkoppelung einbauen, so dass der Rechner immer weiß, wo sich das Gewicht gerade befindet? Vielleicht über einen optischen Sensor oder über einen Hall-Effekt-Sensor? Letzterer erfasst Magnetfeldänderungen. Wenn wir als Gewicht einen kleinen Magneten verwenden, könnte es sogar mit dem Sensor funktionieren, der auf der ESP32 Platine ohnehin verbaut ist. Durch sanftes Anstoßen (=Energiezufuhr passend zur Eigenfrequenz) können wir das Pendel endlos in Bewegung halten.