Sortier-Roboter

Hier werden aktuell Informationen zum R-Zettel Sortier-Roboter eingestellt. Die Abbildungen folgen dann anschließend.

1. Video zum Roboterbetrieb

Hier zuallererst ein kleiner Eindruck, was der von Bernhard Peltner gebaute Roboter so kann.

Dazu einfach auf das Bikd rechts klicken.


Link zu externem YouTube Video
2. Wie kommt man denn auf so eine Idee?

Diese Frage wurde tatsächlich gestellt und ist berechtigt. Jeder R-Zettel-Sammler hat Spaß daran, neu erhaltene Zettel mit seiner Sammlung abzugleichen. Größere Mengen dazu allerdings zuvor zu sortieren macht im Gegensatz dazu gar keinen Spaß! Sind diese doch dazu mehrfach in die Hand zu nehmen: Sortieren zuerst nach Leitgebieten (1. Stelle der Postleitzahl) dann nach der 2. Stelle …. bis endlich auch die 4. Stelle sortiert ist, ist jedem von uns sicher schon einmal die Lust vergangen. Also: Das muss doch einen Computer zusammen mit einer Maschine machen können!

So ging mir dies einige Jahre durch den Kopf bis mein Sohn seiner Tochter einen „Magic Mirror“ baute, also einem hinter einem Spiegel befindlichen Monitor, der sich per Bewegungssensor einschaltet, aus dem Internet die Informationen zu Datum, Uhrzeit, Wetter und Abfahrtzeiten der S-Bahn und BOB (Bayerische Oberland Bahn) anzeigt, nicht zu vergessen mit einem Spruch des Tages wie „you are looking very sexy today“ aufzuwarten.
Dies erfolgt über den etwa Scheckkarten großen „Raspberry PI3 B+“-Rechner (Preis unter € 50) der „alles“ kann und zudem ein echter Prozessrechner ist, also externe Signale verarbeiten und auch externe Komponenten steuern kann. Ah ha dachte ich mir: Das könnte es sein. Hatte zuvor noch nie davon gehört.
Also kaufte ich mir im August 2017 einen solchen Rechner samt kleinem 7 Zoll Bildschirm, Tastatur und Maus lagen noch herum und los ging es mit einem netten kleinen 1.100 Seiten Handbuch, bald kam noch ein zweiter 1.000 Seiten Wälzer zur Programmiersprache (Python 3 – natürlich war diese neu zu erlernen) hinzu. Auf der längeren Bahnfahrt von München nach Flensburg und zurück zum Besuch anlässlich des 70. Geburtstags meines Studienfreundes Gerd begann das Lernen.

3. Erster Test zur Texterkennung

Zuerst interessierte ich mich für Texterkennung. Schließlich sollte der Roboter ja lesen können und wissen, was er zu tun hat. So erfuhr ich, dass es für Python eine große Menge von „open source“, also frei verfügbare Programme (Module) gibt. Darunter auch „Tesseract“, einer guten OCR (Optical Character Recognition) Software. Kurz ausprobiert und siehe da, das klappt. Diese Hürde war also genommen.

4. Erster Test zum Unterdruckheber

Anschließend kam der Test für das geplante Unterdrucksystem. Weil zur Größe eines R-Zettels passend nahm ich also einen 4×2-er LEGO®-Stein. Ich schliff die Noppen ab und bohrte 8 Löcher (Ø 1 mm) hinein, dann wurde noch ein Plastikschlauch per Heißsiegelkleber angebracht. Auf die Unterseite kam noch ein Moosgummi, natürlich auch mit 8 Löchern, und fertig war mein Prototyp. Und siehe da, es klappte auf Anhieb: Ich konnte R-Zettel gut ansaugen und ablegen. So wird es klappen.


Test Unterdruckheber
5. Linearantriebe: CONUCON

Jetzt suchte ich nach einem CNC (Computerized Numerical Control) XYZ-Linearantrieb. Fündig würde ich bei der Firma CONUCON in Bad Oldesloe. Nach Überlegungen zur Größe und gutem Informationsaustausch zu meinen Anforderungen bestellte ich im September eine Sonderanfertigung mit 1 x 2 x 0,2 Meter Fahrweg. Diese wurde sehr schnell geliefert und so besaß ich einen kompletten XYZ-Linearantrieb mit eigenem Arduino-Rechner, Controllern für die Schrittmotoren samt Windows-Firmware und Benutzeranleitung. Die bestellte Größe schätze ich, da ich ja einen „1.000er“ Setzkasten mit einer Netto-Fachtiefe von 10 cm befüllen wollte.

6. Schrittmotor mit Hinderniserkennung: Mechaduino

Zur Z-Achse (also der vertikalen Bewegung) empfahl und lieferten mir CONUCON einen Mechaduino-Schrittmotor (von Tropical Labs aus Washington D.C., USA) samt eigenem Arduino Rechner plus Software zur Ansteuerung. Diese Kombination kann Unglaubliches: Die Bewegung erfolgt so lange, bis ein Hindernis entdeckt wird. Selbst ein rohes Ei zwischen den Backen eines großen Schraubstocks wird dabei nicht zerbrochen! Genau das was ich brauchte, ebenfalls ohne vorher zu wissen, dass es so etwas überhaupt gibt.

7. Bau des Robotertisches und des Hochregallagers

Als erstes startete ich mit dem Bau des „Tisches“ für den CNC-Antrieb, das Steuerpult zum Einbau der Stromversorgungen, der Steuerungs-Controller für die CNC-Antriebe und natürlich für den Raspberry. Ein Mauervorsprung im Hobbykeller definierte das Gesamtmaß: 1,45 x 2,11 Meter. Darüber entstand mein „Hochregal-Paletten-Lager“. Schließlich würde ich ja Platz für 8 Stück der 1.000-er Setzkästen benötigen. Auch wurden 8 regelbare Spannungsversorgungen gebaut. Am 23.1.2018 sah der Aufbau samt der professionellen Schleppketten für die Kabelführungen dann bereits so aus:


Bauzustand im Januar 2018
8. Bildschirm

Als Bildschirm – der 7“ Bildschirm war mir dann doch „etwas“ zu winzig – kommt ein fast noch neuer, aber nicht mehr für das digitale Zeitalter brauchbarer, 30“ Fernseh-Bildschirm zum Einsatz. Dieser wurde hochkant auf einem Schwenkarm installiert und per HDMI-Kabel am Raspberry angeschlossen. Selbstredend ist es für den Raspberry ein Kinderspiel, die Ausgabe um 90 Grad zu drehen.

9. Benutzeroberfläche: GUI

Irgendwie war mir recht schnell klar, dass ich für die Entwicklung der Steuerungssoftware und dann den späteren Betrieb eine ordentliche Benutzeroberfläche brauchen würde. Das würde vieles leichter machen. Etwas leichter gesagt als getan, denn komplexere Beispiele dazu sind rar. So half mir auch hier das Internet – ohne Suchmaschinen wäre meine Gesamtaufgabe sicher unmöglich zu lösen gewesen. Ich fand schließlich mit „tkinter ttk“ ein echt starkes Werkzeug zur Programmierung einer „professionellen“, Windows-ähnlichen GUI (Graphical User Interface).


Startbildschirm mit Funktionen zur Datensicherung (1.000 x 480 Pixel)

Es brauchte doch etliche Monate bis ich meine Benutzeroberfläche mit 7 Arbeitsblättern gebastelt hatte.
Eine Anmerkung zur Datensicherung: In dieser Oberfläche kann ich eine Komplettdatensicherung aller Programme und Steuerungsdaten auf einen USB-Stick, der permanent verbaut ist, vornehmen. Diese übertrage ich dann von Zeit zu Zeit zusätzlich auf meinen Entwicklungsrechner. Das Betriebssystem und alle Daten des Raspberry‘s werden über eine Spiegelung der Micro-SD-Karte, auf dem sich dieses alles befindet, auf eine zweite Karte gesichert. Das erfolgt mittels eines Windows-PC’s.

10. Namensgebung: RZ-D6

Jetzt sollte kurz ich auf die Bezeichnung „RZ-D6“ meines Roboters eingehen. Wer erinnert sich nicht an „R2-D2“, den witzigen Roboter aus StarWars®, dem „Paten“ für meinen Roboter? „RZ“ steht natürlich für R-Zettel. „D6“ steht für die 6 Dimensionen seines „Könnens“:

    1. X-Achsen-Bewegung
    2. Y-Achsen-Bewegung
    3. Z-Achsen-Bewegung
    4. Unterdruck-Transport der Zettel
    5. Drehen für „Kopfsteher“
    6. Wenden bei „Rückenlage“

Das wäre damit auch erklärt. In diesem Bild entdeckt Ihr auch, dass es ein Produktiv- und ein Entwicklungssystem gibt. Das Entwicklungssytem ist auf meinem Windows-Laptop, dort habe ich mir sowohl eine Python- als auch eine Arduino-Entwicklungsumgebung geschaffen. So kann ich auch an einem schattigen Plätzchen unter Bäumen im Garten „mal programmieren“. Meine Programme sind dabei so geschrieben, dass sie erkennen, in welcher Umgebung (Linux oder Windows) sie laufen. So werden beim Testen alle Linux- und Raspberry spezifischen Programmteile übersprungen: Der Windows-Rechner schafft es ja z.B. kaum, Input-/Output-Kanäle anzusprechen, die er nicht hat.

11. Die drei Rechner: 1 Raspberry und 2 Arduinos

Raspberry PI 3B+

Arduino Nano

Arduino Zero

Wie schon angedeutet gibt es den Raspberry als (Haupt-) Steuerungsrechner. Dieser (wie auch die beiden Arduinos) sind Linux-Rechner. Neuland für mich, da gab es natürlich wieder viel zu lernen. Apropos „Arduino“: Arduino ist eine aus Soft- und Hardware bestehende „Physical-Computing-Platform“. Die Hardware besteht aus einem einfachen E/A-Board mit einem Mikrocontroller und analogen und digitalen Ein- und Ausgängen.
Der CONUCON-Linearantrieb für X- und Y-Achse werden über einen „Arduino Nano“ gesteuert. CONUCON liefert dazu eine Windows-Firmware. Mit dieser Benutzeroberfläche lässt sich dieser Arduino, über ein USB-Kabel angeschlossen, gut steuern.
Der Mechaduino für den Linearantrieb der Z-Achse ist ein „Ardiuno Zero“. Die mitgelieferte Arduino-Software (ähnlich C++, also wieder eine neue Programmiersprache zum erlernen) wird standardmäßig ebenfalls über einen Windows-Rechner und eine frei verfügbare Arduino IDE (Integrated Development Environment = Entwicklungsumgebung) betrieben. Auch das klappt schnell.
Alle 3 RZ-D6 Rechner sind über einen USB-HUB (Schalt-Verteiler) miteinander verbunden. Dieser dient zum Umschalten zwischen dem externen Windows-Rechner (für Entwicklung und Test) und dem Raspberry.
Ab hier nenne ich jetzt den Raspberry „RPI“, den CONUCON „CON“ und den Mechaduino „MEC“.

12. Serielle Schnittstelle zwischen den Rechnern

Werden CON und MEC über den Windows-Rechner betrieben, ist dies relativ einfach und gelingt schnell. Bei mir sollte dies jedoch der RPI übernehmen, damit daraus ein selbständig agierender Roboter wird. Das gestaltete sich als „nicht ganz trivial“ und dauerte viele Monate.
Zuerst musste ich lernen, wie zwei Rechner – über USB-Kabel verbunden – miteinander kommunizieren. Es gibt dazu zwar Beispiele, aber keine fertigen Programme (Module). Der Universal Serial Bus (USB) ist ein serielles Bussystem, mit dem alle Rechner verbunden sind und „miteinander quatschen“. So musste ich in den sauren Apfel beißen und mir eine dynamische Standardschnittstelle (also für mehrere Rechner nutzbar) programmieren. Jetzt zeigte sich bereits der Vorteil meiner Benutzeroberfläche, über die ich dies alles testen konnte. Es entstand mein „Serieller Monitor“:


Serieller Monitor

Auch der große Bildschirm erwies sich jetzt als Vorteil. So dient der obere (größere) Teil als Protokollmonitor, im unteren Teil wird meine GUI (Benutzeroberfläche) angezeigt.

13. Babylonisches Sprachgewirr

Einen funktionierenden Seriellen Monitor zu haben ist das eine. Welcher Rechner allerdings welche Sprache versteht steht auf einem anderen Blatt. So musste ich diese erst einmal alle lernen um zu verstehen, was da abläuft.
Das Betriebssystem des RPI ist „Raspbian“. Will man Ihm einen Auftrag geben, muss man des „LX-Terminal“ öffnen und ein LINUX-Kommando eingeben. Um z.B. Tesseract zu installieren lautet dies: „sudo apt-get install tesseract-ocr“, also eine recht kryptische Sprache.
Um für den RPI Programme zu schreiben öffnet man eine „Entwicklungsumgebung“ und nutzt die Programmiersprache „Python 3“. Diese ist gut zu erlernen: „if A == B : tu dies else: oder das“, das ist schon verständlicher.
Will man dem CON einen Fahrbefehl mitteilen, verwendet man „G-Codes“, eine übliche Sprache für CAM (Computer Aided Manufacturing), schließlich ist ein CNC (Computerized Numerical Control) -Linearantrieb eine solche „CAM-Maschine“. So lautet ein Fahrbefehl recht einfach z.B. „G0X12Y100“: fahre also 12 mm in X- und 100 mm in Y-Richtung. Soweit so gut. Der CON kennt aber auch CONUCON-spezifische Befehle, so bewirkt z.B. „$H“ die Ausführung einer Referenzfahrt. Also wieder zwei Sprachwelten. Die dritte Sprachwelt des CON sind seine Antworten (die kommen von der CONUCON-Firmware, die auf dem Arduino installiert ist. So antwortet der CON mit vielen Zeilen an Informationen, darunter auch ein : „>: wpos=12.000,100.000,0.000“, sprich: ich bin an dieser Position angekommen. Wenn man dann noch herausgetüftelt hat – über ein “abhorchen“ der USB-Anschlüsse, dass der CON über die serielle Schnittstelle mit „ttyUSB0“ angesprochen werden will, klappt die Kommunikation.
Will man dagegen den MEC ansprechen, er hört auf den Namen „ttyACM0“, muss man natürlich auch seine Sprache – die Ihm Tropical Laps beigebracht hat – verwenden. So lautet ein einfacher Fahrbefehl z.B. „r0, x, y, r360“: definiere die aktuelle Position als „0“, x=nutze des Positionierungs-Modus, y=schalte den Encoder ein, r360=führe eine 360° Umdrehung aus. Die Programme des MEC sind in Arduino/C++ geschrieben und können verändert werden. So brachte ich ihm etliche eigene, RZ-D6 spezifische Befehle bei. So z.B. für seine Fahrt in die HOME-Endposition: „u“. Das geschriebene Programm von mir dazu beschleunigt den MEC, fährt schnell, bremst und tastet sich langsam bis zum Endschalter vor. Natürlich hat der MEC dazu ebenfalls einige Input-/Output-Pins. Auch konnte ich programmieren, wie denn bitte seine Antwort an den RPI lauten soll, wenn er fertig ist, z.B. „Zpos = 360.00“: ich stehe bei 360,00°. Wie ihr seht, er will in Grad und nicht in Millimeter kommunizieren.
Damit ich die Serielle Kommunikation zwischen den Rechnern programmieren konnte, musste ich zu den Programmierern des CON und MEC Kontakt aufnehmen und erfahren, was deren Arduinos so „erwarten“. Die Unterstützung war unkompliziert, schnell und gut. An dieser Stelle also mein Dank an Andy von CONUCON und an Joe von Tropical Labs.Nun brauchte ich dem RPI nur noch diese Sprachen beibringen, schließlich muss er diese Fahrbefehle ja nach Aufgabenstellung selbst generieren. Und natürlich musste ich ihm auch das Verstehen der Antworten beibringen damit er weiß, ob alles geklappt hat – oder auch nicht.
Und „schon“ klappte die Kommunikation zwischen den 3 Rechnern. Dass ich dafür doch „eine längere“ Zeit benötigte dürfte jetzt jedem klar geworden sein.

14. Parameter-Dateien und CNC-Koordinaten

Damit der RZ-D6 seine Aufgaben erledigen kann, benötigt dieser doch recht viele Informationen, die über 14 Parametertabellen definiert werden:


Externe Parameter und CNC-Koordinaten

Euch ist klar, dass er natürlich wissen muss, wie weit er sich in allen Dimensionen bewegen darf und wo sich die 1.000 Setzkasten, die 60 Servicefächer sowie die Servicepositionen (z.B. Kamera, Servos) befinden. Über meine GUI und extern bereitgestellten Dateien (berechnet mit EXCEL auf meinem Windows-Laptop) können so all diese Daten verändert bzw. direkt gepflegt werden. So wurde das Entwickeln und Testen – wie beabsichtigt – sehr vereinfacht.

15. Kamera-Modul und Bildbearbeitung

Eine essentiell wichtige Aufgabe für den RPI ist, dass er sich den R-Zettel anschauen und diesen lesen kann. Es gibt eine schöne kleine PI-Kamera, diese ist über ein Flachbandkabel direkt mit dem RPI verbunden. Da diese Kamera natürlich kein Makro-Objektiv besitzt, baute ich mir aus einem alten Fernglas eine entsprechende Optik mit regelbarer indirekter Beleuchtung und Glasdeckel zur Ablage des R-Zettels durch den RZ-D6.
Ein Arbeitsblatt meiner GUI dient der Eingabe und Veränderung der Parameter dazu:


Kalibrieren der Bildausschnitte und Servofahrwege

Auch die Servo-Fahrwege für die 3 Servos zum Drehen und Wenden der Zettel können hier eingestellt werden.
Die gesamte Service-Station sieht damit so aus:


Servicemodul: Wenden – Drehen – Bildaufnahme – Abstreifen

Auf der rechten Seite ist eine Reihe von feinen Pinseln erkennbar. Dieser Teil meiner Service-Station übernimmt die Funktion des „Abstreifens“ eines ggf. an der Perforation hängenden zweiten R-Zettels und liegt auf dem CON-Fahrweg zwischen den Vorratsfächern und der Kamera. Diese Situation kennen wir auch von der manuellen Sortierarbeit – und diese Aufgabe wurde von RZ-D6 auch schon mehrfach brav erledigt.

16. Input-Output Kanäle eines Prozessrechners

Der RPI wird durch seine 24 (!) nutzbaren Input-Output-Kanäle zum Prozessrechner. Mit diesen GPIO-Kanälen (General Purpose Input Output) können externe Funktionen gesteuert werden (z.B. die Servos oder Magnetventile) oder externe Signale (z.B. von Endschaltern oder Drucksensoren) verarbeitet werden. Der RZ-D6 nutzt derzeit 23 dieser Kanäle, davon 7 als Outputkanäle. Alle Input-Kanäle werden kontinuierlich überwacht und erlauben oder verhindern die Aktivitäten des RZ-D6, besonders die vom MEC und CON.
In der Abbildung rechts dazu das LED-Anzeigemodul, das den komprimierten Überblick zum Hardwarestatus ermöglicht.


GPIO-Anzeigemodul

Input-Output Kanäle des Raspberry’s

In der Benutzeroberfläche des RZ-D6 werden parallel dazu die vom RPI über die I/O-Kanäle erfassten Hardware-Signale angezeigt. Es ist also erkennbar, ob der RPI auch „alles“ richtig verstanden hat.
Jetzt ist es an der Zeit etwas zu den „roten Feldern“ auf der Benutzeroberfläche zu sagen. Dabei handelt es sich um insgesamt 27 verschiedene Ampeln. Diese kennen natürlich den üblichen Status rot-gelb-grün, beim RZ-D6 zusätzlich mit einem Schlagwort zur Erklärung. Diese Ampeln sind nach Betriebsstart (dazu später) in der Regel grün und zeigen so sehr plakativ den Status der GPIO-Kanäle und weiterer Funktionen an. So sehe ich sofort, wenn etwas nicht passt.

17. Setzkasten

Die R-Zettel werden ja in einem (bzw. acht) 1.000er-Setzkasten „versenkt“. Dieser ist (mit den Servicebereichen) 1.860 x 770 mm groß. Die Fachtiefe beträgt 100 mm, also Platz für viele hunderte von R-Zetteln je Fach. Als Baumaterial stand aus Kostengründen recht schnell 2,5 mm dicke Wellpappe fest. So holte ich im September 2017 auf einer gemeinsamen schönen Fahrt mit meiner Frau ins herbstliche Lenggries bei der „Bayerischen Wellpappe“ 200 m² von diesem Material, für mich dort schon auf noch handhabbare 1 x 2 Meter Stücke zerkleinert. Es dauerte allerdings bis zum Dezember 2019, bevor ich mich an den Bau wagte.

Der Grund dazu war (zumindest für mich eindeutig): Erst musste der RZ-D6 alles können und seine maximalen Fahrwege klar sein. So ergab sich der oben genannte nutzbare Arbeitsbereich. Der Setzkasten besteht aus 40 Spalten und 27 Zeilen (25 davon für den „1.000er-Bereich). Die Größe der Fächer lässt dem (normal großen) R-Zettel ringsherum ca. 2 mm Platz. Da alle geplanten über 8.000 Fächer die absolut gleiche Größe haben müssen – sonst käme der RZ-D6 damit nicht zurecht – war Präzision angesagt. EXCEL rechnete mir schnell vor, dass ich mit Reserven gut 12.000 Teile benötigen würde:


Vorrat der Zwischenstege für den Setzkasten
18. Schneidetisch

Also baute ich mir im Oktober 2019 einen großen Schneidetisch mit gut einem Meter nutzbarem Scheideweg.


Schneidetisch für den Setzkasten

Als Scheidewerkzeug diente ein Skalpell, für das ein justierbarer „Messerblock“ gebaut wurde. So war es möglich, die 4 verschiedenen benötigten Teile auf jeweils 0,1 mm Genauigkeit herzustellen. Zur Sicherheit wurden alle (!) Schnitte und Teile einer Sorte mit einer festen Schneidetischeinstellung hergestellt. Jetzt weiß ich, dass ein Skalpell zwischen 130-250 Meter Wellkarton scheiden kann, bevor es stumpf wird. Diese Scheideaktion dauerte Dank des hergestellten Schneidetisches nur wenige Wochen.

19. Klebevorrichtung für die Setzkastenelemente

Versuche hatten mir gezeigt, dass sich die Wellpappe mit verdünntem, wasserfestem Ponal sehr gut und schnell zusammenkleben lässt. Zur Sicherstellung einer +/- 0,1 mm Toleranz für über 800 herzustellenden „10er-Kästen“ baute ich mir eine „etwas komplexere“ Klebevorrichtung:


Klebevorrichtung für die Setzkastenelemente

In diese Vorrichtung werden die mit Ponal versehenen 14 Einzelteile eingelegt, von „Schiebern“ und Spiralfedern gehalten und so in genauer Position fixiert. Bereits nach einer Minute kann der 10er-Kasten entnommen und mit dem nächsten begonnen werden. Der „menschliche Kleberoboter“ benötigt allerdings nach 10-12 Kästen eine Konzentrationspause. Der erste 1.000er – Kasten war so in knapp einer Woche hergestellt.

Recht schnell waren dann diese 100 Stück 10er-Kästen mit entsprechenden Paletten und herausnehmbaren Distanzstreifen aus MDF (mitteldichte Holzfaserplatte) als Setzkasten in den Roboter-Tisch eingebaut und fixiert.

Mit dem Ergebnis war ich zufrieden. Das Gesamtmaß wurde bei den 40 nebeneinander liegenden Fächern auf knapp 2 mm eingehalten. EXCEL durfte dann diese endgültigen Maße verwenden und die X-/Y-Positionen neu berechnen. So machen dann die Parametertabellen Sinn.

Alles passt perfekt, nichts kann sich bewegen und der RZ-D6 „trifft“ diese Fächer präzise.

Die 10er-Kästen sind übrigens so aufgebaut, dass Vorder- und Rückseite zusammen eine Trennwand ergeben. So können die R-Zettel anschließend sehr einfach entnommen werden:


Setzkastenelemente
20. Das Unterdrucksystem

Über den ersten Prototyp eines Hebers für den R-Zettel-Transport hatte ich ja bereits berichtet. So begann die Entwicklung dieses Systems mit Unterdruckpumpe, Drucksensoren und Magnetventilen samt eigens entwickelter Steuerungselekronik. Der Heber wurde anfangs optimiert um eine möglichst starke Haltekraft durch den Unterdruck zu erreichen. Das war nicht so gut, denn dann wurden schnell 2-3 R-Zettel gleichzeitig angehoben. Dünnes Papier ist anscheinend doch recht „löchrig“! Also wieder runter mit dem Druck. Der Heber bekam noch ein Federelement zur automatischen rechtwinkeligen X-Y-Anpassung an die Unterlage (den R-Zettel Stapel bzw. Kamera oder Servos).
Auch wurde eine Diode und ein Fotosensor in die Heber-Unterseite integriert um prüfen zu können, ob im Vorratsfach noch Zettel liegen oder der schwarze Fachboden erreicht ist und das nächste Vorratsfach angefahren werden muss.
Rechts die Abbildung des Heberkopfes nach der Optimierung. Der Kopf ist an dem blauen Legostein trennbar! Durch den Fotosensor wird auch erkannt, ob beim Transport der R-Zettel noch vorhanden ist bzw. nach dem „Abwerfen“ dieser auch wirklich abgeworfen wurde.

“ “

Aufbau des Heberkopfes

Das System hatte anfangs noch ein weiteres Problem: „Zu dicht“. Nach Abschalten des Unterdruckes blieb der Zettel hängen. Zuerst wurde über ein zweites Magnetventil also wieder Umgebungsdruck zugeführt. Das half, aber nicht immer. Auch trat bei den ersten Dauerversuchen eine statische Aufladung des Heberkopfes auf: Der R-Zettel blieb kleben. So wurde der Heberkopf aus einer kupfer-beschichteten Leiterplatte gefertigt und ein Mini-Kompressor angebracht. Dieser erzeugt anstelle des Umgebungsdruckes einen kurzen Luftstoß. Dazu musste natürlich noch eine Elektronik entworfen und gebaut werden, die dies mit einstellbarer Verzögerungs- und Blasdauer steuert. Jetzt klappt das Abwerfen perfekt. Die Schwerkraft alleine reicht nicht.


Unterdrucksystem mit LED-Anzeigeeinheit,den Steuereinheiten für die
Magnetventile,dem Drucksensor sowiedem Luftstoßgenerator samt Zeitmodul
21. Laserpointer

Insgesamt wurden 6 Laserdioden verbaut um die genaue Position des Hebers erkennen zu können. Zwei sind auf den Rand des Setzkasten ausgerichtet und zeigen mir Spalte und Zeile an. Auf den Wänden wurden dazu einfach entsprechende Papierlineale per PC-Drucker angebracht. Vier Laserdioden sind senkrecht nach unten auf die Schnittpunkte der Setzkastenfächer ausgerichtet. So kann die genaue Positionierung des Setzkastens justiert und während des Betriebes die genaue Positionierung des Hebers ständig überprüft werden.


Laserpointer und Heber im Überblick
22. Heber

Ein weiterer Dreh- und Angelpunkt des Roboters ist der Heber. Er ist an der Z-Achse des RZ-D6 montiert und wird komplett vom MCE vertikal bewegt, nachdem ihn der CON in die richtige Position gefahren hat.
Vor einem Absenken prüft natürlich der RPI, ob die angefahrene Position auch eine „gültige“ Setzkasten- oder Serviceposition ist. Der MEC würde zwar beim Auftreffen auf ein Hindernis stoppen, dies sollte aber immer ausgeschlossen sein.
Hier sieht man auch die Laserpointer an den Ecken des Setzkastenfaches und im Hintergrund an der Y-Achse.

23. Zwangskühlung und Temperaturüberwachung

Es ist ja ein Dauerbetrieb geplant. So befinden sich 4 Temperatur-Messfühler an „kritischen“ Punkten, die Anzeigen dazu sind ebenfalls im Steuerpult untergebracht. Die gesamte Elektronik im Steuerpult sowie die Unterdruckpumpe sind jeweils per 12 V Lüfter zwangsgekühlt. Somit kann sich kein Wärmestau bilden. Bisher bleiben alle Komponenten unter 30° C.

24. Protokolle und Dokumentationen

Den Protokollmonitor hatte ich ja schon erwähnt. Gerade während der Entwicklungszeit will ich natürlich mitlesen können, was die Programme so „anstellen“. So sind alle Status- und Fehlermeldungen über das anschließend gezeigte GUI-Arbeitsblatt ein- und ausschaltbar. So kann am Protokollmonitor einerseits extrem detailliert berichtet werden – oder auch für „Ruhe“ gesorgt werden. Einige Protokolle werden allerdings auch während des Betriebes abgespeichert (natürlich auch ein-/ausschaltbar) und können später dann eingesehen werden.


Protokolldetaillierung und Dokumentationen

Hier habe ich auch alle Dokumentationen der Komponentenhersteller und meiner Programme hinterlegt und kann mir diese anzeigen lassen.

25. Ablaufsteuerung

Ein weiteres Kernstück des RZ-D6-Roboters ist seine Sortierroutine. Das ist eine in einem parallelen Prozess im Hintergrund laufende Endlosschleife aus 57 Funktionen. Diese arbeitet die verschiedenen Sortieraufgaben ab und ermittelt, was jeweils zu tun ist. So steuert diese also die optionalen Servofunktionen zum Drehen oder Wenden des R-Zettels und ermittelt, wohin der R-Zettel abgelegt oder welches Vorratsfach angefahren werden muss. Im Vorrat können ja auch R-Zettel aus fremden Leitgebieten liegen oder es kommen R-Zettel mit nicht lesbarem Text bei sehr schlechtem Druck des R-Zettels vor.


Sortier-Monitor

Diesen Bildschirm kennt Ihr ja bereits aus dem Video. Hier wird die Sortieraufgabe festgelegt. Der RZ-D6 kann ja nicht nur ein Leitgebiet nach Postleitzahlen sortieren. Auch kann er unsortierte Zettel zuerst nach Leitgebieten sortieren. Nachdem die 8 Hauptstädte Berlin bis München doch eine Menge von Postämtern besitzen, habe ich EXCEL auch eine Parametertabelle für die 972 Postämter dieser Städte berechnen lassen. So weiß der Roboter dann auch, wohin er diese einsortieren soll.
Der Sortier-Monitor zeigt zudem auch laufend die Ergebnisse der Bildbearbeitung, Texterkennung und Textanalyse an. Selbstverständlich zeigt er mir auch, an welcher der 57 Funktionen er gerade arbeitet. Dieser Sortierprozess kann auch durch Bildschirmeingabe angehalten und fortgeführt werden. Ein sofortiger Abbruch ist natürlich möglich. Teile ich dem RZ-D6 „Beenden“ mit, arbeitet er die Funktionen für den aktuellen R-Zettel ab und fährt dann in seine „HOME-Position“. Der Entwurf für diese Routine entstand übrigens im Januar 2019 auf einer Mittelamerikakreuzfahrt von Los Angeles durch den Panama-Kanal nach Miami. Auf so einer langen Kreuzfahrt hat „man“ ja doch viel Muße.
Die Sortierroutine ist somit das Herzstück des RZ-D6. Wesentliches Element dabei ist, dass vor jeder auszuführenden Funktion zu prüfen ist, ob diese auch „erlaubt“ ist, also alle Voraussetzungen gegeben sind und auch physisch nichts im Wege steht. Stellt Euch vor, der Heber ist gerade tief in einem Setzkastenfach und die Ablaufsteuerung würde dem CON sagen „beweg dich mal“. Also wird alles Erdenkliche vor Auslösung einer der 57 Funktionen geprüft. Anschließen muss natürlich analysiert werden, ob die Aufgabe auch wie geplant erfolgreich abgearbeitet wurde und entschieden werden, was als nächstes zu tun ist.

Damit wird der RZ-D6 zum Roboter!

26. Prozessebenen

Ein Rechner wird auch dadurch zu einem echten Prozessrechner, wenn er mehrere Aufgaben gleichzeitig bearbeiten kann. Das musste ich auch dem RZ-D6 beibringen. Neben der Benutzeroberfläche, die ja immer bereit für Eingaben sein muss, läuft parallel ein Prozess, der ständig die Input-Kanäle überwacht. Schließlich müssen diese Signale ja ggf. auch zu direkten Aktionen der Ablaufsteuerung führen. Ein weiterer Prozess ist für die Aktualisierung der Informationen der Benutzeroberfläche aus „tieferen“ Programmebenen zuständig. Dies würde normalerweise erst erfolgen, wenn das entsprechende Programm abgearbeitet ist. Ich möchte allerdings, dass ich die Arbeitsergebnisse wie z.B. die Bildausschnitte oder die Ergebnisse aus Texterkennung und -Analyse sofort angezeigt bekommen. Auch sollen meine schönen Ampeln sofort anzeigen, wenn sich ein Status verändert hat. So übernimmt dieser Prozess, dass diese Informationen „sofort“ an die Benutzeroberfläche gemeldet werden und diese aktualisiert wird. Zu guter Letzt läuft die Sortierroutine in einem eigenen Prozess. Jede dazu definierte Information wird von diesem Prozess an die Benutzeroberfläche gemeldet damit ich sehe, woran der RZ-D6 gerade arbeitet. Zudem kann ich so parallel in der Benutzeroberfläche arbeiten. Wie Ihr Euch denken könnt musste ich mir auch erarbeiten, wie diese Parallelität der verschiedenen Prozesse und deren gegenseitiger Informationsaustausch zu programmieren ist.
Nun noch einige Kernstücke zur Verarbeitung des über das Kamera-Modul aufgenommenen Fotos vom R-Zettel.

27. Bildbearbeitung

Im Arbeitsblatt „Kalibrieren“ und „Sortieren“ sind ja verschiedene Bildausschnitte zu sehen. Dazu müssen zuerst einmal aus dem Kamerabild entsprechend Ausschnitte erzeugt werden. Spannend wird es, wenn man den Bildausschnitt des „R“ dahingehend analysiert, in welcher Lage (Kopfsteher oder Rückenlage) sich der R-Zettel befindet. Das erfolgt über eine Farbanalyse. Ist der überwiegende Farbanteil „rot“: der R-Zettel liegt in Normallage, ist nur „weiß“ vorhanden: der R-Zettel befindet sich in Rückenlage. So gut so schön. Jeder von uns Sammlern kennt allerdings die zahlreichen Rottöne und Papierfarben. So war die zuerst programmierte Auswertung sehr fehleranfällig, es musste was Besseres her. Ich beschäftigte mich mit den „RGB“ (rot-grün-blau) Farbtönen eines Digitalbildes und fand nach einigem Suchen heraus, wie man diese verändern kann. Nun hat das Kamerabild (bereits nach einer Verkleinerung) immer noch 100.000 Pixel, mit je drei Farben sind das also 300.000 Farbinformationen. So installierte ich mir ein Modul des „mathematischen Python“ zur Matrixmanipulation, nur so kann in vertretbarer Rechenzeit die erforderliche Bildbereinigung erfolgen. Alle Rottöne werden in „reines rot“ (RGB 255,0,0) umgewandelt. Ebenso werden die Farben schwarz (RGB 0,0,0) und weiß (RGB 255,255,255) bereinigt. Das Ergebnis ist ein wirklich „sauberes“ Bild das gut weiterverwendet werden kann:


Kamera-Aufnahme

Aufbereitetes Bild

Jetzt klappt auch die Farbanalyse zur Lageerkennung zu 100%. Beim Bildausschnitt des Textbereiches werden noch zusätzlich alle roten Pixel in weiße Pixel umgewandelt, da hat es die Texterkennung doch viel leichter. Die Texterkennung mag aber auch schlecht horizontal ausgerichtet Texte weniger. Zum Glück hat ja jeder R-Zettel einen „Horizont“: Die waagerechte Trennlinie zwischen Numerator und Ortseindruck. So schrieb ich mir ein Programm diese Linie „zu erkennen“, erinnerte mich an Geometrie und berechnete so den Winkel für eine waagerechte Ausrichtung des Textausschnittes. Jetzt klappt die Texterkennung noch besser.

28. Texterkennung und Textaufbereitung

Ich war bei der Texterkennung des 1. Münchner R-Zettels überrascht: „Miinchen“ wurde erkannt. Wie konnte ich (als Münchner) übersehen, dass es auch Umlaute gibt. Ich hatte der Texterkennung vergessen den deutschen Zeichensatz mitzugeben. Also wieder Suche im Internet: Deutschen Zeichensatz finden und lernen, wie dieser dem Tesseract-Modul mitgegeben werden kann. Und siehe da, es klappte. Vor Weitergabe an die Textanalyse werden alle erkannten Zeichen noch um all diejenigen bereinigt, die nicht auf einem R-Zettel vorkommen können: Alle Sonderzeichen („€[email protected]§%&?“ usw.) werden entfernt.

29. Textanalyse

Primäre Aufgabe dabei ist natürlich, den Text in Postleitzahl, Ortseindruck und wenn vorhanden das Postamt zu zerlegen. Alle nicht 4-stelligen Postleitzahlen mussten natürlich zu vierstelligen mit entsprechenden „Nullen“ aufgefüllt werden.
Nun kennt jeder die sehr unterschiedliche Qualität gerade der frühen im Zeilensetzverfahren hergestellten und schlecht gedruckten R-Zettel. Da kommt jede Texterkennung an Ihre Grenzen.
So laß ich etwas über „eigene Wörterbücher“, die man sich für Texterkennungsprogramme anlegen kann.

30. Abgleich mit dem R-Zettel-Ortsverzeichnis

So erinnerte ich mich an die tollen Dateien des SF Günther Krämer, der alle bekannten Orte von R-Zetteln mi 4-stelliger Postleitzahl aus den Jahre 1964 – 1993 erfasst hat. Ich hatte diese Dateien schon früher einmal aufbereitet und in einer ACCESS-Datenbank vorliegen. So ging es recht schnell daraus ein „Wörterbuch“ mit 19.392 PLZ-Ortsnamen (-Kombinationen) zu erstellen. Unter den nahezu unerschöpflich vielen verfügbaren Python-Modulen fand ich eines für „get close matches“ (finde nahe Übereinstimmung). Das war schnell importiert und für das „R-Zettel-Wörterbuch“ eine weitere Parametertabelle angelegt. Zuvor musste ich also dem RZ-D6 beibringen, die erkannten Texte um alle Ortszusätze wie „am, im, Kreis, Kr, bei, über, …“ zu bereinigen und weiter ging es.
In knapp 1,5 Sekunden bekomme ich nun tolle Analyseergebnisse. Als falsch erkannte Ziffern in der Postleitzahl oder als falsch erkannte Buchstaben im Ortsnamen spielen nun keine Rolle mehr. So stieg die Erkennungsrate auf aktuell über 90 / 95%. So sollte es sein. Anbei ein paar Beispiele von schlechten Ergebnissen der Texterkennung und der aus dem Ortsverzeichnis „korrekt“ ermittelten Orte:

Ergebnis der Texterkennung
809 Wasserburg a lnn I
4000 Düsseidorf 1 o1
4000 DüsseMor I 33
20cm HamÄrrg 36
805 Hohenkammer
Abgleich mit Ortsverzeichnis
8090 Wasserburg
4000 Düsseldorf 1
4000 Düsseldorf 33
2000 Hamburg 36
8051 Hohenkammer
31. Der Roboter arbeitet

So konnte nach dreieinhalb Jahren in 4 Wintern, knapp 4.000 ausgebenen Euros und gut 7.500 Zeilen Python Programmcode (natürlich einschließlich der „inline“ Programmdokumentation) am 31.12.2020 die Ablaufsteuerung den ersten Zettel erfolgreich ablegen. Im Januar folgten dann zahlreiche Optimierungen und am 31.1.2021 konnten diese erfolgreich getestet werden. Der Roboter arbeitet. Aktuell benötigt der RZ-D6 ca. 50 Sekunden pro R-Zettel

32. Und wie geht es weiter?

Es steht der Test bzw. die Beobachtung des Dauerbetriebes an. Da wird sich sicher noch das eine oder andere zeigen. Es warten etliche 100.000 R-Zettel darauf, sortiert zu werden. Hier ein Eindruck davon:


Arbeitsvorrat für den Roboter

Zur Abarbeitung dürfte der RZ-D6 dazu ca. 1 Jahr an Betriebsstunden benötigen. Mal sehen, ob bei der Zykluszeit noch eine Optimierung möglich ist.
Natürlich warten auch noch „einige“ Wellpappenteile darauf zu weiteren 1.000er Setzkästen zusammengeklebt zu werden.

33. R-Zettel-Schubladen-Schrank

Bleibt noch zu erwähnen, dass nach dem Sortieren ja der Abgleich bzw. die Ergänzung der R-Zettel Sammlung folgt.

Dazu hatte ich mir 2013 einen feinen Schubladen-Schrank mit 81 Schubladen bei einer Tiefe von 60 cm gebaut. Der Bau der Schubladen dauerte doch einige Zeit, der Zusammenbau des Korpuses gelang mit Hilfe meiner Frau dann in wenigen Stunden. Darin verschwinden die erworbenen 50.000 A6-Steckkarten spielend, sind doch über 45 Meter Platz vorhanden. So ist NIE ein Umsortieren erforderlich. Soll ja schon vorgekommen sein.


Schubladenschrank

Liebe Leser, ich hoffe Ihr seid jetzt nicht erschlagen von diesem Bericht. Für mich war es spannend, all diese Entwicklungsschritte erneut Revue passieren zu lassen und diese für Euch – und für mich – zu beschreiben. Beim nächsten Betrachten des Videos fällt Euch dann sicher einiges mehr auf und Ihr habe eine Idee davon, was da alles „ablaufen“ muß damit das Sortieren auch klappt.

Und zu guter Letzt:

Da fragte mich vor einigen Jahren mein australischer Freund Costa: „Bernd, what do you do if you do nothing?“ Also jetzt wisst Ihr es auch: „Was ich mache, wenn ich nichts mache“.


RZ-D6 Sortier-Roboter
(PS. Das Gipfelfoto auf dem Monitor zeigt den Autor in Ostgrönland)

zum Seitenanfang

Stand Oktober 2021