Asuro: Linienfolger mit PD-Regler

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

Zitat:

---

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

Code:

---

[Konstanten]
vmax=1 -> Maximalgeschwindigkeit; zur manuellen Steuerung (Curser in weißes Feld, dann über Pfeiltasten) höhere Werte (z.B. 3) sinnvoll
pause=1 -> Pause in ms, zum beobachten z.B: auf 100 setzen
robox=175 -> Startwerte Robo
roboy=386
roboalpha=45
radstand=100 -> Dimensionierung
radradiuslr=15
radbreitelr=10
achsdicke=7
abstand=50
radradiusm=15
radbreitem=7
nachlauf=10
sensorx=75 -> Abstand Sensoren von Achse
sensorymitte=10 -> Abstand der zwei mittleren Sensoren (alle außenliegend)
sensoranzahl=8
sensoryabstand=6 -> Abstand zw. allen anderen Sensoren
vdiff=0,1 -> wird nicht mehr benötigt
kp=5 -> PID (alles /100, also kp=5 entspricht 0,05)
ki=0
kd=0
tast=100
reg=100 (verzögerte Reaktion)

---

Und der angepasste Quelltext

Code:

---

procedure TForm1.followtrack;    /////////////////////////////////Spurverfolgung
var
  m: integer;
  sensor1, sensor2, sensor, regel, yp, yi, yd: real;

begin
  sensor1:=0;
  sensor2:=0;
  for m:=1 to sensoranzahl do begin
    if chk(m) and (sensor1=0) then begin
      if m<=sensoranzahl/2 then  sensor1:=-sensoranzahl/2-1+m
        else sensor1:=m-sensoranzahl/2;
      if m<>sensoranzahl then begin
        if chk(m+1) then begin
          if m+1<=sensoranzahl/2 then  sensor2:=-sensoranzahl/2+m
            else sensor2:=m+1-sensoranzahl/2;
        end;
      end;
    end;
  end;

  if sensor2<>0 then sensor:=(sensor1+sensor2)/2 else sensor:=sensor1;

  sensor:=sensor/(sensoranzahl/2);

  yp:=(kp/100)*sensor;
  yi:=yialt+(ki/100)*(tast/100)*sensor;
  yd:=(kd/100)*(sensor-sensoralt)/(tast/100);

  yialt:=yi;
  sensoralt:=sensor;

  regel:=yp+yi+yd;

  button6.caption:=floattostr(regel);

  vralt:=vr;
  vlalt:=vl;

  regel:=(reg/100)*regel;

  if regel<0 then begin
    vr:=vralt+abs(regel);
    if vr>=vmax then begin
      vr:=vmax;
      vl:=vlalt-abs(regel);
      if vl<0 then vl:=0;
    end;
  end;
  if regel>0 then begin
    vl:=vlalt+abs(regel);
    if vl>=vmax then begin
      vl:=vmax;
      vr:=vralt-abs(regel);
      if vr<0 then vr:=0;
    end;
  end;   

end;

---

(Button6 ist nur zum debuggen mit drin)

Wenn man in der Oberfläche z.B. den Haken bei Umrisse und Löschen rausnimmt, kann man sehr schöne Ergebnisse erzielen.

Zum Ändern der PID-Werte in INI ändern, speichern, in Robosim auf Zurücksetzen klicken!

Unter Testreihe kann man eine, wen wunderts, Testreihe mit versch. Werten ausprobieren (gestoppt wird eine Runde). Das Ergebniss wird dann in der logfile.txt gespeichert und kann z.B. in Excel importiert und nach Bestzeiten geordnet werden. Um das zu beschleunigen am besten die ganzen Haken bei Umrisse, Sensoren, Löschen, Hintergrund usw. rausnehmen!

Noch Fragen/Verbesserungsvorschläge?

Grüße, ähM_Key

Bild hier  

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