Warum der erste Arm nicht gereicht hat

Angefangen hat das Ganze mit einem gedruckten Roboterarm. Robotico 5, Sieben-Achser auf Arduino-Basis. 36 Druckteile, acht Servos, ein Wochenende Aufbau. Am Ende steht er da und fährt alle sieben Achsen sauber. Trotzdem hab ich ihn beiseite gelegt und mir einen anderen Arm gekauft. Warum, ist eigentlich die Geschichte. An der Software lag es nämlich nicht.

Erst der Aufbau

Der Robotico 5 kommt als Satz Druckdateien, die Elektronik suchst du dir selber zusammen. Bei mir wurde daraus:

• WEMOS LOLIN32 statt Arduino Uno, weil WLAN direkt mit drauf ist
• PCA9685, 16 Kanäle PWM mit 12 bit, über I2C
• 8× TD-8120MG, 20 kg Metallgetriebe, digital
• J2 als Doppelgelenk mit zwei gespiegelten Servos, deshalb acht Servos auf sieben Achsen

Zwei Sachen haben dabei richtig Zeit gefressen. Ein Dreierpack ESP32 war komplett tot. “No serial data received”, null Bytes vom Chip, auch beim Reset. Ich hab erst die Treiber verdächtigt, dann die Boot-Pins, dann die Kabel. Vom Modul kam aber schlicht gar nichts zurück. Der LOLIN32 lief dann auf Anhieb. Und ich hatte 3,3 V auf V+ gelegt statt auf VCC. Damit hing der ganze Servo-Rail an 3,3 Volt. Die Servos haben nur noch gezuckt, und beim WLAN-Start kam der Brownout. Auf dem PCA9685 liegen die zwei Klemmen direkt nebeneinander und heißen fast gleich. VCC ist die Logik, V+ sind die Servos.

Dann die eigene Steuerung

Zum Set gehört eine Desktop-App, die per USB an einem Arduino hängt. Wollte ich nicht. Kabel zum Rechner, fremde Software, und ändern kannst du auch nichts. Also eigene Steuerung auf den ESP32. Der hängt sich ins WLAN und ist im Browser unter robotico.local erreichbar. Klappt die Verbindung nicht, macht er wieder seinen eigenen Access Point auf. Bedient wird auf Achsebene und nicht auf rohen PWM-Kanälen. J2 sind zwar zwei Servos, aber nur ein Regler, der zweite läuft gespiegelt mit. Sonst drücken die beiden gegeneinander. Dazu Software-Endstops pro Achse, und beim Einschalten stehen alle Servos erstmal locker, damit nichts ruckartig anspringt.

Der Ruckel-Fix

Die erste Fassung sollte alle 15 Millisekunden einen festen 2°-Schritt fahren. Hat sichtbar geruckelt und das Ziel nicht sauber getroffen. Da lagen zwei Sachen übereinander. Die 15 Millisekunden waren nämlich nur der Plan. Der Webserver hält den Takt unregelmäßig auf, in echt vergehen mal 15 und mal 40 ms. Der Schritt bleibt aber immer 2°, also klumpt die Bewegung. Und ganze Grad sind für ein Servo ziemlich grob, das siehst du als Stufen. Geholfen hat, beide Annahmen wegzuwerfen:

• Zeitbasiert statt schrittbasiert. Jeder Schritt wird proportional zur wirklich vergangenen Zeit gerechnet, dann fällt der Jitter vom Webserver einfach raus.
• In Mikrosekunden als Fließkomma rechnen statt in ganzen Grad. Ein Grad sind rund 11 µs Pulsbreite. In Mikrosekunden triffst du das Ziel exakt statt auf ein Grad gerundet.
• I2C von 100 auf 400 kHz hoch, Tempo als Parameter statt fest verdrahtet.

Danach lief er sauber. Die Software war an dem Punkt gut genug.

Und dann die Grenze

Was blieb, war eine Sache, die sich nicht wegprogrammieren ließ: J2 sackt ab, sobald J3 ausfährt. Am Netzteil lag es nicht, das hat 10 A. Zwei Erklärungen kamen in Frage. Entweder ein kurzer Spannungseinbruch beim Anlauf von J3, oder einfach zu wenig Haltemoment, weil der ausgestreckte J3 das Moment auf J2 hochtreibt. Unterscheiden kannst du das am Verhalten: Zuckt J2 genau im Moment des Anlaufens, ist es der Strom. Sackt sie umso weiter, je weiter J3 draußen ist, ist es Mechanik. Beim Grübeln darüber ist mir aufgegangen, dass die Antwort eine Ebene höher liegt. PWM-Hobby-Servos haben drei Eigenschaften, die für einen Sieben-Achser prinzipiell nicht reichen. Open Loop. Du kommandierst eine Position und hoffst. Es kommt nichts zurück. Kein Ist-Wert, keine Last, keine Fehlermeldung. Weiches Haltemoment. Unter Last werden sie zurückgedrückt. An den unteren Achsen summiert sich Armgewicht mal Hebelarm, und genau da tut es am meisten weh. Deadband und Getriebespiel von ein bis zwei Grad. Damit wird das nie richtig steif und nie richtig präzise. Das ist die Lösung für “läuft für eine Demo”, nicht für “arbeitet präzise”. Ein dickerer Elko hätte das J2-Symptom vielleicht entschärft. An den drei Punkten oben ändert der nichts.

Die Entscheidung

Was ich eigentlich will, sind zwei Dinge. Ein Arm, der sich präzise steuern lässt, und einer, den eine KI über Kameras bedienen kann. Damit war die Frage nicht mehr “wie repariere ich den Robotico”, sondern “welche Klasse von Hardware brauche ich überhaupt”.

Option	Antrieb	Präzision	Kosten
LeRobot SO-101	Serial-Servos mit Feedback	Servo-Güte, etwas Spiel	~250–350 €
Annin AR4	Closed-Loop-Stepper	~0,2 mm wiederholgenau	~2,5–3,5 k€
BLDC mit Zykloidgetriebe	BLDC + Encoder, hält stromlos	sehr gut, wenn sauber gebaut	~1,5–4 k€
Fertiger Cobot	integriert	gut, sofort einsatzbereit	~4–8 k€

Der AR4 wäre der präzisere Arm. Aber mich reizt nicht die letzte Zehntelmillimeter, sondern das Zusammenspiel aus Kamera, KI und Greifer. Dafür bringt das LeRobot-Ökosystem am schnellsten ein Ergebnis. Und im Betrieb lerne ich, was mir an Präzision und Traglast wirklich fehlt. Das ist eine bessere Grundlage als jetzt 3.000 € auf einen Verdacht zu setzen. Geworden ist es das Waveshare SO-ARM101 CAM Kit. Zwei Arme, einer zum Führen und einer zum Arbeiten, zwölf Servos mit Positions- und Lastrückmeldung, dazu zwei Kameras mit Stativen. Die 101er läuft auf 12 V mit 30 kg·cm, nicht zu verwechseln mit der schwächeren 100 auf 7,4 V. Bei den Waveshare-Angeboten musst du übrigens genau hingucken. Es gibt ein “3DP Parts Kit” mit nur den Druckteilen und ohne Elektronik, ein “No-3DP Parts Kit” mit Servos und Boards aber ohne Druckteile, und das “CAM Kit” mit allem inklusive Kameras. Die Namen sehen sich sehr ähnlich.

Was der Robotico gebracht hat

Er steht noch da und ich bereue kein einziges Druckteil. Ohne ihn wüsste ich nicht, was mir fehlt. “Ich brauche Servos, die zurückmelden was sie tun” holst du dir schlecht aus einem Datenblatt. Da musst du einmal davorgestanden haben und gesehen haben, wie eine Achse langsam wegsackt und die Software das nicht mal merkt. Dieses Nicht-Merken hat mich dann durchs ganze nächste Projekt verfolgt.