Archiv verlassen und diese Seite im Standarddesign anzeigen : 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
Uiuiuiuiuiiiii! Du meinst es ja echt ernst! Nicht schlecht! Freu mich schon auf eine Fortsetzung! Simuergebnisse wären auch echt interessant!
Simulationen kommen noch, aber alles zu seiner Zeit.
Aber wart's ab, wenn erst Differenzialgleichungen und Laplace-Transformation dran sind! :wink:
Keine Angst, darauf werde ich verzichten. Ich bin da selbst nicht sattelfest.
Gruss Waste
Sternthaler
18.08.2005, 00:41
Ups, ich hoffe ich greife jetzt nicht etwas vor.
Teil 1, 2 und 3 habe ich mir so 'gedacht' und hab deshalb schon mal bei Punkt 4 angefangen. Dabei habe ich gleich das 'volle' Programm von P, I und D genutzt und einen PID-Regleger zusammengestellt und in C-Code umgesetzt. Punkt 5 ist bei mir funktionsfähig. (mein Gedanke zur Optimierung ist jetzt, dass ich in Kurven noch die Geschwindigkeit runterregeln möchte. Weiterer PID-Regler in Sicht. Aber wer weiss, was eine Kurve ist, wenn man nur 2 Detektoren hat?)
In Datei gerade.c werden am Anfang Werte an die Variablen p1, p2, q0, q1 und q2 zugewiessen. Diese Werte habe ich mit Hilfe der im ZIP enthaltenen EXCEL-Datei ermittelt.
Der Reiter 'Tabelle1' ist dafür zuständig.
Der Reiter 'Tabelle2' kann die vom ASURO gesamelten Messwerte anzeigen. (Muster in PID.txt)
Um die 'richtigen' Parameter zu finden habe ich mein Gefühl auf Reiter 'Tabelle1' losgelassen. Die grün hinterlegten Felder musste ich 'mal hier und mal dort' ändern um eine halbwegs 'schöne' Kurve zu bekommen.
Dann habe ich die blauen Felder in gerade.c in die oben erwähnten Variablen (eigendlich Konstanten) übernommen.
P.S.: Die kleine Formel unter /* Berechnung der Reglerausgangsgroesse */ ist der PID-Regler. Hier kann ich nur auf eine Z-Faltung der Summe aus proportionalem, integralem und differentialem Anteil in der Literatur hinweisen. Jedenfalls hat das da so gestanden. (Quelle ist leider im internet verloren gegangen. bzw. ich habe mal wieder keinen Bookmark gesetzt. sorry)
Sternthaler
18.08.2005, 00:46
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
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
Das sind ja interessante Programme!
@Sternthaler
Könntest du bitte dein Excelprogramm etwas näher erklären. Was bedeuten die Parameter? Kp, Ki, Kd, Ta sind klar, aber was bedeuten die anderen? Was kann man aus dem Diagramm ersehen? Wie geht man z.B. vor, wenn man eine möglichst schnelle und stabile Regelung haben will?
Ich habe deinen PID-Linienfolger auf meinem Asuro kurz getestet. Kann es sein, dass der keine Rechtskurven mag oder bockt da wieder mal mein Asuro?
@ähM_Key
interessantes Programm, damit muss ich mich bei Gelegenheit noch näher befassen. Delphi kenn ich leider nicht, aber ansonsten will ich schon behilflich sein wo es geht, z.B. PID-Regler Theorie. Hast du eigentlich in dem Programm auch dynamische Prozesse berücksichtigt?
Gruss Waste
Hallo!
Nein dynamische Prozesse sind leider nicht drinn, was mir ehrlich gesagt aber auch noch zu kompliziert ist.
Das macht das gesammte Programm natürlich weniger tauglich, gerade, weil es sozusagen keine Ansprechzeit gibt.
Hier mal der interessante Teil des Quelltextes vom Regler
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;
yp:=(kp/100)*(sensor/(sensoranzahl/2));
yi:=yialt+(tast/100)/(ki/100)*sensor;
yd:=(kd/100)*(sensor-sensoralt)/(tast/100);
yialt:=yi;
sensoralt:=sensor;
regel:=yp+yi+yd;
button6.caption:=floattostr(regel);
if regel<0 then begin
vr:=vr+abs(regel);
if vr>=vmax then begin
vr:=vmax;
vl:=vl-abs(regel);
if vl<0 then vl:=0;
end;
end;
if regel>0 then begin
vl:=vl+abs(regel);
if vl>=vmax then begin
vl:=vmax;
vr:=vr-abs(regel);
if vr<0 then vr:=0;
end;
end;
end;
Der obere Teil berechnet nur, wo eine Linie unter den Sensoren liegt und im unteren werden die Motoren (L/R) angesteuert.
Vielleicht kannst du ja was damit anfangen, ansonsten muss ich's halt noch mal genauer beschreiben. ;)
Grüße; ähM_Key
Hallo ähM_Key,
schade, dass keine dynamischen Prozesse drin sind, das wäre wirklich interessant gewesen. Ist aber trotzdem ein schönes Tool.
Nun zu deinem Code:
Die Formeln für den Regler sind im Prinzip ok, nur:
ki wird normalerweise multipliziert, sollte aber trotzdem funktionieren, nur wirkt ki eben mit kleinerem Wert stärker
warum wird bei yp zusätzlich durch sensoranzahl/2 geteilt und sonst bei yi und yd nicht?
Für ein besseres Verständnis müsste ich noch wissen, welche Werte die Variable sensor annehmen kann bei typischen Abweichungen.
Und noch was:
Bei der Begrenzung bei vmax darfst du nur den Rest auf die andere Seite übertragen und nicht den vollen "regel"-Wert. Sonst ist es nicht linear. (Ausser es ist so gewollt)
Gruss Waste
warum wird bei yp zusätzlich durch sensoranzahl/2 geteilt und sonst bei yi und yd nicht?
Mein Fehler (dürfte an der Version liegen), natürlich sollte das entweder bei allen oder keinem sein.
Für ein besseres Verständnis müsste ich noch wissen, welche Werte die Variable sensor annehmen kann bei typischen Abweichungen.
Also sensor kann bei 8 Sensoren die Werte -4 bis +4 annehmen;' sensor/sensoranzahl/2' dementsprechend -1 bis +1.
Bei der Begrenzung bei vmax darfst du nur den Rest auf die andere Seite übertragen und nicht den vollen "regel"-Wert. Sonst ist es nicht linear. (Ausser es ist so gewollt)
Hmm, darüber habe ich mir noch gar keine Gedanken gemacht; werde ich bei Gelegenheit noch ergänzen!
Grüße; ähM_Key
Sind die Sensoren digital? Gibt es also nur ganze Zahlen -1, 0, +1, +2 usw.
Ja, die sind digital, aber wenn Sensor 1+2 anspricht, wird 1,5 ausgegen. (bzw. halt -3,5)
MK
ok, 0,5er Schritte, alles klar
Eigentlich sollte es funktionieren, die angesprochenen Änderungen sollten nicht wesentlich sein für eine prinzipielle Funktion
Kann ich selbst die Parameter in RoboSim einstellen?
Waste
Sternthaler
18.08.2005, 22:23
An waste und alle die es noch interessiert.
Hier ein Erklärungsversuch für die Parameter in der EXCEL-Datei (in linie-pid.zip):
Kp
Kopplungs- bzw. Verstärkungswert für die Proportional-Komponente
Ki
Kopplungs- bzw. Verstärkungswert für die Integral-Komponente
Kd
Kopplungs- bzw. Verstärkungswert für die Differential-Komponente
Ta [sec]
Zykluszeit zum messen der Sensoren, PID rechnen und regeln.
Ti [sec]
Im Verhältis zu Ta, im EXCEL also 50-fach, die Zeitspanne, in der die Reglung nach einer Abweichung den I-Anteil berücksichtigen soll.
Td [sec]
Im Verhältis zu Ta, im EXCEL also 10-fach, die Zeitspanne, für den P-Anteil
DIES SCHEINEN die Werte für eine SCHNELLE REGLUNG zu sein, nach der waste fragte. (Ta kurz halten und die Verhältnisse über Ti und Td abschätzen war meine Methode)
STABILE REGLERWERTE scheinen sich zu ergeben, wenn die EXECL-Kurve möglichst schnell gegen 0 geht. (Hier habe ich aber Grenzen gefunden, die bestimmt mit der Masse und der Trägheit der Motoren zu tun hat. Jetzt kommt bestimmt Punkt 1.Analyse der Regelstrecke und Modellierung aus wastes Ansatz zur Vorgehensweise zum tragen. Habe ich ja leider komplett vernachläßigt.)
Fehlersprung
Die Differenz der Sensoren, die in dem EXECL-Blatt die Tabelle (und die Grafik) erzeugen soll.
Der Wert 20 ist von mir dort so hinterlassen. Ich habe den Asuro auf meine Linie gesetzt und ein bisschen hin und her geschoben und habe für mich entschieden, daß eine Differenz von ca. 10 bis 40 schon eine Nachreglung vertragen kann.
Parameter q0, q1, q2
Die habe ich so als Formel, auf der ja leider verbummelten Internetseite, gefunden um sie als 'Konstanten' in der PID-Regler-Formel einzusetzen.
Reglergleichung
Hier muss man wissen, daß die e-Werte die Fehler sind. Die u-Werte sind die Reglerberechnungen, und k stellt den Zeitpunkt (Takt) dar.
Somit wären z.B.:
u(k-2) [im Programm u2] der Regleroutput vom VORLETZTEN Takt
e(k) [im Programm e0] der aktuelle Fehler (SensorLinks - SensorRechts)
e(k-1) [im Programm e1] der letzte Fehler
Damit erklären sich die Paremter p1 und p2. Sie stellen Faktoren da, mit denen die 2 letzten Reglerberechnungen in der aktuellen Reglerberechnung einfließen.
Allgemein zu den Formeln:
Sind alle 'Raubkopiert', und in dieser Form von mir nicht verstanden. (An pebisoft: v=m/s ist aber weiterhin gültig)
Allgemein zur Grafik auf Blatt 'Tabelle1':
Der erste Ausschlag entspricht dem Eingabewert 'Fehlersprung'.
Die restlichen Werte sind die 'theoretischen' Fehler, die in der Spalte e(k) berechnet werden, da u(k) ja schließlich als Korrekturwert in jedem weiteren Takt den Fehler beheben soll.
Allgemein zur Grafik auf Blatt 'Tabelle2':
Der ASURO sammelt im Source gerade.c MAXDATA Daten. Dies sind e0, u0 und die an MotorSpeed gegebenen Geschwindigkeiten.
Die Werte können aus dem ASURO mit einem druck auf den linken Kontaktsensor über die Schnittstelle gesendet werden.
Im EXCEL-Blatt kann man diese Werte einfügen (siehe auch Datei PID.txt) und man sieht somit in der oberen Grafik sowohl den Fehler (blaue Linie) als auch den IM ASURO berechneten PID-Wert (rote Linie).
Die untere Grafik zeigt sowohl für den linken (blaue Linie) als auch für den rechten (rote Linie) Motor die gesetzte MotorSpeed an.
Bei weiteren Fragen, werde ich wohl doch die 'verlorene' Seite im Netz wiederfinden müssen. Hier ist mein PID-Latein nämlich am Ende.
Fazit
Ich fand die Grafik in 'Tabelle1' sehr schön, und habe deshalb die Werte so im Programm eingetragen.
RIESENENTSCHULDIGUNG FÜR DIE RECHTSKURVEN:
Rechtskurven sind bestimmt bei vielen ein Problem.
Dies liegt an MEINEM Asuro, da er einen schlappen rechten Motor hat und ich dort immer mehr Gas gebe.
LÖSUNG:
In asurocp.h ist der define MOTORDIFF bei mit mit 50 belegt. (Rechts gibt es immer 50 Einheiten mehr Saft)
Hier müßt ihr einen Wert eintragen, der die Leistungsdifferenz eurer Asuro-Motoren ausgleicht. Der Wert darf auch negativ sein falls der linke Motor der Schwächling ist.
Schöne Grüße von Sternthaler
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/zeigebeitrag.php?p=104377&highlight=#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:
https://www.roboternetz.de/phpBB2/files/asuro2_158.gif
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
Das müsste eigentlich in der RoboSim.ini gehen!
Werd mir das morgen aber nochmal genauer ansehen, da es sein kann, dass da wieder was mit der Version nicht hinhaut.
gn8, ähM_Key
PS: Sehr schöner/professioneller Lösungsansatz; ich hoffe den ganzen Spass lerne ich auch noch im Studium.
PPS: Hab ich das richtig erkannt, dass der Asuro nur 2 Liniensensoren hat, die mit unmoduliertem Licht und Analogauswertung betrieben werden? Weil ich habe vor die (vorrausichtlich) 8 Sensoren, als Reflexkoppler CNY70 mit moduliertem IR-Licht und Schmitt-Trigger zu betreiben, um vom angesprochenem Fremdlicht so unabhängig wie möglich zu sein!
@Sternthaler
Danke für die Erklärungen zum Excelsheet, ich werd mich mal damit spielen, womöglich kommen noch weitere Fragen.
@ähM_Key
was studierst du? (Fachrichtung)
Hab ich das richtig erkannt, dass der Asuro nur 2 Liniensensoren hat, die mit unmoduliertem Licht und Analogauswertung betrieben werden?
Ja, genau so ist es.
Mit meiner Methode aus/ein, wird praktisch die Modulation nachempfunden, funktioniert ganz gut, nur etwas umständlich.
Ich seh schon, das wird ein richtiger Experten-Thread. :wink:
Gruss Waste
Bevor das dynamische Verhalten die Betrachtung bestimmt nur noch mal eine kurze Betrachtung des Systems von der mechanischen Seite:
Wie wird das Regelverhalten von der Konfiguration des Systems mit der Anordnung der Räder und des Sensorblocks mitbestimmt?
Wenn man davon ausgeht, dass ein Zweipunktregler instabil ist, dann kann man sich wundern, wie stabil einfache Linienfolger ohne entsprechende Auslegung des Regelverhaltens im elektronischen Teil fahren können: Sie haben neben der I Regelung einen kräftigen P Anteil schon in ihre mechanische Konfiguration eingebaut.
Eine Kurskorrektur die durch die Differenz der Radgeschwindigkeit vorgenommen wird, äußert sich nicht erst bei der Weiterfahrt und der dabei eintretenden Verschiebung des gesamten Fahrzeugs quer zur Linie. Es tritt schon eine Wirkung auf den Sensor ein, auch ohne das Fahrzeug weiterfährt, wenn nur die beiden Räder eine Differenzgeschwindigkeit haben und das Fahrzeug drehen. Dieser P-Anteil ist umso stärker, je weiter der Sensorblock vom Drehpunkt des Fahrzeuges entfernt ist. Die Wirkung des P-Anteils hemmt die Korrektur der Fahrtrichtung und wirkt dämpfend auf die Regelschwingung.
Wie sehr dieser P-Anteil das Regelverhalten beeinflusst, könnte man sich leicht klar machen, wenn man den Abstand des Sensorblocks zum Drehpunkt des Fahrzeugs leicht verschieben könnte. Bei der Mechanik ist es nicht ganz so leicht, aber einen weiteren Wert kann man leicht einstellen, nämlich den gleichen Wert negativ, wenn man das Fahrzeug rückwärts fahren lässt.
Der Einfluss wird dann schon beim Folgen einer geraden Linie sehr spektakulär deutlich, was mit etwas Geschick bei der Auslegung der Regelung und bei einer ausreichend kontinuierlichen Kennlinie des Liniensensors noch gehen wird.
Manfred
Hallo Manfred,
eine Linie rückwärts zu verfolgen ist wahrlich eine Herausforderung. Wenn der Asurowettbewerb nicht so schnell eingeschlafen wäre, hätte ich das noch als Vorschlag gebracht. Die Ergebnisse würde ich gerne sehen. :) Aber vielleicht können wir das noch nachholen.
Nun zu deinem Diskussionspunkt: Ich hatte mir auch überlegt, ob denn nicht die Fahrgeschwindigkeit als Verstärkung in das System eingeht. Denn vom Gefühl her sollte es so sein. Bin dann auch zu dem Schluss gekommen, dass es auch im Stand funktioniert und damit unabhängig von der Fahrgeschwindigkeit ist.
Allerdings kann ich dir nicht folgen, wie durch die Anordnung des Sensors zusätzlich ein D-Anteil dazukommt. Angenommen der Asuro hätte eine lange Schnauze und der Sensor wäre sehr weit vorne. Das hätte eine zusätzliche Hebelwirkung, aber für mich ist das ein reiner P-Faktor. Wäre dir dankbar, wenn wir da noch auf einen gemeinsamen Nenner kommen.
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 hätte gerne eine Abschätzung um wieviel sich die Zeitkonstante ändert anhand des echten Asuros. Der Schwerpunkt liegt zwar schon relativ zentral, aber das sollte schon noch quantifiziert werden.
Übrigens freut mich die aktive Teilnahme hier in dem Thread ungemein. Ich hatte eigentlich die Befürchtung, dass ich Alleinunterhalter sein werde, aber ich wurde vom Gegenteil überzeugt. Macht weiter so.
Gruss Waste
Was studierst du? (Fachrichtung)
Naja, ich studiere (leider) noch nicht, bin aber schon immatrikuliert und am 10.10. geht's dann mit Mechatronik los!
Bin ja ganz begeistert von dem Thread, weil ich zur gleichen Zeit auch geplant habe, Linienverfolgung über nen PID-Regler zu realisieren. Da mir aber die Grundlagen fehlen (fehlten ;) ), und man sich nicht mal einfach so ein Semester Regelungstechnik beibringen kann, hätte ich wahrscheinlich sehr viel mit dem im AVRco integrierten PID-Regler rumprobiert...
Gruß, ähM_Key
wie durch die Anordnung des Sensors zusätzlich ein D-Anteil dazukommt. Angenommen der Asuro hätte eine lange Schnauze und der Sensor wäre sehr weit vorne. Das hätte eine zusätzliche Hebelwirkung, aber für mich ist das ein reiner P-Faktor.
Ich habe das oben abgeändert in (I und P) anstelle von (P und D). So sollte es heißen.
Es ist so gemeint: Der Sollwert der Position ist der, bei dem sich das Fahrzeug mit seinem Drehpunkt (der Mitte) über der Linie befindet. Die Regelabweichungen werden beim Fahren durch Drehbewegungen, die der geradlinigen Fahrt überlagert sind, ausgeglichen.
Ist der Sensor im Drehpunkt des Fahrzeugs, dann erkennt man die Positionsänderung als eine Integration über die Stellgröße Drehung. Erst bei einer Verlegung des Sensors nach vorne kann man durch eine Drehung schon direkt eine Korrektur der Position des Sensors erreichen, die dann eine Korrektur der Fahrzeugposition nach sich zieht.
Eine einfachere Betrachtung ist, nur die Drehung als Regelvorgang anzusehen, und den Winkel, unter dem die Linie von Sensor erfasst wird auszuregeln. Die Störgröße ist dann die Winkeländerung der Linie die sich bei der aktuellen Geschwindigkeit ergibt und die Korrektur ist gerade die Drehung des Fahrzeugs.
Manfred
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
Hallo Manfred,
das ist doch wieder eine schöne Kopfnuss-Aufgabe! :)
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
Wie gross ist das Trägheitsmoment?
Ist es wirklich eine Torsionsschwingung? Mir kommt die Schwingung vom Gefühl her so langsam vor.
Ist der Sensor im Drehpunkt des Fahrzeugs, dann erkennt man die Positionsänderung als eine Integration über die Stellgröße Drehung.
Jetzt bin ich doch wieder unsicher, ob nicht noch ein weiterer Integrator in das Modell muss. Dein Beispiel ist sehr plausibel. Das muss ich mir nochmal genau überlegen. Es ist schon ziemlich kompliziert.
Waste
Ich bin nicht dazu gekommen, das Trägheitsmoment auszurechnen, ich wollte nur schon mal ein paar Werte dazu aufnehmen.
Der Draht ist eben ziemlich dünn und lang. Ich habe aber zum geeigneten Vergleich der beiden Versuche die gleiche Amplitude 2U (Spitze Spitze) genommen und bin auf ähnliche Periodendauern gekommen.
Manfred
@Waste
Wenn der Asurowettbewerb nicht so schnell eingeschlafen wäre, hätte ich das noch als Vorschlag gebracht. Die Ergebnisse würde ich gerne sehen. Aber vielleicht können wir das noch nachholen.
Hallo Waste,
eigentlich ist der ASURO-Wettbwerb ja nicht eingeschalfen.
Die Wettbewerbe
- Nikolaushaus
- Schatz auf Linie
wurden ja mit erfolgreichen Ergebnissen abgeschlossen.
Den Nikolaushauswettbewerb habe ich angestossen, weil das Zeichnen des Nikolaushauses meiner Meinung nach der beste Test für eine exakte Bahnregelung des ASURO-Roboters ist. Es ist nämlich äusserst schwieirg dass der Roboter nach mehreren Linienfahrten und Drehungen wieder an den Ausgangspunkt zurückzukehrt. Die beiden präsentierten Lösungen arbeiten ohne Regler sondern die Motoren werden vorkallibriert. Meiner Meinung nach ist es sogar fast unmöglich, das Nikoaushaus zu zeichnen wenn während der Fahrt geregelt wird.
Was bei den Wettbwerben noch aussteht, ist der große Wettbwerb mit der Navigation des ASURO auf dem Gittermuster und dafür ist ja die Arbeit die Ihr hier gerade leistet, die ideale Grundlage.
Ausserdem scheint es mir, als wenn der große Wettbewerb noch mal in Teilwettbwerbe zerlegt werden muss, wenn man sieht, wie lange man sich an der Linienverfolgung aufhalten kann ( so professionell, wie Ihr es betreibt ).
Als Teilwettbwerb schwebt mir vor, dass der ASURO bei freier Fahrt auf einen Barcode ( oder irgend ein Linienmustter ) treffen soll und diesen Barcode als Befehl interpretiert.
Als Möglichkeit den Barcode zu erkennen könnte man vielleicht die Kreukorrelationsfunktion verwenden.
Im Moment sind das aber nur so die ersten Ideen die mir dazu einfallen und ich möchte mit dem Start des Wettbwerbs noch warten. Falls sich genügen Leute finden, die sich für das Thema interessieren kann man ja mal darüber nachdenken.
Viele Grüße,
stochri
Hallo stochri!
Gut, dass es nicht in Vergessenheit geraten ist. In der Zwischenzeit können wir ja Vorschläge sammeln bis sich genügend Teilnehmer finden.
Gruss Waste
Zur Berechnung der Trägheitsmomente des ASURO aus den Messungen wird zunächst die Federkonstante des Drahtes bestimmt.
Das Trägheitsmoment des Stabes ist Js = ¼ * m * r² +1/12 * m * l² = 250µkgm²
Daraus ergibt sich die Torsions-Federkonstante D’ = 4 * pi² * Js / T² = 24 µNm (pro radiant).
Das Trägheitsmoment des ASURO waagerecht um den Achsenmittelpunkt wird damit: J1 = T² * D’ / (4 * pi²).
J1 = 200 µkgm².
Nach Steiner ist für das Trägheitsmoment um ein Rad, das Trägheitsmoment der Masse konzentriert im Schwerpunkt zu addieren.
Jz = m² * halbe Spurweite (ist je nach Lage der Akkus nicht genau der Abstand zum Schwerpunkt).
Mit 0,17kg und 105mm Spurweite ergibt sich Jz = 468 µkgm².
Damit ist das Trägheitsmoment um ein Rad:
J2 = 668 µkgm².
Manfred
http://de.wikipedia.org/wiki/Tr%C3%A4gheitsmoment
http://de.wikipedia.org/wiki/Steinerscher_Satz
https://www.roboternetz.de/phpBB2/viewtopic.php?p=66902#66902
Hallo ähM_Key,
ich habe eine einfache Möglichkeit gefunden die Trägheit in deinem RoboSim zu berücksichtigen. Es braucht nichts anderes als eine Filterfunktion. In dem Fall ist es die Funktion wie in meinem PT1-Block, das ist eine e-Funktion wie bei einem RC-Glied.
Realisierbar durch: out(t) = out(t-1)+c*(in(t)-out(t-1))
wobei c eine Konstante ist, die zw. 0...1 liegt.
c = 1 - exp(t/tau)
Wenn dein Takt 0.1sec ist und tau 0.13sec, dann ist c=0.537
Für deinen Fall ist dann die Berechnung noch einfacher weil (in(t)-out(t-1)) der Variable "regel" entspricht. Damit reicht eine einfache Berechnung um echte Beschleunigung zu simulieren.
Beispiel:
valt:= v
v:= valt + 0.537*regel
Du brauchst das nur vor der neuen Ausgabe der Geschwindigkeit einbauen. Das wars.
Damit ist das Programm noch interessanter.
Gruss Waste
@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
Hier meine Erkenntnisse zu den Messungen:
Die äquivalente Masse, die ich in meinem Ersatzschaltbild zu berücksichtigen habe, berechnet sich aus m = I / r²
Für die Drehung um ein Rad ergibt sich: 668µ/0.105² = 60g
Drehung um Achsenmittelpunkt: 200µ/0.0525² = 72g
Mit dem Faktor 240/170 auf das Gewicht meines Asuros umgerechnet ergibt das:
85g für die Drehung um ein Rad
102g für die Drehung um den Achsenmittelpunkt
Die Korrekturen bei der Linienfolge werden durch Drehung um den Achsenmittelpunkt durchgeführt, deshalb muss ich 102g für die Simulation vorsehen. Zusätzlich bleiben natürlich die 190g verursacht vom Trägheitsmoment des Motors, was insgesamt eine Masse von 292g ergibt. Im Vergleich zu den 310g bei geradliniger Beschleunigung sind es nur 6% Unterschied, was für die Simulation unerheblich wäre. Trotzdem ist es gut zu wissen, der Unterschied hätte auch sehr viel gravierender sein können. Ich hatte zwar erwartet, dass der Unterschied nur gering sein wird, aber bei der Drehung um ein Rad habe ich mich getäuscht, da hatte ich sogar eine geringfügige Erhöhung erwartet.
Meine Messungen bestätigen die von Manfred. Die Zeitkonstante ist bei beiden Drehungen geringer als bei der Vorwärtsbeschleunigung. Zu berücksichtigen ist bei "nur rechts beschleunigt" also der Drehung um ein Rad, dass ein Motor die gesamte Reibung des Tischtennisballs übernehmen muss und deshalb die Höchstgeschwindigkeit niedriger ist. Trotzdem aber schon nach 100ms auf 0.3m/s beschleunigt und damit die kürzeste Zeitkonstante aufweist. q.e.d.
Vielen Dank nochmal an Manfred für die Mitwirkung.
Als nächstes ist noch der zusätzliche Integrator zu klären. Ich bin noch am Überlegen, ist gar nicht so einfach. Muss mal googeln, vielleicht find ich da was.
Waste
Sternthaler
20.08.2005, 02:18
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
@Sternthalter
bei der Linienfolgung einen Barcode seitlich zu platzieren um damit eine 'gleich' kommende Abzweigung anzukündigen.
Damit kann man dann Linien 'verlegen', die einer Modelleisenbahn mit Weichen, Abstellgleisen, und Sonstigem ähneln kann
Und damit dürfte das Spielen mit dem ASURO ein interessante Komponente bekommen. Vor kurzem, als ich die Experimten für den 2ten Wettbwerb gemacht habe, war ein paar Freunde mit einem Kind von 2.5 Jahren zu Besuch. Es war sehr begeistert. Wobei ich zugeben muss, dass der ASURO nicht unbedingt robust genug ist, um ihn mit dem Kind alleine zu lassen. Ein kleiner Schlag mit dem Patschhändchen kann dem ASURO schon sehr zusetzen.
Einen etwas robusteren Roboter könnte man also sehr gut als Kinderspielzeug verwenden.
Es begeistert besonders, wenn der Roboter den Anschein erweckt, als wenn er eine Aufgabe erfüllen wollte, wie zum Beispiel einer Linie zu folgen, bei der ja ständig die Gefahr besteht, dass er sie verliert.
Aspekte, wie Roboter emotionales Verhalten erzeugen werden wissentschaftlich untersucht. Ein Artikel der serh gut dazu passt:
http://www.gmd.de/pointer/2-98/dautenhahn.html
( die Seite ist zwar nicht gut formatiert und wissenschaftlich vielleicht etwas dünn, aber sie beschreibt doch sehr gut, wie man mit einem einfachen Roboter Emotionen erzeugen kann )
Vielleicht könnte man als Spiel auch Papierblätter mit Strichcodes im Raum verteilen und der ASURO muss versuchen, sich von einer Orientierungsinsel zu nächsten vorzuhangeln, immer mit der Gefahr die nächste Insel zu verfehlen.
Deine Bahnstrecke ist übrigens recht beeindruckend.
Gruss,
stochri[/quote]
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
[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
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
http://www.web-upload.de/data/media/20/RoboSim.jpg
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
Hallo ähM_Key,
je mehr ich mit RoboSim spiele, umso mehr gefällt es mir. Scheint jetzt mit den Reglergleichungen zu funktionieren, nur ist der Wertebereich wahrscheinlich etwas zu eng. Bei ki ist scheinbar schon 1 zu viel. Desweiteren habe ich festgestellt, dass das Fahrzeug manchmal springt. Ist wahrscheinlich ein Überlauf oder sonst ein Bug im Programm.
Einen Verbesserungsvorschlag habe ich auch schon:
Für eine Analyse der Reglerparameter wird meistens die Sprungfunktion verwendet. Die könnte auch hier angewandt werden, indem eine gerade Linie einen Versatz hat. Durch einen weiteren Kurs(Hintergrund), der eine waagrechte Linie mit Sprung aufweist, könnte man die Sprungantwort durch Aufzeichnen wie in deinem obigen Beispiel sichtbar machen. Das ermöglicht eine gute Analyse auf Änderungen der Reglerparameter. Oft werden auch in der Literatur Einstellregeln anhand der Sprungantwort angegeben. Die könnte man damit ausprobieren.
Schön wäre es natürlich, wenn man auch den Asuro simulieren könnte. Dazu müsste aber der Sensor auf analog umschaltbar sein.
Eigentlich hat dein schönes Programm einen eigenen Thread verdient. Ich bin mir sicher, dass viele Interessierte es in diesem Thread nicht erwarten und auch nicht finden. Der Thread ist ja doch etwas umfangreich geworden und zudem noch anspruchsvoll.
Gruss Waste
@waste
Der Thread ist in der Tat ziemlich anspruchsvoll und wenn man nicht aufpasst hat man den Faden auch schon verloren ( ich hab's leider schon aufgegeben ). Am Schluss ist es nur noch eine Diskussion zwischen den Leuten, die bis dahin durchgehalten haben.
Ich glaube auch, dass es sinvoll ist, für das Robosim einen neuen Thread aufzumachen.
Gruss,
stochri
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
@waste ... oder gibt es etwa gar keine Leser mehr die Fragen stellen könnten.
Auch wenn ich (noch) keine Fragen stelle, ich lese alles, versuche es zu verstehen und probiere es auch aus.
Macht bitte so weiter! Den ASURO hab ich gekauft um was zu lernen.
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
Ä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
Im Thread hab ich den Überblick über das Simulationsmodell nicht gefunden.
Sollte das Ganze so aussehen ?
Mit dem Übersichtsbild zum Gesamtsystem wird es sicher leichter klar.
Ich sehe noch nicht, welche Bedingungen wie kritisch sind für eine instabile Fahrt. Es gibt Einflüsse durch die Regelung wie Steilheit und Verzögerungen. Die Regelung sollte bei einer Abweichung vielleicht auch nur verlangsamend auf den ausgewählten Motor wirken. Es gibt die Länge des Auslegers mit den Sensoren, die vielleicht nur in die Steilheit eingeht und natürlich das von Waste schon angekündigte D-Verhalten, das die Fahrt stabilisieren wird. Sollte man versuchen die Einflüsse im Gesamtbild darzustellen?
Zur allgemeinen Veranschaulichung des D-Verhaltens habe ich hier einen Link:
Bei dem hier dargestellten Linienfolger ist in zwei kurzen Filmen das Verhalten mit und ohne D Regler gezeigt. Es ist eine allgemeine Darstellung über den gesamten Aufbau und es wird nicht im Detail auf die Regelparameter eingegangen. http://elm-chan.org/works/ltc/report_j.html
Manfred
Filme:
Nur P Regelung http://members.jcom.home.ne.jp/felm/ltc4.mpg
Mit D Regelung http://members.jcom.home.ne.jp/felm/ltc5.mpg
http://elm-chan.org/works/ltc/ltc01.jpeg
Eine kleine Einführung in die Regelungstechnik.
Hier habe ich einen recht guten
"Online-Kurs für Neulinge in diesem Metier die sich zunächst ein grundlegendes Verständnis für dieses Gebiet aneignen möchten"
gefunden. http://www.meilhaus.com/regeltechnik/
Hallo waste!
Habe den Wertebereich vergrößert, geht jetzt von 1/1000 bis 1. Wenn's immernoch nicht reicht muss halt noch eine 0 drangehangen werden.
Kannst du mir mal die Einstellungen sagen, bei denen die Kiste springt? Klingt wirklich nach nem Bug...
Die Background.bmp kann man ja beliebig editieren; meinst du das so wie im Anhang?
Das mit dem auf analog Umschalten der Sensoren habe ich noch nicht ganz verstanden...könnte man das ev. dadurch in Griff bekommen die Sensoren sehr nah beieinander zu plazieren (Sensorabstand)?
Und auf euer 'Drängen' hin ( ;) ) habe ich mal nen RoboSim-Thread aufgemacht: https://www.roboternetz.de/phpBB2/viewtopic.php?p=107585#107585
Grüße; ähM_Key
Hallo ähM_Key,
die Sprungfunktion zum Testen der Bahnregelung muss meiner Meinung nach als Sprung in der Krümmung der Bahn realisiert werden.
Also auf Deutsch:
- Rechteck
-Sexeck
- 8-Eck usw. sind gute Tests für die Bahnverfolgung.
Die neue Bahn von Dir hat zwar einen Sprung, aber ich habe irgendwie das Gefühl ein Knick ist der richtige Test.
Gruss,
stochri
Hm, verstehe. Paint ist dein Freund :D
Wenn der minimale Radius wesentlich kleiner als der Abstand der Sensoren von der Achse ist, müsste man das in vielen englischen Dokumentation als 'overshooting' bezeichnete 'über die Bahn hinausschießen' mit in die Software implementieren, da sonst die Bahn sehr leicht verloren gehen kann.
Gruß, ähM_Key
Der Sprung auf der Gerade ist schon richtig im Beispiel von ähM_Key, aber nur eine Linie von links nach rechts. Man startet den Lauf, der Roboter trifft auf den Sprung und zeichnet die Sprungantwort. So habe ich mir das vorgestellt.
Ich habe es schon selbst mit einer Background.bmp versucht, aber da stürzt das Programm ab.
Übrigens ward ihr recht fleissig. Auf die anderen Beiträge gehe ich nach der F1 ein. Bis später.
Waste
Ich habe es schon selbst mit einer Background.bmp versucht, aber da stürzt das Programm ab.
Übermale am besten die alte oder verwende Background_leer.bmp als Vorlage, damit es funktioniert. Das Bild muss ein Auflösung von 600*600 und 24 Bit haben!
Die angepassten ini-Werte für den Background im Anhang sind:
robox=100
roboy=305
roboalpha=0
MK
ok, mit Paint hat es geklappt. Vorher hatte ich ein anderes Zeichenprogramm verwendet.
Im Anhang sind 2 Beispiele ausgeführt. Einmal stabil und das 2. instabil. In der Art kann man die Einstellungen sehr gut überprüfen.
Waste
Hallo Manfred,
eine interessante WebSite mit dem putzigen Linienfolger!
Kannst du eigentlich Kanji lesen? Oder hast du auch noch die englische Seite gefunden. :)
http://elm-chan.org/works/ltc/report.html
Übrigens verwendet er auch die on/off Methode beim Liniensensor zur Kompensation des Umgebungslicht.
Waste
Hallo stochri,
hier nochmal die Kennlinie des Liniensensors:
https://www.roboternetz.de/phpBB2/files/liniensensor.gif
Interessant, deine Überlegungen zu dem Thema! Hier ein paar Anmerkungen von meiner Seite: Die Reibung geht nur als Verstärkungsänderung (K-Faktor) in das Simulationsmodell ein, da bei höherer Reibung nicht mehr die volle Höchstgeschwindigkeit erreicht wird. Die Zeitkonstante des PT1 bleibt bestehen.
Der Begrenzer muss vor den Antrieb, also bei der PWM sein.
Der Soll/Ist-Vergleich kommt gleich nach dem Sensor. Der Sollwert ist 0, also keine Abweichung.
Ich habe ein Modell aus meiner Sicht angehängt und zum Vergleich das Blockschaltbild mit den für die Simulation relevanten Blöcken. Ich hoffe es wird dadurch verständlicher.
Waste
@ ähM_Key
Im Moment springt in RoboSim nichts mehr, war wohl ein sporadisches Problem meines Rechners.
Den analogen Sensor stelle ich mir so vor wie die Kennlinie in meinem vorigen Beitrag. Die Kennlinie auf eine trapezähnliche Funktion vereinfachen, dass ein linearer Anstieg bis 5mm Abstand, konstanter Wert bis 10mm und wieder linear abfallend bis 15mm übrig bleibt. Das wäre eine Kennlinie für 2 Dioden im Abstand von jeweils 7.5mm zur mittleren LED, wie beim Asuro.
Notfalls nur eine einzige lineare Steigung oder Dreieck, wenn die erste Funktion nicht geht.
Waste
Hallo Waste,
Die Reibung geht nur als Verstärkungsänderung (K-Faktor) in das Simulationsmodell ein, da bei höherer Reibung nicht mehr die volle Höchstgeschwindigkeit erreicht wird. Die Zeitkonstante des PT1 bleibt bestehen.
Müsste dem Modell entsprechen, welches ich geziechnet habe.
Allerdings hat das ja, die von Dir mal früher erwähnten Schwachpunkte, dass es keinen Unterschied zwischen Bremsen und Beschleunigen macht.
Ausserdem funktioniert es natürlich auch nicht bei Geschwindigkeiten bei weniger als 1/5tel der Maxiamlgeschwindigkeit.
Falls der Regler später weiter runterregeln will, wird das Modell stark von der Realität abweichen.
Der Begrenzer muss vor den Antrieb, also bei der PWM sein.
Oh ja, das war in der ersten Zeichnung noch falsch.
Der Soll/Ist-Vergleich kommt gleich nach dem Sensor. Der Sollwert ist 0, also keine Abweichung.
Bei meinem Modell läßtt sich die Geschwindigkeit als Sollgröße vorgeben. Dein Modell und meines lassen sich mathematisch exakt ineinander umformen, sofern man die Tatsachen nutzt, dass Du das Innere Deines Reglers noch nicht genau spezifiziert hast.. Was hältst Du davon die Geschwindigkeit als Sollgröße zu verwenden ?
In Deinem Modell wird die Geschwindigkeitsdifferenz integriert, mathmatisch läßt sich der Integrator vor die Differenz ziehen und in 2 Integratoren aufspalten. Ich fände es anschaulicher, wenn die Integration dem Antriebstrang zugeschlagen wird, weil ja in der Realität jedes einzelne Rad den Weg integriert und es keinen Integrator gibt, der die Geschwindigkeitsdifferenz integriert.
Danke für die Liniensensorkennlinie.
Gruss,
stochri
Hier die graphische Darstellung der Äquiivalenz der beiden Modelle.
Bei meinem Modell läßtt sich die Geschwindigkeit als Sollgröße vorgeben. Dein Modell und meines lassen sich mathematisch exakt ineinander umformen, sofern man die Tatsachen nutzt, dass Du das Innere Deines Reglers noch nicht genau spezifiziert hast..
In Deinem Modell wird die Geschwindigkeitsdifferenz integriert, mathmatisch läßt sich der Integrator vor die Differenz ziehen und in 2 Integratoren aufspalten. Ich fände es anschaulicher, wenn die Integration dem Antriebstrang zugeschlagen wird, weil ja in der Realität jedes einzelne Rad den Weg integriert und es keinen Integrator gibt, der die Geschwindigkeitsdifferenz integriert.
Mannomann, heute war ich sowas auf dem Schlauch gestanden, das gibt es normalerweise nicht. Bin den ganzen Tag einer Diskrepanz nicht auf die Spur gekommen. Jetzt endlich habe ich es gefunden. Ich wollte heute eigentlich mit dem Bodediagramm weiter machen und erklären was ein stabile Regelung ausmacht, welche Eigenschaften kritisch sind, usw. Beim Erstellen der open loop gain hatte ich dann die Diskrepanz in der Verstärkung mit den von Hand gerechneten Werten. Das musste natürlich zuerst geklärt werden.
Nachdem ich es jetzt herausgefunden habe, muss ich auch folgende Aussage von mir korrigieren:
Die Reibung geht nur als Verstärkungsänderung (K-Faktor) in das Simulationsmodell ein, da bei höherer Reibung nicht mehr die volle Höchstgeschwindigkeit erreicht wird.
Das stimmt so nicht, das war mein Denkfehler. Für die Stabilität ist die differenzielle Steilheit also die Steigung ausschlaggebend und da ändert sich bei grösserer Reibung nichts. Das kann man sehr schön an dem Diagramm von stochri sehen. Ich habe den Ausschnitt noch mal als Bild angehängt. Man sieht sehr deutlich, dass sich zwar die Geschwindigkeit mit stärkerer Reibung ändert, aber die Steigung bleibt erhalten, die Kurve wird nur parallel nach unten versetzt. Nachdem das geklärt ist, kann es vermutlich morgen weiter gehen.
@ stochri
Ich wüsste jetzt nicht, wie man bei einem Linienfolger die Geschwindigkeit als Sollwert verwenden kann. Der Asuro soll ja genau der Linie folgen und Abweichungen von der Linie sofort ausregeln. Die Abweichung ist eine Wegstrecke und keine Geschwindigkeit. Ich glaube du verwechselst da was. Natürlich kann man zusätzlich eine Geschwindigkeitsregelung einbauen, aber die ist extra zu betrachten.
Die Simulation für die Stabilität, die ich machen will, basiert auf der Analyse des dynamischen Verhaltens. Da werde ich nicht nur im Zeitbereich analysieren, sondern auch im Frequenzbereich. Dafür habe ich das Modell erstellt und es möglichst einfach gehalten. Es sind nur die für die Simulation relevanten Eigenschaften enthalten.
Hoffentlich gibt es morgen nicht noch einmal so ein Problem wie heute, sonst verzweifle ich. Aber das öffentlich machen von so einer Projektarbeit hat schon was für sich. Bevor man es schreibt, wird es nochmal überprüft und dabei werden doch noch kleine Fehler entdeckt. Ohne der Veröffentlichung hätte ich den Unterschied vermutlich übersehen. Es zwingt einen schon zu genauer Arbeit.
Gruss Waste
Hallo Waste,
Ich wüsste jetzt nicht, wie man bei einem Linienfolger die Geschwindigkeit als Sollwert verwenden kann. Der Asuro soll ja genau der Linie folgen und Abweichungen von der Linie sofort ausregeln. Die Abweichung ist eine Wegstrecke und keine Geschwindigkeit.
Um das zu verdeutlichen habe ich Dein Modell im obigen Post abgezeichnet und die Regelerstruktur in Deinen Regler eingezeichnet. Ich dachte das wär so am besten verständlich.
Die rot gezeichnete Strukur beschreibt folgendes.
Der linke Motor wird mit einem festen PWM-Wert angesteuert ( das ist sozusagen die Sollgröße und kann bei Bedarf veränderte werden )
Der rechte Motor wird vom Regler gesteuert
( Wenn ich mich nicht täusche enspricht das sogar einem Deiner Linienfolgeprogramme. )
Die Sollgröße ( Abweichung von der Linie ) in Deinem Modell wird wie Du schon beschrieben hast auf 0 gesetzt ( sinnvolerweise ). Das heisst, man kann die Subtraktionsstelle streichen und durch * -1 ersetzen.
Zu den rot gezeichneten Antriebsträngen:
der Integrator lässt sich verschien, weil folgendes gilt:
intgral(v1-v2)=integral(v1)-integral(v2)
Ich glaube du verwechselst da was. Natürlich kann man zusätzlich eine Geschwindigkeitsregelung einbauen, aber die ist extra zu betrachten.
Was die Umformung der Reglerstruktur angeht, bin ich mir ziemlich sicher. Vielleicht habe ich noch nicht die richtige sprachliche Erklärung gefunden.
Die Simulation für die Stabilität, die ich machen will, basiert auf der Analyse des dynamischen Verhaltens. Da werde ich nicht nur im Zeitbereich analysieren, sondern auch im Frequenzbereich. Dafür habe ich das Modell erstellt und es möglichst einfach gehalten.
Den Frequenzgang dieser Modellstruktur zu analysieren sollte machbar sein, es entspricht Deinem Modell.
Viele Grüße,
stochri
Den analogen Sensor stelle ich mir so vor wie die Kennlinie in meinem vorigen Beitrag. Die Kennlinie auf eine trapezähnliche Funktion vereinfachen, dass ein linearer Anstieg bis 5mm Abstand, konstanter Wert bis 10mm und wieder linear abfallend bis 15mm übrig bleibt. Das wäre eine Kennlinie für 2 Dioden im Abstand von jeweils 7.5mm zur mittleren LED, wie beim Asuro.
Also erst nochmal zu der Kennlinie:
Ich habe das so interpretiert, das auf der X-Achse die Abweichung der mittleren LED zur Mitte der Strecke angegeben wird, und auf der Y-Achse die gemessenen Analogwerte der Sensoren in Prozent oder was auch immer. Dabei wird bei einem Sensor der negative Wert genommen.
Ich bin der Meinung, dass der wieder abfallende Teil der Kurve ( > |10mm| ) sowieso nicht nutzbar ist, weil der Roboter nicht weiß, wo er ist, also das Abfallen bei Abweichungen von > |10mm| könnte genausogut < |5mm| bedeuten. (Ich hoffe das war heilweg's verständlich; die Betragszeichen sind sicherlich nicht korrekt, aber ihr wisst ja was ich meine)
Wie funktioniert das bisher? Denkfehler meinerseits?
Desshalb wäre ich dafür, nicht direkt die Daten der Sensoren als Input für den Regler zu verwenden, sondern das ganze erst mal zu 'linearisieren', also aus der Kennlinie die wirkliche Abweichung zu errechnen. Ist meiner Meinung nach sauberer, als das dann dem Regler zu überlassen.
Sicher wäre es kein Problem so eine Kennlinie in RoboSim mit einzubauen, aber wie gesagt, ich bezweifle, dass das so gut ist.
Um einem analogen Sensor nahe zu kommen, kann man ja die Sensoranzahl beliebig erhöhen und den Sensorabstand auf 1 setzen. Mehr macht sowieso keinen Sinn, da die Bahn nur pixelweise aufgelöst ist; natürlich könnte man auch das verändern, ist aber dann mit nicht ganz unerheblichem Programmieraufwand verbunden.
Grüße; ähM_Key
@ ähM_Key
Ich probier es mal mit der Sensoranzahl erhöhen und Abstand auf 1 Pixel. Wenn das klappt ist es ausreichend.
Waste
Hallo ähM_Key,
Ich bin der Meinung, dass der wieder abfallende Teil der Kurve ( > |10mm| ) sowieso nicht nutzbar ist, weil der Roboter nicht weiß, wo er ist, also das Abfallen bei Abweichungen von > |10mm| könnte genausogut < |5mm| bedeuten. (Ich hoffe das war heilweg's verständlich; die Betragszeichen sind sicherlich nicht korrekt, aber ihr wisst ja was ich meine)
Wie funktioniert das bisher? Denkfehler meinerseits?
Ich denke, Du hast richtig gedacht. Es ist einfach so, wenn die Liniensensoren des Asuro mehr als 1cm abweichen, hat der ASURO die Linie verloren.
Der enge Fangbereich ist das große Problem bei der ASURO-Linienverfolgung.
Gruss,
stochri
In dieser Fortsetzung geht es um die Stabilitätskriterien von Regelschleifen, dazu wird das Bodediagramm der Schleife erstellt.
Vorher nochmal eine Zusammenstellung der Kennwerte der einzelnen Komponenten:
Antrieb statisch: 0.002 m/s
PT1-Block (differenzielle Steilheit des Antriebs): 0.0027 m/s
PT1-Block Zeitkonstante: 120ms (wegen des geringeren Trägheitsmoments beim Drehen)
Integrator: 1s
Sensor Hebelwirkung: 77/103 = 0.75
Sensor Empfindlichkeit: 14 pro mm
Totzeit durch AD-Wandler: 1.6ms
Der Regler wird vorerst nur mit der Verstärkung von 1 angesetzt, um zu sehen was die Schleife alleine macht. Es wird dazu das Bodediagramm der "open loop gain", also der Verstärkung in der Schleife erstellt. Siehe dazu auch Bild "open_loop_gain.gif". In dem Bild sind Amplituden- und Phasengang (grüne Linien) der Verstärkung aufgetragen. Die gestrichelte Linie ist die Phase. Ein Kriterium für die Stabilität der Schleife ist der Phasenrand und der Amplitudenrand. Diese sind violett eingezeichnet. Der Phasenrand ist die Phase bei Verstärkung = 1 (entspricht 0dB). Der Amplitudenrand ist die Dämpfung wenn die Phase durch 0 geht. Es ist verständlich, dass die Schleife schwingen würde, wenn bei 0 Grad eine Verstärkung > 1 wäre. In unserem Fall ist der Amplitudenrand 25dB und der Phasenrand etwa 27 Grad. Das ist nicht sehr viel, aber stabil. Die Regel lautet: Eine geschlossene Regelschleife arbeitet genau dann stabil, wenn der Phasenrand positiv ist. Wie stabil es ist, können wir auch an der Sprungantwort sehen.
Die Sprungantwort ist eine Analyse im Zeitbereich und zeigt die Antwort des Systems auf einen Sprung am Führungswert. Wie unser System reagiert, sieht man in Bild "Sprungantwort.gif". Es schwingt schon deutlich über und pendelt auch eine Zeitlang aus. Jetzt stellt sich die Frage, wie geht man vor, um den Regler einzustellen. Würde man im Regler die Verstärkung erhöhen, also nur P-Anteil erhöhen, dann ist aus dem Bodediagramm leicht zu erkennen, dass der 0dB-Durchgang der Verstärkung zu höheren Frequenzen rutscht (nach rechts) und der Phasenrand abnimmt. Bei einem P-Anteil von 18 (entspricht 25dB) würde die Schleife sogar schwingen (kein Phasen- und Amplitudenrand mehr). Also müssen wir zuerst den Phasenrand erhöhen, damit die Schleife stabiler wird und danach können wir, sofern genügend Phasenspielraum vorhanden ist, die Verstärkung erhöhen um eine schnellere Ausregelung zu bekommen.
Dazu schauen wir uns erstmal die Übeltäter an. Zum einen ist es der Integrator, der konstant die Phase um -90 Grad dreht und zum anderen ist es der PT1-Block, der mit seiner Zeitkonstante von 120ms den Frequenzgang wie in Bild "PT1_fg.gif" hat. Die Grenzfrequenz liegt bei 1.3Hz, da hat die Phase bereits 45 Grad gedreht. Was man dagegen macht, wird im nächsten Beitrag erklärt. Ich kann leider nur 3 Bilder pro Beitrag zeigen, deshalb geht es im nächsten Beitrag weiter.
Waste
Fortsetzung folgt.
Wenn man nun genau das Gegenteil von dem, was der PT1-Block macht, in den Regler integriert, dann wäre alles wieder in Butter. Das geht mit einem Differenzierglied. Im Bild "D-Anteil.gif" ist der Frequenzgang des Differenzierglieds (rote Kurve) gezeigt, der genau den Frequenzgang des PT1-Blocks (grüne Kurve) kompensiert. Im Regler wird das mit einem D-Anteil realisiert, der eine Zeitkonstante von 120ms hat.
Jetzt wollen wir mal sehen, wie sich das auf den Phasenrand und auf die Sprungantwort ausgewirkt hat. Siehe dazu die Bilder "olg2.gif" und "Sprungantwort2.gif". Na, das sieht doch gut aus! Der Phasenrand ist jetzt 85 Grad und es ist auch noch Raum für eine Erhöhung des P-Anteils. Aber schöner noch ist die Sprungantwort mit D-Anteil (rote Kurve). Zum Vergleich ist auch noch das Einschwingen ohne D-Anteil (grüne Kurve) eingezeichnet.
Im nächsten Beitrag versuchen wir noch am P-Anteil zu drehen.
Bis dann.
Waste
Fortsetzung folgt
Ich störe ja ungern deine genialen Ausführungen, aber es gibt ein kleines Update von RoboSim!
https://www.roboternetz.de/phpBB2/viewtopic.php?p=107941#107941
Grüße; ähM_Key
Ah, danke, jetzt sehe ich erst deinen Thread.
Werd es gleich testen.
Gruss Waste
Sternthaler
23.08.2005, 01:29
Hallo zusammen,
da ich zum weiteren verfolgen des Threads erst den Keller nach meinen alten Regelungstechnikunterlagen durchsuchen musste, hat's etwas gedauert bis ich den Ausführungen von waste wieder folgen konnte.
Nachdem ich so die Bode- und Zeitdiagramme wieder halbwegs verstehe, habe ich vor allem (über mein geliebtes EXCEL) zugesehen, das auch bei mir ein negativ wirkender D-Anteil stärker wirkt.
Ausserdem hat waste schön dargelegt, das die Regelzeit so um 120 ms betragen wird.
Entsprechend habe ich (schon wieder im EXECL) das Verhältniss von Ti (Nachstellzeit) und Ta (Abtastzeit) darauf angepasst.
waste hat wohl richtig gerechnet.
Die Grafiken im EXECL 'Tabelle2' zeigen im oberen Bild eine von mir in der Strecke erzeugte Störung (und deren Ausreglung). Im unteren Teil kann man auch noch gut sehen, dass die Motorgeschwindigkeiten dafür sehr sanft geregelt werden. Das macht sich auch sehr schön in der recht ruhigen Fahrt vom Asuro bemerkbar.
Klasse dieser Thread!
Schöne Grüße von Sternthaler
ACHTUNG: auch hier ist wieder der rechte Motor mit 50 höher betrieben in MotorSpeed.
Fortsetzung:
Der D-Anteil bewirkt ein Vorhalten der Ansteuerung um die Verzögerung in der Regelstrecke auszugleichen. In unserem Fall kennen wir die Zeitkonstante des Antriebs und können dem Regler genau sagen wie er vorhalten muss. Das Vorhalten hat allerdings Grenzen, denn sonst bräuchte man unbegrenzt Power.
Jetzt optimieren wir nochmal den Regler, indem der P-Anteil um den Faktor 3 erhöht wird. Das ist für die Stabilität kein Problem, da genügend Phasenreserve im vorigen Beispiel war. Sehen wir uns dazu die Sprungantwort an (grüne Kurve V(s) im Bild "unbegrenzt.gif"). Das Einschwingen hat sich nochmal um den Faktor 3 verbessert. Achtung, die Zeitskala ist jetzt 0.5s anstatt 2s wie im vorigen Beitrag. Die Optimierung nach dem Bodediagramm könnte man noch weiter ausreizen, aber wie schon angesprochen sind uns da von anderen Seiten her Grenzen gesetzt. Das sieht man in den darüber angeordneten Kurven. Die rote Kurve V(v) bedeutet die Geschwindigkeit und die violette Kurve V(m) die Ansteuerspannung. Man sieht, für diese Beschleunigung bräuchte man kurzzeitig 100V als Ansteuerspannung für den Motor. Die haben wir leider nicht.
Aber wie sieht es in der Realität aus, wenn die Ansteuerung die Befehle des Reglers, auf das was möglich ist, begrenzt. Im Bild "begrenzt.gif" sieht man das Dilemma, das flotte Einschwingen ist wie eine Seifeblase zerplatzt. Und es kommt noch dicker! Wenn man beim Asuro nur die PWM-Ansteuerung für die Regelung verwendet, dann ist der Asuro beim Herunterregeln der Geschwindigkeit im Freilauf. Das liegt an der Ansteuerschaltung. Die Auswirkung ist in Bild "Freilauf.gif" zu sehen. Der Freilauf ist an der abfallenden Spannung (violett) im Bereich 70ms bis 240ms zu sehen. Zu dem Zeitpunkt ist die Ansteuerung hochohmig und es ist die Gegen-EMK des Motors zu sehen. In dem Bereich wird der Asuro nur durch die Reibung gebremst. Die Bremsphase ist dadurch sehr viel länger geworden.
Wie man sieht, ist so eine Dimensionierung eines Reglers noch von Randbedingungen abhängig. Man kann nicht alles mit einer Regelung kompensieren bzw. verbessern. Irgendwo sind durch die Mechanik und Elektronik die Grenzen gesetzt. Um weitere Verbesserungen zu erzielen, muss dort angesetzt werden. Glücklicherweise wird durch den D-Anteil bei Korrekturen immer voll ausgesteuert, so dass man beim Asuro zum Bremsen "BREAK" verwenden kann. Das macht allerdings die Ausführung des Reglers im Programm etwas komplizierter. Notfalls kann auch noch Rückwärts mit einbezogen werden, aber ob das sinnvoll ist, müssen erst noch Praxistests zeigen.
Tipp an Regelschleifenbauer anderer Projekte, womöglich lesen welche mit. Diese Erkenntnisse gelten auch für andere Positions- oder Lageregelungen, wie z.B. beim Quattrocopter. Die Ansteuerung der Motoren sollte für eine effektive Regelung mit genügend Reserven ausgestattet sein und aktiv bremsen können. Desweiteren ist auf eine sorgfältige Auswahl der Motoren bezüglich des Trägheitsmoments zu achten. Man sollte sich genau überlegen, ob ein Brushless Aussenläufer die richtige Wahl ist. In der Hinsicht sind bestimmt Glockenankermotoren die beste Wahl.
Im nächsten Beitrag wird eine vorläufige Parametrierung des Reglers festgelegt und dann geht es an die Umsetzung in Code.
Waste
Fortsetzung folgt
Fortsetzung:
Heute geht es darum, wie man vom Bodediagramm auf die Parameter Kp, Ki und Kd für den Regler kommt.
Ich habe nochmal die Sprungantwort auf die Begrenzung optimiert. Ich musste dazu den D-Anteil etwas zurücknehmen, damit das Einschwingen besser wird. Die Sprungantwort ist im Bild "PD1.gif" als grüne Kurve zu sehen. Das zugehörige Bodediagramm ist im Bild "olg3.gif". Die rote Kurve ist die "open loop gain" und die grüne Kurve ist die Verstärkung des Reglers. Zusätzlich habe ich noch einen I-Anteil hinzugefügt, da die Verstärkung des P-Anteils nicht ausreichen wird, um auch enge Kurven zu fahren. Eine Verstärkung von nur 3 kann die Ansteuerung (PWM) um maximal 3*60 = 180 verändern, weil der Sensor max. nur 60 liefert und das reicht nicht aus um das innere Rad soweit zu drosseln, dass auch sehr enge Kurven gefahren werden können. Ursprünglich war ich der Meinung der P-Anteil würde höher sein und da kann ich auf den I-Anteil verzichten, also brauch nur einen PD-Regler zu realisieren, aber das hat sich jetzt zerschlagen, ich muss doch einen PID-Regler machen. Das hat jetzt den Vorteil, dass auch der I-Anteil in die Erklärung mit einbezogen wird. Der I-Anteil ist im Bodediagramm links an dem Abfall der grünen Kurve bis ca. 1Hz zu sehen.
Die Parameter für den PID-Regler sind folgendermassen definiert:
Kp ist die Verstärkung des P-Teils
Ki = 1/Ti (Ti ist die Zeitkonstante des Integrators)
Kd = Td (Td ist die Zeitkonstante des Differenzierglieds)
Die Zeitkonstanten können zum einen aus der Simulationsschaltung direkt bestimmt werden als auch aus dem Bodediagramm. Dazu sind in dem Bild "regler_bode.gif" die Anteile des Reglers P, I und D einzeln dargestellt um die Zeitkonstanten herauszufinden. Die Zeitkonstanten errechnen sich aus den 0dB-Durchgängen der I- und D-Kurve. Der D-Anteil ist die rote Kurve, die kreuzt bei 0.712Hz die 0dB-Linie, d.h. fd=0.712Hz.
Damit ist: Kd = Td = 1/(2*pi*fd) = 0.225
Der I-Anteil ist die hellblaue Kurve, die kreuzt bei 1.59Hz die 0db-Linie, d.h. fi=1.59Hz.
Damit ist: Ki = 1/Ti = 2*pi*fi = 10
Der P-Anteil ist einfach, das ist die violette Kurve. Wie schon früher festgestellt ist Kp = 3 das entspricht den 9.5dB.
Somit sind die Parameter des Reglers bestimmt und es kann im nächsten Beitrag mit der Umsetzung in Code weitergehen.
Waste
Fortsetzung:
Heute geht es darum, wie das bisherige Wissen in einen Code umsetzt wird.
Hierzu eine Zusammenstellung der Formeln. Wer eine Herleitung der Formeln will, kann sich im WWW informieren, es gibt darüber genügend Literatur.
Begriffsdefinitionen:
W = Sollwert
X = Istwert
Xw = Regelabweichung
Y = Stellgrösse
Yp = P-Anteil von Y
Yi = I-Anteil von Y
Yd = D-Anteil von Y
Kp = Proportionalbeiwert
Ki = Integrierbeiwert
Kd = Differenzierbeiwert
dt = Taktzeit des Reglers
Formeln zur Berechnung:
Xw = W - X
Yp = Kp * Xw
Yi = Ki * (Isum + Xw * dt)
Isum: ist die Summe aller vergangenen (Xw * dt) Berechnungen
Yd = Kd * (Xw - Xwalt)/dt
Xwalt: ist der Xw-Wert des letzten Zyklus
Y = Yp + Yi + Yd
Zum besseren Verständnis habe ich in das Blockschaltbild die benützten Kürzel eingetragen (siehe Bild). Der Regler ist jetzt detailierter dargestellt.
Der Sollwert W ist in unserem Fall Null. Der Istwert X ist der ausgelesene Wert des Liniensensors. Die berechnete Stellgrösse Y ist die Korrektur, die auf den PWM-Wert zur Ausregelung gebracht wird. Man hat die Wahl, entweder die Stellgrösse Y je zur Hälfte im entgegengesetzten Sinn auf beide Motore zu geben oder nur einen Motor zu verlangsamen oder zu beschleunigen. Auf das Vorzeichen muss geachtet werden, sonst regelt er nicht aus.
So, jetzt kann mit dem Programmieren losgelegt werden! Wer will es selbst versuchen?
Mit den Parametern aus dem letzten Beitrag hat man alles, was man dazu braucht.
Kp = 3; Ki = 10; Kd = 0.225;
dt = 0.0016
Während Ihr inzwischen fleissig programmiert, werde ich mein vorläufiges Programm noch auf Vordermann bringen, um es hier reinstellen zu können.
Tipps:
Mit etwas Geschick kann man auf floating point verzichten und man kommt mit Integer aus.
Sorgfalt ist geboten um Überläufe zu verhindern.
Beim D-Anteil kommt prinzipbedingt ein sehr hoher Wert in der Berechnung vor. Die Weitergabe an den PWM-Wert muss begrenzt werden, aber der Rest darf nicht verworfen werden, sonst stimmt das Verhalten nicht mehr.
Waste
Fortsetzung folgt
Ohhh, liegt es am guten Wetter ?
Ich kann mir nicht vorstellen das sich da keiner traut.
Aber ich werde mal meine Versuche mit PD-Regler (mit float und long) mit deinen Werten umschreiben
Fortsetzung:
Hier ist mein Programm. Es ist soweit kommentiert, dass jeder damit klar kommen sollte.
/************************************************** *****************************
*
* Description: Asuro Linienverfolgung mit PID-Regler
* Version 1: Korrektur auf beide Motoren verteilt
* Autor: Waste 26.8.05
*
************************************************** ***************************/
#include "asuro.h"
#include <stdlib.h>
unsigned char speed;
int speedLeft,speedRight;
unsigned int lineData[2];
int x, xalt, don, doff, kp, kd, ki, yp, yd, yi, drest, y, y2, isum;
void FollowLine (void)
{
unsigned char leftDir = FWD, rightDir = FWD;
FrontLED(OFF);
LineData(lineData); // Messung mit LED OFF
doff = (lineData[0] - lineData[1]); // zur Kompensation des Umgebungslicht
FrontLED(ON);
LineData(lineData); // Messung mit LED ON
don = (lineData[0] - lineData[1]);
x = don - doff; // Regelabweichung
isum += x;
if (isum > 16000) isum =16000; //Begrenzung um Überlauf zu vermeiden
if (isum < -16000) isum =-16000;
yi = isum/625 * ki; //I-Anteil berechnen
yd = (x - xalt)*kd; // D-Anteil berechnen und mit
yd += drest; // nicht berücksichtigtem Rest addieren
if (yd > 255) drest = yd - 255; // merke Rest
else if (yd < -255) drest = yd + 255;
else drest = 0;
if (isum > 15000) BackLED(OFF,ON); // nur zur Diagnostik
else if (isum < -15000) BackLED(ON,OFF);
else BackLED(OFF,OFF);
yp = x*kp; // P-Anteil berechnen
y = yp + yi + yd; // Gesamtkorrektur
y2 = y/2; // Aufteilung auf beide Motoren
xalt = x; // x merken
speedLeft = speedRight = speed;
MotorDir(FWD,FWD);
if ( y > 0) { // nach rechts
StatusLED(GREEN);
speedLeft = speed + y2; // links beschleunigen
if (speedLeft > 255) {
speedLeft = 255; // falls Begrenzung
y2 = speedLeft - speed; // dann Rest rechts berücksichtigen
}
y = y - y2;
speedRight = speed - y; // rechts abbremsen
if (speedRight < 0) {
speedRight = 0;
}
}
if ( y < 0) { // nach links
StatusLED(RED);
speedRight = speed - y2; // rechts beschleunigen
if (speedRight > 255) {
speedRight = 255; // falls Begrenzung
y2 = speed - speedRight; // dann Rest links berücksichtigen
}
y = y - y2;
speedLeft = speed + y; // links abbremsen
if (speedLeft < 0) {
speedLeft = 0;
}
}
leftDir = rightDir = FWD;
if (speedLeft < 20) leftDir = BREAK; // richtig bremsen
if (speedRight < 20) rightDir = BREAK;
MotorDir(leftDir,rightDir);
MotorSpeed(abs(speedLeft),abs(speedRight));
}
int main(void)
{
unsigned char sw;
Init();
MotorDir(FWD,FWD);
StatusLED(GREEN);
speed = 150;
kp = 3; ki = 10; kd = 70; // Regler Parameter kd enthält bereits Division durch dt
sw = PollSwitch();
if (sw & 0x01)
{ki=20;}
if (sw & 0x02)
{speed = 200;}
if (sw & 0x04)
speed = 100;
if (sw & 0x08)
kd = 35;
if (sw & 0x10)
kd = 70;
if (sw & 0x20)
kd = 140;
FrontLED(ON);
LineData(lineData);
speedLeft = speedRight = speed;
while(1){
FollowLine();
}
return 0;
}
Ergänzende Hinweise:
Ich habe den Differenzierbeiwert kd gleich durch dt geteilt, damit ich mit Integer rechnen kann.
kd/dt = 0.225/0.0016 = 140
Mit diesem Wert zittert (schwingt) der Asuro leicht. Als gute Werte haben sich 40 bis 70 herausgestellt. Da fährt der Asuro schön stabil. In der main Routine kann man die Parameter verändern, wenn man nach dem Einschalten des Asuros eine der Tasten drückt bis die Motore anlaufen. Da kann man verschiedene Einstellungen testen.
Das Zittern bei kd=140 liegt vermutlich an dem zu grossen Getriebespiel. Meinen Asuro kann ich etwa 2mm hin und her schwenken ohne dass sich die Motoren mitdrehen. Dadurch ergibt sich eine zusätzliche Totzeit , die das Schwingen erklären könnte. Ganz sicher bin ich mir aber nicht, das müsste man noch genauer untersuchen. Aber mit kleineren kd-Werten funktioniert der Regler wunderbar. Bei Kd=70 ist er sehr schnell und stabil. Bei kd=35 ist er schon deutlich langsamer aber immer noch sehr stabil. Bei noch kleineren Werten sieht man schon leichtes Nachschwingen.
Die Regelabweichung ist in meinem Programm x anstatt Xw. Da der Sollwert 0 ist, habe ich gleich den Istwert x für die Berechnungen genommen. Ansonsten sollten die Variablen mit meinem letzten Beitrag übereinstimmen.
Der I-Anteil wird durch Begrenzen von Isum auch begrenzt. Bei ki=10 ist der Grenzwert 256, das ist praktisch Vollausschlag an den Motoren. Mehr braucht man nicht, es könnte sogar eine niedrigere Begrenzung sinnvoll sein, um bei S-Kurven nicht auszurasten.
Der D-Anteil kann sehr hohe Werte annehmen, die in einem Zyklus gar nicht verwertet werden können. Um dennoch das richtige Verhalten des Reglers zu erreichen, wird der nicht verwertete Rest in der Variable "drest" gespeichert und bei den nächsten Zyklen wieder berücksichtigt.
Das Programm ist auch noch komplett mit hex-File in einer zip-datei angehängt. Probiert es mal aus. Da mein Asuro mit den grösseren Akkus etwas schwerer ist als im Original, können sich bei Euch etwas andere Ergebnisse herausstellen. Ich selber werde auch noch mit den Parametern spielen und einige Freiheitsgrade testen.
Waste
Als vorhin nachhause kam, habe ich dein fertiges Programm gesehen. Das musste ich doch sofort testen.
Soweit ich es bisher sehen kann ist die Regelung, ausgezeichnet.
Ich habe bei 100,150 und 200 keine Fehler bemerkt. Kein zittern oder ausbrechen !
Meine Linie ist ein 3m langer schwarzer Klebestreifen 24mm breit auf einer Sperrholzplatte 120+80 cm. Kurvenradius 140 mm.
Ich habe auch 4 AA Akkus auf meinem Asuro von denen zwei hinten überstehen. Er wiegt 270 Gramm. Auf dem Vorderrad, ein durchbohrter KugelKnopf mit 14mm Durchmesser liegen nur noch 20 Gramm.
Sternthaler
28.08.2005, 03:53
SUPER,
läuft perfekt auch beim meinen 'krummen' Motoren!
Weitere Komentare nach Programm-Analyse. (siehe Uhrzeit)
GANZ Viele Grüße von Sternthaler
Ui, da hat einer ne Nachtschicht eingelegt. :)
Es freut mich, dass es bei Euch auch so gut funktioniert.
Ich bin auch noch am Testen, es gibt noch so viele Varianten durchzuspielen.
Gruss Waste
Hier mein Testergebnis:
1. In schnell gefahrenen Kurven flog der Asuro noch raus. Eine Verbesserung brachte eine Erhöhung von kp und dafür ein Veringern von ki. Die optimalsten Werte für meinen Asuro sind nun:
kp=5; ki=5; kd=70;
2. Ich habe kurze Schwankungen (im 4er Takt) bei den Sensordaten festgestellt. Dies brachte durch die Differenzierung starke Auschläge auf die Ansteuerung auch bei Geradeausfahrt. Dadurch wurde die Fahrt unnötig gebremst. Abhilfe schaffte eine Filterung der Sensordaten über 4 Zyklen.
Mit diesen beiden Verbesserungen fährt nun mein Asuro auch mit Vollgas über meinen Testparcours.
Das neue Programm incl. hex-file habe ich angehängt.
Gruss Waste
Hi waste!
Zu deinem Proggi: Uiuiuiuiui!! Der Asuro fährt seine Bahnen sauberst ab, wackelt kein einziges Mal und gibt an den richtigen Stellen Gas! Richtig richtig gut!!!
An einigen Stellen bricht er manchmal noch aus (ich hab in meiner Bahn einige ca. 120° - 150° Ecken eingebaut), aber er fährt sauberst durch die Gegend. Der Rest dürfte über eine Anpassung der Regelparameter zu machen sein.
Ich guck mir das Proggi auch nochmal genauer an, wenn: ZEIT!
Jupp, hast ja wahrscheinlich auch gemerkt, daß ich zu dem PID Regler im Laufe der Wochen nix geschrieben habe, gleiches Argu: ZEIT! Ist gerade Jobsuche angesagt, von daher fahr ich fast jeden Tach durch die Gegend.
Sobald die Phase aber wieder vorbei ist, guck ich mir das Proggi mal genauer an, schaut echt interessant aus und läuft phänomenal gut!
(Damit machst du auf dem Robocup glaub ich fast jeden platt - *grins* - Asuro wins vs 1000 Euro Bot - stellt euch das mal vor ;D )
Hallo payce!
Ja, lange nichts mehr von Dir gehört. Schön, dass Dir das Programm gefällt.
Der Sinn der Sache war für mich, einmal auch in Mechatronik einen klassischen Regler von Grund auf zu entwerfen. Wenn ich schon mitreden will, dann sollte ich es auch einmal gemacht haben. :) In Mechatronik hatte ich nämlich noch keine Erfahrung, im Gegensatz zur Elektronik wo ich schon zig Regler entworfen hatte. Ich habe es nun auch nach der Methode, wie in der Elektronik üblich durchgezogen. Für manche bestimmt zu aufwendig und detailiert, denn Mechaniker gehen da üblicherweise sehr viel pragmatischer ran. Da gibt es Tabellen und Einstellregeln nach denen ausgewählt und eingestellt wird. Wenn es hilft, ist es ok, aber ich wollte es verstehen.
Ein schöner Nebeneffekt ist natürlich, dass es auch noch gut funktioniert. Zudem ist es ein Reglerbeispiel mit dem man spielen kann und sich das geänderte Verhalten beim Ändern der Parameter sichtbar machen kann.
Der nächste Schritt wäre jetzt noch der Fuzzy-Regler. Vielleicht findet sich dazu ein Fuzzy-Experte.
Gruss Waste
@Waste
Das Programm (Line_PID.zip) funktioniert bei mir sehr gut.
Gruß Winne
@Waste
Ich habe meinen Asuro mit Deinen Programm beim Linienverfolgen gefilmt. Die Filme + Code kann man sich dann von meiner Homepage saugen.
Gruß Winne
Hallo Winne!
Schöne Videos!
Hab auch eins gemacht. Meins ist allerdings nicht so schön, aber die Geschwindigkeit kommt deutlich raus. Der Asuro fährt den Testkurs mit Vollspeed.
Hier der Link: http://dl4.rapidshare.de/files/4647109/73878680/DSCN2854.MOV
Gruss Waste
@ waste
Ok, ich habe mir das Video angesehen!
Gruss Winne
Hi!
Bin zu faul zum suchen...wie schnell fährt der Asuro eigentlich? ca. 30cm/s?
Wie breit ist so eine Spur auf der getestet wurde? 1,5cm?
Weil unser Roboter fährt nur etwas langsammer auf einer 1,5cm breiten Spur mit einem minimalen Radius von 15cm. Die Überlegung war erst mal, dass man den Abstand Achse-Sensoren nicht größer als ungefähr 15cm macht, um in engen Kurven das innere Rad nicht rückwärts drehen lassen zu müssen, um auf der Spur zu bleiben. Ist das soweit richtig gedacht?
Aber nun zur eigentlichen Frage, und zwar die Anordnung der Sensoren, wobei wir Reflexkoppler CNY70 (also digitale Auswertung) verwenden wollen. Der Asuro hat eine 'Sehbreite' von 1,5cm, was ich etwas wenig finde.
Meint ihr 8 Sensoren mit einem Abstand von jeweils 1cm ('Sehbreite'=7cm, Auflösung bei 1,5cm Spur 0,5cm) sind angemessen und schnell (nat. mit darauf angepasstem PID-Regler) oder sollte man es eher dem Asuro annähern und die Sensoren dichter Packen und dann eine geringere 'Sehbreite' für eine höhere Auflösung in Kauf nehmen?
Ich hoffe das Problem heilwegs verständlich dargestellt zu haben; mehr als 8 Sensoren kommen an sich nicht in Frage.
Grüße; ähM_Key
pebisoft
11.09.2005, 17:59
ihr könnt die spurverfolgung 100% machen, wenn ihr euch neue zahnräder kauft, die etwas teurer sind und aus anderer plaste. auch ist die bhrung zu gross für die beigelegte welle. es stimmt hinten und vorne nicht. der anpressdruck des motor lässt beim beschleunigen nach, das ein zu grosse leerlaufspiel vom zahnrad und motor zustande kommt. hatte mir damals zu anfang gleich bessere edelstahlwellen geholt und neu zahnräder. habe auch das axiale wandern beseitigt und siehe da der robby fuhr in der spur mit meinen einfachen programm in winavr-c wie ein schneekönig. die rechnungen die du oben anwendest, kann der asuro ohne meine änderung nicht umsetzen, wenn ähnliche ergebnisse erzeilt werden, ist es zufall.
ich habe vorn ein rad vom legomotorrad untergebaut, schwenkbar.
nach dem er gut lief, war meine anderer gedachter aufbau zu schwer und verwende den asuro nicht mehr. hatte schnell mein ziel ereicht.
mfg pebisoft
@ ähM_Key
Bin zu faul zum suchen...wie schnell fährt der Asuro eigentlich? ca. 30cm/s?
Wie breit ist so eine Spur auf der getestet wurde? 1,5cm?
Der Asuro hat eine Höchstgeschwindigkeit von ca. 0,5m/s.
Meine Spur ist so ca. 1,2 - 1,5cm breit.
Stimmt, der minimale Radius des Kurses und die Geometrie des Roboters sollten so sein, dass sich das innere Rad nicht rückwärts drehen muss.
Wie man am Asuro sieht, ist bei einer schnellen Regelung die schmale Erkennung kein Problem, obwohl es bei Höchstgeschwindigkeit schon ziemlich an der Grenze ist.
Bei einem digitalen Sensor mit diskreten Schritten kann zwischen zwei Schritten nicht geregelt werden. Das ist wie bei einem 2-Punktregler, nur eben mit mehr Schritten. Der Roboter wird also zwischen den Auflösungsschritten pendeln, auch wenn die Regelung stabil ist. Das ist zu bedenken.
Gruss Waste
Hallo Waste,
heute habe ich mal ein wenig Dein Programm ausprobiert. Der Asuro fährt ziemlich flot um die Kurven und wackelt auch nicht. Allerdings verliert er gerne bei zu engen Rechtskurven die Linie. Wenn er die Linie mal verloren hat, fängt er an sich immer schneller im Kreis zu drehen.
Ansonsten: Saubere Arbeit, wie alles was Du bisher gemacht hast. Gratulation !
Beste Grüße,
stochri
Hallo stochri
Ja, wenn er mal ausrastet, dann fährt er im Kreis. Das liegt am I-Anteil des PID-Reglers, der einen Offset des Liniensensor aufsummiert, bis er nur noch im Kreis fährt.
Gruss Waste
Sternthaler
13.09.2005, 23:12
hallo mal wieder.
Nach geraumer Zeit mal eine Zusammenfassung. --> So wie ich sie verstanden habe. <---
Alle hier aufgeführten Punkte habe ich aus den Beiträgen von waste und Manf und können somit jederzeit in diesem Thread nachvollzogen werden. (Bis auf meine Tippfehler)
Mein Anliegen war es, die von waste erstellte Ausarbeitung für genau meinen Asuro nachzurechnen.
Für die einzelnen Punkte habe ich folgende Schreibweise gewählt:
Beitragszeile: Seite im Thread; Autor; Datum Uhrzeit; Thema
Inhaltszeile : Kürzel aus folgender Legende; laufende Nummer [laufende Nummer(n), die zur Berechnung der aktuellen Zeile benutzt wurde(n)]
Legende der Kürzel:
MA = Messen mit Asuro
EH = Ermittelbar aus Handbuch
RE = REchnung mit bekannten werten
WI = WIssen (erfahrung von waste)
MM = Messen mit zusätzlichem Messgerät
VO = VOrgabe von waste
AB = ABleitung aus messergebnissen
?? = unbekannte verwendung/berechnung
?R = unbekannte Rechnung (waste nutzt einen simulator)
P1 = Programm: Liniensensor Übertragungsmaß
P2 = Programm: Beschleunigungsmessung beide Motoren
P3 = Programm: Beschleunigungsmessung ein Motor
K1 = Konstante: 255 -> Maximalwert für Mortorspeed
K2 = Konstante: 0,1050 Meter -> Radabstand Asuro
K3 = Konstante: 0,0525 Meter -> halber Radabstand Asuro
K4 = Konstante: 170 g -> normales Gewicht vom Asuro
OK, auf geht's
<table><tr><td width="100" colspan="2">S1 waste</td><td align=left>18.08.2005 22:52 Beschleunigung</td></tr><tr><td>MA</td><td>1 [P1]</td><td>Übertragungsmaß Liniensensor (Abstand von Mitte) 14/mm</td></tr><tr><td>EH</td><td>2</td><td>Verzögerung AD-Wandler 1,6ms</td></tr><tr><td>MA</td><td>3 [P2]</td><td>Beschleunigung ca. 130ms (1*tau)</td></tr><tr><td>MA</td><td>4</td><td>Vmax ca. 0,51 m/s</td></tr><tr><td>RE</td><td>5 [4|K1]</td><td>Verhältniss PWM-Wert zur Geschwindigkeit PWM/v = 0,51/255 = 0,002m/s</td></tr><tr><td>WI</td><td>6</td><td>Trägheitsmoment Motor 1,12gcm^2;</td></tr><tr><td>MM</td><td>7</td><td>Fahrzeugmasse (bei waste) 240g</td></tr><tr><td>RE</td><td>8 [6]</td><td>Motorträgheit in äquivalenter Masse 2*190g</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td width="100" colspan="2">S2 Manf</td><td>19.08.2005 21:47 Trägheitsmoment GEMESSEN mit Kleiderbügel</td></tr><tr><td>MM</td><td>9</td><td>Trägheit Achsmittelpunkt 200 micro-Kgm^2;</td></tr><tr><td>MM</td><td>10</td><td>Trägheit um ein Rad 668 micro-Kgm^2;</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td width="100" colspan="2">S2 waste</td><td>20.08.2005 00:41 Massenberechnung</td></tr><tr><td>RE</td><td>11 [10|K2]</td><td>äquivalente Masse; Drehung um ein Rad m=I/r^2; 668 micro /0,105^2=60g</td></tr><tr><td>RE</td><td>12 [9|K3]</td><td>äquivalente Masse; Drehung um Achsmitte m=I/r^2; 200 micro /0,0525^2=72g</td></tr><tr><td>MM</td><td>13 [7|K4]</td><td>geändertes Gewicht bei wastes Asuro 240g (waste Asuro) / 170g (std. Asuro)</td></tr><tr><td>RE</td><td>14 [11|13]</td><td>äquivalente Masse (Rad) waste 60g * 240g/170g = 85g</td></tr><tr><td>RE</td><td>15 [12|13]</td><td>äquivalente Masse (Achsmitte) waste 72g * 240g/170g = 102g</td></tr><tr><td>?R</td><td>16 [8|14]</td><td> " plus Motorträgheit = 310g</td></tr><tr><td>RE</td><td>17 [8|15]</td><td> " plus Motorträgheit = 292g</td></tr><tr><td>MA</td><td>18 [P3]</td><td>Beschleunigung um nur ein Rad ca. 100ms</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td width="100" colspan="2">S2 waste</td><td>20.08.2005 19:38 Analyse Frequenzbereich / Bodediagramme</td></tr><tr><td>VO</td><td>19</td><td>v-soll = 0,4m/s</td></tr><tr><td>AB</td><td>20 [1]</td><td>Arbeitsbereich der Reglung = 15mm</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td width="100" colspan="2">S3 waste</td><td>21.08.2005 17:03 Regler- und Simulationsmodel</td></tr><tr><td></td><td></td><td>Hier wiederholt waste das Regler- und das Simulationsmodel als Bild</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td width="100" colspan="2">S3 waste</td><td>22.08.2005 19:06 Reglerstabilität</td></tr><tr><td>AB</td><td>21 [5]</td><td>Antrieb statisch = 0,002m/s</td></tr><tr><td>AB</td><td>22 [3]</td><td>Steigung PT1-Block = 0,0027m/s</td></tr><tr><td>AB</td><td>23 [5|18]</td><td>Zeit PT1-Block = 120ms (kleinstes Trägheitsmeoment drehen)</td></tr><tr><td>VO</td><td>24</td><td>Intergrator 1s</td></tr><tr><td>??</td><td>25</td><td>Sensor Hebenwirkung = 17/103 = 0,75</td></tr><tr><td>AB</td><td>26 [1]</td><td>Sensor Empfindlichkeit = 14/mm</td></tr><tr><td>AB</td><td>27 [2]</td><td>Totzeit AD-Wandler = 1,6ms</td></tr><tr><td>?R</td><td>28</td><td>P-Anteil auf 1 ergibt: Amplitidenrand = 25dB (Stabilitätsgrenzen)</td></tr><tr><td>?R</td><td>29</td><td>P-Anteil auf 1 ergibt: Phasenrand = 27Grad (Stabilitätsgrenzen)</td></tr><tr><td>AB</td><td>30 [23]</td><td>Hier folgt eine Erlärung von waste:</td></tr><tr><td></td><td></td><td>P-Anteil auf 18 -> entspricht 18dB -> dadurch Phasenerhöhung</td></tr><tr><td></td><td></td><td>Grund: Integrator mit Phasendrehung -90Grad -> PT1-Zeitkonstante 120ms</td></tr><tr><td></td><td></td><td>Grenzfrequenz folgt zu 1,3Hz, da Phase um 45Grad gedreht ist (Verstanden?)</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td width="100" colspan="2">S3 waste</td><td>22.08.2005 20:18 Reglerstabilität Teil 2</td></tr><tr><td></td><td></td><td>Um das Problem der Phasendrehung im PT1-Block zu beheben muss im Regler</td></tr><tr><td></td><td></td><td>das 'Gegenteil' inplementiert werden. -> Differenzierglied (D-Anteil)</td></tr><tr><td>AB</td><td>31 [23]</td><td>D-Anteil wird somit zu 120ms gesetzt.</td></tr><tr><td>SI</td><td>32</td><td>Hierdurch geht der Phasenrand auf 85Grad hoch.</td></tr><tr><td></td><td></td><td>Somit kann der P-Anteil erhöht werden.</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td width="100" colspan="2">S3 waste</td><td>23.08.2005 20:57 Weitere Überlegungen</td></tr><tr><td></td><td></td><td>Der D-Anteil bewirk einen 'Vorhalt' um die Motorverzögerung auszugleichen.</td></tr><tr><td>WI</td><td>33 [28|29]</td><td>Der P-Anteil wird um den Faktor 3 erhöht. P-Anteil = 1*3=3</td></tr><tr><td></td><td></td><td>Die Simulation ergibt ein besseres Einschwingverhalten um den Faktor 3.</td></tr><tr><td></td><td></td><td>Hier muss aber noch optimiert werden, da der Asuro sonst eine Ansteuer-</td></tr><tr><td></td><td></td><td>spannung von 100 Volt liefern müsste.</td></tr><tr><td></td><td></td><td>Wird die Ansteuerspannung auf 5V begrenzt, zeigt die Simulation ein Überschwingen.</td></tr><tr><td></td><td></td><td>Dies wird hauptsächlich durch die freilaufenden Asuro-Motoren ausgelöst.</td></tr><tr><td></td><td></td><td>FAZIT: Hardware + Ansteuerung bergen Probleme in der Reglung.</td></tr><tr><td></td><td></td><td>LÖSUNG: Der D-Anteil steuert immer VOLL aus -> Beschleunigung, also kein Leerlauf.</td></tr><tr><td></td><td></td><td>Der andere Motor kann mit BREAK bzw. RWD schnell verzögert werden.</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3"></td></tr><tr><td width="100" colspan="2">S3 waste</td><td>25.08.2005 23:25 Umsetzung der Bodediagramme in Kp, Ki und Kd</td></tr><tr><td></td><td></td><td>Die Sprungantwort wurde optimiert.</td></tr><tr><td></td><td></td><td>D-Anteil zurückgenommen -> besseres Einschwingen</td></tr><tr><td></td><td></td><td>Wegen 'Freilauf' im PWM-Bremsbereich durch zusätzlichen I-Anteil verbessert,</td></tr><tr><td></td><td></td><td>da D-Anteil nicht ausreicht.</td></tr><tr><td>RE</td><td>34 [1|33]</td> <td>D-Anteil=3 kann PWM nur um 3*60=180 ändern. (60=max.Wert aus Kennlinie Sensor)</td></tr><tr><td></td><td></td><td>--> Ableitung aus dem Bodediagram (links, abfallende grüne Kurve bis ca. 1HZ)</td></tr><tr><td></td><td></td><td>--> Parameterdefinition:</td></tr><tr><td></td><td></td><td>Kp = Verstärkung P-Anteil</td></tr><tr><td></td><td></td><td>Ki = 1/Ti mit Ti=Zeitkonstante Integrator</td></tr><tr><td></td><td></td><td>Kd = Td mit Td=Zeitkonstante Differenzierglied</td></tr><tr><td></td><td></td><td></td></tr><tr><td></td><td></td><td>Bild 'regler_bode.gif' von waste stellt die P,I und D-Anteile dar</td></tr><tr><td></td><td></td><td>wobei die 0-dB-Durchgänge für I und D relevant sind.</td></tr><tr><td></td><td></td><td></td></tr><tr><td>SI</td><td>35</td><td>D = rote Kurve -> 0,712 Hz (fd)</td></tr><tr><td>SI</td><td>36 [35]</td><td>--> Kd = Td = 1/(2*PI*fd) = 0,225</td></tr><tr><td>SI</td><td>37</td><td>I = hellblaue Kurve -> 1,59 Hz (fi)</td></tr>
<tr><td>SI</td><td>38 [37]</td><td>--> Ki = 1/Ti = 2*PI*fi = 10</td></tr><tr><td>SI</td><td>39</td><td>P = violette Kurve</td></tr><tr><td>SI</td><td>40 [33]</td><td>--> Kp = 3</td></tr><tr><td colspan="3"></td></tr></table>
So, dass sind die von mir gefundenen Werte und Rechenschritte.
Fragen werden folgen, aber ich möchte erst auf Reaktionen warten. Vor allem auf Korrekturen meiner Ausfertigung.
Viele Grüße von Sternthaler
Sternthaler
13.09.2005, 23:17
Entschuldigt die 'Lücke'.
Ich habe ein bisschen Text, und dann mit '<table>' '</table>' die Daten geschrieben. Vor '<table>' scheint die Lücke eingefügt zu werden. Ich bekommen sie nicht weg.
Ausserdem soll ² hoch 2 sein
und µ soll halt micro sein.
Viele Grüße von Sternthaler
Nachtrag:
'Lücke' ist weg.
² ist jetzt ^2
µ ist jetzt micro
Liegt wohl daran, dass hier bestimmt HTML verboten ist, oder?
Test
Test :D (War zwischen den "Test"s nen Zeilenumbruch?)
Nein, es liegt daran das hie rim Forum sämtliche leerzeichen innerhalb des Tabellencodes entfernt werden müssen.
Also aus z.B.
<tr><td>WI</td><td>6</td> <td>Trägheitsmoment Motor ...
musst du
<tr><td>WI</td><td>6</td><td>Trägheitsmoment Motor ...
machen usw. Es wäre schön wenn du das noch editieren könntest
Sternthaler
15.09.2005, 00:02
Nein, es liegt daran das hier im Forum sämtliche Leerzeichen innerhalb des Tabellencodes entfernt werden müssen.
Ja, danke, das hat fast komplett funktioniert.
Kleiner Hinweis um die 'Lücke' komplett zu entfernen: Es müssen auch alle Zeilenumbrüche hinter den einzelnen Zeilen (also bei mir nach </tr> entfernt werden. (Möglicher Grund??: DOSen-Rechner speichern mit CR/LF und der hier bestimmt genutzte TUNIX-Server speichert nur mit CR. Evl. kommen da noch ein paar 'Lücken'-Zeilen hinzu.)
HTML verboten
Ja, das war auch mein erster Gedanke. Zum Glück schaut Frank hier zu und hilft den Anfängern.
Auf alle Fälle vielen Dank für den Hint und
Schöne Grüße von Sternthaler
Hi!
Wie man am Asuro sieht, ist bei einer schnellen Regelung die schmale Erkennung kein Problem, obwohl es bei Höchstgeschwindigkeit schon ziemlich an der Grenze ist.
Bei einem digitalen Sensor mit diskreten Schritten kann zwischen zwei Schritten nicht geregelt werden. Das ist wie bei einem 2-Punktregler, nur eben mit mehr Schritten. Der Roboter wird also zwischen den Auflösungsschritten pendeln, auch wenn die Regelung stabil ist. Das ist zu bedenken.
...langsam hast du mich überzeugt, und ich bin auch der Meinung, dass es besser ist den PID-Regler mit analogen statt mit digitalen Werten zu füttern. Da noch nix (wie beim Asuro) vorgegeben ist stehen mir noch alle Möglichkeiten in der Dimensionierung und Anordnung der LED's offen.
Fest steht, dass man in der Mitte ein große LED mit großem Abstrahlwinkel, vielleicht sogar 2 leicht schräg angebrachte brauchte. Ich dachte an IR statt rotem Licht.
So nun komm ich mal auf den Punkt; meint ihr, dass es dem Asuro Geschwindigkeitsvorteile bringen würde, wenn er mehr als 15mm mit seinem Liniensensor abdecken könnte (ich weiß du hast geschrieben es ist kein Problem)? Ich stelle mir vor, dass ein solcher Roboter dann ev. 'gedämpfter' fahren kann.
Wie gesagt unsrer fährt mit ca. 30cm/s, minimaler Kurvenradius 15cm, Abstand Rad-Sensoren ca. 15cm, Radstand ~20cm.
Die Motoren, Getriebe, Räder sind vorgegeben, desshalb kann man dort nix mit der Geschwindigkeit rausholen. Desshalb kommt es auch auf eine annähernd ideale (also optimale ;) ) Regelung an.
Also, in welchem Anstand würdet ihr die Liniensensoren anbringen?
Danke euch, Grüße; ähM_Key
Hallo ähM_Key,
da Dein Robot etwas grösser als der Asuro ist, würde ich auch die Sensoren etwas weiter als beim Asuro anordnen. Beim Asuro sind es 15mm, bei Deinem sollten also 20 bis 25mm ausreichend sein. Bei zu großem Abstand wird die Empfindlichkeit zu gering und damit der Fremdlichteinfluss zu groß.
Gruß Waste
Sternthaler
21.09.2005, 16:03
Hallo ähM_Key,
meine folgende Überlegung müsste doch eigendlich passen:
Wenn beide Liniensensoren genau über den Kanten der Linie angebracht sind, dann müsste doch eine Abweichung von der Mitte das beste auszuwertende Ergebniss liefern. Die Idee ist, dass die Messergebnisse beider Sensoren so am schnellsten einen 'scharfen' Kontrast bekommen müssten. Der Normalfall wäre ja ein Schwarz/Weiss-Mittelwert, und bei einer Abweichung ist ein Sensor 'plötzlich' über 'reinem' Weiss und der andere über 'reinem' Schwarz.
Dies gilt dann natürlich nur bei 'großen' Abweichungen, die aber durch den Regler gesteuert nicht auftreten sollten. Somit bin ich nicht sicher, ob dieser Ansatz überhaupt richtig ist.
Mein Fazit wäre also die Linienbreite an die Hardware (Abstand der Sensoren) anzupassen.
Schöne Grüße von Sternthahler
Sternthaler
22.09.2005, 00:59
Hallo Leute,
ich poste jetzt mal die Sourcen um waste-PID mit Sternthaler-PID gleichzeitig im ASCURO zu haben. (Immer dran denken, dass Sternthaler einen schlechten rechten Motor hat! Parameter kann aber jetzt mit ASURO-Tastern geändert werden.)
Es besteht die Möglichkeit, einige Parameter mit den Tastern am ASURO zu ändern so dass nicht ständig neu geflascht werden muss. (Bitte nutzt ein Terminalprogramm und IR um die Änderungen der (änderbaren Parameter) zu sehen)
Als Bedinungsanleitung könnt ihr in test.c nachsehen.
Kurzform:
Taste 1 bis 3: Ändern die Parameter
Taste 4 und 5: Starten unterschiedlicher PID's (Sternthaler, waste)
Taste 6: Sendet im ASURO gesammelte Infos an den PC
Wenn der ASURO unsere Lieblingslinie verfolgt, kann jederzeit mit einem beliebigen Tastendruck ins 'Hauptprogramm' zurückgesprungen werden.
Allgemein kann ich sagen, dass der PID von waste einfach besser ist. Hat ja schliesslich auch Hand und Fuss und Simulator :-)
Grundsätzlicher Unterschied:
Durchschnittsgeschwindigkeit bei waste ist schlecht.
Geschwindigkeitsbereich bei waste ist sehr gut.
Motordifferenzen ausregegeln ist bei waste EXTREM gut.
Rechenzeitverbrauch ist bei waste sehr hoch.
Aufgabenstellung gelöst ist bei waste UNENDLICH GUT. (lob, lob, lob)
Viel Spaß und lange Nächte wünscht euch
Sternthaler
Rage_Empire
15.10.2005, 17:08
Hab hier ein Prog gefunden, vieleicht intressierts euch ja:
http://www.auto.tuwien.ac.at/~jlukasse/project.htm
Weil es doch öfters nervt, hier ist ein Testprogramm für den LinienSensor des ASURO.
Ausgabe über seine LED's und zum HyperTerminal.
Hab hier ein Prog gefunden, vieleicht intressierts euch ja:
http://www.auto.tuwien.ac.at/~jlukasse/project.htm
Hi!
Sieht nicht schlecht aus, aber braucht man dafür nicht ein funktionsfähiges Mathematica, damit man an den Kernel kommt?
Grüße, ähM_Key
Hallo Waste,
welches Modell hast du eigentlich für die Bewegung des Roboters verwendet. Kannst du bitte mal die Bewegungsgleichungen angeben.
MfG Jeffrey
Hallo jeffrey,
das Modell des Antriebs ist vereinfacht ein Verzögerungsglied 1. Ordnung (PT1-Block). Die Bewegungsgleichung ist:
x'' = (K/T)*y - (1/T)*x'
x'': Beschleunigung, 2. Ableitung der Position x
x': Geschwindigkeit, 1. Ableitung von x
y: Stellgröße
K: Verstärkung des PT1-Blocks
T: Zeitkonstante des PT1-Blocks
Gruß Waste
Hi,
danke, aber das ist leider nicht das was ich gemeint habe. Wie die Gleichung für ein PT1-Glied aussieht weiß ich.
Du betrachtest ja aber immer nur einen Motor, damit kannst du natürlich gut die Analysen für eine Drehzahlregelung machen. Aber das Ziel ist ja eine Lageregelung, dazu benötigt man ja auch ein Modell für die Bewegung des Roboters. In die Änderung der Lage gehen ja die Drehzahlen w1 und w2 ein, sowie der Abstand der Sensoren zum Drehpunkt. Außerdem noch der Sinus bzw. Cosinus von Phi, allerdings hägt Phi_Punkt auch von w1 und w2 ab
Ich denke es sollte eine Kaskadenregelung realisiert werden, innen der Drehzahlregelkreis für Links und Rechts, außen der Lageregelkreis, der die Drehzahlen vorgibt. Dabei handelt es sich ja um einen Mehrgrößensystem, da linke und rechte Drehzahl vorgegeben werden muss, ich denke um das zu optimieren ist es auch wichtig die Bewegungsgleichungen des gesammten Roboters in der Ebene zu betrachten.
MfG Jeffrey
Hallo jeffrey,
ok, jetzt weiß ich, auf was du hinaus willst, aber die Vereinfachungen im Modell wurden in diesem Beitrag bereits diskutiert, sind vielleicht überlesen worden bei der Länge des Threads.
Man kann das Modell zur Vereinfachung auf einen Motor reduzieren, da die Untersuchung gezeigt hat, dass es ziemlich gleich ist, ob man die Stellgröße auf beide Motoren aufteilt oder nur einen Motor drosselt oder beschleunigt. Es kommt nur auf die Differenzgeschwindigkeit der beiden Räder an und für die Simulation ist es um so leichter je einfacher das Modell ist.
In die Änderung der Lage gehen ja die Drehzahlen w1 und w2 ein, sowie der Abstand der Sensoren zum Drehpunkt. Außerdem noch der Sinus bzw. Cosinus von Phi, allerdings hägt Phi_Punkt auch von w1 und w2 ab. Das stimmt! Die Sache wurde auch betrachtet und diskutiert. Siehe: https://www.roboternetz.de/phpBB2/viewtopic.php?p=107311#107311
Die Analyse ergab, dass man es vernachlässigen kann.
Ich denke es sollte eine Kaskadenregelung realisiert werden
Um ehrlich zu sein, habe ich bei der Realisierung überhaupt nicht an eine Kaskadenregelung gedacht und wenn ich so im Nachhinein darüber nachdenke, wird das mit dem Asuro auch nicht so einfach gehen. Der Asuro hat zwar eine Odometrie, ist aber für eine schnelle Drehzahlregelung nicht geeignet. Die Totzeit durch die Odometrie wird den gesamten Regelkreis vermutlich langsamer machen als ohne Kaskadierung.
Ich sehe, du kennst dich sehr gut aus. Falls du bereits eine Kaskadenregelung realisiert hast, deine Erfahrungen würden mich interessieren.
Gruß Waste
Hi,
ja ich habe etwas Ahnung davon, ich studiere Kybernetik.
Versteh ich das richtig, dass du die Regelung so realisiert hast, dass du ein Rad immer mit konstanter Geschwindigkeit fahren lässt, und nur das andere regelst?
MfG Jeffrey
Ich habe beide Varianten ausprobiert und beide funktionieren mit gleicher Dimensionierung des Reglers. Sowohl die Aufteilung der Regelgröße je zur Hälfte mit entgegengesetztem Vorzeichen auf beide Motoren als auch die Methode nur einen, den kurveninneren Motor zu drosseln. Bei Höchstgeschwindigkeit geht sowieso nur noch die 2. Methode. Die finde ich auch eleganter, da auf geraden Stücken schnell gefahren wird und in den Kurven langsamer.
Waste
SnoopysBot
06.02.2006, 21:22
Hallo waste,
ein sehr interessanter, äußerst fundierter Thread! Respekt!
Da ich nach meinem (abgebrochenen) Elektrotechnik-Studium leider nichts mehr mit Regelungstechnik zu tun hatte, muss ich mich hier erst wieder einfinden, um Euren Ausführungen folgen zu können. Aber anhand des konkreten Beispiels mit dem Asuro steigt die Motivation dazu ungemein!
Ich habe den Thread in ein Word-Dokument zusammengefasst und mich dabei auf Deine Beschreibung, wie man einen Regelkreis analysiert, beschränkt und alle dazu passenden Grafiken aufgenommen, sowie die wichtigsten Diskussionsbeiträge und Zwischenfragen, die einige Punkte verdeutlichten.
Bitte meldet Euch, wenn ich das Word-Dokument (unkomprimiert 237 KB) hier irgendwo ablegen soll. Hier im Thread scheint es mir nicht sinnvoll, vielleicht - mit waste's Einverständnis - im Wiki-Bereich?
Viele Grüße und in der Hoffnung auf viele weitere so gehaltvolle Diskussionen,
Euer SnoopysBot
Hallo SnoopysBot,
ich habe nichts dagegen, wenn du den Thread auf das Wesentliche zusammengefasst in den Wikibereich stellst.
Waste
farmerjo
16.02.2006, 16:01
Hi!
Welche Einheiten haben eigentlich P I und D?
Die Regelabweichung müßte ja dimenssionlos sein. aber was ist mit dem Rest?
Gruß Johann!
Welche Einheiten haben eigentlich P I und D?
Gute Frage!
Auf die Schnelle würde ich sagen:
Kp ist dimensionslos
Ki hat die Einheit [1/s]
Kd hat die Einheit [s]
Damit gibt es zumindest keinen Konflikt mit den Formeln in meinem Wiki-Artikel.
Gruß Waste
fchaleun
09.05.2006, 23:15
Hallo Liebe Leute,
ich bin ganz neu hier. Kann jemand mir die Folge von der Lageregelung unter Elektronik dann regelungstechnik zur Verfügung stehen?
mfg
Ich versteh die Frage nicht...
fchaleun
11.05.2006, 07:19
hallo,
also, unter der Rubrik Elektronik-->Regelungstechnik steht eine Lageregelung(bzw. Kaskaderegelung); und diese wurde nur teilweise dimensioniert(nr den Stromregler). Davon möchte ich eine komplettedimensionierung,wenn's möglich erhalten oder genau detalliert.
Die Adresse dafur ist:https://www.roboternetz.de/wissen/index.php/Regelungstechnik#Regelung
Gruß
hi,
die dimensionierunfg musst du schon selbst machen, da sie vom system und den gestellten anforderuzngen abhängt. das vorgehen ist aber in dem artikel gut beschrieben.
mfg jeffrey
Fortsetzung:
Hier ist mein Programm. Es ist soweit kommentiert, dass jeder damit klar kommen sollte.
/************************************************** *****************************
*
* Description: Asuro Linienverfolgung mit PID-Regler
* Version 1: Korrektur auf beide Motoren verteilt
* Autor: Waste 26.8.05
*
************************************************** ***************************/
#include "asuro.h"
#include <stdlib.h>
unsigned char speed;
int speedLeft,speedRight;
unsigned int lineData[2];
int x, xalt, don, doff, kp, kd, ki, yp, yd, yi, drest, y, y2, isum;
void FollowLine (void)
{
unsigned char leftDir = FWD, rightDir = FWD;
FrontLED(OFF);
LineData(lineData); // Messung mit LED OFF
doff = (lineData[0] - lineData[1]); // zur Kompensation des Umgebungslicht
FrontLED(ON);
LineData(lineData); // Messung mit LED ON
don = (lineData[0] - lineData[1]);
x = don - doff; // Regelabweichung
isum += x;
if (isum > 16000) isum =16000; //Begrenzung um Überlauf zu vermeiden
if (isum < -16000) isum =-16000;
yi = isum/625 * ki; //I-Anteil berechnen
yd = (x - xalt)*kd; // D-Anteil berechnen und mit
yd += drest; // nicht berücksichtigtem Rest addieren
if (yd > 255) drest = yd - 255; // merke Rest
else if (yd < -255) drest = yd + 255;
else drest = 0;
if (isum > 15000) BackLED(OFF,ON); // nur zur Diagnostik
else if (isum < -15000) BackLED(ON,OFF);
else BackLED(OFF,OFF);
yp = x*kp; // P-Anteil berechnen
y = yp + yi + yd; // Gesamtkorrektur
y2 = y/2; // Aufteilung auf beide Motoren
xalt = x; // x merken
speedLeft = speedRight = speed;
MotorDir(FWD,FWD);
if ( y > 0) { // nach rechts
StatusLED(GREEN);
speedLeft = speed + y2; // links beschleunigen
if (speedLeft > 255) {
speedLeft = 255; // falls Begrenzung
y2 = speedLeft - speed; // dann Rest rechts berücksichtigen
}
y = y - y2;
speedRight = speed - y; // rechts abbremsen
if (speedRight < 0) {
speedRight = 0;
}
}
if ( y < 0) { // nach links
StatusLED(RED);
speedRight = speed - y2; // rechts beschleunigen
if (speedRight > 255) {
speedRight = 255; // falls Begrenzung
y2 = speed - speedRight; // dann Rest links berücksichtigen
}
y = y - y2;
speedLeft = speed + y; // links abbremsen
if (speedLeft < 0) {
speedLeft = 0;
}
}
leftDir = rightDir = FWD;
if (speedLeft < 20) leftDir = BREAK; // richtig bremsen
if (speedRight < 20) rightDir = BREAK;
MotorDir(leftDir,rightDir);
MotorSpeed(abs(speedLeft),abs(speedRight));
}
int main(void)
{
unsigned char sw;
Init();
MotorDir(FWD,FWD);
StatusLED(GREEN);
speed = 150;
kp = 3; ki = 10; kd = 70; // Regler Parameter kd enthält bereits Division durch dt
sw = PollSwitch();
if (sw & 0x01)
{ki=20;}
if (sw & 0x02)
{speed = 200;}
if (sw & 0x04)
speed = 100;
if (sw & 0x08)
kd = 35;
if (sw & 0x10)
kd = 70;
if (sw & 0x20)
kd = 140;
FrontLED(ON);
LineData(lineData);
speedLeft = speedRight = speed;
while(1){
FollowLine();
}
return 0;
}
Habe diese Umsetzung des Linienfolgers mal ausprobiert, nur irgendwie funzt das alles nicht so richtig. Beim compilen bekomme ich zwar keinen error...
-------- begin --------
avr-gcc --version
avr-gcc (GCC) 3.3.1
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Size before:
test.elf :
section size addr
.text 2568 0
.data 0 8388704
.bss 38 8388704
.noinit 0 8388742
.eeprom 0 8454144
.stab 4416 0
.stabstr 3117 0
Total 10139
Size after:
test.elf :
section size addr
.text 2568 0
.data 0 8388704
.bss 38 8388704
.noinit 0 8388742
.eeprom 0 8454144
.stab 4416 0
.stabstr 3117 0
Total 10139
Errors: none
-------- end --------
> Process Exit Code: 1
...aber beim Starten des Asuro leuchtet die linke Back-LED auf. Soll das so?
Hallo pult,
eine leuchtende Backled zeigt eine Begrenzung des I-Anteils an. Das kann bei längerer Kurvenfahrt vorkommen, ist für die Diagnose gedacht.
Vielleicht hast du nicht meine Headerdateien/Libs verwendet. Probier mal mein Hexfile aus, das ist auch hochgeladen. Wenn es da auch nicht funktioniert, dann ist deine Hardware fehlerhaft oder nicht kompatibel, denn bei vielen anderen hat es ja funktioniert.
Waste
Hi bin noch net so der pro in c++, hab mir gedacht mit helfe der Lichtempfindlichkeit den Asuro sobald ein großer schwarzer Fleck auftaucht zum stehen zubringen geht auch alles soweit ist halt net alles so toll wie das Programm von waste. Daher frag ich was ich bei deinem Prog ändern muss damit er die Motorspeed auf 0 stellt sobald beide Sensoren nur noch schwarz empfangen.
Achja bitte um Hilfe :)
Hallo Gladius!
Nun, ich werde dir jetzt nicht den Code auf dem Silbertablett servieren. Das wäre doch zu einfach und der Lerneffekt gleich Null.
Aber hier die Vorgehensweise:
Zuerst musst du rausfinden, welche Werte der Liniensensor bei Schwarz liefert. Da ich in meinem Programm das Umgebungslicht kompensiere, musst du also die Werte mit eingeschalteter FrontLED und mit ausgeschalteter FrontLED messen und voneinander abziehen und das jeweils für links und rechts. Wenn nun der typische Wert für schwarz etwa 20 ist, dann mach in mein Programm eine zusätzliche Abfrage auf < 30. Das sieht in etwa so aus:
if ((Wertlinks < 30) && (Wertrechts < 30) dann Motor aus und Ausstieg
Den typischen Wert von 20 für schwarz habe ich jetzt nur angenommen. Den richtigen Wert musst du selbst aus deinem Asuro mit dem Hyperterminal auslesen. Wie das geht findest du hier im Forum, einfach die Suchfunktion benutzen.
Wenn dein Programm fertig ist, dann poste es hier. Es interessiert bestimmt auch andere.
Gruß Waste
Habs jetzt den ganzen Tag versucht die Abfrage in dein Programm reinzubekommen , aber bis jetzt hab ich wohl die richtige Stelle nicht gefunden oder bekamm irgendwelche komischen Fehler beim compilieren. Ich
frag vielleicht kann mir ja noch einer Helfen die richtigen Werte ausgelesen das hab ich geschafft war ja net so ganz schwer nur die richtige Funktion in deine Funktionen einzubauen schaff ich leider nicht hab das Manual das bei lag schon 10x durchgelesen...
Ich würde die Abfrage im Hauptprogramm (main) nach FollowLine() durchführen. Da die Variable lineData[] überschrieben wird, braucht man eine Zwischenspeicherung in FollowLine(). Ich würde da wegen der Übersicht gleich 4 globale Variablen dafür spendieren, z.B.:
Loff = lineData[0]
Roff = lineData[1]
...
Lon = lineData[0]
Ron = lineData[1]
Im Hauptprogramm dann die Differenz Lon - Loff zur Kompensation des Umgebungslichts bilden. Das Selbe nochmal für rechts und dann die Abfrage starten. So sollte es eigentlich funktionieren.
Waste
@waste
Ich glaube, das Problem ist bei mir auf den Antrieb zurückzuführen. Irgendwie dreht sich das linke Rad langsamer als das rechte, egal welches (auch vorher halbwegs funktionierende) linienfolger-prog ich benutze. Schade eigentlich, da muss ich wohl nochmal ran, obwohl ich sagen muss, das die Übersetzung der Motordrehzahl auf die Achsen beim Asuro sehr sehr unglücklich gelöst wurde.
vanharmelen
01.08.2006, 14:25
Hallo Waste,
Obschon es schon lange her ist, will ich dir doch gratulieren mit deine „Linienfolger mit PID Regler fur die Asuro“. A fantastic job!!!!
Weil meine Kenntnisse auf diesem Gebiet sehr klein ist habe ich ein paar Frage:
1. Clockwise fahrt mein Asuro (ziemlich) flot um die Kurven auf eine schwarze Linie (auf weisse Untergrund). Anticlockwise verliert er gerne (bei gleiche parameters: speed, Kp.,Ki, Kd) bei zu enge Rechtskurven die Linie und fangt an im Kreis zu drehen.
Hat das zu tun mit das Einlesen der Sensorsignale (an der linken Linienfolge_LED ist es heller (oder Dunkler ?) als an der rechten ??
2. Ich habe versucht selbst ein Antwort zu finden , aber is ist mir nicht gelungen :
Warum bekomme ich auf eine weisse Linie (auf schwarze Untergrund) kein Resultat. ?
Mit freundliche Grusse Rien vamn Harmelen (NL)
1. Clockwise fahrt mein Asuro (ziemlich) flot um die Kurven auf eine schwarze Linie (auf weisse Untergrund). Anticlockwise verliert er gerne (bei gleiche parameters: speed, Kp.,Ki, Kd) bei zu enge Rechtskurven die Linie und fangt an im Kreis zu drehen.
Hat das zu tun mit das Einlesen der Sensorsignale (an der linken Linienfolge_LED ist es heller (oder Dunkler ?) als an der rechten ??
Das kann an einem unsymmetrischen Liniensensor als auch an unterschiedlichen Motoren oder Getrieben liegen. Auf der Seite, wo weniger Regelverstärkung vorhanden ist, fliegt er eher raus. Ich habe im Programm nichts vorgesehen, um die Linie wieder zu finden, falls der Asuro einmal die Linie verloren hat.
Seit mein Asuro einmal vom Tisch gefallen ist, habe ich auch das Problem dass er bei voller Geschwindigkeit in engen Kurven auf einer Seite nicht immer folgen kann. Er fährt auch ohne Regelung nicht mehr gerade aus.
Grundsätzlich kann die Regelung nicht die physikalischen Gesetze ausser Kraft setzen. Ein Auto kann auch nicht mit 100km/h eine enge Kurve durchfahren.
2. Ich habe versucht selbst ein Antwort zu finden , aber is ist mir nicht gelungen :
Warum bekomme ich auf eine weisse Linie (auf schwarze Untergrund) kein Resultat. ?
Bei weisser Linie auf schwarzem Untergrund ist die Polarität des Liniensensor umgekehrt. Damit dreht sich auch der Regelsinn um. Der Asuro wird also von der weissen Linie wegregeln.
Gruß Waste
vanharmelen
03.08.2006, 10:20
Hallo Waste
Danke fur deine schnelle Antwort.
Ich habe in deine Programm doff resp don geandert in:
doff = Lineright - lineleft
don = Lineright – lineleft
und … es ist zum Staunen...... mein Asuro lauft flot auf einer weisser Linie (auf schwarzem Untergrund)
Is dass wass Sie meinen mit: Bei weisser Linie auf schwarzem Untergrund ist die Polarität des Liniensensor umgekehrt ?
Mit freundliche Gruss : Rien van harmelen (NL)
Ja, genau das habe ich damit gemeint.
Gruß Waste
radbruch
05.03.2007, 22:24
WOW!
Da kann ich nur noch staunen. Ein beeindruckender und lehrreicher Thread. Dank an alle Mitwirkenden.
irobot_22587
11.03.2007, 17:05
Waste,
ich habe Deinen Code leicht modifiziert, da Dein Programm bei mir keiner Linie folgte.
Folgende Aenderungen habe ich vorgenommen:
1.) die Variablen drest, xsum und xalt in MAIN, da diese Variablen sonst nicht initialisiert werden
2.) Linedata mit LED off zur Initialisierung von doff in MAIN, da bei mir die LED beim Ein- und Ausschalten in FollowLine zu traege ist und scheinbar immer an bleibt.
3.) Implementierung mit Lib Ver. 2.70
Das war's. Nun folgt mein Asuro brav der Linie und der PID-Regler ist viel sensibler als der einfache P-Regelkreis!
Ich habe noch eine Frage:
Ich verstehe die Logik beim abbremsen nicht.
Links von der Linie (rechts bremsen)ist der Code:
speedRight = speed - y; // rechts abbremsen
Links dagegen
speedLeft = speed + y; // links abbremsen
Kannst Du mir das mal erklaeren. Besten Dank im voraus.
Hier ist der neue Code:
/************************************************** *****************************
*
* Description: Asuro Linienverfolgung mit PID-Regler
* Version 1: Korrektur auf beide Motoren verteilt
* Author: Waste 26.8.05
*
* Version 2: initialization of parameters in Main, measurement with LED off in Main
* Author: irobot22587 11.03.2007
*
************************************************** ***************************/
#include "c:/WinAVR/avr/include/asuro.h" // ver 2.70
unsigned char speed;
int speedLeft,speedRight;
unsigned int lineData[2];
int x, xalt, don, doff, kp, kd, ki, yp, yd, yi, drest, y, y2, isum;
void FollowLine (void)
{
unsigned char leftDir = FWD, rightDir = FWD;
LineData(lineData); // Messung mit LED ON
don = (lineData[0] - lineData[1]);
x = don - doff; // Regelabweichung
isum += x;
if (isum > 16000) isum =16000; //Begrenzung um Überlauf zu vermeiden
if (isum < -16000) isum =-16000;
yi = isum/625 * ki; //I-Anteil berechnen
yd = (x - xalt)*kd; // D-Anteil berechnen und mit
yd += drest; // nicht berücksichtigtem Rest addieren
if (yd > 255) drest = yd - 255; // merke Rest
else if (yd < -255) drest = yd + 255;
else drest = 0;
if (isum > 15000) BackLED(OFF,ON); // nur zur Diagnostik
else if (isum < -15000) BackLED(ON,OFF);
else BackLED(OFF,OFF);
yp = x*kp; // P-Anteil berechnen
y = yp + yi + yd; // Gesamtkorrektur
y2 = y/2; // Aufteilung auf beide Motoren
xalt = x; // x merken
speedLeft = speedRight = speed;
MotorDir(FWD,FWD);
if ( y > 0) { // nach rechts
StatusLED(GREEN);
speedLeft = speed + y2; // links beschleunigen
if (speedLeft > 255) {
speedLeft = 255; // falls Begrenzung
y2 = speedLeft - speed; // dann Rest rechts berücksichtigen
}
y = y - y2;
speedRight = speed - y; // rechts abbremsen
if (speedRight < 0) {
speedRight = 0;
}
}
if ( y < 0) { // nach links
StatusLED(RED);
speedRight = speed - y2; // rechts beschleunigen !!!was speed - y2!!
if (speedRight > 255) {
speedRight = 255; // falls Begrenzung
y2 = speed - speedRight; // dann Rest links berücksichtigen !!was speed - speedRight!!
}
y = y - y2;
speedLeft = speed + y; // links abbremsen !! was speed + y!!!
if (speedLeft < 0) {
speedLeft = 0;
}
}
leftDir = rightDir = FWD;
if (speedLeft < 20) leftDir = BREAK; // richtig bremsen
if (speedRight < 20) rightDir = BREAK;
MotorDir(leftDir,rightDir);
MotorSpeed(abs(speedLeft),abs(speedRight));
}
int main(void)
{
unsigned char sw;
Init();
MotorDir(FWD,FWD);
StatusLED(GREEN);
speed = 150;
kp = 3; ki = 10; kd = 70; // Regler Parameter kd enthält bereits Division durch dt
drest=0;
isum=0;
xalt=0;
sw=0;
/*
sw = PollSwitch();
if (sw & 0x01)
{ki=20;}
if (sw & 0x02)
{speed = 200;}
if (sw & 0x04)
speed = 100;
if (sw & 0x08)
kd = 35;
if (sw & 0x10)
kd = 70;
if (sw & 0x20)
kd = 140;
*/
FrontLED(OFF);
Msleep(50);
LineData(lineData); // Messung mit LED OFF
doff = (lineData[0] - lineData[1]); // zur Kompensation des Umgebungslicht
FrontLED(ON);
Msleep(100);
speedLeft = speed;
speedRight = speed+25;
while(1){
FollowLine();
}
return 0;
}
Ich habe noch eine Frage:
Ich verstehe die Logik beim abbremsen nicht.
Links von der Linie (rechts bremsen)ist der Code:
speedRight = speed - y; // rechts abbremsen
Links dagegen
speedLeft = speed + y; // links abbremsen
Kannst Du mir das mal erklaeren. Besten Dank im voraus.
Wenn y>0 ist, soll er rechts bremsen, also speedRight soll kleiner werden, das passt mit -y.
Wenn y<0 ist, dann soll er links bremsen, speedLeft soll kleiner werden. Da y schon negativ ist, muss also +y da stehen.
Waste
fh_frankfurt
12.12.2007, 12:13
Hallo an Alle, die zu diesem Artikel beigetragen haben...
Ich hätte allerdings nur noch eine Bitte:
Kann man das ganze Thema (ASURO mit PID-Regler) so kompensieren und kurz Beschreiben, dass auch Leute, die wenig Ahnung von Reglern haben einen Überblick bekommen???
(Besonders die Berechnung der P I und D Anteile mit den ganzen Variablen und Konstanten)
MfG
PS: Sozusagen "ASURO mit PID-Regler für Dummies"
hi,
vielleicht schaust du mal hier rein:
https://www.roboternetz.de/wissen/index.php/Regelungstechnik
Hi,
Hallo an Alle, die zu diesem Artikel beigetragen haben...
Ich hätte allerdings nur noch eine Bitte:
Kann man das ganze Thema (ASURO mit PID-Regler) so kompensieren und kurz Beschreiben, dass auch Leute, die wenig Ahnung von Reglern haben einen Überblick bekommen???
(Besonders die Berechnung der P I und D Anteile mit den ganzen Variablen und Konstanten)
MfG
PS: Sozusagen "ASURO mit PID-Regler für Dummies"
Denke schon, dass man das kann ;-) also leg los, es hält dich bestimmt keiner davon ab das zu machen.
mfg jeffrey
Sternthaler
13.12.2007, 20:36
Hallo fh_frankfurt,
druck dir alle Seiten dieses Threads aus.
Hier (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=109170#109170) ist die Zusamenfassung von Waste
Hier (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=114472#114472) ist eine Zusammenstellung, evl. schwirig zu verstehen da von mir, um Beiträge im Thread zu finden.
Viel Erfolg
Gruß Sternthaler
der PID Regler funktioniert wunderbar... hab noch nie eine so saubere Linienverfolgung hinbekommen. Werde mal ein Video demnächst reinstellen.
Mich interessiert das Thema auch, jedoch habe ich keinen Asuro zum Testen.
Kann daher nochmal jemand ein Video vom Asuro mit PID-Regler reinstellen? Die Videos hier aus dem Thread sind leider nicht mehr verfügbar.
Moin moin allerseits,
Toplles aber für mich ein etwas schwieriges Thema welches aber bald
auf mich zukommt. :-) Ich habe den Thread sowie das RN Wiki über
Regelstrecken gelesen, habe aber doch ein paar grundlegende Fragen.
Habe ich es richtig verstanden das ich die Sprungantwort möglichst
mit betriebsbereitem Bot ermitteln sollte damit halt die Verlußte und
die Massenträgheit gleich mit berücksichtigt werden?
Bei mir geht es weniger um Linienfolgen als um einen guten Gleichlauf
der Räder. Ich habe am Kollecktor der Scheibenwischermotoren kleine
Magnete befestigt welche mittels Hallsensor abgetastet werden und komme
bei vollast auf etwa 160 Hz. Diese Frequenzen möchte ich vergleichen
und die Differenz als Stellgröße verwenden.
Gleichzeitug/zusätzlich als Speedmeter und die Impulse selber als
Wegstreckenzähler....Für Kurvenfahrten stelle ich mir vor den einen
oder anderen oder Beide Motoren "gefälschte" Daten vorzulügen.
Haltet Ihr das vom Prinzip her (so) für durchfürbar?
Grüße Richard
oberallgeier
21.12.2008, 17:04
... Sprungantwort möglichst mit betriebsbereitem Bot ermitteln ...?Wieso möglichst. Nur - würde ich sagen. Man lässt ja die Motoren nicht alleine durch die Welt fahren.
... Bei mir geht es ... um einen guten Gleichlauf der Räder ...Gleichlauf heisst doch: genaues Einhalten der Vorgaben. Damit ist es egal, welchen Zweck Du erreichen willst. Ich habe die Sprungantwort gemessen und daraus die Regelstrecke parameterisiert und rechne aus Zeitgründen alles integer. Läuft sehr schön (https://www.roboternetz.de/phpBB2/viewtopic.php?p=390196#390196)(klar, eigene Erfolge sind IMMER gut)!
... Für Kurvenfahrten stelle ich mir vor den einen oder anderen oder Beide Motoren "gefälschte" Daten vorzulügen ...Ich gebe einfach die Daten vor, die ich haben will. Keine Ahnung was das mit dem "lügen" soll.
... Für Kurvenfahrten stelle ich mir vor den einen oder anderen oder Beide Motoren "gefälschte" Daten vorzulügen ...Ich gebe einfach die Daten vor, die ich haben will. Keine Ahnung was das mit dem "lügen" soll.
Moin moin Oberallgeier. :-)
Mit "lügen" meinte ich die tatsächlichen IST Werte verändern,je nach
Bedarf etwas hinzuaddieren oder Abziehen um den Kurs zu beeinflussen,
ohne dabei die eigentliche Regelfunktion zu verlieren. Aber das kann jetzt
auch ein Denkfehler von mir sein, der soll Wert MUß ja nicht 0 sein wie
beim Linienfolgen.
Gruß Richard
Sternthaler
25.12.2008, 02:49
Hallo Richard,
erst einmal schöne Weihnachten. Natürlich für alle Leser.
Ich bin auch fürs Lügen.
Sinn macht das Ganze ja auf alle Fälle dann, wenn eine Kurve z.B. so gefahren werden soll, so das ein Rad die doppelte Strecke gegenüber dem anderen fahren soll. Klar, dass ich dann bei den Tiks lüge und dem Regler etwas vom Pferd erzähle.
Der hier von waste entwickelte PID läßt sich auch für solche Dinge hervoragend nutzen und in einen Kurven-Regler (eine Gerade ist nur ein Sonderfall einer Kurve) umbauen.
Ist bei mir schon 'etwas' länger im Betrieb.
Hier mal meine vom Baron erzählte Lügengeschichte mitten im waste-Code:
case PID_ODOMETRIE:
if (links == 0 || rechts == 0)
use_regler = FALSE;
else
{
absLinks = abs (links);
absRechts = abs (rechts);
/* Odometrie-Zaehler so justieren, dass fuer eine Kurvenfahrt
die Tic-Anzahl auf beiden Seiten identisch aussehen.
Die Seite auf der weniger Tic's zu fahren sind wird auf die
hoehere Anzahl 'hochgerechnet'.
*/
if (absLinks < absRechts)
{
faktor = (float)absRechts / (float)absLinks;
LWert = sens.rad_tik [LINKS] * faktor;
RWert = sens.rad_tik [RECHTS];
}
else
{
faktor = (float)absLinks / (float)absRechts;
LWert = sens.rad_tik [LINKS];
RWert = sens.rad_tik [RECHTS] * faktor;
}
kp = g_kp;
ki = g_ki;
kd = g_kd;
}
break;
Der Regler nutzt dann die beiden Variablen LWert und RWert um 'seiner' Meinung nach geradeaus zu fahren. In sens.rad_tik [..] stehen bei mir die gemessenen Tiks. Und dann wird gelogen auf float komm raus.
@oberallgeier
Lügen kann in der heutigen Zeit einfach hilfreich sein um die Kurve zu kratzen ;-). Außer man fährt AC-Schnitzer getunetes. Da wird natürlich rechtwinklig abgebogen ;-). (Schau bitte nicht auf die Uhrzeit. Ist Urlaub.)
Gruß und guten Rutsch ins Neue Jahr an alle.
Sternthaler
oberallgeier
25.12.2008, 11:08
Halleluja,
ich verstehe die Sache mit dem "Lügen" trotzdem nicht. Nicht (nur) weil Weihnachten ist. Mein Regler für den Antrieb bei meinem Dottie sind ja zwei Regler, für jeden Motor, also für jedes Rad, ein eigener.
Die Funktionstüchtigkeit bzw. Adaptionsfähigkeit dieser Regler ist damit nachgewiesen, dass ich den identischen Algorithmus mit gleichen Parameterwerten habe für jeden einzelnen der zwei Antriebe, wobei die Antriebe deutlich unterschiedliche Zeitkonstanten (im Target gemessen) haben: 8 ms und 12 ms. Diese Unterschiede werden vom Algorithmus selbst sehr gut ausgeglichen - schaut euch die Dottie-Videos an: mein R2D03 läuft bei Geradeausfahrt auf 1 m mit weniger als +/- 1 mm Abweichung. Die Encoderauflösung ist etwa 1 Tic pro 0,1 mm Radumfang.
Mit den Hilfen aus dem RN (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=389480#389480)habe ich meinen Regler aufgebaut. Meinen erprobten und aktuellen Code für den Motor 12 (1 und 2 sind zwei der vier Ausgänge am L293D) habe ich mit einigen meiner Überlegungen hier vorgestellt. (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=389526#389526) UND wenn mein Dottie (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=390196#390196) nun eine Kurve fahren soll, dann werden die Vorgaben entsprechend bereitgestellt - lügen ist das ja nun nicht. Da ich in der Regelroutine nur integer rechne (Zeitgründe - sie läuft ja im Interrupt), könnte es Sinn machen, den offset für das "schnellere" Rad beim Kurvenfahren erst floatingpoint zu berechnen und nach dieser Sollwertberechnung für das kurvenäussere Rad den "frac"-Anteil (also den Nachkommaanteil) für die nächste Berechnung zu konservieren. Dieser Überhang wird der nächsten Berechnung zugeschlagen, damit nicht durch Rundungsvorgänge die gewünschte Kurvenform leidet. Dieses Vorgehen steht noch auf meiner Vorhabenliste, über Auswirkung/Erfolg kann ich daher nicht berichten.
Lange Rede kurzer Sinn: lügt nicht. Ehrlich währt am längsten - und fährt am präzisesten *ggggggg*. Lügen langt aber sicher um die Kurve zu kratzen *gggggg*. Aber wer macht sowas schon.
@Sternthaler: der AC-Schnitzer muss leider ohne Regler auskommen - differentiallose Starrachse - und ich habe KEINEN Platz für nen Encoder. Aber das Teil wird ja auf AL (..AbstandsLimit..) geregelt, auch wenns nur ne sehr einfache Regelung ist ... warts mal ab, die Erlkönigphase ist eigentlich vorbei, ich muss aber noch eine saubere Kalibriermöglichkeit vor Fahrtantritt programmieren. Und . . . mein PC steht eigentlich in der Ecke - hier spricht nur der Not(fall)book.
Frohe Weihnachten
hi,
der asuro und der dottiregler unterscheiden sich ja schon.
man hat ja bei beiden eigentlich ein mimo system. bei dotti wird das mit 2 siso-regler geregelt, und beim asuro mit einem siso-regler. wenn ich das jetzt richtig erkannt habe.
bei dotti wird ür jdes rad eine solldrehzahl vorgegeben, die dann durch jeweils einen regler eingestellt wird.
beim asuro wird die drehzahl differenz ausgewertet und damit die motoren geregelt. mit dem vorlügen würde ich sagen ist gemeint, dass die tics verfälscht werde, sprich anzahl links *1,5, bedeutet, dass das rechte rad 2/3 längeren weg fährt wie das linke. ich persönlich halte aber diese variante nicht für so sinnvoll. dann liber den sollwert von der drehzahldifferenz ändern, also anstatt 0, irgendeinen anderen wert nehmen, dann kann auch weiterhin mit integers gerechnet werden.
so, ich hoff, verstanden zu haben, was die leute gmeinet haben, und ic hab net totalen schwachsinn verzapft.
noh weiterhin schöne feiertgae.
mfg jeffrey
oberallgeier
25.12.2008, 14:04
... asuro und der dottiregler unterscheiden sich ...So sehe ich das ja auch. Und deswegen und trotz meinem Erfolg bei meinem Miniprojekt - das ja auf wastes phantastischem Wicki-Artikel beruht - trau ich mich nicht an die Regelung des asuro heran. Annahme: wenn es besser ginge, hätte waste oder Sternthaler oder irgend ein anderer Guru das schon längst erledigt. Aber ich vermute, dass es beim asuro noch Möglichkeiten gibt. (.... die dann vielleicht DOCH auf mich warten ...... schrecklich!)
juhecomp
28.01.2009, 19:48
hallo ich habe ein Problem :D
ich könnte heulen mein Asuro macht einfach nicht das was er soll,
der Linie entlang fahren. Er ruckelt hin und her und erkennt auch manche dunkleren stellen doch nicht auf der linie er fährt immer ein kleines stück der linie entlang und dan biegt er ab. Manchmal fährt er am Rand des Papiers entlang aber meistens dreht er sich im Kreis. Ich weiß einfach nicht was ich noch machen soll ich habe schon so viele Programme ausprobiert.
Habt ihr eine Idee?
Liegt es vielleicht an der Ausgedruckten Strecke (zu dünn, zu scharfe Kurven, zu glänzend wegen Laserdrucker ????) ich weiß es nicht.
Also wäre nett wenn ihr vllt eine Lösung wüsstet.
juhecomp
28.01.2009, 21:57
Mein Asuro ist übrigens im Originalzustand falls das wichtig ist ;)
pinsel120866
29.01.2009, 07:58
Hallo,
wenn der Asuro die Linie verliert kannst du dir dadurch behelfen, indem du eine kleine Manschette machst, die du über Photodioden und FrontLed steckst.
Viel bringt auch den Liniensensorumbau zu machen und die Bauteile einzustecken. Dadurch kommen sie näher an die Linie. Du hast ausserdem den Vorteil dass du mit verschiedenen Front-LEDs experimentieren kannst.
Moglicherweise musst auch nur das Programmparameter besser an die Liniensensorgruppe anpassen.
juhecomp
29.01.2009, 19:02
ich hab sie steckbar gemacht und ich hab auch schon n schrumpfschlauch drüber gesteckt aber das hat nie sehr viel geholfen wobei ich damals auch noch nich das programm mit pid regler hatte sondern das beispiel programm
juhecomp
31.01.2009, 23:33
also bin dann doch direkt in den super Elektronik Laden in Freiburg gegangen und hab mir einen Meter Schrumpfschlauch und Isolierband gekauft und hab mir auf meinem Tisch einen Kreisgeklebt und siehe da es funktioniert ich weiß nicht was ich immer falsch gemacht habe aber es geht
er fährt zwar nicht ganz flüssig also er ruckelt immer hin und her aber er fährt der Linie nach *freu*
Vielen Dank vielleicht weiß jemand wie ich das ruckeln noch beheben kann aber Hauptsache ist erstmal das er der Linie nachfährt :)
koenig222
31.08.2012, 18:12
Habe das Programm von waste runtergeladen, es funktioniert super !! Asuro's von meinen Zwilingen folgen tatsächlich der Linie! Beide!
Nur wenn ich selber kompiliere, tut nichts, also wie pult im Forum schon geschrieben hat, beim Starten des Asuro leuchtet die linke Back-LED auf.
Das liegt wahrscheinlich an den Libs.
Kann man die Libs irgendwo runterladen?
Würde das Programm gerne erweitern, dass auch die Sensortaster abgefragt werden...
Kann mir jemand helfen?
hallo,
hier (https://www.roboternetz.de/community/threads/64274-linienfolger) mein versuch den code für den RP6 "umzuschreiben"...
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.