Kleiner Linienverfolger / line following robot

[juh]

Hallo,

ich stelle Euch hier mal meinen Linienverfolger vor (Video s.u.), den ich schon öfters mal erwähnt habe. Er kann gegenüber anderen Linienverfolgern nicht besonders viel. Die einzigen Anforderungen, die ich hatte, waren, dass er einer handgezeichneten Linie möglichst schnell und genau folgen sollte und dabei möglichst klein und wendig sein sollte. Idee war, dass die Kids eigene Strecken auf Poster malen können und er damit klarkommt.

resized_DSC_0936.JPG (124.82 KiB) 2945 mal betrachtet

resized_DSC_0934 (1).jpg (114.24 KiB) 2945 mal betrachtet

Es kommen einige selbstgedruckte Teile und ein Arduino mit zwei DC-Motortreibern zum Einsatz. Interessant finde ich aber vor allem die Steuerungssoftware. Sie nutzt einen PID-Regler, den wir ja jüngst schon hier (nicht als erste) diskutiert haben. Die PID-Parameter können dynamisch auch während der Fahrt mit Hilfe einer Infrarot-Fernbedienung geändert werden. Die aktuellen Werte oder alternativ eine Visualisierung der Sensoren (PID Regelgröße) und des Output (PID Stellgröße) werden per OLED-Display angezeigt.

Im Gegensatz zu anderen Linienverfolgern kommt das Modell mit nur zwei Sensoren (Typ TCRT5000) aus, die hier analog ausgewertet werden (es gibt viele Beispiele mit diesem Sensor, die ihn nur digital mit einstellbarer Schwelle auslesen). Die Differenz der beiden Messwerte (links - rechts) kommt als Input (Regelgröße) in den PID-Regler, der Sollwert ist 0, was einer mittleren Position über der Linie entspricht. Einen Spursucher habe ich bisher nicht implementiert, der Roboter muss also am Anfang manuell auf die Linie gesetzt werden.

Da mir mir die 9V-Blockbatterien/akkus zu kurzlebig sind, verwende ich zwei 3,7V 14500 LiIonen-Akkus als Stromquelle. Ebenfalls gedruckt sind der An-/Ausschalter und der Baustein 15 mit Kugelrad.

Einiges an weiteren Erklärungen v.a. zur Steuerung habe ich in den Video gepackt, fragt gerne, wenn was unklar ist:

https://youtu.be/hU7KIjeh6Fw

Wie man sieht, fährt das System bei 66% der mit MiniMotor, U-Getriebe und ca. 8V maximal möglichen Geschwindigkeit sehr genau und weitgehend geschmeidig. 100% sind nur auf Kosten harter (ruckartiger) Steuerungseingriffe zu fahren, wenn die Linie zuverlässig gehalten werden soll. Vielleicht fällt ja den PID-Profis unter Euch noch was auf, aber ich habe da wirklich lange rumprobiert und es nicht besser hinbekommen.

Einer der Stolpersteine für mich war bei dem Projekt die Frequenz des PID-Regler-Aufrufs. Die ansonsten sehr empfehlenswerte Arduino-Library von Brett Beauregard hat als Standard ein Intervall von 200 mS für die Aktualisierung des PID-Reglers eingestellt, was hier natürlich viel zu lang ist, in der Zeit fährt der Roboter mind 5 cm. Selbst ein häufigerer Aufruf führt zu keiner schnelleren Aktualisierung, wenn man diesen Default nicht per SetSampleTime() ändert. Auch interessant war die Umrechnung des Output (Stellgröße) auf passende PWM-Werte für die beiden Motoren. Problem war anfangs, dass die Sensoren je nach Bedingungen etwas unterschiedliche Werte-Bereiche lieferten, damit aber der vordefinierte PWM-Bereich von 0-255 angesteuert werden sollte. Hier hat die Kalibrierung mit anschließender Normierung des Messwertebereichs per map() geholfen (s. Video).

Mein Fazit ist, dass der PID-Regler auch keine Wunder bewirken kann. Das System, so wie es hier aufgebaut ist, bringt einiges an Trägheiten mit sich. Sensor und Arduino kommen an ihre Grenzen, was die Reaktionsgeschwindigkeit angeht, und das Spiel des Getriebes bringt die Geschwindigkeitswechsel auch nicht 1:1 auf die Straße. Bei Gelegenheit werde ich den Linienverfolger wahrscheinlich ähnlich noch mal mit einem weniger schnarchigen Wemos/ESP und Mini-Getriebemotoren nachbauen.

lg
Jan

[NBGer]

Hallo,
ein nettes, kompaktes Teil. Schön gemacht!

Ich hätte nicht gedacht, dass man das mit 2 PWM-geregelten DC-Motoren machen kann!
Du hast ja keine direkte Rückmeldung der Drehzahl der beiden Motoren, sondern nur eine indirekte Rückkopplung der Regel-Schleife über die Position auf der Linie.
Von daher sehe ich da einen Ansatzpunkt, wenn Du noch was verbessern möchtest. Ich hätte das wahrscheinlich mit Stepper-Motoren gemacht. Ein Drehwert/Drehwinkelgeber an beiden Motoren würde wahrscheinlich auch Verbesserung bringen.
Dann müsstest Du evtl. mit 3 Reglern arbeiten. Einer für die Spursuche und jeweils einer für die Geschwindigkeitsregelung der Motoren.

Außerdem, wie hast Du die Regelparameter bestimmt? Wahrscheinlich durch ausprobieren?
Um den Regler zu optimieren, müsstest Du vielleicht mal die Soll/Istgrößen aufzeichnen und graphisch darstellen. Die beiden häufigsten Probleme:
- entweder der Regler braucht zu lange, bis der Sollwert erreicht ist (oder erreicht in nie), oder er übersteuert und braucht zu lange, bis er einschwingt.

PID-Kurven.jpg (16.96 KiB) 2906 mal betrachtet

Optimal für eine schnelle Sprungantwort wäre die grüne Kurve; kurzes Übersteuern und schnelle Annäherung an den Sollwert, ohne zu schwingen

Achja, wie funktioniert dein Steuerprogramm im Detail? Wie berechnest Du die beiden PWM-Werte aus dem Regler-Output?
Ich frage deshalb, ob die 100% Geschwindigkeit überhaupt möglich sind. Du brauchst ja "Luft nach oben" für die Regelung. Oder als Alternative: das kurvenäußere Rad fährt immer mit PWM 100% und die Regelung bremst nur das kurveninnere Rad ab.

[NBGer]

und noch ein Hinweis:

eventuell musst du den Sensorwert glätten/filtern, bevor du ihn an den Regler übergibst.
Die meisten Filter haben aber den Nachteil, dass die Reaktionsgeschwindigkeit schlechter wird.
Gute Erfahrung habe ich mit dem Butterworth-Filter gemacht:
https://de.wikipedia.org/wiki/Butterworth-Filter

Google mal danch , du findest auch C-Code, um diesen Filter zu programmieren.

Allerdings habe ich meine Zweifel, ob das auf dem Arduino noch funktioniert! Ohne Floating-Point-Unit dauern solche Berechnungen wahrscheinlich zu lange!

[juh]

Hallo NBGer,
und danke für die ausführlichen Kommentare. Beim Thema PID merkt man erst auf den zweiten Blick, dass die drei Formeln nur der Anfang sind!

Dass PID auch zur Geschwindigkeitssteuerung der beiden DCs genutzt werden könnte, darauf wäre ich nicht gekommen. Tatsächlich schwebt mir schon länger eine zum U-Getriebe "nachrüstbarer" Drehwertgeber vor (Hall lässt grüßen), mit dem jeder mini-mot zum Encoder-Motor würde. Sowas wäre hier natürlich bestens anwendbar. Stepper sind halt bei mobilen Modellen nicht so ideal wegen des hohen Verbrauchs, auch größenmäßig müsste man schauen. Wobei das Modell eigentlich mit Steppern begonnen hat und zwar den kleinen (superbilligen) 28BYJ-48. Die fuhren mit PID superzuverlässig, aber das ist auch kein Wunder, denn sie schaffen max. 3 RPM. Daher das flottere Modell mit den Mini-Mots, die kleinen Getriebestepper kommen demnächst in einem Logo/Turtle-Bot zum Einsatz.

Ja, die Parameter habe ich durch viel probieren ermittelt, v.a. weil ich ein eigenes Gefühl für die drei Komponenten entwickeln wollte. Durch die Infrarot-Fernbedienung geht das "in situ", so dass ich die Auswirkungen immer sofort beobachten konnte, ich bilde mir ein, dass ich Sollwert-Erreichen, Übersteuern und Einschwingen dadurch teils ganz gut live beobachten konnte. Mir ist aber klar, dass das nicht garantiert, die Ideallösung zu finden. Eine Option, die ich noch nicht probiert hatte, ist die PID-Autotune library, ebenfalls von Brett Beauregard.

Das Aufzeichnen/graphisch darstellen wäre auch schön, wird beim Arduino aber schwierig aufgrund des kleinen Speichers und fehlender Drahtlosverbindung, auch da wird ein ESP32/ESP8266 neue Möglichkeiten eröffnen.

Ja, das Steuerprogramm fährt das äußere Rad immer bei 100% und bremst nur das innere linear, bei maximalem Output/Regelgröße auf 0%. Der verantwortliche Code sieht ungefähr so aus:

Code: Alles auswählen

  // read sensors
  leftOn  = constrain(map(analogRead(inPinLeft), leftMinIR, leftMaxIR, 100, 900), 0, 1023);
  rightOn  = constrain(map(analogRead(inPinRight), rightMinIR, rightMaxIR, 100, 900), 0, 1023);
  Input = leftOn - rightOn;
  if (myPID.Compute()) { // interval set by setSampleTime() has passed
    // compute motor speeds
    rightPWM = min ( maxSpeed, map (Output, -PIDlimit, PIDlimit, 0, 2 * maxSpeed));
    leftPWM = min ( maxSpeed,  map (Output, -PIDlimit, PIDlimit, 2 * maxSpeed, 0));
    mot_run(leftMot, constrain (leftPWM, -255, 255));
    mot_run(rightMot, constrain (rightPWM, -255, 255));
  }

maxSpeed ist z.B. im Video bei 170 oder 255. PIDlimit ist die Ausgangsbegrenzung und entspricht hier den möglichen Extremwerten des Input (-800 bis 800), ...min/...maxIR sind die bei der Kalibrierung ermittelten Extremwerte für hell/dunkel.

Das mit der Glättung ist auch noch eine spannende Idee, ich hätte aber auch Bedenken bei der Reaktionsgeschwindigkeit. Bei Fullspeed fährt der Roboter derzeit ca. 1-2 mm pro loop(). Wenn dann noch Rechenzeit für die Glättung dazukommt und der Wert über mehrere Zyklen geglättet wird, könnte das die Vorteile gleich wieder schlucken. Dennoch werde ich mir das in jedem Fall noch mal genauer ansehen, aber erst nächstes Jahr.

lg und allen einen guten Rutsch
Jan

[NBGer]

ok...ich bin jetzt nicht ganz sicher, ob ich Deinen Code auf Anhieb verstanden habe, aber....

du verwendest den PID-Output, um sowohl die PWM für das rechte und das linke Rad zu berechnen, und schneidest dann bei MAX-Speed ab, oder?
Das könnte bedeuten, dass der vom Regler errechnete Wert bechnitten wird. Der PID-Regler weiß davon ja nichts, und dreht bei jedem Rechenschritt den Output weiter auf, da ja der Ist-Wert nicht so schnell folgen kann, wie erwartet.
Das könnte dann starkes Übersteuern oder einen Windup zur Folge haben.

Ich hätte wahrscheinlich das kurvenäußere Rad fest auf 100% PWM gesetzt und den vollen Regler-Anteil auf das kurveninnere Rad wirken lassen (100% - Output).

Alles Gesagte aber im Konjunktiv; da würden kurze Aufzeichnungen mehr Klarheit schaffen.

Trotz alledem macht Dein kleiner Linienverfolger seine Sache bereits ausgesprochen gut! Im Video ist mir nur aufgefallen, dass er etwas ruckartig lenkt. Dies könnte eine der genannten Ursachen haben oder eine GANZ ANDERE