FANUC Text-to-Trajectory Writing Robot

01

Einem Roboter das Schreiben beibringen, ohne jeden Punkt zu teachen

Ein kurzer Satz bedeutet Hunderte Roboterpositionen. Ich wollte sie nicht von Hand aufnehmen.

In den letzten zwei Wochen meines Praktikums stand in der Werkstatt ein FANUC 200iD/7L, der gerade für kein Kundenprojekt gebraucht wurde. Die Wochen davor hatte ich an Palettierzellen gearbeitet, wo der Roboter einen Sack von einer Stelle zur anderen bewegt. Ich wollte ein vollständiges System bauen, statt einzelne Befehle zu üben, also habe ich mich entschieden, den Roboter schreiben zu lassen.

Normalerweise fährt man den Roboter im Jog-Betrieb zu jedem Punkt und speichert die Position. Schon ein kurzer Satz braucht Hunderte Positionen. Sie von Hand einzulernen war deshalb nicht praktikabel. Ich wollte einen wiederholbaren Weg von dem Text, den ich tippe, zu einem Bewegungsprogramm, das die Steuerung ausführen kann.

Schreiben verzeiht außerdem weniger als Pick and Place. Die Stiftspitze muss über das ganze Blatt hinweg nahe an einer Ebene bleiben. Der Kontakt muss fest genug sein, um eine Linie zu hinterlassen, und leicht genug, um nichts zu verbiegen. Hunderte kleiner Bewegungen müssen in der richtigen Reihenfolge laufen. An jeder dieser Stellen zeigt sich ein Fehler im Koordinatensystem.

• Papier Passt auf A4 quer bei 297 × 210 mm, sonst schrumpft der Text, bis er passt
• Zeichen A-Z, a-z, 0-9, Satzzeichen und die türkischen Buchstaben ç ğ ı İ ö ş ü
• Sicherheit Keine Koordinate außerhalb des konfigurierten Arbeitsbereichs erreicht je den Roboter
• Arbeitsablauf Das erzeugte Programm muss sich über den üblichen FANUC-Workflow laden lassen
• Orientierung Kartesisches CONFIG und W/P/R stammen aus einem am realen Roboter geprüften Punkt, nicht aus einer Vermutung

02

Das Programm erzeugen, statt die Punkte zu teachen

Text geht hinein, ein Bewegungsprogramm kommt heraus, und eine SVG-Vorschau zeigt den Pfad, bevor der Roboter ihn fährt.

Der Generator ist eine einzige Python-Datei ohne Fremdbibliotheken. Das war Absicht: Er musste auf einem Werkstattlaptop laufen, ohne dass jemand etwas installiert.

Die Schrift ist der Teil, den niemand erwartet. Jedes Zeichen ist eine Liste von Polylinien in einer Einheitsbox. Es gibt keine Umrisse zum Füllen, denn der Stift zieht immer nur einen Strich. In dieser Box ist y = 0 die Versalhöhe, y = 1 die Grundlinie, und Unterlängen reichen bis 1.30. Eine Glyphe bildet direkt die Abschnitte ab, in denen der Stift aufliegt.

Die türkischen Zeichen werden zur Laufzeit zusammengesetzt. ç ist c plus Cedille, ğ ist g plus Breve, ü ist u plus Trema. Um eine Sprache hinzuzufügen, ergänze ich Akzentfunktionen, statt ein Alphabet neu zu zeichnen.

Drei Entscheidungen waren in diesem Ablauf besonders wichtig.

Die erste ist die automatische Anpassung. Passt der Text nicht auf das Papier, sucht der Generator die größte Buchstabenhöhe, die passt, und skaliert Zeichen- und Wortabstände im selben Verhältnis, damit die Proportionen stimmen. Er verkleinert den Text nur. Bei einer nötigen Höhe unter 3 mm bricht er ab, weil der Stift so kleine Buchstaben nicht mehr ausreichend genau zeichnen kann.

low = minimum_height_mm
high = original_height

# Binary search for the largest height that fits.
for _ in range(50):
  middle = (low + high) / 2.0
  candidate = scaled_config(middle)
  if fits_paper(layout_text(candidate), candidate):
      low = middle
  else:
      high = middle

return scaled_config(low * 0.999)

Die zweite ist die Terminierungsart an jedem Punkt. Sie entscheidet darüber, ob die Linie sauber aussieht.

Die Punkte, an denen der Stift aufsetzt und abhebt, werden als FINE ausgegeben. An diesen beiden Punkten muss die Spitze die vorgegebene Position exakt erreichen. Jeder Eckpunkt dazwischen ist CNT10, damit die Steuerung die Ecken verschleift, statt an jeder einzelnen anzuhalten. Mit FINE überall stottert der Roboter durch jedes Zeichen. Mit CNT10 überall rundet der Stift den Anfang jedes Strichs ab.

for point in points:
  termination = (
      "FINE"
      if point.motion_type in {"PEN_DOWN", "PEN_UP"}
      else "CNT10"
  )
  motion_instructions.append(
      f"L P[{point.number}] {point.speed_mm_sec}mm/sec "
      f"{termination} ;"
  )

Die dritte Entscheidung betrifft den Umgang mit Fehlern. Jeder Punkt wird gegen die konfigurierten Grenzen geprüft, bevor überhaupt eine Datei geschrieben wird. Eine Koordinate außerhalb des Arbeitsbereichs löst einen Fehler aus, statt stillschweigend begrenzt zu werden. Ein Programm, das sich nicht erzeugen lässt, kostet eine Minute. Ein Programm, das einen Punkt stillschweigend an den Papierrand schiebt, kann dagegen das beschädigen, was der Roboter trifft.

if not all(math.isfinite(value) for value in (x, y, z)):
  raise ValueError(f"Non-finite coordinate: {(x, y, z)}")
if not (config.min_x_mm <= x <= config.max_x_mm):
  raise ValueError(f"X out of bounds: {x:.3f} mm")

Aus demselben Grund sind der CONFIG-String und die Werkzeugorientierung Parameter mit einer Warnung im Docstring. Ich habe keine Werte fest in die Datei geschrieben. Sie müssen von einem geprüften Punkt an genau diesem Roboter kopiert werden, und ein Standardwert, der plausibel aussieht, wäre schlimmer als gar kein Standardwert.

03

Eine Feder im Greifer

Die Bahn stimmte, aber die Linie war trotzdem zu blass. Geholfen hat eine mechanische Änderung.

Das Koordinatensystem war der schwierige Teil der Software, und es hat länger gedauert als erwartet. Maßstab, Ursprung, Schreibebene und Strichreihenfolge müssen alle zusammenpassen, und wenn eines davon nicht stimmt, kommen die Zeichen verzerrt, gespiegelt oder in falscher Reihenfolge heraus. Sobald es stimmt, sieht man davon nichts mehr in der Ausgabe.

Dann habe ich es am Roboter laufen lassen. Der Pfad war richtig, und in RoboGuide war er es auch. Auf Papier war die Linie stellenweise blass und stellenweise gar nicht da.

Mein erster Impuls war, das Werkzeug weiter ins Papier zu drücken, die Schreibebene um einen Millimeter tiefer zu legen und es noch einmal zu versuchen. Das wäre der falsche Ansatz gewesen. Ein Roboter, der in eine starre Oberfläche kommandiert wird, fährt weiter, bis etwas nachgibt. Ich hätte riskiert, den Halter zu verbiegen und den Stift zu beschädigen, und jeder kleine Kalibrierfehler wäre gefährlicher geworden statt harmloser. Diese Fehler sind klein und unvermeidbar. Der Tool Center Point liegt um einen Bruchteil daneben, das Papier ist nicht perfekt eben, der Tisch nicht perfekt waagerecht. Ein TCP-Fehler betrifft jedes Zeichen auf der Seite.

Also habe ich den Greifer geändert und eine Feder hineingesetzt.

Mehr brauchte es nicht. Der Stift kann sich im Halter bewegen. Die Kontaktkraft wird deshalb hauptsächlich von der Feder bestimmt und hängt weniger davon ab, wie genau die Papierposition kalibriert ist. Kleine Höhenabweichungen führten vorher zu fehlenden Linien oder zu hoher Belastung. Jetzt gleicht die Feder sie aus.

Diese einfache Änderung ist mir in Erinnerung geblieben. Ich hatte versucht, das Kontaktproblem in der Software zu lösen. Die bessere Lösung lag aber in der Mechanik.

04

Er hat geschrieben

Derselbe Satz, einmal als SVG-Vorschau des Generators und einmal in Tinte.

Der Generator funktioniert. Für den Text Hazar Ekin Uçan erzeugt er 19 Striche und 127 Roboterpunkte und verkleinert die angeforderte Buchstabenhöhe von 30 mm auf 23.31 mm, damit die Zeile auf die Seite passt. Diese Werte habe ich beim Ausführen des Programms ermittelt.

Das Video unten zeigt den Roboter beim Schreiben. Ich zeige es ohne Ton, weil auf der Originalaufnahme nur Werkstattlärm zu hören ist.

In diesem Projekt habe ich fast alles angewendet, was ich in den Wochen davor gelernt hatte. Bedienung des Teach Pendant, Tool- und User-Frames, Register und Positionsregister, digitale E/A, Bewegungsarten und Geschwindigkeiten, Mastering, Kalibrierung und Alarmbehebung kamen alle zum Einsatz. Am Ende stand ein System, bei dem ich am Ergebnis sofort sehen konnte, ob es funktioniert.