Ein handygesteuertes Roboterauto über Bluetooth oder WLAN bauen
Ein Roboterauto, das du per Bluetooth oder WLAN vom Handy fährst und das von allein stoppt, sobald die Verbindung abreißt, statt wegzulaufen.
Was du baust
Ein Roboterauto, das du vom Handy fährst – über Bluetooth mit HC-05 oder über WLAN mit ESP32, der seine eigene Steuerseite serviert.
Es ist der zugänglichste Roboter dieser Seite: keine Regelungstheorie, kein richtig hinzubekommender Algorithmus, und die Fehlermoden sind sichtbar statt mathematisch. Es ist auch der, der eine Lektion lehrt, die jeder andere Roboter braucht – was zu tun ist, wenn man aufhört, die Kontrolle zu haben.
Die zwei Funkwege
| HC-05 (Bluetooth) | ESP32 (WLAN) | |
|---|---|---|
| Extrahardware | Ein Modul plus Teiler an RX | Keine – Funk steckt im Controller |
| Auf dem Handy | Eine Bluetooth-Serienapp | Ein beliebiger Browser |
| Reichweite | Grob 10 m | 30 m+ draußen |
| Handy behält Internet | Ja | Nein, im Access-Point-Modus |
| Am besten für | Einen ersten Drahtlosbau | Alles, was man anderen in die Hand geben will |
Keiner ist falsch. Das HC-05 ist der kürzere Weg zu einem Roboter, der sich bewegt; der ESP32 ist das bessere Erlebnis, sobald es läuft – denn „mit diesem WLAN verbinden und Browser öffnen“ braucht keine Erklärung.
Stückliste
Zwei Routen, und man braucht nur eine. Die Bluetooth-Variante bauen, wenn man bereits einen Arduino besitzt; die WLAN-Variante, wenn man heute Teile kauft.
| Teil | Bluetooth-Route | WLAN-Route | Ungefähre Kosten |
|---|---|---|---|
| Controller | Arduino Uno | ESP32 | 5–8 $ |
| Funk | HC-05-Modul | Eingebaut | 4 $ / 0 $ |
| Pegelwandlung | 1 kΩ + 2 kΩ am RX des Moduls | Nötig an jedem 5-V-Sensoreingang | 0,10 $ |
| Motortreiber | 1 | 1 | 2–4 $ |
| TT-Getriebemotor | 2 | 2 | 4 $ |
| 2WD-Chassis | 1 | 1 | 6–10 $ |
| Akkupack | 1 | 1 | 6 $ |
| Handyapp nötig | Ja – ein Bluetooth-Serienterminal | Nein – ein beliebiger Browser | — |
Gesamt: grob 25–35 $ so oder so.
Der entscheidende Unterschied sind nicht die Kosten, sondern die Steuerschnittstelle. Ein HC-05 liefert einen Bytestrom – das Handy braucht also eine App, die Bytes senden kann. Ein ESP32 serviert seine eigene Webseite – das Handy braucht einen Browser: Jeder kann den Roboter fahren, indem er eine URL öffnet, ohne etwas zu installieren. Für einen Roboter, den man anderen in die Hand geben will, ist das ein großer Unterschied für kein Extrageld.
Die Bluetooth-Route verdient ihren Platz, wenn man bereits einen Arduino hat oder wenn man die denkbar einfachste Verbindung ohne Netzwerkwissen überhaupt will. Ein Byte hinein, ein Byte hinaus.
Baureihenfolge
1 – Auf der Werkbank fahren lassen. Motoren, Treiber, Akku, Räder in der Luft, gar kein Funk. DC-Motoren mit PWM steuern folgen und vorwärts, rückwärts sowie jede Drehung mit fest verdrahteten Befehlen bestätigen. Funk und Motortreiber gleichzeitig zu debuggen lässt Nachmittage verschwinden.
2 – Den Funk dazu und Echo. Das HC-05 verdrahten oder den Access Point des ESP32 hochbringen – und Text in beide Richtungen bewegen, bevor man ihn an etwas hängt, das sich dreht.
3 – Mit einem Protokoll verbinden. Ein Buchstabe plus Wert, mit Zeilenumbruch abgeschlossen. Bis zum Terminator lesen statt auf jedes Byte zu reagieren – denn „einige Bytes sind da“ ist nicht „die Nachricht ist da“.
4 – Ausfallsicher machen. Das ist der Schritt, den Leute auslassen – und der, auf den es ankommt.
Der Totmann-Timeout
Ein Drahtlosroboter tut weiter das Letzte, was man ihm sagte. War das „Vollgas vorwärts“ und ist man gerade außer Reichweite gegangen, stoppt der Roboter nicht – er zieht durch.
Die Lösung hat zwei Hälften und braucht beide:
- Der Controller wiederholt. Das Handy sendet den gehaltenen Befehl alle 100 ms, nicht einmal beim Drücken.
- Der Roboter erwartet ihn. Trifft ~400 ms nichts ein, stoppen.
if (millis() - lastCommandAt > 400) stop();Nun erzeugen losgelassener Knopf, geschlossene App, leerer Handyakku und Verlassen der Reichweite dasselbe Ergebnis. Man hängt nie an einer Stoppnachricht, die nie gesendet werden mag.
Dafür millis() statt delay() verwenden. Ein delay(200) irgendwo in der Schleife sind 200 ms, in denen der Roboter nichts liest und nichts prüft.
Hardwarenotizen
Dem Funk eine saubere Versorgung geben. Beide Module ziehen beim Senden Strom in scharfen Stößen. Eine mitsackende gemeinsame Schiene mit Motoren verursacht Resets, die exakt wie Softwareabstürze aussehen – der Roboter reagiert mitten in der Fahrt nicht mehr und kommt eine Sekunde später zurück. Die Motoren aus dem Akkupack über den Treiber speisen und die Logikversorgung getrennt halten.
Die 3,3-V-Pins beachten. Das RX des HC-05 und jedes ESP32-GPIO sind 3,3-V-Teile. Ein 5-V-Arduino, der hineinsendet, braucht einen Teiler. Der Schaden ist graduell und partiell – was die Diagnose schwer macht.
Ein L298N reicht hier. Sein Spannungsabfall zählt an einem Roboter, der einer Linie mit Tempo jagt; an einem handgefahrenen Auto gleicht man schlicht mit dem Gas aus – der billigere, gängigere Treiber ist also die vernünftige Wahl.
Wie gut aussieht
| Messung | Bluetooth (HC-05) | WLAN (ESP32) |
|---|---|---|
| Befehlslatenz | 20–60 ms | 30–100 ms im lokalen Netz |
| Reichweite, freie Sicht | ~10 m | ~50 m, oder überall im Netz |
| Reichweite durch eine Innenwand | 3–5 m | 15–25 m |
| Zeit bis zur ersten Steuerung nach Einschalten | ~2 s nach Paarung | ~5 s bis WLAN-Beitritt |
| Wiederverbindung nach Abbruch | Manuell, meist | Automatisch |
| Totmann-Timeout, der sich richtig anfühlt | 300–500 ms | 300–500 ms |
Der Totmann-Timeout ist die Zahl, die sorgfältiges Abstimmen lohnt – und beide Funkwege brauchen ihn. Zu lang, und der Roboter fährt nach Verbindungsabriss merklich weiter – was bei 0,3 m/s und 1-s-Timeout 30 cm unbeaufsichtigte Fahrt sind. Zu kurz, und normaler Paketjitter stoppt den Roboter ständig, was sich kaputt anfühlt.
300–500 ms sind das nutzbare Band für beide. Unter etwa 250 ms beginnt gewöhnlicher WLAN-Jitter auszulösen; über etwa 700 ms ist eine abgerissene Verbindung sichtbar ein Durchgehen.
Wohin das weitergeht
Die gebaute Befehlsschicht ist von jeder Verhaltensebene unabhängig – genau das macht sie zu einem guten Fundament. Einen Ultraschallsensor dazu, und der Roboter kann sich weigern, in eine Wand zu fahren, selbst wenn du Vorwärts hältst – der Anfang des Hindernisvermeidungsroboters.
Diese Kombination – ein Roboter, den man fahren kann und der einen überstimmen kann –, ist auch der leichteste Weg, Autonomie zu entwickeln: Man kann den Roboter exakt dorthin stellen, wo ein Fehler geschieht, ohne hinzugehen und ihn aufzuheben.
Projekt-Roadmap
Der Baupfad
Folge dem Technikbaum von den Bauteilen bis zum funktionierenden Roboter. Jeder Knoten wird freigeschaltet, sobald seine Voraussetzungen erledigt sind, und dein Fortschritt wird auf diesem Gerät gespeichert.
0 / 14 erledigt
Bauteile
- ControllerArduino UnoDas gutmütige 8-Bit-Board, über das die meisten die Robotik kennenlernen.
- KommunikationHC-05 Bluetooth ModuleKabelloses Seriell über Bluetooth – Roboter vom Handy fahren mit zwei Pins.
- ControllerESP32Ein Dual-Core-Mikrocontroller mit WLAN und Bluetooth – der drahtlose Aufstieg vom Uno.
- TreiberL298N MotortreiberDie Doppel-H-Brücke, die schwache Logikpins in Motorleistung verwandelt.
- AktorDC Gearmotor (TT Motor)Der gelbe Getriebemotor, der aus nacktem Chassis ein fahrendes Roboterauto macht.
- Chassis2WD Robot ChassisDie Plattform, auf die zwei Motoren, eine freie Rolle und die Elektronik geschraubt werden.
- StromversorgungRobot Battery & Power PackDer Unterschied zwischen einem Roboter, der läuft, und einem, der ständig neu startet.
Tutorials in diesem Pfad
- Einsteiger · 1 StundeRoboter per Bluetooth mit HC-05-Modul steuernKopple ein HC-05 mit deinem Handy und fahre einen Roboter über Bluetooth-Seriell – ohne den klassischen 5-V-Fehler.
- Mittelstufe · 1,5 StundenEinen Roboter per Browser fahren mit ESP32-WebserverEine Steuerseite direkt vom ESP32 servieren, damit jeder Browser den Roboter fährt – keine App nötig.
- Einsteiger · 18 Min. LesezeitGleichstrommotoren steuern mit PWM und H-BrückeVerdrahte und steuere einen bürstenbehafteten Gleichstrommotor sicher mit PWM, H-Brücke und realistischen Stromgrenzen.
- Einsteiger · 17 Min. LesezeitEndliche Zustandsmaschinen für RoboterverhaltenVerhedderte Roboterbedingungen durch explizite Zustände, Ereignisse, Übergänge, Timeouts und Erholung ersetzen.
Häufig gestellte Fragen
Soll ich Bluetooth oder WLAN für ein Roboterauto nehmen?
Bluetooth mit HC-05 geht schneller in Betrieb und paart einmal – braucht aber eine serielle Terminal-App und reicht grob zehn Meter. Ein ESP32 über WLAN braucht gar keine App – er serviert seine eigene Steuerseite an jeden Browser – und reicht weiter, doch das Handy verliert seine Internetverbindung, solange es im Roboternetz hängt. Für einen ersten Bau ist Bluetooth der kürzere Weg; für alles, was man vorführen will, ist die app-lose Steuerseite des ESP32 die Extrastunde wert.
Warum fährt mein Bluetooth-Roboter weiter, nachdem ich den Knopf losließ?
Weil er das Loslassen nie hörte. Ein kabelgebundener Roboter stoppt beim Loslassen; ein drahtloser tut weiter das Letzte, was man ihm sagte. Die Lösung ist zweiseitig: Das Handy wiederholt den gehaltenen Befehl alle 100 ms, solange ein Knopf gedrückt ist, und der Roboter stoppt automatisch, wenn wenige hundert Millisekunden nichts eintraf. Dann erzeugen losgelassener Knopf und verlorenes Signal dasselbe sichere Ergebnis – und man hängt nie an einer Stoppnachricht, die nie ankommen mag.
Kann ich das HC-05 beschädigen, wenn ich es direkt an Arduino verdrahte?
Ja, an einem Pin. Die Modullogik ist 3,3 V und sein RX-Pin ist nicht 5-V-tolerant – ein Arduino, der direkt hineinsendet, stresst diesen Eingang. Tückisch daran: Der Schaden ist meist partiell – das Modul paart weiter und sendet weiter, korrumpiert oder ignoriert aber lautlos, was man ihm schickt. Zwei Widerstände als Teiler an dieser einen Leitung verhindern es.
Brauche ich eine App, um den Roboter vom Handy zu steuern?
Nur für Bluetooth. Ein HC-05 braucht irgendein Bluetooth-Serienterminal auf dem Handy, das den Port öffnet. Ein ESP32 braucht nichts: Er erzeugt sein eigenes WLAN und serviert eine HTML-Seite – man verbindet sich und öffnet einen Browser. Das ist das stärkste praktische Argument für den ESP32 an einem Roboter, den andere fahren können sollen.
Kann ein handygesteuerter Roboter auch selbst fahren?
Ja – und es ist der natürliche nächste Schritt. Die hier gebaute Befehlsschicht ist von der Verhaltensebene getrennt – Sensoren dazu, und der Roboter überstimmt dich: Er verweigert, in eine Wand zu fahren, selbst wenn du Vorwärts hältst. Erst die manuelle Schicht bauen: Einen Sensor zu debuggen ist weit leichter, wenn man den Roboter von der Raumseite von Hand positionieren kann.