Der Arm sortiert Würfel

Vier Würfel liegen auf der Platte, zwei gelbe und zwei cyane. Der Arm holt sie einzeln und legt sie nach Farbe getrennt an die Seite. Zweimal hintereinander ohne Fehlgriff. Der Arm ist ein SO-101, ein offener Sechsachser zum Selberdrucken. Greifen konnte er vorher schon. Würfel erkennen, Position ausrechnen, Backen ausrichten, zupacken, anheben, das lief seit Tagen. Was fehlte war der ganze Rest. Wohin damit? Kommt er da überhaupt hin? Und kriegt er es mit, wenn nicht?

Ablagezonen ohne Papier

Meine erste Idee waren gedruckte Blätter mit Markern, die die Kamera erkennt. Also noch eine Erkennungsaufgabe obendrauf, mit allem was da dranhängt. Beleuchtung, Verdeckung, Blickwinkel. Dann ist mir aufgefallen, dass ich mir das Problem selber gebaut hatte. Der Arm weiß doch, wo er ist. Der kennt seine eigenen Koordinaten. Eine Ablagezone muss er überhaupt nicht sehen, es reicht wenn ich ihm sage wo sie liegt. Seitdem sind die Zonen einfach Zahlen. Vier Stück, bei (180, ±120) und (75, ±160) Millimeter. Jede ist ein 3x3-Raster mit 40 Millimetern Abstand, macht neun Plätze pro Farbe. Kein Papier, keine Marker, nichts was verrutschen oder im Schatten liegen kann. Wenn ich eine Zone verschieben will, ändere ich eine Zahl. Der eigentliche Gewinn kam nebenbei: Die Erkennung muss jetzt nur noch Würfel finden. Sie kann sich nicht mehr an einem Marker verschlucken, den ich vorher aus Versehen mit einem abgelegten Würfel zugedeckt habe.

Der Greifer lag sechs Prozent daneben

Das war allerdings nicht der erste Lauf. Beim ersten Sortierversuch hat er zu weich gegriffen, nicht immer, aber oft genug dass es nervte. Die zwei sauberen Läufe kamen erst danach. Die Werte für die Greiferöffnung standen seit dem Aufbau in der Konfiguration und ich hatte die nie hinterfragt. Also nachgemessen. Backen ganz zu, Position ablesen. Backen ganz auf, Position ablesen. Spaltmaß mit dem Messschieber. Ein Tick ist der kleinste Schritt, den der Lagegeber im Servo auseinanderhalten kann, die volle Umdrehung hat 4096 davon. Und meine Spanne zwischen den Anschlägen war 87 Ticks kürzer als in der Datei stand. Wie viele Millimeter ein Tick sind, ergibt sich aus dieser Spanne und dem Spaltmaß von 53 Millimetern. Weil die Spanne in der Datei zu groß war, war der Millimeterwert pro Tick sechs Prozent zu klein. Heißt: Wenn der Code auf 20 Millimeter Spalt gefahren ist, waren es in echt 18,3. Bei einem 20er-Würfel ist genau das der Unterschied zwischen greifen und schieben. Jetzt stehen die Anschläge bei 1076 und 2623 Ticks. Dazwischen liegen 1547 Ticks, und über die geht der Greifer von zu auf 53 Millimeter offen. Macht 0,034247 Millimeter pro Tick. Das ist also kein gemessener Wert, der fällt aus den beiden Anschlägen und dem Spaltmaß raus. Gerechnet war an den alten Zahlen nie was falsch. Nur die Spanne, mit der gerechnet wurde, hatte nie jemand nachgemessen.

Die Kinematik antwortet auch da, wo der Arm nicht hinkommt

Die Rückwärtskinematik rechnet aus, wie die Gelenke stehen müssen, damit der Greifer an einer bestimmten Stelle rauskommt. Gibst du ihr einen Punkt außerhalb der Reichweite, erwartest du eine Fehlermeldung. Kriegst du aber nicht. Sie liefert dir weiter eine Lösung, und die sieht erstmal völlig vernünftig aus. Der Arm fährt dann irgendwohin in die Nähe und greift daneben. Belastbar ist er bis ungefähr 280 Millimeter. Die vier Zonen liegen mit 180 und 216 Millimetern gut darunter, auch mit dem Raster obendrauf. Statt mir das im Kopf zu merken, prüft das Zonen-Skript beim Einrichten trotzdem alle 36 Plätze einmal durch und sperrt, was nicht erreichbar ist. Beim aktuellen Aufbau sind alle 36 in Ordnung. Wenn ich eine Zone verschiebe, sagt er mir das jetzt aber, statt einfach danebenzugreifen.

Das Muster dahinter

Wenn ich mir angucke, was zwischen “greifen” und “sortieren” wirklich Zeit gekostet hat: Es war fast nie eine falsche Rechnung. Es war jedes Mal eine Stelle, die einen falschen Wert zurückgibt und sich nicht beschwert. Sechs Stück habe ich an dem Wochenende gefunden.

• Die Kamera lieferte ein sechs Minuten altes Bild. Kein Fehler. Nur halt alt.
• Die Würfelortung gab ein Ergebnis mit einem Gütewert von 14919 zurück. Der Wert sagt, wie gut die gefundene Position zum Bild passt, bei einem sauberen Treffer liegt der nahe null. Zurückgegeben hat sie es trotzdem.
• Die Prüfung, ob der Arm die Platte berührt, hat mit der befohlenen Stellung gerechnet statt mit der echten.
• Die Lastprüfung lief in der falschen Schleife und hat damit nie geprüft was sie sollte.
• Die Kinematik antwortet außerhalb ihrer Reichweite, siehe oben.
• Und die Schnittstelle, über die eine Bewegung ausgelöst wird, hat ihr eigenes Ergebnis weggeworfen. Ein Gelenk, das sein Ziel verfehlt hat, ist deshalb nie aufgefallen.

Alle sechs werfen mittlerweile einen Fehler, statt einfach weiterzumachen. Was ich daraus mitgenommen habe: Eine fehlende Fehlermeldung ist teurer als ein Absturz. Beim Absturz weißt du, wo du suchen musst. Ein plausibler falscher Wert läuft dir durch die ganze Kette, bis der Arm irgendwo danebengreift. Und dann suchst du am Greifer, obwohl das Problem bei der Kamera sitzt.

Wo es steht

Der Sortierlauf ist im Kern durch. Erkennen, zuordnen, ablegen, in einem Rutsch für alle gefundenen Würfel. Zweimal fehlerfrei ist allerdings zweimal und nicht zwanzigmal. Wie er sich über viele Läufe schlägt, weiß ich schlicht noch nicht. Offen ist auch der Aufbau mit mehr als zwei Farben. Vier Zonen sind eingerichtet, belegt sind bisher zwei. Ob die Farberkennung mit Blau und Violett genauso stabil läuft wie mit Gelb und Cyan, muss sich zeigen. Die Kabel am Arm liegen farblich ziemlich ungünstig in genau dem Bereich.