Elektronik-Grundlagen für Roboter: Ein Lernpfad
Einen Roboter versorgen, der unter Last stabil bleibt, mehrere Sensoren an einen I²C-Bus hängen und eine Schleife schreiben, die alle ausliest, ohne je zu blockieren.
Die meisten Roboterprobleme, die wie Softwareprobleme aussehen, sind keine. Die Platine setzt sich zurück und der Code wird beschuldigt; ein Sensor liefert Unsinn und die Bibliothek wird beschuldigt; der Roboter ignoriert seinen Bumper und die Logik wird beschuldigt. In jedem Fall liegt der Fehler eine Schicht tiefer – in dem Teil des Systems, über den niemand ein Tutorial geschrieben hat, weil er zu grundlegend wirkte, um eines zu brauchen.
Dieser Pfad ist diese Schicht. Er behandelt Stromversorgung – warum die Akkuspannung beim Motoranlauf einbricht und was dagegen hilft; den I²C-Bus – was diese beiden Drähte, die sich alle Sensoren teilen, tatsächlich tun; und Timing – warum eine Schleife, die stehen bleibt, ein Roboter ist, der nicht reagieren kann.
Nichts davon ist schwierig. Alles davon setzt jeder andere Pfad dieser Seite voraus.
Bevor du beginnst
Du brauchst einen Mikrocontroller, den du bereits flashen kannst, und die Bereitschaft, ein Multimeter an einen Akku zu halten. Keine Regelungstheorie, keine Mathematik jenseits von Addition und einer Division. Wer überhaupt schon etwas gebaut hat – selbst eine blinkende LED –, ist bereit.
Was du danach kannst
- Einen Reset in unter einer Minute von einem Absturz unterscheiden – und wissen, welchen von beiden du vor dir hast, bevor du irgendeinen Code öffnest.
- Die Stromaufnahme eines Roboters zusammenzählen und daraus einen Akkupack wählen, statt aus dem, was im Set lag.
- Erklären, warum ein 9-V-Block mit der höchsten Spannung im Regal unter Last das schlechteste Ergebnis liefert, und vorhersagen, wie weit jeder Pack einbricht.
- Mehrere Sensoren an einen I²C-Bus verdrahten, mit einem Scanner finden und eine Adresskollision auf drei verschiedene Arten auflösen.
- Eine Schleife schreiben, die Sensoren ausliest, Motoren antreibt und Status meldet – mit drei verschiedenen Raten, ohne je zu blockieren –, und den Überlauf-Vergleich korrekt hinbekommen.
- Die eigene Worst-Case-Schleifenzeit messen statt annehmen.
Wo die meisten feststecken
„Kein Reset“ als Beweis werten, dass die Versorgung in Ordnung ist. Der Brownout-Detektor eines Arduino liegt bei 2,7 V, aber ein ATmega328P mit 16 MHz braucht etwa 3,8 V, um innerhalb seiner Spezifikation zu laufen. In diesem Band läuft der Chip außerhalb der Spezifikation und nichts greift ein – dort leben die seltsamsten Fehler eines Roboters: korrupte Variablen, ein zuckendes Servo, ein Sensor, der plausiblen Unsinn liefert.
Einen Kondensator einlöten und erwarten, dass er den Reset behebt. Die Rechnung spricht dagegen: Ein 1000-µF-Kondensator, der 10 ms lang einen 2-A-Einbruch tragen soll, würde um 20 V einbrechen. Er glättet Schaltripple und Kommutierungsspitzen – was sich lohnt –, aber nur ein steiferer Akku trägt den Einbruch.
Breakout-Boards auf einem Bus stapeln. Fast jedes Board bringt eigene Pull-up-Widerstände mit, und sie liegen parallel. Drei Boards sind grenzwertig und das vierte drückt den Bus unter den Strom, den irgendein Bauteil senken kann – drei Sensoren funktionieren also und der vierte tötet alle, ohne dass tatsächlich etwas kaputt ist.
Eine 8-Bit-Adresse aus dem Datenblatt lesen. Im Datenblatt des MPU-6050 steht 0xD0; die Arduino-Bibliothek will 0x68 – dieselben Bits, um eins nach rechts geschoben. Das ist der häufigste I²C-Fehler überhaupt und sieht exakt aus wie ein totes Board.
now >= last + interval schreiben. Es liest sich natürlicher als die Subtraktionsform und bricht beim Überlauf nach 49,7 Tagen – feuert dann dauerhaft statt zu warten. Immer subtrahieren.
Der Schleifenlogik die Schuld für eine blockierte Schleife geben. Interrupts laufen während delay() weiter, also bleibt eine Encoderzählung perfekt korrekt, während der Roboter aufhört zu reagieren – weshalb das Symptom wie ein Entscheidungsfehler aussieht statt wie ein Timingfehler.
Was du brauchst
| Was | Warum dieser Pfad es braucht | Ungefähre Kosten |
|---|---|---|
| Einen flashbaren Mikrocontroller | Jede Messung hier findet auf einer laufenden Platine statt, nicht auf Papier | Arduino Uno, ~8 € als Clone |
| Ein Multimeter | Das eine Instrument, ohne das dieser Pfad nicht geht – jede Behauptung verifizierst du selbst | ~15 € |
| Einen Akkupack unter Last | Ein unbelastet gemessener Pack sagt nichts; du brauchst einen, der etwas antreibt | 4×AA-Halter oder 2S-Li-Ion |
| Zwei I²C-Breakout-Boards | Ein Board zeigt das Pull-up-Problem nie. Zwei fangen an. | MPU-6050 + irgendetwas, ~5 € |
| Einen oder zwei Motoren | Die Last, die die Schiene einbrechen lässt – der Fehler, dessentwegen es diesen Pfad gibt | Beliebiger DC-Getriebemotor |
Kein Oszilloskop. Jede Messung auf diesem Pfad ist eine Gleichstrommessung für ein billiges Multimeter.
Warum der Pfad in dieser Reihenfolge läuft
Die Reihenfolge ist nicht beliebig – jede Station nimmt der nächsten eine Möglichkeit, dich anzulügen.
Timing kommt vor allem Gemessenen. Eine blockierte Schleife macht jede andere Messung verdächtig, weil man nicht mehr sagen kann, wann ein Messwert aufgenommen wurde. Erst mit nicht blockierender Schleife kann man einem Zeitstempel vertrauen – und erst dann lohnt es sich, eine Messung aufzuschreiben.
Strom kommt vor Analog. analogRead auf einem Arduino ist ratiometrisch – es meldet den Eingang als Bruchteil seiner Referenz, und die Standardreferenz ist dieselbe 5-V-Schiene, die Motoren nach unten ziehen. Einen Akku über einen Teiler auf einbrechender Schiene messen, und der Messwert steigt, während der Akku fällt. Eine Spannung ehrlich zu messen ist unmöglich, solange man nicht weiß, was die eigene Schiene tut – die Stromstation muss also zuerst kommen.
I²C kommt nach Strom, ist aber unabhängig von Analog. Der Bus ist ein eigenes Subsystem und fällt auf eigene Art aus – durch Pull-up-Arithmetik und Adresskollisionen, nicht durch Versorgungseinbrüche. Er hängt direkt an der Platinenstation, weshalb sich der Baum dort verzweigt.
Das Labor kommt zuletzt. Der Sensorsimulator lässt Rauschen, Offset und Aussetzer gezielt zu einem sauberen Signal hinzufügen. Das ist erst lehrreich, wenn man die eigene Hardware sie versehentlich erzeugen sah und weiß, was jeweils dahintersteckte.
Kontrollpunkte: Woran man merkt, dass eine Stufe sitzt
Jede davon ist eine Werkbankprüfung, kein Quiz. Wer die Zahl nicht liefern kann, ist mit der Stufe nicht fertig.
| Stufe | Die Prüfung | Wie Bestanden aussieht |
|---|---|---|
| Nicht blockierendes Timing | Die Worst-Case-Dauer der eigenen Schleife über 10 Sekunden ausgeben | Eine Zahl in Mikrosekunden, die du gemessen, nicht angenommen hast – und sie wächst nicht, wenn ein Sensor abgezogen wird |
| Akku unter Last | Packspannung bei stehenden, dann blockierten Motoren messen | Du kannst den Einbruch in Volt nennen und durch den Strom teilen, um den Innenwiderstand des Packs zu erhalten |
| Leistungsbudget | Die Stromaufnahme jedes Bauteils auf Papier addieren, dann die Summe messen | Papier und Messgerät stimmen auf etwa 20 % überein; wenn nicht, hast du ein Bauteil gefunden, das mehr zieht als sein Datenblatt behauptet |
| Analogeingang | Denselben Akku über deinen Teiler bei stehenden und laufenden Motoren lesen | Der Messwert ändert sich beim Motoranlauf nicht – wenn doch, wandert deine Referenz |
| I²C-Bus | Einen Busscanner laufen lassen und Boards einzeln hinzufügen | Jede Adresse erscheint, und du kannst den gesamten Pull-up-Widerstand auf dem Bus nennen |
| Adresskollision | Den AD0-Pin des MPU-6050 auf High legen | Der Scanner meldet 0x69 statt 0x68 – und du kannst erklären, warum im Datenblatt 0xD0 steht |
Wo dieser Pfad endet
Dieser Lernpfad endet bewusst dort, wo die Elektronik aufhört, dich anzulügen. Er behandelt keine Motortreiber, keine Regelschleifen, nichts, was entscheidet, wohin ein Roboter fahren soll – das sind die Pfade Motorsteuerung und PID-Regelung, und beide setzen alles hier voraus.
Er lässt außerdem drei Dinge aus, die man nennen sollte, damit man weiß, dass es sie gibt. Keine Schaltregler – so holt man 5 V aus einem 12-V-Pack, ohne die Differenz als Wärme in einem Linearregler zu verbrennen. Kein Level-Shifting zwischen 5-V- und 3,3-V-Bauteilen, das man braucht, sobald ESP32 und 5-V-Sensor erstmals denselben Bus teilen. Und kein Platinenlayout oder Löten – alles hier geschieht auf dem Steckbrett, was zum Lernen in Ordnung ist und selbst eine Quelle für Wackelkontakte darstellt, sobald sich ein Roboter bewegt.
Lern-Roadmap
Der Pfad
Folge den Knoten der Reihe nach – jeder schaltet den nächsten frei, sobald du ihn erledigt hast. Dein Fortschritt wird auf diesem Gerät gespeichert.
0 / 9 erledigt
Häufige Fragen
Häufig gestellte Fragen
Welche Elektronik muss ich vor dem Roboterbau kennen?
Drei Dinge, und keines davon ist fortgeschritten. Man muss eine Stromversorgung aus dem Strom dimensionieren, den der Roboter tatsächlich zieht, damit er sich beim Motoranlauf nicht zurücksetzt. Man muss den I²C-Bus gut genug verstehen, um mehrere Sensoren an zwei gemeinsame Drähte zu hängen, ohne dass sie sich stören. Und man muss eine Regelschleife schreiben, die nie stehen bleibt, damit der Roboter reagieren kann, während er etwas anderes tut. Alles andere – Regelungstheorie, Navigation, Kinematik – sitzt obendrauf.
Warum setzt sich mein Arduino zurück, wenn die Motoren anlaufen?
Der Innenwiderstand des Akkus verwandelt den Anlaufstrom der Motoren in einen Spannungseinbruch, und die ganze Schiene sackt mit. Ein Motor, der 2 A Anlaufstrom durch einen Pack mit 0,5 Ω Innenwiderstand zieht, drückt die Schiene um ein volles Volt nach unten, bevor irgendetwas den Regler erreicht. Fällt die Platine dabei unter ihre Brownout-Schwelle, startet sie neu. Die Lösung ist ein steiferer Akku und eine getrennte Motorversorgung, kein größerer Kondensator – ein 1000-µF-Kondensator, der 10 ms lang 2 A tragen soll, würde um 20 V einbrechen, also kann er einen Einbruch dieser Größe nicht überbrücken.
Wie viele I²C-Sensoren passen an einen Arduino?
Der Adressraum erlaubt 112 Bauteile, aber die elektrische Grenze kommt lange vorher. Fast jedes Breakout-Board bringt eigene Pull-up-Widerstände mit, typisch 4,7 kΩ, und gestapelte Boards schalten diese Widerstände parallel. Vier Boards ergeben etwa 1,2 kΩ, was bei 5 V über 4 mA Senkenstrom verlangt – mehr als die 3 mA, die ein I²C-Bauteil verkraften muss. Drei Boards funktionieren meist und das vierte tötet den ganzen Bus. Die Pull-ups bis auf ein Board entfernen, und man kommt deutlich weiter.
Ist delay() im Robotercode wirklich so schlimm?
Für einen Roboter: ja. Während der Prozessor in delay() sitzt, liest er keine Sensoren und trifft keine Entscheidungen – ein Roboter in delay(500) ist eine halbe Sekunde blind, was bei 0,3 m/s 15 cm Fahrt sind. Tückisch an der Diagnose: Interrupts laufen weiter, also bleiben Encoderzählungen die ganze Zeit perfekt korrekt. Das Symptom sieht aus wie defekte Entscheidungslogik statt blockiertes Timing. Durch das millis()-Muster ersetzen – und beim Vergleich subtrahieren statt addieren, sonst bricht der Vergleich beim Überlauf nach 49,7 Tagen.
Brauche ich ein Oszilloskop für diesen Pfad?
Nein. Ein Multimeter reicht für alles hier – Akkuspannung unter Last messen, Teilerausgang prüfen, bestätigen, dass keine Schiene eingebrochen ist. Ein Oszilloskop macht Brownouts und I²C-Probleme deutlich sichtbarer, und wer eines besitzt, sollte es nutzen – aber jede Messung, die dieser Pfad verlangt, ist eine Gleichstrommessung für ein 10-Euro-Messgerät.
Wie lange dauert dieser Lernpfad?
Etwa zwei Stunden Lesezeit über die vier Tutorials und realistischerweise ein bis zwei Abende an der Werkbank für die eigentlichen Messungen. Die Messungen sind der Sinn – die Zahlen, denen dieser Pfad vertrauen lehrt, sind der Einbruch des eigenen Akkus, die Pull-up-Summe des eigenen Busses und die Worst-Case-Zeit der eigenen Schleife, von denen sich keine nachschlagen lässt.