Entfernungssensoren und ihre Tücken…

Nachdem es im letzten Monat große Fortschritte gab, ging es diesen Monat leider so gut wie gar nicht voran (deshalb gab es auch keine neuen Beiträge…).

Verursacht wurde diese Verzögerung durch die Entfernungssensoren des Roboters. Wir benutzen die analogen Sharp IR-Entfernungssensoren mit einer Reichweite von 4cm – 30cm. Diese Sensoren arbeiten optisch, nach dem Prinzip der Triangulation (mehr dazu hier). Vorteil dieser Sensoren ist, dass sie zum Einen sehr präzise sind (genau definierter Messpunkt (ca. 5mm Durchmesser, Auflösung ca. 3mm)) und zum Anderen sehr schnell neue Werte liefern (ca. alle 50ms Aktualisierung des analogen Ausgangs eines Sensors).
Wenn man bestimmte Dinge allerdings nicht beachtet (wie wir :/ ), hat man nichts davon; Die Werte rauschen und springen dann ohne Ende, sodass man nicht mehr vernünftig mit ihnen arbeiten kann (was fatal ist, denn ohne Entfernungssensoren geht gar nichts).

Wir mussten also die Ursache für das Rauschen finden: Nachdem wir die Hardware des Roboters als Ursache ausschließen konnten, haben wir näher direkt bei den Sensoren gesucht. Wir haben recht schnell herausgefunden, dass die Sensoren zum Einen bei Sonnenlicht nicht funktionieren (beim Wettbewerb kann uns das egal sein, denn erstens findet dieser in einer Halle statt und zweitens würden alle anderen Teams dann auch Probleme bekommen). Aber auch, wenn die Sonne nicht schien, lieferten die Sensoren unbrauchbare Werte. Die Sensoren müssen sich also irgendwie gegenseitig beeinflussen. In Frage kam da zu Beginn nur das Plexiglaschassis, welches den Strahl des Sensors vielleicht ungünstig reflektiert. Die Probleme traten allerdings auch auf, nachdem die Sensoren weiter nach unten gesetzt wurden und eine Reflexion durch das Plexiglas ausgeschlossen werden konnte.

Wir haben uns dann den Analogausgang der Sensoren genau auf einem Oszilloskop angesehen:

Rauschen
Das Rauschen und die Spikes sind wieder klar zu erkennen. Man sieht aber auch, dass sie periodisch auftreten. Nach einigem Hin- und Her und Tappen im Dunkeln haben wir die Ursache dann gefunden:

Schwingungen

Wie im Bild erläutert, beeinflussen sich die Sensoren gegenseitig (Interferenzen). Um das zu prüfen, haben wir einfach immer nur einen Sensor pro Richtung „sehen“ lassen und die anderen zugedeckt. Das Ergebnis ist das obere Bild.
Das periodische Rauschen tritt auf, weil die LED der Sensoren mit einer bestimmten Frequenz moduliert wird. Der Sensor reagiert dann nur auf Licht, das mit der gleichen Frequenz wieder beim Sensor ankommt. So soll ausgeschlossen werden, dass Umgebungslicht den Sensor stört (das Sonnenlicht hat allerdings ein sehr breites Spektrum, weshalb das dann nicht so gut funktioniert).
Man muss sich dann einmal das „aufgenommene“ Bild aus Sicht der Sensoren sehen. Ein Sensor sieht im Schlimmsten Fall dann drei Punkte auf einer Fläche (den eigenen Messpunkt und dem der anderen Sensoren) und kann nicht unterscheiden, welcher Messpunkt von ihm kommt. Die Messpunkt werden allerdings nur in periodischen Abständen sichtbar, weil die Modulationsfrequenz von Sensor zu Sensor minimal voneinander abweicht und nur in diesen periodischen Abständen identisch ist.

Eine erste Idee war dann eine Abschattung der Sensoren gegenseitig, sodass der Sensor nur noch einen eigenen Messpunkt sieht. Das hat leider nur für einen bestimmten Bereich funktioniert. Die einzige Lösung ist also, dass der Roboter pro Messung nur einen Sensor pro Richtung aktiviert. Das ist nicht optimal, aber leider gibt es keine andere Lösung. Dazu haben wir vor jeden Sensor in die Versorgungsspannung einen Transistor gebaut und die entstandenen Steuerleitungen von jedem Sensor zum Controllerboard geführt:

Steuerleitungen

Benötigt werden nur drei Pins am Mikrocontroller, da ja in jede Richtung ein Sensor gleichzeitig an sein darf. Nach einiger Programmiererei (da das ganze seeeehr zeitkritisch ist, weil wir ja so schnell wie möglich die neuen Werte der Sensoren haben wollen und die Kamera auch so schnell wie möglich ausgelesen werden muss) haben wir dann aber 100%ige Werte bekommen, ohne Rauschen.

Im folgenden Bild stellt das blaue Signal den Analogausgang eines Sensors dar und das gelbe Signal den Zeitpunkt, zu dem die Analog/Digital Wandlung im Mikrocontroller durchgeführt wird:

Wandlung

Man sieht, dass das Ausgangssignal zunächst ca. 3,5V liegt (der Sensor ist dann ausgeschaltet (!)). Der Sensor wird dann eingeschaltet (Signal fällt auf 0V) und der Sensor braucht ca. 45ms (rauschendes Signal, ca. 3V) bis er seinen Analogausgang wieder aktualisiert hat (Signal fällt) und der Mikrocontroller das Signal auslesen kann. Direkt danach wird der Sensor bzw. die Sensorgruppe wieder abgeschaltet und die nächste Sensorgruppe aktiviert. Da sieht das dann genau so aus.

Da wir so maximal drei Sensoren pro Seite abfragen, brauchen wir insgesamt 150ms, bis alle 10 Sensoren am Roboter einmal abgefragt wurden. Das ist auch das Maximum, wenn der Roboter länger brauchen würden, müsste die Geschwindigkeit, mit dem er durch den Parcours fährt, reduziert werden, weil er sonst zu träge reagiert.

Ein weiteres (kleineres) Problem, was wir dann beobachtet haben, ist, dass Sensoren einer Seite unter Umständen bei gleicher Entfernung nicht das gleiche Signal ausgeben, was zu Folge hat, dass sich der Roboter über die Differenz zweier Sensoren nicht mehr an der Wand anpassen kann. Deshalb haben wir für jeden Sensor noch eine Messreihe genommen und bekommen die Werte nun fast Millimetergenau und linear.

Nachdem wir das Problem endlich lösen konnten, werden wir uns nun weiter der Optimierung und ich mir meinem Facharbeitsthema widmen, bei dem ich mich ja mit der Implementation von SLAM auf unserem Roboter beschäftige… Mal sehen, was daraus wird, weitere Informationen dazu kommen noch. :)