Schneller Line Follower

[GoZu]

Hallo,

ich möchte mir gerne einen Line Follower basteln der ziemlich schnell ist. Dazu wollte ich jetzt mal ein paar Fragen einholen und schauen, ob jemand Tipps hat, damit ich gleich von Anfang an gut starten kann

Geplant hätte ich jetzt 2 Antriebsmotoren (jeweils links und rechts) und vorne und hinten "Ball caster" (also so metallkugeln zum rollen).
Ansteuern möchte ich das ganze mit einem atmega (muss noch schauen welche version da 2 PWM Ports mit 16 bit Auflösung haben (oder reichen für sowas 8 bit?).
Als Sensoren möchte ich das Bauteil CNY70 verwenden (oder gibts zum Linien erkennen was besseres?). Davon hätte ich eine ganze Matrix am vorderen Ende des Roboters angebracht (also von ganz vorne bis zur Motorachse).
Die Matrix um Krümmungen zu erkennen. Um genügend Ports zu haben, würde ich mehrere 74xx165 Schieberegister verwenden.
Als Akkus habe ich 4 nimh Akkupacks mit jeweils 12V und 3200 mAh (jeweils 2 in Serie geschalten um die Motoren mit 24V zu Versorgen bzw. möglicherweise noch ein Spannungsregler auf 15 Volt davor, mal schauen wieviel die Motoren aushalten).
Als Motor diesen hier:
http://www.mfacomodrills.com/gearboxes/919d_series.html
Mit einer Übersetzung von 6:1

Ich hab hier im Forum gelesen, dass es "gut ist" das Chasis aus GFK Platten zu bauen. Was wäre da der Vorteil gegenüber z.b. Aluminium?
Außerdem habe ich gelesen, dass die Sensoren per CPLD vorverarbeitet werden sollten? Ist das wirklich nötig (also wäre ein atmega zu langsam?).
Bezüglich der Räder, gibts da irgendwelche speziellen welche eine sehr gute Haftung haben? Ich wollte eigentlich zuerst einen Roboter mit 3 Rädern und Omniwheels bauen, allerdings glaube ich, dass das für schnelle Linienverfolgung nicht gut geeignet ist.
Gibts sonst noch von jemanden gute Tipps? (bin grad beim durchschauen von anderen Projekten bezüglich line follower).

Ich überlege zurzeit auch noch, ob ich eine Webcam anbringe und dann die Bilder in Echtzeit auswerte und damit den Roboter steuere. Dazu würde ich einen rasperry pi nehmen (um genügend rechenleistung zu haben) + eine webcam dafür und dann mit dem Rasperry PI (mit einem modifiziertem Linux mit verändertem Scheduling Verfahren) dann die Bilder auswerten. Das kann man ja ziemlich schnell in Assembler programmieren, wenn man nur Kanten (also Linien) erkennen möchte (und dann die Daten per SPI/I2C zum atmega senden).

Wäre über jeden Tipp oder Hilfestellung dankbar

edit:
Bezüglich Sensoren hätte ich mir gedacht, dass ich 8 Sensoren pro Linie mache und dann ca. 4-8 Linien am vorderen Ende des Roboters anbringe. D.h. 1 Linie wird mit 1 Schieberegister angesprochen. Jetzt stellt sich mir die Frage, ob sich das Zeitlich überhaupt ausgeht, dass ich so die Sensoren abfrage (weil das Abfragen ja dadurch um den Faktor 8 langsamer wird). Bzw. habe ich auch gelesen, dass es eine gute Idee ist, wenn man bei den CNY70 Sensoren einmal mit und einmal ohne eingeschalteter IR LED die Werte entnimmt, um Fremdstrahlung entgegenzuwirken. Geht sich sowas überhaupt zeitmäßig aus, wenn der Roboter sehr schnell fahren soll?

[ranke]

oder reichen für sowas 8 bit?

Ich denke 8 bit sollten genügen.

Als Sensoren möchte ich das Bauteil CNY70 verwenden (oder gibts zum Linien erkennen was besseres?). Davon hätte ich eine ganze Matrix am vorderen Ende des Roboters angebracht (also von ganz vorne bis zur Motorachse).

Der CNY wird gerne genommen. Man ist etwas festgelegt was die Auflösung betrifft (also die Linienbreite), wenn es aber passt, sicher keine falsche Wahl. Bezüglich der Matrix hätte ich Bedenken ob das sinnvoll ist. Mir ist nicht klar, welchen Vorteil man über einer einzeiligen Anordnung gewinnt.

Außerdem habe ich gelesen, dass die Sensoren per CPLD vorverarbeitet werden sollten? Ist das wirklich nötig (also wäre ein atmega zu langsam?).

Knapp und pauschal über den Daumen: Wenn das Signal digital eingelesen wird, der MC mit 10MHz getaktet wird und zum Einlesen und Auswerten pro Sensor 10 Maschinenbefehle gebraucht werden, braucht man pro Sensor 1 Mikrosekunde. Bei 10 Sensoren in einer Reihe also 10 Mikrosekunden. Wenn er pro mm Fahrtstrecke eine Zeile einlesen soll, darf er also nicht schneller als 100m/s fahren. Das ist die Größenordnung der Höchstgeschwindigkeit eines Formel 1 Fahrzeugs - da sind die Motoren und Akkus wohl das schwächere Glied in der Kette, selbst wenn Du mehrere Sensorreihen verwirklichen willst.

habe ich auch gelesen, dass es eine gute Idee ist, wenn man bei den CNY70 Sensoren einmal mit und einmal ohne eingeschalteter IR LED die Werte entnimmt, um Fremdstrahlung entgegenzuwirken

Das Auswerten mit und ohne LED geht nur sinnvoll, wenn man die Werte analog einliest. Wenn man aus dem Sensorsignal gleich einen Digitalwert macht hilft nur ordendliches Abschatten gegen Fremdlicht.

[Besserwessi]

Für die Auswertung der CNY70 reicht der µC aus. Es reicht auch eine Zeile an der vorderen Kante des Fahrzeuges aus, wo die Linie weiter hinten verläuft, kann der µC aus der Bewegung berechnen, falls das überhaupt noch von Interesse ist. Mit den CNY70 wäre ggf. eine analoge Auswertung der Sensoren sinnvoll, um eine höhere Auflösung zu erreichen und auch ein dünnere Linie noch zu erkennen.

Die Linieauswertung per Kamera braucht wirklich viel Rechenleistung möglich sollte es aber sein. Für den Anfang würde ich aber klein anfangen, also erst einmal eher langsam und mit nur 2 - 4 der CNY als Sensoren. Für die Sensoren kann man sogar einen ersten Test machen ganz ohne Fahrwerk, einfach nur um die Position der Linie zu erkennen. Das braucht man nachher sowieso als Schnittstelle zwischen Sensoren und Fahrzeugsteuerung. Wenn das geht kann man immer noch zusätzliche Sensoren montieren. Mit der Erfahrung mit der 1. Version kann man dann ggf. an eine wirklich schnelle herangehen.

Wenn es gut gemacht ist, wird die Geschwindigkeit auch eher durch das Fahrwerk bestimmt als den µC - ein saubere Erfassung der Linie hilft aber ein guten Kurs zu fahren, ohne zusätzliche Umwege durch Fehler bei der Linienerkennung. Beim Fahrwerk kommt es auf gute Haftung der Reifen und ein passende Gewichtsverteilung an: wenig Gewicht auf das 3. nicht angetriebene "Rad" (ggf. auch eine extra Abstützung fürs Bremsen), tiefer Schwerpunkt, Masse nicht zu weit außen (damit das Trägheitsmoment nicht zu hoch wird im Vergleich zur Spurbreite).

Eine extra Spannungsregelung für die Motoren braucht man nicht - die Nennspannung der Motoren ist keine scharfe Grenze - kurzzeitig ist auch die 1,5 bis 2-fache Spannung kein Problem und ggf. zur Beschleunigen sogar hilfreich.

Eine GFK Platine ist ein recht gute Wahl für das Chassis - mechanisch eher etwas besser als Aluminium und gut erhältlich und günstig (im Gegensatz zu high Tech Alu/Magnesium).

[oberallgeier]

Hi GoZu,

... Sind die Motoren wirklich zu groß? ... in Assembler oder ist C für sowas auch schnell genug?

Vielleicht siehst Du Dir mal ein paar Linefollower an? Dieser (dazu vielleicht das spanische Video?) oder dieser oder ein ganz Schneller hier.

Große Motoren? Vielleicht verstehe ich es falsch, aber ein Linefollower ist kein Dragster - auch wenn die Vorbauten manchmal so aussehen. Die haben aber eher regelungstechnische Hintergründe, manche fahren damit buchstäblich "ums Eck"!! Übrigens ist einer der wirklich schnellen Linefollower der 3pi - siehe dieses Video.

Assembler - na ja, ich würde eine aufwändige Regelung nicht in Assembler programmieren müssen. Lieber jede andere Strafe. C ist sicher schnell genug - wenn Dein Konzept stimmt und Deine Programmierfähigkeiten *gg* und Du beim neuen Controller das CKDIV8 umfust.

... Wenn cih mir das so überlege, dann sollte es doch besser sein, wenn die Reifen ziemlich nahe beieinander sind ...

Blos nicht - überleg das nochmal.

[GoZu]

Naja, an der Programmierung wirds nicht scheitern (bin Informatik Student), bin eher in der Mechanik/Elektronik schlechter, da muss ich mich immer einlesen

Ehrlich gesagt finde ich keinen einzigen der Roboter von den Links "wirklich schnell". Na klar, schnell sind sie sicherlich, aber sind das wirklich die "schnellsten Roboter die es gibt"? Wenn man sich anschaut haben die alle imm die Bewerbe gewonnen, aber ich finde, das sollte doch viel schneller auch gehen...
Bzw. die Roboter von deinen Links hab ich auch schon gefunden und wollte mir durchlesen

Warum würdest du die Reifen weit auseinander bauen? In meiner Vorstellung wären Reifen die nahe sind viel besser, ich überlege sogar schon, ob ich die Motoren hintereinander baue (so das auch die Reifen versetzt sind), damit sie näher zusammen kommen. Dann wäre zwar ein Reifen weiter vorne als der andere, aber sie wären näher beisammen. Dadurch könnte ich schneller Kurven fahren (aber dafür wäre das Programmieren aufwändig und in eine richtung könnte ich schnellere Kurven fahren...).
So ganz verstehe ich nicht, warum die Reifen weit auseinander sein sollen.

[ranke]

So ganz verstehe ich nicht, warum die Reifen weit auseinander sein sollen

Bei Kurvenfahrt tritt eine Beschleunigungskraft zur Seite auf (Fliehkraft), die auf Höhe des Schwerpunkts des Gefährts angreift. Diese Kraft wird über resultierende Kräfte an den Radaufstandspunkten kompensiert. Diese resultierenden Kräfte entlasten das kurveninnere Rad, so dass weniger Antriebsmoment übertragen werden kann. Im Extremfall kann das kurveninnere Rad abheben und des Fahrzeug kippt zur Seite. Die resulierenden Kräfte werden gering wenn die Spurweite groß und der Abstand des Schwerpunkts zum Boden gering ist. Darauf sollte man bei der Konstruktion achten.
Der Gedanke, dass bei einem gegebenen Antrieb die Beschleunigung um die Hochachse bei engstehenden Rädern höher ist ist allerdings auch richtig. Für verschiedene Szenarien könnte man wohl eine optimale Spurweite rechnen. Bei der Schwerpunktlage gibt es nur ein Optimum: so tief wie möglich und in Längsachse des Fahrzeugs gesehen etwa auf Höhe der Achse.

[Besserwessi]

Die Motoren müssen gar nicht so besonders stark sein. Vor allem wenn die Bahn relativ enge Kurven hat, kommt man auch schon mit relativ moderater Motorisierung an die Grenze, dass die Reibung der Räder das Limit ist. Schon wegen der möglichst flachen Lage des Schwerpunktes hat man eher nicht die Gefahr das der Bot umkippt - das Problem ist eher das die Räder einfach rutschen - in den Kurven nach außen oder beim Beschleunigen/Bremsen einfach durchdrehen. Eine Aufgabe ist es da relativ dicht an die Grenze der Reibung zu kommen, aber nicht drüber. Einfach mal die Fahrphysik durchzurechnen zeigt dann schon auf welche Parameter (Gewicht, Trägheitsmoment (um die Vertikale), Drehmoment der Motoren, Schwerpunktlage, Achsweite, Reibkoeffizient man beim Fahrzeug achten sollte, und wo man nicht weiter optimieren muss. Wenn das noch nicht reicht, kann man auch den Drehimpuls in den Motoren berücksichtigen - das gibt ggf. auch noch ein paar Überraschungen, wenn die Motoren relativ schwer und überdimensioniert (mit hoher Übersetzung) sind. Eine Frage ist auch für wie enge Kurven der Bot ausgelegt ist: je enger die Kurven, desto kleiner sollte der Bot im Idealfall sein - einer großer ist dann nur damit beschäftige das Fahrzeug quasi auf der Stelle zu Drehen, und das geht prinzipiell mit dem kleinen schneller. Die Vorgeschlagenen Motoren / Akkus sind da schon mehr was für eine große Bahn, ohne enge Kurven.

In Grenzen wäre ein verschiebbares Gewicht ggf. sinnvoll, aber eher von vorne nach hinten, damit die Kraft auf das nicht angetriebene Stützrad kleiner wird. Das ist aber eher ein experimenteller Schritt, wenn man wirklich ans Limit gehen will - mehr Einfluss hat da eher die Wahl die Reifen (Gummi-mischung).

Wenn der Motor für 5-15 V ist, wäre eine Spannung von z.B. 12-16 V (also etwa 10 Zellen NiMH oder 4 Zellen LiIon) OK. Da das Limit der Motoren eher nicht braucht, geht ggf. auch noch etwas weniger. Bei einigen alten Motortreiben (z.B: L293) verliert man auch noch da etwa 2-3 V, um die sie Spannung höher sein kann bzw. sollte.

Ein weiterer relativ schneller Line Follower - allerdings in klein, und nicht ganz neu:
http://elm-chan.org/works/ltc/report.html

[Manf]

Für schnelle Kurven gibt es hier eine prinzipielle Lösung:

("outside the box" und schon etwas "over-sophisticated")

UC Berkeley's Little Legged Robots Grow Wings and Tails​





hier vorgestellt:
https://www.roboternetz.de/community...Ieee-icra-2013