Linienfolger

[i_make_it]

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.

[HaWe]

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.
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.

[oberallgeier]

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.