Algorithmen zur Bahnplanung

@SternThaler,

da fällt mir aber ein Stein vom Herzen, wenn ich höre, dass Dein Kriseneinsatz ohne Blessuren beendet ist!

Deine ASURO-Sorgen? - frowning? - No sweat! Da greifen wir doch kühn zum Bleistift und schwingen ihn ein wenig, so wie weiland Don Quijote seine Lanze:
Die Antwort auf Deine Fragen findest Du in angehängter pdf-Datei!

Ciao,

mare_crisium

P.S.: In der Hitze des Gefechtes hat es Don Quijote mit der deutschen Rechtschreibung nicht immer sooo genau genommen! ;-)

Edit: Anhang gelöscht, wg. Upload-Quota

Hallo Don Quijote,
ja, ich bin es, Sanchos Panza. Man könnte mich auch mit Rucio verwechseln.

Deine Ausführungen sind wieder sehr lesenswert. Diesmal konnte ich keine Rechtschreifehler oder sonstige Prolbeme feststellen, da ich gerade mal den ersten Absatz gelesen habe. Dies reichte, um mir Rucio, genügend Input zu geben. (Der Rest ist trotzdem mal wieder gut.)

Klar, wenn schon nicht ein ganzer Tik da ist, machen wir halt halbe Sachen.
Das werde ich die nächsten Nächte erst mal wieder mit Excel umsetzen und dann nochmal den Interrupt und die Zähler anpassen.

Danke, und einen lieben Gruß an dich mein Don Quijote
Rucio

P.S.: Hast du mit Frank 'telefoniert'? Du kannst ja zum Glück wieder uploaden.

Rucio,

nee, ich hab' einfach soviele meiner früheren Posts gelöscht, bis wieder genug Quota frei war! ;-)

Ciao,

mare_crisium

Hallo,
will mich jetzt hier auch mal einmischen ;-)
Leider seid ihr ja vom ursprünglichen Thema Bahnplanung inzwischen auf Geschwindigkeitsschätzen gewechselt.
Hab mal kurz paar Fragen.
Ihr schreibt, dass der regler mit Abtastzeit 2ms läuft, aber selbst bei Topspeed habt ihr 500 36kHz Ticks, also 13 ms Messzeit. Es ist doch sinnlos den regler schneller laufen zu lassen, als man messen kann.
Warum habt ihr eigentlich nur 8 Ticks pro Umdrehung? Ihr hobt doch 8 Flächen, also 16 farbwechsel.
so jetzt auch mal paar anmerkung zur geschwindigkeitsschätzung. wie wäre es einen beobachter oder kalmanfilter zu verwenden, um die geschwindigkeit des anderen rades zu schätzen. das eingangssignal für die motoren ist ja bekannt, mit einem modell des motors kann man dann aus den letzten messungen und dem eingangsignal die motorgeschwindigkeit schätzen. das ergebnis wird natürlich umso besser, je kleiner die störungen sind.
mfg jeffrey

Wow, ein Spion in unserem Thread ;-)

Hallo jeffrey,
sei mir nicht böse, aber wenn ich schon Filter, und dann noch von einem Kalmanfilter, höre, sieht mir das verflixt nach höherer Mathematik aus. Ich bin so froh, dass sich mare_crisium um meine mathematische Fortbildung kümmert und oberallgeier auch dabei ist, so dass ich mich nicht ganz alleine in der Klasse fühle, wäre ich dir dankbar, zumindest für mich einen Link zu einer Einführung zu geben. (Für oberallgeier, glaube ich, ist das nicht notwendig. Der fährt nämlich nicht mit angezogener Handbremse um die Kurve, sondern weiß was er tut.)
Alleine die unter http://de.wikipedia.org/wiki/Kalman-Filter aufgeführten Varianten machen mich schon ganz schwindelig.
Den Modellfehler Q hatte ich aber nur ganz selten bei meinen Fallerhäusern.


So, nun vergiss mein Gejammer ganz schnell wieder. Denn jetzt musst du in den sauren Apfel beißen und meine Antworten auf deine Anmerkungen lesen ;-)

- Abtastzeit 2 ms
Tja, da ist nun waste dran schuld. Nein, eigendlich liegt es nur daran, dass ich die PID-Parameter, die waste mal für die Linienverfolgung ermittelt hatte, nicht selber für andere Zeiten berechnen kann. Somit bin ich (erst einmal) an wastes 2ms gebunden. (mare_crisium gibt bestimmt noch weiteren Matheunterricht?)
Und die 13 ms sind nun mal im Moment der Ansatz, so einen 'langsamen' 8-er-Tik abzuwarten.

- 8 Tik's pro Umdrehung
Beim 'sehen' aller Kanten (16 Wechsel) ergeben sich unterschiedliche Zeiten zwischen schwarzen und weißen eingeschlossenen Flächen.
Ungefähr so: _______+++_______+++______
Bei 8 Tik's:.. ___________+++++++++______
(_ und + sollen bei 8 Tik's gleich lang aussehen.)
Das liegt wohl daran, dass der Triggerwert nicht immer genau die Helligkeit einer Kante representiert, und somit immer an der Kante 'vorbeischaut'.
Entweder macht man den Triggerwert auch noch dynamisch, oder man mittelt, oder man macht halt nur den 8-ter. (Habe ich mir jedenfalls so ausgedacht.)
- Dynamik ist heftig, da ich dann ja auch schon eine Historie kennen muss.
(Diesen Ansatz versuche ich beim Asuro seit ca. 2,5 Jahren ohne Historie zu realisieren.)
- Mitteln, da hat mare_crisium wegen der Mathematik etwas gegen.
- 8-ter reduziert die Genauigkeit von 1,5 mm auf 3 mm.

Sonst bleibt mir nur noch folgendes zu sagen:
Nur weiter mit Einwänden und Anregungen. Bei meinem Tempo, das zu programmieren, muss man ja zwischendurch auch was zu lesen (und schreiben) haben.

Zitat:

---

Leider seid ihr ja vom ursprünglichen Thema Bahnplanung inzwischen auf Geschwindigkeitsschätzen gewechselt.

---

Ich bin Schuld.
Aber es geht wohl auch eher in die Richtung keine Planung zu machen, sondern einfach nur zum gewünschten Punkt zu fahren.

Gruß Sternthaler

[EDIT]
Blödsinnige Formulierung entfernt. Entschuldigung.

Howdy, jeffrey,

ich dachte schon, SternThaler, Oberallgeier und ich wären hier ganz allein im Thread! - Gute Fragen :-) stellst Du.

Also: Es geht uns darum, die Bahnplanung für einen Fahrroboter vom ASURO-Typ (zwei separat angetriebene Räder) auf die Beine zu stellen. Im Endzustand soll es eine Liste anzufahrender Punkte geben, eine Programmebene (um mit Oberallgeier zu sprechen: den Kapitän), die feststellt, ob der aktuelle Zielpunkt erreicht ist und welcher Zielpunkt als nächstes angefahren werden soll, eine nächste Programmebene (Oberallgeier: der Steuermann), die Fahrtrichtung und -strecke ausrechnet und einregelt.

Das alles soll mit einfachen mathematischen Mitteln funktionieren, ohne solche Nebelgranaten wie Kalmanfilter, Beobachter usw. Hast Du sowas schon in einem ATmega32 funktionieren gesehen? Ich meine: Selbst gesehen? Die Gefahr bei den mathematisch aufwendigeren Verfahren ist immer, dass sie die Schwierigkeiten nicht wirklich lösen, sondern nur an eine andere Stelle verschieben, wo sie nicht sofort auffallen. Meist werfen sie sogar noch zusätzliche Probleme auf.

Der Algorithmus, an der wir hier gemeinsam basteln, baut auf der Drehwinkelmessung an den Antriebsrädern auf. Jetzt hat SternThaler auf Probleme hingewiesen, die mit dieser Messung auftreten. Um den Algorithmus ausprobieren zu können, müssen wir also erstmal das Messproblem lösen. - So sieht es auf den ersten Blick aus, als wären wir vom Thema abgekommen - sind wir aber gar nicht. Und Mitstreiter sind allzeit willkommen!

Hast Du Dir unseren Algorithmus mal angeguckt? Was hältst Du davon? Wenn das hinhaut, dann kann man ihn selbst in Assembler programmieren und er passt vermutlich sogar in einen ATmega16.

Deine Einwände zum Verhältnis zwischen Abtastzeit der Messung und Frequenz der Reglerberechnung sind berechtigt.

@SternThaler,
hast Du gut erklärt! Wegen der Reglerparameter mach' Dir mal keine Sorgen, die kann man auch ohne Rechenmodelle experimentell anpassen. So habe ich das mit meinen Kolonnen auch gemacht. Und das funktionierte selbst in jenen fernen Zeiten, als die Regler noch mit Druckluft liefen (Tatsache, kein Schmäh!) sehr zuverlässig.

Ciao,

mare_crisium

Zitat:

---

Zitat von jeffrey

... anmerkung zur geschwindigkeitsschätzung. wie wäre es einen beobachter oder kalmanfilter zu verwenden, um die geschwindigkeit des anderen rades zu schätzen ... eingangssignal für die motoren ist ja bekannt, ... modell des motors .. aus den letzten messungen ... eingangsignal die motorgeschwindigkeit schätzen ... ergebnis wird natürlich umso besser, je kleiner die störungen sind.
mfg jeffrey

---

Hmmm, Beobachter - hmmm, schätzen - hmmm - umso besser - hhhhmmmm.

Hast Du schon mit Beobachtern gearbeitet? Also ICH habe das gemacht. Es ging (vor vielen Jahren) um einen hydraulisch angetriebenen Roboter. Und ich lag im Wettstreit mit dem damals führenden (heute wohl auch noch) Hochschulinstitut für hydraulische Antriebe und Regelungen. Die Fuzzies dort hatten Rechnerkapazität ohne Ende (und eine wirklich angetriebene Achse) - und hatten sagenhaft schöne, wissenschaftliche Arbeiten gemacht. Ich musste in der Industrie mit einem popeligen 8Bitter auskommen, zu dem ich mir aber noch einen Arithmetikprofessor leisten durfte. Selbst ohne meiner Minimalausrüstung (also in der Testumgebung, im Technikum) bin ich mit aufwendigen Rechnern und Rechenkonzepten bei meinem 5-achsigen Gelenkroboter nicht wirklich auf Tempo gekommen mit dem Sch...beobachter. Dauernd musste man dem Typen sagen what happens nur damit der grobe Vorhersagen machen konnte, die von der Wirklichkeit aber immer ein bisschen entfernt waren. Nicht sehr - aber es war ein ziemlicher Aufwand. Gebracht - für meine Industrieanwendung - hatte es dann ein ziemlich popeliger PIRegler - und eine s..gute Diplomarbeit.

:^o UND :-({|= :arrow: Das Institut hatte meinen Ansatz übernommen und den Beobachter über Bord geworfen.

Das ist nur ein isolierter Erfahrungsbericht. Sicher gibt es hier Fortschritte. Aber es bleibt immer noch viel Rechenaufwand mit meist transzendenten Funktionen. Du hast da sicher die Möglichkeit, neue Pfade zu beschreiten und Lorbeeren zu ernten . . . also los.

Zitat:

---

Zitat von jeffrey

... ergebnis wird natürlich umso besser, je kleiner die störungen sind.

---

Ok, das wolln wir mal nicht diskutieren. Es ist ja auch tagsüber heller als nachts.

Zitat:

---

Zitat von mare_crisium

Das alles soll mit einfachen mathematischen Mitteln funktionieren ... Meist werfen sie sogar noch zusätzliche Probleme auf.

---

Na ja, steht ja schon da - ich brauch halt etwas mehr Wörter als mare_crisium für die gleiche Aussage. Aber die Kernaussage von mare_crisium "mit einfachen ... Mitteln" ist wichtig. Wir arbeiten mit Einchip-Rechnern, deren Vorteil in der Beschränkung liegt (will ich nun nicht weiter ausführen) - und die dadurch irre effektiv werden. Und ich hatte etliche Regelkonzepte gesehen, deren Einfachheit für manche Spezialisten erschreckend war - aber ebenso erschraken die gelegentlich über die guten Ergebnisse. Und nun kommt wieder Deine vorige Aussage ins Spiel:

Zitat:

---

Zitat von jeffrey

... ergebnis wird natürlich umso besser, je kleiner die störungen sind.

---

Die Störungen sind umso kleiner, je schneller Du reagierst. Aber auch das ist ziemlich simpel. Ich bin auch ziemlich simpel.

Hallo,
ja kalmanfilter in mega8,16,32, ka welcher es war habe ich schon gesehen, ging dabei um die messwerterfassung bei nen quattrocopter. wie er genau umgesetzt wurde weiß ich nicht, habe es gebaut.
Ich bin auch der Meinung, dass es so einfach wie möglich bleiben soll. Ich würde einfach die zuletzt gemessene Geschwindigkeit nehmen, ohne irgendwelche Schätzungen.
Die neuen Parameter auszurechnen sollte nicht das Problem sein.
Nehmen wir mal als diskreten Regler: y=Kp*(ek+Kd/Ta*(ek-e(k-1))+Ki*Ta*Sum(ei))
dabei sind die Ks die Reglerverstärkungen und Ta die Abtastzeit, und die ks Indizes hoff, dass ist so einigermaßen verständlich.
Jetzt kannst du ja jeweils mit deinen alten Werten von K und Ta Kd das reglerverhalten ausrechenen, und damit auch, wie du deine Verstärkungen ändern musst, wenn sich dein Ta ändert.
MfG Jeffrey

Hey Sternthaler, hey mare_crisium,

Zitat:

---

Zitat von jeffrey

... das ergebnis wird natürlich umso besser, je kleiner die störungen sind...

---

Der Vollständigkeit halber muss ich dazu noch etwas sagen. Wir arbeiten digital (ja ja, das wisst Ihr), selbst floating point ist da von begrenzter Genauigkeit. Und das kann natürlich bei kleinen Messwerten (bei integer kanns fürchterlich werden) zu Problemen führen.

Das beiliegende Bild (aus einer völlig anderen Thematik) zeigt ein Beispiel. Der untere Graph ist eine Art Geschwindigket. Sieht relativ gut aus, nicht wahr? Der obere Graph ist - schon wieder, aber es zu erklären würde zu weit führen - eine Art Ableitung des ersten Graphen. Man sieht nun das jämmerliche Messrauschen. Durch kleine Incremente werden die nur finit langen Messwert-Differenzen teilweise so klein, dass Rundungsfehler eintreten (das ganze lief mit double precision - aber die Messwerte hatten eben keine 15 signifikanten Stellen), die zu einem Rauschen um den Nullpunkt führen. Insgesamt macht das nix aus - aber wenn man einen begrenzten Abschnitt betrachtet (oder auswertet), dann hat man wirklich Probleme!

Mit ähnlicher Problematik hat der integrierende Regler zu tun - der zwar allmählich irre genau werden kann, aber OHNE freigeschnittenen "Mittelstreifen" um den Sollwert zum Schwingen neigt.

Und bei kleinen "Störungen" - und/oder bei Schleichfahrt - könnten natürlich adaptive Algorithmen erst RICHTIG ihre Probleme zeigen.

Hab ich mich verständlich gemacht?

Hallo Fach-Diskuskusionsrunde,
und nun mein OT dazu, da ich zwar gerne mitlesen, aber aktuell doch eigendlich den Rand halten sollte.

Zitat:

---

Zitat von mare_crisium

Wegen der Reglerparameter mach' Dir mal keine Sorgen.

---

Sorgen? was ist das. Du bist doch da!

Zitat:

---

Zitat von oberallgeier

Also ICH habe das gemacht. Es ging (vor vielen Jahren) um einen hydraulisch angetriebenen Roboter.
...
Das Institut hatte meinen Ansatz übernommen

---

Da habe ich wohl in's Fettnäfchen getreten. Ganz große Entschuldigung.

Zitat:

---

Zitat von oberallgeier

Ich bin auch ziemlich simpel.

---

Das möchte ich bezweifeln!

Zitat:

---

Zitat von jeffry

y=Kp*(ek+Kd/Ta*(ek-e(k-1))+Ki*Ta*Sum(ei))

---

Ist bestimmt nicht für meine Augen gedacht ;-)

Zitat:

---

Zitat von oberallgeier

Hab ich mich verständlich gemacht?

---

Habe ich sogar verstanden, dass float nicht die Lösung aller Probleme ist.

Da ich zur Sache nichts beitragen kann, nun Ende.

Gruß Sternthaler