Liste der Anhänge anzeigen (Anzahl: 1)
Asuro: Linienfolger mit PD-Regler
Hallo!
Ich will den Linienfolger meines Asuros etwas aufpäppeln. Die 1. Version funktioniert zwar, ist aber nur mit einem einfachen P-Regler ausgeführt. Ich fragte mich, ob es nicht mit einem anderen Reglertyp (PI, PD, PID) besser gehen könnte. Dazu musste ich mich etwas in die Thematik einarbeiten. Ich habe zwar genügend Erfahrung mit Regelschleifen in der Elektronik, aber ein gemischtes System mit Mechanik und digital war auch für mich Neuland. Aus den vielen Nachfragen hier im Board, wie man eine klassische Regelung realisiert die über einen normalen P-Regler hinaus geht, weiss ich um den Wissensbedarf und habe mich entschlossen meine Erkenntnisse hier weiter zu geben. Das Projekt ist zwar noch nicht fertig, ich lege aber trotzdem schon mal los, weil ich sonst vielleicht einige Details wieder vergesse. Ausserdem können von Euch noch Anregungen kommen, die das Projekt in eine andere Richtung bringen. Ich habe zwar im Titel schon den PD-Regler vorweggenommen weil sich der nach einer 1. Analyse als sinnvoll herausstellte. Aber das heisst jetzt nicht, dass damit der PD-Regler schon als beste Lösung zementiert ist. Es kann sich durchaus im Laufe des Projekts ein anderer Reglertyp als bessere Lösung ergeben. Möglicherweise endet es sogar in einem Fuzzy-Regler. Wir werden sehen.
Wer jetzt in Kürze schon einen funktionierenden Code erwartet, den muss ich enttäuschen, das wird noch eine Weile dauern. Zuerst muss einmal der Iststand aufgenommen werden, danach folgt dann die Analyse, Optimierung und Umsetzung. Für manche wird es zu sehr ins Detail gehen, für andere aber zu wenig. Bei der grossen Bandbreite an Lesern hier im Forum ist es wohl schwierig den Bedarf jedes Einzelnen genau zu treffen. Man möge mir das nachsehen, Wissensbegierige können ja nachfragen.
Das Ziel ist klar: Die Regelung soll so optimiert werden, dass sie möglichst schnell und trotzdem stabil ist.
Die Vorgehensweise:
1. Analyse der Regelstrecke und Modellierung
2. Auswahl des Reglertyps
3. Simulation und Optimierung des Reglerentwurfs
4. Parametrierung des Reglers und Umsetzung in Code
5. Praxistest und Nachoptimierung
Los geht's mit der Analyse der Regelstrecke!
Die Regelstrecke enthält den Liniensensor, PWM-Steller, Motor und Getriebe. Der Liniensensor reagiert auf Abweichungen von der Linie, also auf Streckenänderungen. Damit ist schon einmal klar, dass es sich hierbei um eine Positionsregelung handelt. Das macht es für mich auch etwas leichter, da die Positionsregelung in der Literatur bereits vielfach abgehandelt wurde. Mit dem Motor lässt sich mittels PWM die Geschwindigkeit steuern. Es fehlt also noch ein Glied in der Kette um von Geschwindigkeit auf Wegstrecke zu kommen. Das ist der Integrator. Ein Integrator wird für die Modellierung gebraucht, weil die Wegstrecke das Integral der Geschwindigkeit über der Zeit ist. In der Mechanik gibt es noch mehr Beispiele mit Integralverhalten, wie z.B.:
Schub -> Beschleunigung -> Geschwindigkeit -> Weg
Als nächstes betrachten wir das Zeitverhalten der einzelnen Elemente. Der Liniensensor wird mit einem AD-Wandler ausgelesen. Das dauert etwas. Dafür müssen wir eine Verzögerung berücksichtigen. Weil dabei die Amplitude unverfälscht bleibt, ist es ein Verzögerungsglied 0. Ordnung. Der Einfachheit halber packen wir auch gleich die Rechenzeit des Prozessors da mit hinein. Es gibt auch Verzögerungsglieder höherer Ordnung, das werden wir gleich am Beispiel des Motors sehen. Ein Motor lässt sich nicht in beliebig kurzer Zeit beschleunigen, denn die Masse des Rotors hat eine Trägheit. Die physikalische Grösse dafür ist das Trägheitsmoment. Wenn man eine Spannung an einen Motor anlegt, dann beschleunigt der in einer e-Funktion, das ist wie bei einem RC-Glied, also wie ein Verzögerungsglied 1.Ordnung (PT1). Da das Trägheitsmoment bei Rotationsbewegungen äquivalent ist zur Masse bei geradliniger Bewegung kann man die Masse des Asuros auch gleich damit hinein packen. Damit hätten wir alle Elemente der Regelstrecke charakterisiert und können ein Modell der gesamten Regelschleife zeichnen (siehe Bild).
Im Blockschaltbild ist der Regler noch eine Blackbox, den wollen wir ja herausfinden. Der nächste Block ist das Verzögerungsglied PT1, das stellt den Motor mit seinem Trägheitsmoment incl. Getriebe und Masse des Asuros dar. Die Schnittstelle zwischen PT1 und dem Integrator ist die Geschwindigkeit "v". Der Integrator errechnet daraus die Wegstrecke. Im Rückwärtszweig ist das Verzögerungsglied "delay", welches den Liniensensor und die AD-Wandlung modelliert. Danach steht der Istwert zur Verfügung. Der Istwert wird mit dem Sollwert verglichen (Subtraktion) und auf den Regler gegeben. Damit ist die Regelschleife geschlossen. Der Sollwert ist in unserem Fall 0, weil der Asuro möglichst ohne Abweichung der Linie folgen soll.
Das reicht vorerst, ist genügend Stoff zum Verdauen. Eine Fortsetzung folgt, da werden dann die Kennwerte der einzelnen Blöcke (Liniensensor, Motor usw.) ermittelt.
Gruss Waste
Liste der Anhänge anzeigen (Anzahl: 1)
Jetzt mit ZIP?
Ich versuche es nochmal mit der ZIP-Datei.
So steigere ich wenigstens die Anzahl meiner Einträge ;-)
Im übrigen fehlte folgendes:
Schöne Grüße von Sternthaler
Liste der Anhänge anzeigen (Anzahl: 1)
Hi!
Hab mich auch mal daran versucht einen PID-Regler in die von mir programmierte RoboterSimulation einzubauen, was aber irgendwie noch nicht richtig funktioniert.
Vielleicht hat ja jemand Ahnung von Delphi oder es hilft sonst irgend jemandem.
Beantworte gerne Fragen zum Programm!
Grüße; ähM_Key
Liste der Anhänge anzeigen (Anzahl: 3)
Hier kommt die Fortsetzung des eigentlichen Themas:
Ermittlung der Kennwerte für Liniensensor und Motor
Von früheren Projekten her weiss ich, dass der Liniensensor stark vom Umgebungslicht abhängig ist. Zum einen wird das Ergebnis verfälscht wenn Umgebungslicht von der Seite kommt, zum anderen wird die Steilheit der Kennlinie des Liniensensor verändert, was einer Verstärkungsänderung entspricht. Die Änderung der Verstärkung war je nach Umgebungslicht bis zu Faktor 5. Aus Erfahrung weiss ich, das ist zu viel um eine Regelschleife optimal auslegen zu können. Glücklicherweise hatte ich für das Problem schon eine Softwarelösung parat. Das Umgebungslicht wird dabei durch eine Messung bei ausgeschalteter FrontLED kompensiert. Wie es geht, ist hier nachzulesen:
https://www.roboternetz.de/phpBB2/ze...hlight=#104377
Damit bleibt die Steigung der Kennlinie auch bei Umgebungslicht einigermassen konstant. Die Kennlinie des Liniensensors ist als Bild angehängt, siehe Liniensensor.gif. Die Kennlinie wurde aufgenommen, indem ich einen Papierstreifen mit einer kurzen Linie seitlich unter dem Liniensensor durchzog. In Schritten von 1mm wurden die Werte ausgelesen. Als Steigung kann ich etwa 14 pro 1mm ablesen, damit ist das Übertragungsmass des Liniensensors 14/mm. Als Verzögerungszeit durch die AD-Wandlung habe ich etwa 1.6ms gemessen.
Nun kommen wir zur Ermittlung der Kennwerte des PT1-Glieds. Am einfachsten ist es eine Beschleunigungsmessung durchzuführen und aus der aufgenommenen Kurve die Zeitkonstante abzulesen. Das habe ich auch gemacht, hier die Kurve:
Bild hier
Die Messwerte wurden mittels Odometrie vom Asuro selbst aufgenommen und gespeichert und nach der Messfahrt auf den PC ausgelesen. Die ermittelte Zeitkonstante ist ca. 130ms, die Höchstgeschwindigkeit ca. 0.51m/s. Damit ist das Übertragungsmass des PT1-Blocks, das Verhältnis von Geschwindigkeit zu PWM-Einstellung = 0.51/255 = 0.002 m/s. Eigentlich hat man jetzt alle Angaben um mit der Simulation loslegen zu können. Ich wollte aber noch wissen, wie gross der Anteil des Trägheitsmoments des Motors ist. Dazu habe ich das Trägheitsmoment des Motors extra ermittelt. Viele werden sich jetzt denken, das kann ich mir sparen, das sind doch nur ein paar Gramm. Schon, aber die paar Gramm müssen auf eine hohe Drehzahl (über 7000 UPM) beschleunigt werden und das macht sich bemerkbar. Das Trägheitsmoment eines Motors ist 1.12gcm². Als äquivalente Masse auf das Fahrzeug umgerechnet sind das 190 Gramm. Beide Motoren haben dann eine äquivalente Masse von 380 Gramm, das ist wesentlich mehr als die Masse (Gewicht) des Asuro selbst. Mein Asuro wiegt mit den grösseren Akkus 240 Gramm. Wie man sieht, darf man das Trägheitsmoment der Motoren auf keinen Fall vernachlässigen, auch nicht bei so kleinen Motoren.
Da ich aus früheren Simulationen bereits ein Ersatzschaltbild für einen Motor hatte, habe ich den PT1-Block noch weiter zerlegt und mit dem Ersatzschaltbild des Motors versehen. Das Bild PT1_Block.gif zeigt die Schaltung. Der Motor ist aufgeteilt in einen elektrischen und mechanischen Teil. Im el. Teil sind der Ankerwiderstand Ra1, die Ankerinduktivität La1 und die Spannungsquelle B1, die die Gegen-EMK simuliert. Der mechanische Teil besteht aus der Stromquelle B2, I1 und Cm1. B2 simuliert das Drehmoment. In meinem Fall habe ich den Antrieb mit der Übersetzung gleich mit rein gerechnet, damit entspricht in dem mech. Teil:
- der Strom in Ampere jetzt der Kraft in Newton,
- ein Kondensator in Farad jetzt einer Masse in kg und
- die Spannung in Volt jetzt einer Geschwindigkeit in m/s.
In der Schaltung entspricht B2 der Kraft des Motors, I1 der Reibung und Cm1 der Masse des Asuros. Der Widerstand R1 simuliert geschwindigkeitsabhängige Verluste. Die Schaltung simuliert nur einen Motor mit einer Hälfte des Asuro, deshalb ist die Masse auch nur (380g + 240g)/2 = 310g, damit die Dynamik wieder stimmt.
Simuliert wird es mit LTSpice, das ist ein FreeWare Schaltungssimulationtool. Es wurde hier im Forum schon mal vorgestellt, bei Interesse einfach danach suchen.
Nun überprüfen wir ob das Modell der Wirklichkeit entspricht und simulieren eine Beschleunigung aus dem Stand. Dazu geben wir einen Spannungssprung von 0V auf 5V auf den Motor. Das Ergebnis ist in Bild Motor_Sim1.gif zu sehen. Es stimmt ziemlich genau mit der wirklich gemessenen Beschleunigung überein. Kleine Abweichungen sind unwesentlich für die Regelschleifenoptimierung.
Fortsetzung folgt
Waste
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
Was anderes ist es mit der Beschleunigung um die Drehachse, das ist noch ein offener Punkt, der kommt sowieso in Kürze dran. Bin um jede Hilfe dankbar. Hier die offene Frage: Wie verändert sich die Trägheit bzw. die Zeitkonstante des PT1-Blocks wenn anstatt einer geradlinigen Beschleunigung jetzt um die Drehachse beschleunigt wird und zwar:
1. Drehachse mittig zwischen den Rädern
2. Drehachse um ein Rad
Ich schaue mal nach:
Der ASURO Pendelt mit einer Periodendauer von 18sec an dem 40cm langen 0,2mm Stahldraht, waagerecht um den Mittelpunkt seiner Radachsen, ein Stück Stahldraht (Drahtkleiderbügel) mit 47cm Länge 13,4g waagerecht in der Mitte aufgehängt hat eine Periodendauer von 20sec.
Manfred
Liste der Anhänge anzeigen (Anzahl: 3)
@Manf
Danke dir für die Berechnung. Wusste gar nicht, dass das schon mal eine Kopfnussaufgabe war und ausgerechnet mit dem Asuro.
Inzwischen habe ich die Beschleunigungen beim Drehen und um ein Rad nachgemessen. Die Messungen sind angehängt. Zum Vergleich habe ich auch noch die Beschleunigung normal nach vorne nachgemessen, weil die alten Messungen nicht mehr vergleichbar sind. Nach einem Sturz zieht mein Asuro etwas nach rechts, die Höchstgeschwindigkeit wie früher wird nicht mehr erreicht.
Beim Vergleich mit der Rechnung dürfen wir nicht vergessen, dass mein Asuro schwerer ist, er wiegt 240g.
Waste
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo zusammen,
stochri hat die Idee zum erkennen von Barcodes aufgeführt. Das gleiche hatte ich auch schon als Gedanke, um bei der Linienfolgung einen Barcode seitlich zu platzieren um damit eine 'gleich' kommende Abzweigung anzukündigen. Somit könnte der Asuro dann über einen Barcode die Info bekommen, dass die kommende Y-förmige 'Störung' in der Linie bewusst nach links oder eben rechts zu korrigieren ist. Damit kann man dann Linien 'verlegen', die einer Modelleisenbahn mit Weichen, Abstellgleisen, und Sonstigem ähneln kann. Wenn man zu den Barcodes für Weichen, noch welche für Wartestellen, kreuzende Linien, Geschwindigkeitsangaben und eventuell Sackgassen definiert, kann man bestimmt so einige interessante Fahrten beobachten. Zum verlassen der Sackgassen muss man sich dann aber wirklich an Manf's Idee zum rückwärtsfahren machen.
@waste
ich hoffe, dass dein Asuro nicht wegen meines 'rechtsdrall's' vom Tisch fuhr.
Hier kommt jetzt auch endlich der Link bei dem ich meinen PID abgekupfert habe.
http://www.tu-harburg.de/~kt1pg/digital.html PID-Regler
http://www.tu-harburg.de/~kt1pg Homepage von Peter Gerulat
So, jetzt muss ich erst einmal euere Schreibwut als Input verarbeiten.
Zur Ansicht meine 'Eisenbahnlinie' bisher ohne Weichen. (Fliesenkantenlänge 30cm)
P.S.: Ich finde die Leistung von waste zum Thema echt klasse.
Schöne Grüße von Sternthaler
Liste der Anhänge anzeigen (Anzahl: 1)
Hi!
Habe RoboSim jetzt mal umgeschrieben.
Dass das an der einen Stelle nicht linear regelt habe ich noch nicht behoben, aber der Rest müsste laufen.
Das meiste kann man in der RoboSim.ini einstellen
Code:
[Konstanten]
vmax=1 -> Maximalgeschwindigkeit; zur manuellen Steuerung (Curser in weißes Feld, dann über Pfeiltasten) höhere Werte (z.B. 3) sinnvoll
pause=1 -> Pause in ms, zum beobachten z.B: auf 100 setzen
robox=175 -> Startwerte Robo
roboy=386
roboalpha=45
radstand=100 -> Dimensionierung
radradiuslr=15
radbreitelr=10
achsdicke=7
abstand=50
radradiusm=15
radbreitem=7
nachlauf=10
sensorx=75 -> Abstand Sensoren von Achse
sensorymitte=10 -> Abstand der zwei mittleren Sensoren (alle außenliegend)
sensoranzahl=8
sensoryabstand=6 -> Abstand zw. allen anderen Sensoren
vdiff=0,1 -> wird nicht mehr benötigt
kp=5 -> PID (alles /100, also kp=5 entspricht 0,05)
ki=0
kd=0
tast=100
reg=100 (verzögerte Reaktion)
Und der angepasste Quelltext
Code:
procedure TForm1.followtrack; /////////////////////////////////Spurverfolgung
var
m: integer;
sensor1, sensor2, sensor, regel, yp, yi, yd: real;
begin
sensor1:=0;
sensor2:=0;
for m:=1 to sensoranzahl do begin
if chk(m) and (sensor1=0) then begin
if m<=sensoranzahl/2 then sensor1:=-sensoranzahl/2-1+m
else sensor1:=m-sensoranzahl/2;
if m<>sensoranzahl then begin
if chk(m+1) then begin
if m+1<=sensoranzahl/2 then sensor2:=-sensoranzahl/2+m
else sensor2:=m+1-sensoranzahl/2;
end;
end;
end;
end;
if sensor2<>0 then sensor:=(sensor1+sensor2)/2 else sensor:=sensor1;
sensor:=sensor/(sensoranzahl/2);
yp:=(kp/100)*sensor;
yi:=yialt+(ki/100)*(tast/100)*sensor;
yd:=(kd/100)*(sensor-sensoralt)/(tast/100);
yialt:=yi;
sensoralt:=sensor;
regel:=yp+yi+yd;
button6.caption:=floattostr(regel);
vralt:=vr;
vlalt:=vl;
regel:=(reg/100)*regel;
if regel<0 then begin
vr:=vralt+abs(regel);
if vr>=vmax then begin
vr:=vmax;
vl:=vlalt-abs(regel);
if vl<0 then vl:=0;
end;
end;
if regel>0 then begin
vl:=vlalt+abs(regel);
if vl>=vmax then begin
vl:=vmax;
vr:=vralt-abs(regel);
if vr<0 then vr:=0;
end;
end;
end;
(Button6 ist nur zum debuggen mit drin)
Wenn man in der Oberfläche z.B. den Haken bei Umrisse und Löschen rausnimmt, kann man sehr schöne Ergebnisse erzielen.
Zum Ändern der PID-Werte in INI ändern, speichern, in Robosim auf Zurücksetzen klicken!
Unter Testreihe kann man eine, wen wunderts, Testreihe mit versch. Werten ausprobieren (gestoppt wird eine Runde). Das Ergebniss wird dann in der logfile.txt gespeichert und kann z.B. in Excel importiert und nach Bestzeiten geordnet werden. Um das zu beschleunigen am besten die ganzen Haken bei Umrisse, Sensoren, Löschen, Hintergrund usw. rausnehmen!
Noch Fragen/Verbesserungsvorschläge?
Grüße, ähM_Key
Bild hier
Liste der Anhänge anzeigen (Anzahl: 1)
Hier meine Überlegungen zu dem weiteren Integrator:
Wenn man zur Veranschaulichung die Methode von Manfred hernimmt und den Sensor auf den Drehpunkt zurück schiebt, dann wird klar, dass noch ein zusätzlicher Integrator in das Modell der Strecke muss, denn bei einem Fehlerwinkel zur Linie wird mit zunehmender Grundgeschwindigkeit und Zeit der Fehler immer grösser. Siehe auch Bild strecke.gif
Erklärung des Blockschaltbilds:
Zusätzlich muss jetzt noch die Grundgeschwindigkeit betrachtet werden, sie wird mit V1 simuliert. Die Differenzgeschwindigkeit zu v geht wie gehabt auf den 1. Integrator und erzeugt über die Hebelwirkung (weil der Sensor weiter vorne befestigt ist als der Kreisbogen der Räder) die Abweichung s1. Das entsprach im alten Modell "Weg". Jetzt wird die Abweichung s1 mit V1 multipliziert und auf den 2. Integrator gegeben, um den oben beschriebenen Effekt zu simulieren. Eigentlich müsste man die sinus-Funktion bei der Multiplikation verwenden, aber für kleine Winkel kann man das vernachlässigen. Am Ausgang werden beide Effekte zusammengeführt und addiert.
Ich hoffe es ist so richtig. Ich werde es noch bezüglich Sprungantwort und Analyse im Frequenzbereich untersuchen. Mal sehen, ob es auch da plausibel ist.
Bis später!
Waste
Liste der Anhänge anzeigen (Anzahl: 2)
Ok, ich werde versuchen es kompakter zu machen. Wenn irgendwas fehlt zum Verständnis, einfach nachfragen, oder gibt es etwa gar keine Leser mehr die Fragen stellen könnten.
Jetzt zur Analyse des zusätzlichen Integrators:
Ich habe die Strecke von "v" bis "s3" sowohl im Zeitbereich als auch im Frequenzbereich analysiert. Zum Test habe ich den Abschnitt für 1 Sekunde mit einer Differenzfrequenz von 0.1m/s beaufschlagt. Die Grundgeschwindigkeit ist 0.4m/s. In Bild "S-Test.gif" ist das Ausgangssignal an s1, s2 und s3 zu sehen. Bei der linken Skala entspricht 1mV = 1mm. Ich habe einen grossen Zeitmassstab gewählt damit man überhaupt einen Unterschied zw. s1 und s3 sieht. Die Ergebnisse sind plausibel, allerdings ist in dem Arbeitsbereich des Sensors, also bis 15 mm kaum ein Unterschied von s1 und s3 zu sehen. Ähnlich ist es im Frequenzbereich, siehe Bodediagramm "S-Test_Bode.gif". Da ist erst ein Unterschied unter 0.1Hz zu sehen. Das heisst, der zusätzliche Integrator ist nicht relevant für die Optimierung der Regelung, den kann ich mir im Modell sparen. Hat auch was für sich, ist weniger Arbeit und ausserdem weniger anspruchsvoll.
So, jetzt muss ich mich auch wieder erholen. :)
In den nächsten Beiträgen geht es dann ans Eingemachte.
Gruss Waste
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo,
zum besseren Verständnis hab ich das Motormodell aus den gegebenen Daten selbst mal erstellt. Das Rotationsträgheitsmoment habe ich einfach weggelassen. Macht die ganze Sachen natürlich wesentlich einfacher. Ich poste jetzt einfach mal mein Schmierblatt, sonst müsste ich das Ganze ja noch mal abmalen.
Was für die weitere Modelierung fehlt, ist die Übertragungsfunktion der Liniensensoren, war die nicht schon mal irgendwo geposted ?
Gruss,
stochri
Liste der Anhänge anzeigen (Anzahl: 1)
Ähm,
ich glaube der Begrenzerblock muss an anderer Stelle positioniert werden.
Das Modell hat folgende Eigenschaften:
1. Trägheitsmoment nicht berücksichtigt
2. Unterschiedliche Zeitkonstanten für Beschleunigung/Abbremsen nicht berücksichtigt
3. Nichtlinearität der PWM/Geschwindigkeits Kennlinie unterhalb des Haftreibungspunktes ( v<0.1m/s oder PWM~<100 )nicht berücksichtigt
4. Zeitkonstante 130ms vom schweren 240g Mignonzellen-ASURO verwendet
