Searcher

Hallo Searcher, es gefällt mir ganz gut, wie dein Vehikel fährt. Ein super Video! =D>

Ohne jetzt die Regelstruktur zu kennen ist es schwierig einen Tipp zu Verbesserung zu geben. Nur so auf Verdacht vielleicht mal etwas zum Ausprobieren.
Wenn im normalen Linienbetrieb der Regler einen Regelanteil zu den beiden Winkelgeschwindigkeiten der Antriebsräder addiert/subtrahiert, dreht sich das Fahrzeug in Bezug zu der Linie. D.h. die Regelabweichung wächst kontinuierlich, wenn man die Richtung als Regelgröße annimmt. Das ist ein I-Verhalten der Regelstrecke. Das Schlingern ließe sich mit einem D-Anteil vielleicht etwas minimieren. Würde dann in der Praxis bedeuten - und das ist mein Tipp zum Ausprobieren - Gegensteuern proportional zu Änderung des Sensorwertes.

Hallo witkatz,

vielen Dank. Auch zu Deinen Ideen. Bin schon am überlegen, wie ich den Steueralgorithmus abändern kann. Unvorsichtigerweise hast Du geäußert, daß Du die Regelstruktur nicht kennst. Was nun folgt ist mir etwas aus dem Ruder gelaufen und sollte nicht so lang werden. Also:

Die Lenkung beruht zur Zeit auf einer möglichst schnellen Abtastung der Linie und daraufhin möglichst schneller Ansteuerung der Motore, damit der SLF (Stepping Line Follower) gar nicht anders kann als der Linie zu folgen.

Es steht eigentlich eine genaue Untersuchung über den Verlauf der Werte aus, die der ADC über die Breite der Linie eigentlich liefert. Es haben die Ausleuchtung der Linie, Abstand der Photodioden voneinander und von der Linie und natürlich der Kontrast Linie - Hintergrund Einfluß. Vorteil scheint mir ein einfacher Aufbau, wenig Einfluß von Fremdlicht durch differentielle Auswertung, Relativ unempfindlich gegenüber verschiedener Linienbreiten. Wohl weniger geeignet für Regelschleifenanwendung. Damit habe ich mich aber noch nicht ernsthaft beschäftigt. Es gibt also keine P, I, D oder sonstige Regelung des Vehikels. Nachfolgend mal Beschreibung des Programms und wie SLF gesteuert wird. Möglicherweise gibt es noch Bugs in der Realisierung.

Im Augenblick funktioniert der Normallinienmodus also so:

1. Die Werte der differentiellen Messung des ADCs werden in eine Zahl von 0 bis 126 ohne die Proportionen der eigentlichen Messung zu verändern umgeformt. Sie dienen zusammen mit der Grundgeschwindigkeit, die über die Fernbedienung eingegeben wird, als Eingabe für der Erzeugung der Schrittfrequenz für die Schrittmotore.

Der Wert 63 ist die Neutralstellung und bedeutet, daß sich das Vehikel mittig über der Linie befindet. Bei Übergabe an die Schrittmotorsteuerung soll der SLF damit geradeaus fahren. Liniensensorprogramm wie im vorletzten Blogeintrag mit Ausnahme der CNY Auswertung gepostet. Die ADC Werte werden vor der Übergabe nur etwas geglättet. Und zwar wird jede neue Messung in einem Array mit 8 Elementen abgespeichert. Die älteste Messung wird überschrieben und die verbleibenden acht Werte addiert und 3 mal nach rechts geschoben, also durch 8 geteilt. Das unterdrückt sporadisch auftretendes Zittern vom SLF. Wird der Mittelwert über 16 oder 32 Werte gebildet, kann man schon ein trägeres Lenkverhalten beobachten.

2. Die Ansteuerung für die Schrittmotore erfolgt folgendermaßen:
a. Grundgeschwindigkeit von der Fernbedienung vorgegeben. Es gibt Werte von 0 bis 126(127). Als Beispiel mal Wert 60 hergenommen und im Folgenden GStufe genannt.
Das Vehikel bewegt sich ohne Einlenkung dann mit ca. 25cm/s geradeaus.

Berechnung:
16Bit Timer1 des Mega88 läuft mit 1Mhz.
Schrittmotore haben pro Vollschritt 18° Drehwinkel und laufen im Halbschritt (40 Halbschritte für eine Motorwellenumdrehung)
Getriebeübersetzung = 15:1, Raddurchmesser ist ca. 4cm entspricht etwa 12,6cm Umfang.

Code:

50000/GStufe = 50000 / 60 = 833,333 auf 833 abgerundet und als Vergleichswert zur Erzeugung eines Halbschritts im Timer1 benutzt.
833 Timer1 Ticks entsprechen einem Halbschritt pro 833 * 1/1000000Hz = 0,000833s
In einer Sekunde gibt es dann 1 / 0,000833s = 1200,48 Halbschritte
1200,48Hz / 40 = 30,01 rps (revolutions per second wg. 40 Halbschritte für eine Umdrehung)
30,01rps / 15 = 2rps (Getriebeübersetzung eingerechnet gibt es 2 Radumdrehungen pro Sekunde)
2rps * 12,6cm = 25,2cm/s (Radumfang eingerechnet ergibt das die Geschwindigkeit)

Diese Geschwindigkeit ist auch die Maximalgeschwindigkeit, auf die ein kurvenäußeres Rad eingestellt wird und immer versuchen wird zu erreichen. Beim Einlenken von einer Geraden in eine Kurve wird das kurveninnere Rad verlangsamt - das kurvenäußere Rad bleibt bei seiner Maximalgeschwindigkeit. Wird eine direkte Folge von engegengesetzten Kurven abgefahren, wird gleichzeitig beide Räder in der Geschwindigkeit verändert. Das kurvenäußere Rad mit der Maximalgeschwindigkeit wird verlangsamt und das langsamere Rad auf Maximalgeschwindigkeit beschleunigt.

Die Dauer der Beschleunigung (und Verlangsamung = negative Beschleunigung) wird durch eine Rampe bestimmt und ist auf ein GStufe alle 4,8ms eingestellt. Ist die gegenwärtige Geschwindigkeit GStufe=50 und soll auf 60 beschleunigt werden, dauert es 4,8ms * (60-50) = 48ms bis die GStufe 60 erreicht ist. Falls eingelenkt werden muß und neben der Beschleunigung des einen Rades von 50 auf 60 gleichzeitig das andere Rad um 20 gebremst werden muß, dauert das 4,8ms * 20 = 96ms (Ich bin mir nicht im Klaren, ob sich die ungleiche Dauer der Beschleunigungszeiten von 48ms und 96ms sehr negativ auf das Fahrverhalten auswirken kann?) Falls während der Beschleunigung, also innerhalb der Rampe und vor vor Erreichen der Endgeschwindigkeit, neue Endgeschwindigkeiten gefordert werden, wird die neue Endgeschwindigkeit innerhalb der Rampe sofort wieder mit einer GStufe alle 4,8ms pro Rad zu erreichen versucht.

b. Einlenken. Bisher gab es eine Einstellung von der FB für die Geschwindigkeit, hier als Beispiel 60.
Von dem Liniensensor kommt als Einlenkgröße ein Wert von 0 bis 126 zur Schrittmotorsteuerung. Davon wird erstmal 63 subtrahiert und ergibt Werte von (-63) über 0 bis (+63). 0 für geradeaus und die negativen bzw. positiven Werte für Stärke der Lenkeinschläge nach links bzw. rechts.

Dieser Wert wird mit einem experimentell bestimmten Wert multipliziert. Im Normallinienmodus ist die Konstante 0,022 (Leider eine Fließkommazahl - Single in BASCOM). Sie ist praktisch das Übersetzungsverhältnis des Lenkgetriebes. Je größer die Konstante, desto kräftiger reagiert das Vehikel auf die Einlenkwerte vom Liniensensor. Mal angenommen vom Liniensensor kommt eine 30.

30 - 63 = (-33)
(-33) * 0,022 = (-0,726)
(-0,726) ist negativ, also Vehikel soll nach links lenken.

c. Die vorher eingestellte Geschwindigkeit war 60 und beide Motore drehen also mit dieser GStufe. Nun wird einfach von der GStufe des linken Motors das Produkt von 0,726 und der GStufe subtrahiert. 60 - (0,726 * 60) = 16,44. 16,44 ist also die GStufe der neuen Endgeschwindigkeit des linken Motors nach Ablauf der Bremsvorgangs in der Rampe. Der rechte Motor bleibt auf GStufe 60.

Code:

Gstufe 60 entsprach einer Geschwindigkeit des Vehikels von 25cm/s.
GStufe 16,44 entspricht
50000/GStufe = 50000 / 16,44 = 3041,36 abgerundet = 3041. (Vergleichswert für Timer1)
3041 * 1/1000000Hz = 0,003041s (pro Halbschritt)
1 / 0,003041s = 328,83Hz (Halbschritte pro Sekunde)
328,83Hz / 40 = 8,22rps (Motorwellenumdrehungen pro Sekunde)
8,22rps / 15 * 12,6cm = 6,9cm/s

Die linke Seite des Vehikels fährt also langsamer als die rechte Seite und wird wegen der starren Verbindung der beiden Seiten in eine Kurve gezwungen

Grobe Rechnung im Dreisatz wegen linearer Abhängigkeit aber ohne Rundung auf Ganzzahlen für Timer1 Vergleichswerte:
GStufe 60 entspricht 25,2cm/s
Gstufe 1 entspricht 25,2cm/s / 60 = 0,42cm/s
Gstufe 16,44 entspricht 16,44 * (25,2cm/s / 60) = 6,9cm/s


Ich hatte auch andere Lenkalgorithmen, nicht Steuer- oder Regelalgorithmen versucht, jedoch wieder verworfen. Sie hatten einen größeren Code und damit auch mehr Rechenzeit verursacht. Da ich immer noch die BASCOM Demoversion benutze, bin ich da begrenzt und die Rechenzeit darf auch nicht ins Unendliche wachsen, da ich bei einigen Versuchen meine schon an Timingprobleme in der Zusammenarbeit mit Hauptschleife - Rampe - Stepperinterrupts war. Steht außerdem der schnellen Datenanforderung vom Liniensensor-µC und deren Verarbeitung entgegen.

Im ATTiny für den Liniensensor ist jedoch noch einiges frei für das Aufbereiten der Lenksignale. Da könnte ich Deinem Vorschlag folgen und an dem Verhältnis von ADC-Messung und Lenkwerten drehen.

Hoffe es gibt Dir eine Vorstellung von der Funktion. Ist im Grunde sehr simpel und der Teufel steckt NUR im Detail. Keine Ahnung wie oft ich geflasht habe, bis offensichtliche Bugs beseitigt waren und das Ding so läuft wie es im Video zu sehen ist. Bin gerade dabei den Liniensensor, also den Kabelverhau vorne auf einer Platine zu zivilisieren. Grundplatte, das, wo der Batterietrog draufsteht und die Elektronik und Antriebsblock dranhängt, ist schon erneuert. Die war bei einem unfreiwilligen Sturz vom Tisch angebrochen. Zum Glück keine sonstigen Schäden.

Außerdem überlege ich das Poti für die Lenkung auf der Fernbedienung durch einen Drehencoder zu ersetzen. Das Poti gibt absolute Werte aus und wenn man den Linienmodus des SLF abschaltet, also wieder zur Fernbedienung zurückkehrt, macht sich das manchmal durch abrupte Lenkbewegungen bemerkbar. Das Poti steht eben manchmal ganz anders als der momentane Lenkeinschlag aus der Linien(ver?folgung. (Verfolgung manchmal, wenn die geringe Bodenfreiheit die losen, auf dem Boden liegenden Papplinien mal wieder vor sich her schiebt) Es gibt echt noch viel zu tun ...

Gruß
Searcher

Hallo Searcher,

dynamische Regelalgorithmen wie PD oder PID würden einen deterministischen Zeittakt voraussetzen. Mein Roboter rechnet z.B. alle 4ms den PID Linienrregler. Hab leider k.A., wie so eine Task in Bascom zu realisieren wäre, deshalb sorry - vergiss wieder meinen "Verbesserungsvorschlag"

Für mehr Performance könnte es sich vielleicht lohnen bei Berechnungen möglichst in 16bit Arithmetik zu bleiben. Z.B. ((int16_t)Gst * (int16_t)Sensor) / 45 ist ugf das gleiche wie (single)Gst * (single)Sensor * 0,022, wird aber schneller gerechnet und wahrscheinlich reicht die Genauigkeit aus. Vielleicht kann das Compilat dadurch schrumpfen, wenn Bibliotheksfunktionen für Fließkommaoperationen nicht mitgelinkt werden (müssen).
Das ist jetzt von mir ohne Ahnung von BASCOM nur geraten.

An der Stelle noch mal vielen Dank für deine tollen Blogbeiträge. Ich wünsch dir weiterhin viel Spaß beim B&B (Basteln und Bloggen )

Gruß
witkatz