...und sie leben!

 Als ich Sonntag Morgen am Wohnzimmer vorbei in die Küche schlurfte, merkte ich (so halb) dass irgend etwas anders war. Hatte sich da auf dem Tisch etwas verändert? War die Unordnung von mir hinterlassen worden? War es gestern so spät? Die Synapsen etwas mit Koffein geschmiert, verflog langsam das Dunkel in dem diese Gedanken verschwanden. Die Scan-Maschine geisterte durch meinen Kopf - sie war anders.
Beim näheren Hinschauen sah ich es: Da war ein GP2D02 Sensor auf dem URM37! Wo kam der her?

Nein, ich glaube nicht mehr an das Christkind. Doch in letzter Zeit fiel mir immer öfter auf, dass Programme plötzlich funktionierten, oder Kabel richtig gesteckt waren, obwohl ich am Vortag noch Fehler drin hatte.
Was geht hier vor? Passiert Euch das auch öfter? Habt Ihr auch manchmal den Eindruck Euer Rechner hat einen besonders guten oder besonders schlechten Tag? Dinge verändern sich, ohne Euer Zutun? Programme verschwinden oder tauchen auf? Ich glaube, das ist kein Eindruck, ich glaube sie machen das selbst.Und die Scan-Maschine hat sich einen neuen Sensor aufgepflanzt. Sie verändert sich, entwickelt sich weiter... sie - lebt?

HA! Gebt es zu - beinahe hättet Ihr es geglaubt, stimmts? Bei den Fummeleien mit dem URM37 ist mir eingefallen, dass ich noch ein paar von den GP2D02 rumliegen hatte. Dieser Sensor ist ein Distanzsensor der nach dem Triangualtionsprinzip arbeitet. Eine Sendediode, eine Empfangsdiode. Je stärker die Empfangsdiode leitet, desto näher ist das Objekt. Die messbare Distanz liegt zwischen 5 und 70 cm (laut Datenblatt 80cm). Der große Nachteil jedoch ist, dass der Output des Sensors nicht linear ist, d.h. die Auflösung in Größerer Distanz ist sehr niedrig und steigt mit sinkendem Abstand (siehe Graphik - Abstand auf X, Sensor-Out auf Y1).

Im Netz hab ich genügend Stoff gefunden, wie man sich am Besten einen Look-Up Table baut, um mit möglichst wenig CPU-Power die Umrechnung von Ausgabewert zu Distanz zu bekommen. Im wesentlichen funktioniert das so, dass man für bestimmte Abstände den rohen Sensor-Output aufzeichnet (blaue Linie) dann eine Funktion plottet (gelb) und die Parameter dieser Funktion so trimmt, dass der Fehler (least Squares - grüne Kurve) möglichst klein wird. Den Optimierungs-Bereich habe ich auf 10 - 70 cm eingestellt. Messungen in größeren Distanzen sind extrem ungenau und streuen stark.
Ich hab dann ein kleines Python-Script geschrieben, dass mit den gefundenen Funktionsparametern ein Header-File schreibt, das einen Look-Up Table enthält.
Damit ist eine Funktion realisierbar, welche die gemessene Distanz in [mm] ausgibt, nachdem man den Sensorwert rein steckt. Wenn jemand an Einzelheiten Interesse hat, stelle ich gerne alle Files zur Verfügung (weiß jemand, ob ich das Zeug an diesen Blog tackern kann?).

Danach bin ich wieder Ecken scannen gegangen, genauer gesagt - eine Ecke:

Die Ecken aus Sicht des URM37 sehen etwas schöner aus, dafür verrundet er die Geraden der Wand ein wenig stärker.
In Sachen GP2D02 zeigt die Ecke zwar eine deutliche Charakteristik, aber ein Sensormodell zu realisieren stelle ich mir extrem Schwierig vor - zumal auf einem Micro. Vielleicht könnte man den Sensor dazu gebrauchen, den Boden vor einem Roboter zu scannen und Stufen, etc. zu detektieren. Um ernsthaft an dieser Stelle weiter zu machen wären mehr Tests nötig. Unterschiedliche Oberflächen, Formen, Abstände, usw.

Doch hier mach ich die Biege und tüftel an den Akkus weiter. Ich brauche ein ordentliches Scheduling. Meiner Meinung nach liegt hier eine Schwäche im Arduino Konzept, da es keine direkte Unterstützung für Interrupt-Services gibt.

Übrigens - was mir gerade auffällt: der Look-Up Table sieht anders aus als gestern und der LCD-Text hat auch ein anders Layout...

Brauch mal ne Pause...

Das kann nicht gut sein, wenn man schon von Akkus träumt, wenn man in der Mittagspause Schaltpläne auf Servietten malt und bei schönstem Sonnenschein in der Werkstatt rumhängt.

Also dacht ich mir: Mach mal zwischendurch was anderes. Hab ich auch getan und den URM37 Ultraschall-Sensor aus der Kiste geholt, von dem ich zwei zum Abschied von meinen Arbeitskollegen bekommen habe (neben einen Haufen anderer Sachen - danke nochmal!)
Auf der Suche nach Beispielen stellte ich fest, dass die Seite von yerobot.com nicht erreichbar war, die Software von Miles Burton kleinere Bugs hatte und in der Doku ein Fehler in einer Formal war. Also alles ganz normal und kaum eine Stunde später spuckte das Teil die ersten Messungen aus. Die ersten Tests verliefen ganz gut und ich fragte mich, wozu der Servo-Ausgang gut ist.

In einem gut sortiertem Haushalt findet man immer ein Servo in irgend einer Schublade, und in der Werkstatt war schnell ein Winkel gezaubert. Der hausinterne Stardesigner Laurenzo de G kreierte das ultimative Testfahrzeug dazu und fertig war die monstermäßige Scan-Maschine.

 

Kann der Sensor Ecken scannen? Im Diagramm unten sind ein paar Sprünge zu erkennen. Der Scan stammt aus einer Ecke, drei mal abgetastet. Ich bin mir nicht mehr sicher, ob sich das Testfahrzeug dabei bewegt hat oder nicht, da die Wiederholgenauigkeit zu wünschen übrig lässt...

Beim Blick in die Software fällt auf, dass eine Menge Delays drin stehen. Außerdem sind die Abtast-Zeiten für kurze Distanzen sehr schnell und verlängern sich dann mit zunehmendem Abstand. Deshalb werde ich mir die Software nochmal vornehmen und vielleicht mein altes Scheduling-Konzept ausgraben, welches ich im Terence-Projekt entworfen hatte.

So ein bisschen Abwechslung macht schon Spaß!