Hallo,
Ich habe jetzt meinen Roboter soweit aufgebaut, dass er mit einem
P-Regler eine Dauerschwingung auf einer Geraden schafft.
Jetzt haut er mir aber ab und zu bei stärkeren Kurven ab oder auch wenn
ich den P-Anteil hochdrehe.
DIe Ansteuerung der Motoren erfolgt momentan über den Motortreiber L6205
durch Kurzschließen der Motoren über PWM.
Die Betriebsspannung, die kurzgeschlossen wird über den Treiber beträgt
8V und soll dann später auf 14,8V erhöht werden. Zur Kühlung des
Treibers dient ein sehr großer CPU Kühler. Ohne Kühler ist aber noch
dazu zu sagen, dass ich die Motoren Leeralufen lassen muss, da der
Kurzschlussbetrieb den Treiber zu stark erhitzt.
Ich habe natürlich dank des Display Menüs, das am ROboter drauf sitzt
immer wieder einen I Anteil dazugegeben, jedoch macht er dann nicht das
was er soll, sondern bei sehr hohen Ki irgendwas und bei sehr kleinen Ki
reagiert er zwar auf die Kurve aber entweder verspätet oder auch
irgendwie.
Ich rechne den I-Anteil folgendermaßen dazu:
möchte ich noch erklären.
Da alle Reglerparameter Kp, Ki, und Kd ganze Zahlen sind und ich für den
I Anteil 1/Ti*s habe, muss ich leider dividieren und skalieren, damit
der Bereich halbwegs passt.
Das ganze wird dann wieder zu long und dann weiter multipliziert.
Die Zykluszeit beträgt 300us und sollte meiner Meinung nach schnell
genug sein. Die cny70 reagieren so ca im 70 us Bereich und deshalb
sollte das auch passen.
Was ich jetzt in den Regler reinschicke ist der Bereich, den ich mir
durch die Sensoren ausrechne.
Der Bereich geht fließend und linear von -345...345. Es gibt zwar sehr
sehr kleine Lücken dazwischen, aber die sind jetzt nicht der Rede Wert.
Die Differenz ist -100 wenn Fehlerhafte Werte auftreten und dadurch soll
dann die letzte DIfferenz genommen werden.
Bei der alten Sensotplatine ist -100 öfters so zwischendurch gekommen
ohne einen Grund, also haue ich den Messwert einfach raus.
Meine Frage jetzt nach den ganzen Erklärungen:
Stimmt es wie ich den I-Anteil dazurechne?
Ich glaube nämlich nicht weil ich für den skalierfaktor verschieden
großes eingestellt habe um mit dem 1/sTi sehr sehr klein zu werden, aber
jedoch kein Erfolg.
Wo mache ich den Fehler?
lg andy
Nur ein Verdacht und Schuss ins Blaue, weil alle Variablendefinitionen
fehlen mit denen man den Verdacht erhärten oder ausräumen könnte...
Hast du eine Debugschnittstelle USB oder RS232 vorgesehen?
Wenn ja, gib die Einzelwerte und das Ergebnis darauf aus. Rechne die
Formel mit dem Taschenrechner (oder per Tabellenkalkulation) nach.
Vielleicht hast du im Programm Probleme mit einem Überlauf oder einem
Abschneiden von Nachkommastellen.
Stefan B. schrieb:> Nur ein Verdacht und Schuss ins Blaue, weil alle Variablendefinitionen> fehlen mit denen man den Verdacht erhärten oder ausräumen könnte...
Dasind alle Definitionen die relevant dafür sein sollten:
Stefan B. schrieb:> Hast du eine Debugschnittstelle USB oder RS232 vorgesehen?
Ja, UART und 4-Zeilen LCD
Das LCD ist leider auf den Roboter drauf und der Roboter ist gerade bei
einem Freund für 3 Tage weil er das Gehäuse machen muss.
Also muss ich warten, deshalb muss ich jetzt leider nur mit Software
auskommen.
Die Differenz hat aber keinen Überlauf, genau so wenig wie das y bei I
Anteil = 0. Wie es dann mit I Anteil ausschaut habe ich nicht daran
gedacht ausgegeben.
Dann mal abwarten, was die Debugausgabe bringt.
Um das zu Simulieren: Wie ist Ta definiert? Wie sind die Sensoren
physikalisch angeordnet? So?
Robotmitte
sensorL0 sensorL1 sensorL2 sensorL3 sensorR0 sensorR1 sensorR2 sensorR3
Hallo,
Ist dein Roboter nicht an sich schon ein I-Anteil?
kurze Änderung der Richtung, also kurzes Ausschalten eines Motores hat
eine kontinuierliche Änderung der Position (änderung des Abstands zur
Linie) zur Folge.
Das heisst du hast momentan eine PI-System, dessen Polstelle immer auf
der Imaginären Achse liegt, wie ich gerade sehe.... also immer
grenzstabil und im Zweifelsfall auch noch Schwingungsfähig.
Tu mal einen D-Anteil dazu, das hat meiner Meinung nach mehr Aussicht
auf Erfolg.
Hmm hoffentlich liege ich jetzt nicht total daneben.... vielleicht kann
mich für diesen Fall ja jemand der davon Plan hat korrigieren...
Tueftler
Tueftler schrieb:> Ist dein Roboter nicht an sich schon ein I-Anteil?
Im Prinzip denke ich auch dass das so ist, aber ich möchte schneller
werden und eine Möglichkeit ist es den P-Anteil hochzudrehen, und dann
bekomme ich ein Schwingen und dann brauche ich deshalb einen I.
Ich habe aber einen D-Anteil dazugegeben und er hilft eh.
Weiteres Problem:
Wenn der Roboter die Linie nicht mehr sieht, dann soll der letzte Wert
behalten werden. DIes sage ich ihm mit dem hier:
Jedoch treten in diesem Zustand trotzdem immer wieder falsche Werte auf
aber nur wenn sich die Linie rechts verloren hat.
Wenn die Linie links verschwindet, dann behält er den letzten Wert bei
und steuert auch dadurch die Motoren richtig.
Ich weiß jetzt nicht ob das SOftwarefehler sind oder sich irgendetwas
von die Motoren einkoppelt.
Das aktuelle Programm mit Display Ausgabe ist im Anhang.
Wegen diesem Fehler auf der linken Sensorseite kommt er auch immer wenn
er die Linie verfolgt bei solchen Mustern auch raus oder wenn er zu weit
aufschwingt (hoher P-Anteil).
Die Fehlerhaften Werte treten nicht auf wenn ich die Motoren
ausgeschaltet lasse und den Bereich ausmesse, also vermute ich mal, dass
es an die Motoren liegt und sich über die Sensoren was einkoppelt.
Wenn die Motoren schon ganz ganz langsam drehen, dann passiert dieser
Fehler, aber nur auf der rechten Seite.
Der I-Anteil wird gerne benutzt, um Bleibende Regelabweichung, bzw.
Schleppfehler zu vermeiden.
Schleppfehler: konstante zeitliche Änderung der Führungsgröße,
Regelgröße folgt im konstanten Abstand zur Führungsgröße, holt diese
jedoch nicht ein.
Deshalb braucht man bei konstanter Führungsgröße wenigstens ein I-Glied
im System.
Bei sich linear ändernder Führungsgröße muss man wenigstens zwei
Integratoren haben, damit die Regelabweichung zu null wird. usw...
Dass I-Anteile auch gegen Schwingungen gut sind, wusste ich auch noch
nicht.
Grüße
Tueftler
Richtig, man braucht ein I-Glied im System. Das System besteht hier aber
nicht nur aus dem Regler. Die Regelstrecke gehört auch dazu und bei der
Position im Bezug auf die Radgeschwindigkeit hat man schon ein I-Anteil.
Ich stimme deiner ursprünglichen Argumentation natürlich zu. Und wenn
man Schnelligkeit möchte wird eben der D-Anteil benötigt, wie du auch
schon geschrieben hast.
Ja... wie bereits geschrieben, ist sein Fahrzeug ja bereits wenigstens
ein Integrator..... also wird ein weiterer im Regler meiner Meinung nach
keine Verbesserung mehr bringen können.
Tueftler schrieb:> Ja... wie bereits geschrieben, ist sein Fahrzeug ja bereits wenigstens> ein Integrator..... also wird ein weiterer im Regler meiner Meinung nach> keine Verbesserung mehr bringen können.
Hmm, ok dann lasse ich diesen mal weg, ich dachte nämlich dass ich das
ganze über Ziegler Nicholz mache, also P-Anteil so hoch machen, bis eine
Dauerschwingung auftritt und dann mit I rein, damit ich den rest der
Differenz noch ausgleiche und das ganze stabiler wird.
Ich habe jetzt ein Video hochgeladen, welches mein aktuelles Problem
zeigt.
Die Fehlerhaften Werte kriege ich nicht mehr rein. Grund waren die
Motoren die mit einer zu niedrigen PWM Frequenz geschalten werden -->
längere Kurzschlusszeit --> mehr Störungen.
Jedoch habe ich jetzt andere Probleme.
http://www.filmupload.de/view_video.php?viewkey=7a662aacda2d4b4c7628
Dieses Video zeigt was immer wieder bei dieser Strecke passiert.
Das aktuelle Programm habe ich angehängt und die Sensoren genauso.
Im Video ist ganz gut zu sehen, dass Monty (Robotername) versucht wieder
an die Linie ranzukommen, es aber nicht schafft.
Ich verstehe aber überhaupt nicht aus welchem Grund?
Wenn ich mit der Hand ihn über die Linie fahren lasse ohne dass die
Reifen den Boden berühren, dann passen die Werte.
Wasmich wunder ist dass er auch wenn nur wenig ABweichung ist er
trotzdem rauskommt.
Kp = 3 und Kd = 3 im Video.
Ich kann leider nicht so schnell schauen was passiert und diesen Zustand
wo er vergisst was vorher war finde ich leider auch nirgends in der
Software.
Wenn ich mit den Motoren langsamer werde, dann passtes geoßteils wenn
MOTOR_MAX = 500 ist. Ab und zu kommt er aber dennoch raus und zwar immer
nach dem selben Muster wie im Video.
Ich glaube an der Schnelligkeit der Sensoren und vom Algorithmus liegt
es nicht, da beide insgesamt weniger als 300us brauchen.
Bei früheren Versuchen sind die Motoren noch stärkere Schwingungen
gefahren und viel viel schneller, jedoch hatte ich nur eine elypse als
Strecke und nicht sowas.
Vielleicht ist auch der Sensorbereich zu klein, denn das baut dann eine
Begrenzung in den Regelkreis. Das erklärt aber nicht warum er den
letzten Wert nicht speichert.
Irgendwelche Ideen wieso das nicht so hinhaut?
lg andy
Ich habe jetzt das Problem mit dem rauskommen gelöst. Es lag am
Algorithmus und den 300us. Ich kann aber immer noch nicht galuben, dass
das zu langsam ist.
Hier ist das jetzt zu sehen:
http://www.filmupload.de/view_video.php?viewkey=fe8cf8c09ec91f36f525
ICh habe einfach die Abfrage geändert:
Die Parameter 'Kd', 'Kp'. Außerdem 'y' und 'Ta', welchen Datentyp haben
die? Die Division durch Ta ist eigentlich unnötig, bzw. kann sogar vom
Preprozessor übernommen werden.
Auch sieht deine Verschachtelung etwas komisch aus. Für sowas gibt es
'else if'.
Simon K. schrieb:> Die Division durch Ta ist eigentlich unnötig, bzw. kann sogar vom> Preprozessor übernommen werden.
Du hast recht,habs grad weggeschmissen
Simon K. schrieb:> Auch sieht deine Verschachtelung etwas komisch aus. Für sowas gibt es> 'else if'.
Anders gehts schwer weil ich nochmal messen muss.
Das ganze ist aber nur schnell wenn sich links etwas tut, weil wenn
rechts etwas passiert dann braucht es genau so lange wie vorher.
Ich habe jetzt aber eine Idee und zwar nur die Sensoren auszumessen, an
denen sich auch wirklich etwas tut,
Ich hätte da an 8 OPVs gedacht die mir sagen welche 2/3 etwas machen und
ich diese in die Ifs reingebe also z.B. so:
1
if((OPVsensorL0==1)&&(OPVsensorL1>1))
2
{
3
Messedie2Sensorenausdieetwastun.
4
differenz=250+(sensorL0*100)/(sensorL0+sensorL1);
5
else
6
{
7
if((OPVsensorL1==1)&&(OPVsensorL2==1))
8
differenz=150+(sensorL1*100)/(sensorL1+sensorL2);
9
else
10
{
11
.
12
.
13
.
Also die OPVs (in dem Fall Komparatoren sagen mir welche Sensoren gerade
über 15 (Spannung) haben und aufgrund dessen messe ich dann diejenigen
Sensoren aus.
Weil im Prinzip messe ich sowieso immer mindestens 2 Sensoren und mehr
ein und die Abfragen werden ja dadurch nicht mehr.
Was haltet ihr davon bzw käme da noch was in Frage?
lg andy
Häng mal das komplette Programm an. Du musst bei 'int' (und anderen
integralen Datentypen) extrem aufpassen wegen Wertebereich und
Auflösung.
Ich vermute dein Roboter schwingt deswegen über, weil sich 'y' die ganze
Zeit irgendwo zwischen -1 und 1 bewegt. Da du aber einen integralen
Datentypen hast und keinen der Gleitkomma o.ä. unterstützt hast du nur 3
Punkte innerhalb dieses Bereichs (-1, 0 und +1). Und dadurch gibt es
eben eine extrem grobe Auflösung.
Eine Möglichkeit wäre es, erst mal float zu benutzen und im Nachhinein
auf Fixkomma (Also z.B. mit *256 skalierten Integern) umzubasteln.
Simon K. schrieb:> Ich vermute dein Roboter schwingt deswegen über, weil sich 'y' die ganze> Zeit irgendwo zwischen -1 und 1 bewegt.
Ich glaube kaum dass das so ist weil ich sehe was das y ist. Ich habe
eine LCD Ausgabe und der Grund warum er schwingt ist weil der Controller
einnerseits langsam ist und 2tens die Motoren ziemlich schnell sind.
Ich werde jetzt einfach mal eine Abfrage reinmachen, und schau ob das y
wirklich zu 0, -1, 1 wird, und wenn das passiert, dann soll er stehen
bleiben und mir das anzeigen, vielleicht liegts ja wirklich an dem.
Aber du hast es eh gesehen, eine einfach änderung der Abfrage, sodass er
nicht immer alle ADCs einließt bewirkt schon dass er die Linie jetzt
einmal nicht mehr verliert, ich denke wenn ich noch mehr optimiere
sprich Idee mit den OPVs dann wird das noch besser hoffe ich, wobei ich
vermute dass ein Restschwingen noch überbeleibt, aber das macht der
P-Regler und auch noch der kleine Sensorbereich.
Vielleicht finde ich ja eine perfekte Einstellung, aber bei den ganzen
Begrenzungen im Regler sprich Sensoren, Motoren (die nicht sofort eine
Änderung bewirken --> Totzeit) etc. glaube ich kaum dass der Roboter
perfekt und schnell fahren wird.
Das Programm ist im Anhang
lg andy
Simon K. schrieb:> Ich vermute dein Roboter schwingt deswegen über, weil sich 'y' die ganze> Zeit irgendwo zwischen -1 und 1 bewegt.
Wieso eigentlich?
-1, 1 darf ruhig in Frage kommen, wüsste nicht warum nicht?
lg andy
Thread beobachten
Seitenaufteilung abschalten