Einen Mecanum-Roboter bauen, der seitwärts fährt

Was du baust

Einen vierrädrigen Roboter, der sich in jede Bodenrichtung bewegen kann, ohne erst zu drehen – und drehen kann, ohne zu ändern, wohin er fährt. Ihn seitwärts durch eine Gasse schieben, in die er kaum passt; eine Kamera auf etwas gerichtet halten, während man es umkreist; 3 cm neben einer Linie per 3-cm-Schritt korrigieren statt heraus- und hereinzubogen.

Das ist der erste Roboter dieser Seite mit drei einzeln steuerbaren Geschwindigkeiten statt zwei. Es ist auch der erste, dessen Antriebsstrang wirklich schwerer ist als seine Sensoren – weshalb fast der ganze Bau Motoren, Encoder und Regelschleifen ist.

Der Abnahmetest ist bewusst plump: Ein 1-m-Quadrat strafend fahren und innerhalb 5 cm heimkommen, bei unverändertem Kurs. Kein Differenzialroboter kann diesen Test überhaupt antreten.

Die Zahl, die das Projekt treibt

Alles an diesem Bau kommt auf eine Konstante zurück:

k = lx + ly

wobei lx der halbe Radstand ist (Vorderachse zu Hinterachse, halbiert) und ly die halbe Spur (linke Räder zu rechten Rädern, halbiert). Am Referenzbau 75 mm und 85 mm, also k = 0,160 m.

Diese eine Zahl koppelt Drehung an die Räder. Falsch, und der Roboter fährt weiter – aber ein reiner Drehbefehl kriecht über den Boden, und reines Strafen kurvt, weil Drehung und Translation ineinander bluten. Radmitte zu Radmitte messen, nicht die Chassisplatte, die meist breiter ist als gedacht.

Die anderen Zahlen, die man vor Beginn mit Marker aufs Chassis schreibt:

Stückliste

90–170 £ gesamt. Räder und vierfache Motorzahl sind der Ort, wo aus den 50 £ eines Zweiradroboters das hier wird.

Wie alles zusammenhängt

        2S LiPo ──┬── 470 µF ── TB6612FNG #1 ── FL motor ── FL encoder ─┐
                  │                         └── FR motor ── FR encoder ─┤
                  ├── 470 µF ── TB6612FNG #2 ── RL motor ── RL encoder ─┼── ESP32
                  │                         └── RR motor ── RR encoder ─┘   (4 PWM,
                  └── 5 V BEC ──────────────────────────────── ESP32 ──────  8 GPIO,
                                                                   │         I²C)
                                                   MPU6050 ── I²C ─┘

Drei Verdrahtungsentscheidungen, die nicht offensichtlich sind:

• Der ESP32 bekommt einen eigenen Regler. Vier gemeinsam startende Motoren drücken den Pack hart, und ein Controller an derselben Schiene setzt per Brownout zurück und startet mitten im Befehl neu. Sieht exakt aus wie ein Firmwareabsturz. Das Leistungsbudget-Tutorial lesen, bevor man dem Code die Schuld gibt.
• Ein Stützkondensator über jeden Treiber. 470 µF nah an der Platine. H-Brücken ziehen stoßweise und Leitungsinduktivität verwandelt diese Stöße in Spitzen.
• Die IMU auf die Mittellinie, flach und so weit von den Motoren, wie die Platte erlaubt. Gierdrift ist schlimm genug ohne Magnetfeld vierer Motoren darin.

In Meilensteinen bauen

Jeder hat einen Test. Keinen Fehler nach vorne tragen – an einem Viermotorroboter multiplizieren sie sich.

1. Räder dran, und die X-Probe

Die vier Räder anschrauben und direkt darüberstellen. Der sichtbaren Rollenlinie auf der Oberseite jedes Rads folgen.

Test: Diese vier Linien zielen auf die Robotermitte und zeichnen ein X. Zeichnen sie eine Raute, zwei Räder diagonal tauschen. Bestanden: ein X. Das ist eine Fünf-Sekunden-Probe, die einen Tag spart.

2. Jeden Motor einzeln

Alle vier verdrahten und einen Sketch schreiben, der jeweils ein Rad eine Sekunde mit 40 % treibt.

Test: Jedes aufrufen und bestätigen, dass das richtige Rad richtigherum dreht. Bestanden: vier Räder, vier korrekte Richtungen, keine vertauschten Paare. Verdrahtung in Hardware richten, nicht mit Minuszeichen im Code – man verliert den Überblick.

3. Encoder

Je eine Umdrehung jedes Rads, von Hand gedreht.

Test: Den Zählwert ausgeben. Bestanden: innerhalb 2 % von 1440, und positiv bei Vorwärtsdrehung des Rads. Ein springender oder rückwärts laufender Zählwert heißt: Auf einem statt zwei Kanälen interruptet, oder ein volatile long ohne gesperrte Interrupts gelesen.

4. Kinematik aufgebockt

Den Roboter aufbocken und reines Strafen befehlen.

Test: Diagonalpaare gegenläufig – vorne links und hinten rechts in eine Richtung, vorne rechts und hinten links in die andere. Bestanden: exakt dieses Muster. Dann reinen Dreh befehlen: linke Seite eine Richtung, rechte die andere. Widerspricht ein Rad, sitzt es in der falschen Ecke und Schritt 1 hat gelogen.

5. Eine Drehzahlschleife

Feedforward dann PI an einem Rad abstimmen, aufgebockt, dann unter Last.

Test: 0,3 m/s befehlen und einen Finger auf den Reifen drücken. Bestanden: Die Drehzahl hält und das PWM steigt sichtbar. Einmal sauber tun; die anderen drei sind Kopien mit eigenem kS und kV.

6. Alle vier, gerade Linie

Vier Schleifen, 100 Hz, auf dem Boden. 3 m geradeaus fahren.

Test: Die Seitwärtsdrift am Ende messen. Bestanden: unter 20 mm, und über drei Läufe wiederholbar. Ungeregelt sind das typisch 80–200 mm und jedes Mal anders.

7. 1 m strafen

Test: Exakt einen Meter seitwärts fahren und Strecke wie Kursänderung messen. Bestanden: innerhalb 5 cm, Kurs innerhalb 3°. Eine konsistente Kurve heißt: k-Konstante falsch; eine zufällige heißt: Eine Drehzahlschleife hält nicht.

8. IMU und feldorientiert

Beim Start Bias-kalibrieren, Kurstaste dazu.

Test: Den Steuerknüppel vorne halten und den Roboter von Hand eine volle Drehung drehen. Bestanden: Er fährt weiter gleich über den Boden. Im Stillstand driftet Gier unter 3° pro Minute.

9. Das Quadrat

Der Abnahmetest. 1 m vor, 1 m rechts, 1 m zurück, 1 m links fahren, ohne irgendwo Drehung zu befehlen.

Test: Abstand zum Startpunkt und Kursänderung. Bestanden: innerhalb 5 cm und 3°.

Wie gut aussieht

Die letzte Zeile ist ehrlich statt enttäuschend. An diesem Antrieb ist Rollenschlupf der Mechanismus – die Odometrie ist also die schwächste Zahl am Roboter, selbst wenn alles arbeitet. Die Erwartung einbauen statt ihr hinterherjagen.

Hardwarenotizen, die zählen

Radhändigkeit ist eine Seteigenschaft. Zwei einzeln bestellte Einzelräder aus derselben Anzeige sind sehr oft dieselbe Hand. Prüfen, bevor man irgendetwas bohrt.

Jede Rolle muss sich frei drehen. Jede einzeln von Hand schnippen, bevor die Räder montiert werden. Eine blockierte Rolle verwandelt diese Ecke intermittierend in ein Normalrad, das 45° daneben zeigt – was exakt wie ein Softwarefehler liest.

Mecanum-Räder sind schwer. 180–400 g pro Stück – bis 1,6 kg des Roboters sind also Räder, und das ist rotierende Masse an den Enden der Hebelarme. Der Roboter fühlt sich träge an, und darum zählt die Beschleunigungsdecke.

Der Boden ist ein Bauteil. Polierter Beton und Vinyl liegen um μ = 0,8. Ein staubiger Hallenboden, eine Haarsprayschicht fremder Roboter oder eine Linoleumnaht halbieren ihn lokal – und der Roboter ändert sein Verhalten beim Überqueren. Ansehen, was μ = 0,25 tut, bevor man der Abstimmung die Schuld gibt.

Wenn es schiefgeht

Wohin als Nächstes

Messräder. Zwei oder drei ungetriebene Omniräder auf Federhaltern, mit eigenen Encodern. Sie tragen kein Drehmoment, rutschen also nicht – und verwandeln die schlechteste Zahl dieses Roboters in die beste.

Holonome Pfadfolge. Pure Pursuit und Stanley setzen einen Roboter voraus, der lenkt. Eine Basis, die strafen kann, kann Besseres – Pfadposition und Kurs unabhängig verfolgen, denn dafür hat man getrennte Aktoren.

Eine Kamera auf einer kurs haltenden Basis. Die natürliche Paarung: Eine Visionspipeline wird weit leichter, wenn die Kamera aufs Ziel gerichtet bleiben kann, während sich die Basis umpositioniert. Dafür ist holonomer Antrieb wirklich da.

ROS 2. Dieser Antriebsstrang ist der erste hier, wo cmd_vels linear.y – von einem Differenzialroboter explizit ignoriert – endlich etwas heißt. Die Twist-zu-Räder-Funktion gegen die vierzeilige Mecanumvariante zu tauschen ist der Großteil der Arbeit.