das Zauberwort für schnelle Linienfolger heißt "PID"-Steuerung - das klappte auch immer schon mit Lego wunderbar:
http://www.inpharmix.com/jps/PID_Con...ms_Robots.html
das Zauberwort für schnelle Linienfolger heißt "PID"-Steuerung - das klappte auch immer schon mit Lego wunderbar:
http://www.inpharmix.com/jps/PID_Con...ms_Robots.html
Unabhängig von der Regelungsart (Zweipunkt, P, D, PD, PID, Fuzzy, etc.) geht es als erstes einmal darum ob der Sensor der richtige ist für die Aufgabenstellung.
Linienfolger habe üblicherweise mindestens drei Feflexlichtschranken. Und diese sind monochom und oft auch noch digital und nicht analog.
Ein Farbsensor ist also verdammt wenig und hat einen nicht notwendigen Datenoverhead.
Ein Linienfolgersensor muß ja nur einen Unterschied zwichen Linie (1) und nicht Linie (0) erkennen können.
Eine Linienfolgeaufgabe kommt auch nicht ohne Weiteres zufällig in der Natur vor sondern ist eine künstliche Aufgabenstellung die üblicherweise in Wettbewerben gestellt wird.
Man kann also gemäß der Wettbewerbsbedingungen seinen Sensor gezielt einstellen, so das unabhängig von Vordergrund- (Linie) und Hintergrundfarbe (Boden), ein sicheres Erkennen mit einem Bit möglich ist.
Also wäre es Sinnvoll einen Farbsensor da einzusetzen wo er seine Stärke zeigen kann und nicht zweckendfremded, so das man alle seine Nachteile erst kompensieren muß.
Muß man aber damit leben, dann wäre der erste Schritt, eine Datenreduktion durchzuführen.
Also für jeden Farbkanal einen Schwellwert festlegen und darüber für jeden Kanal festlegen ob er eine 1 oder eine 0 ausgibt.
Dann die Kanäle aufsummieren und nur wenn alle Kanäle 1 sind wird dan final eine 1 ausgegeben, sonst eine 0.
Damit reduziert man z.B. bei einem 3-Kanal Sensor mit 8 Bit Auflösung die über 16,7 Millionen möglichen Kombinationen auf zwei mögliche Zustände.
Allerdings ist das größere Problem, wenn man nur einen Sensor hat.
Denn mir einem Bit kann man nur feststellenn ob man auf der Linie ist oder nicht.
Eine Erkennung in welche Richtung man die Linie verlassen hat, ist wärend der Fahrt nicht möglich.
Bei jeder Änderung müsste man anhalten und auf der Stelle Drehungen durchführen um zu erkennen ob man beim Linksdrehenn ode Rrechtsdrehen wieder auf die Linie zurück findet.
Bei einem Linienfolgesensor mit mindestens drei (Für Wettbewerbe besser 5) Sensoren kann man mit einer Messung deutlich mehr Informationen gewinnen.
Üblicherweise kann die Empfindlichkeit und somit die digitale Schaltschwelle mit einem Komparator eingestellt werden.
Um sich darüber klar zu werden, was man bei der Aufgabenstellung von einem Sensor erwarten kann, kann man sich mal die möglichen Fälle visualisieren.
Im Bild eine 5er Sensorzeile.
Der Fall wenn kein Sensorelement etwas detektiert ist nicht berücksichtigt. (Bei Fall A den High Pegel im Sensor ganz Rechts ignorieren der stammt von einem Fall mit Codemarken paralell zur Linie).
Es sind nur die Fälle für eine Seite berücksichtigt (die andere Seite ist eine Spigelung der Fälle).
Bei Fall A fährt man einfach gadeaus.
Bei Fall B wird das Signal des mittleren Sensors schwächer und der nächste Sensor links gibt ein Signal ungleich 0 zurück.
Je nach Schaltschwelle kann man hier schon ein Auswandern nach links erkennen und mit dem Regeln der Fahrtrichtung beginnen.
Bei Fall C ist ein eindeutiges Auswandern nach links erkennbar und entsprechend ist die Fahrtrichtung nach links zu korrigieren.
Bei Fall D ist ein starkes Auswandern nach links erkennbar, hier könnte man neben starkem Gegenlenken auch die Geschwindigkeit reduzieren um das Verlieren der Linie unwahrscheinlicher zu machen.
Die bisherifgen Fälle treten bei Kurven auf.
Bei Fall E knickt die Linie nach Links ab und ein Anhalten (oder sehr starkes Abbremsen) und scharfes Drehen nach Links um 90° ist durchzuführen.
Bei Fall F kommt man mur mit einem Gedächtniss weiter.
Als Momentaufnahme kann das ein Zielpunkt sein, nur wenn man in diesem Fall weiterfährt und die vorherigen Messungen in Verbindung mit der zurückgelegten Strecke berücksichtigt, kann man erkennen ob es sich um eine Linienkreuzung, T-Stoß oder eine größere Zielfläche handelt.
Dies sind allerdings Überlegungen, die man üblicherweise bei der Analsyse der Aufgabenstellung anstellt, bevor man mit dem Aufbau und der Programmierung beginnt.
Ich kann mich erinnern: Auf der CD im ersten Mindstorm-Kasten war das Linienfolger-Experiment unter so ziemlich den gleichen Bedingungen als Aufgabe zu lösen - ein Sensor, zwei Motoren.
Die offizielle Lösung war übrigens, die Räder abwechselnd anzusteuern und so den Sensor immer einmal über die Linie zu bewegen. Das Gefährt hat sich so langsam nach vorne gewibbelt.
Ist noch gar nicht so lange her, noch keine 20 Jahre.
jap, das wird dann wohl der RCX gewesen sein, der kam vor knapp 20 Jahren auf den Markt
Das Gewibbel hat dann aber durch PID Regelung fast komplett abgenommen - und die Geschwindigkeit zu...
Das Problem ist das man mit einem einzigen Sensorelement nur einen Kantenfolger realisieren kann.
Da LEGO den Farbsensor nimmt, wird man für PID einfach mehrere Farbabstufungen nutzen um zu erkennen wie weit man von der Kante entfernt ist.
Der Messpunkt ist ja in der Realität eine Messfläche und genau auf der Kante ist man wenn 50% Linie und 50% Hintergrund da sind.
Mann kann mit einem einzigen Sensorelement aber nicht erkennen ob man links oder rechts an der Kante der Linie ist.
Das geht dann nur mit dem hin und her schwenken.
Denn nur da kann man aus der Bewegungsrichtung und dem Messergebniss einen Schluß daraus ziehen ob man grade eine linke oder eine rechte Kante erkennt.
Wenn man also beim Algorithmus für einen Sensor davon ausgeht, das man der rechten Kante folgt, gibt man an:
Wird es heller drehe links, wird es dunkler drehe rechts.
Kommt man dann aber z.B. durch einen scharfen Knick und etwas zu viel Geschwindigkeit an die linke Kante dreht man sich bei der Suche nach der Linie von der selben weg und wird in entgegengesetzte Richtung fahren wenn man sie wiederfindet.
Der Aufbau kann also funktionieren, ist aber nicht besonders robust.
Da sollte man also am besten klären, ob man die Funktion Linienfolgen robust oder experimentel realisieren soll/will.
Eine robuste Implementierung erlaubt prinzipiell höhere Geschwindigkeiten.
Die Statements zu Lego Sensorik stimmen so nicht unbedingt.Zitat von i_make_it
Lego verwendet nicht immer einen Farbsensor zur Linienverfolgung, es gibt auch - je nach System - reine Helligkeitssensoren (Lichtsensoren aktiv oder passiv).
Aber auch Farbsensoren können per Firmware/Treiber-Einstellung in einen reinen Helligkeitssensor-Modus geschaltet werden, z.B. für Linienfolger oder andere Zwecke, und das ist bei Lego auch immer der bevorzugte Modus für Linienfolger.
Aber da der TO ja nicht Lego verwendet, sind die Überlegungen zu Lego-Sensortypen auch wohl eher nebensächlich, nur die grundsätzlichen Linienfolger-Algorithmen können ntl ebenfalls verwendet werden.
Farberkennung zur Linienverfolgung ist dabei auch sicher deutlich schwieriger als reine Helligkeitsunterscheidung.
Ich hatte oben schon pololus 3pi (klick mal) erwähnt. Der hat eine Fülle von Linienfolger-Ratschlägen unter "Pololu 3pi Robot User’s Guide". Der Reihe nach hier, siehe entsprechende Einzelpunkte :
User´s Guide:
https://www.pololu.com/docs/0J21
Pololu AVR C/C++ Library User’s Guide
https://www.pololu.com/docs/0J20
und Pololu AVR Library Command Reference
https://www.pololu.com/docs/0J18
Den 3Pi habe ich selbst, daher kenne ich diese Fülle von Informationen (nicht nur über Linienfolger). Leider (*gg*) keine Farbsensorik.
Ciao sagt der JoeamBerg
Die Idee ist echt gut! So kann ich nämlich immer ganz genau ausmachen auf welcher Seite er ausgebrochen ist und dann dementsprechend regulieren. Danke!
Bei Youtube gibt es zu Mindstorms und einem Sensor auch noch andere kreative Lösungen.
Z.B. wurde der Sensor an einem Arm befestigt, der durch einen eigenen Motor hin und her bewegt wird.
Da muß dann die Masse des Roboters nur gedreht werden, wenn man wirklich abbiegt.
Sonst wird nur der Sensor mit dem Arm bewegt.
Nachteil ist halt ein Motor mehr und die Schalter für die Endlagen.
Von der Auswertung ist das identisch zum Drehen des ganzen Roboters.
Berechtigungen
Zitieren
Lesezeichen