Algorithmen zur Bahnplanung

[Sternthaler]

Volles Programm: JA, MACHT SPASS (bewußtest Uppercase !)

Geistiger Input ist doch dann nur klasse, wenn man nicht sofort alles Versteht, aber man noch das Licht am Ende des Tunnels erahnen kann, bzw. man auch seine Grenzen kennt.
Meine Anmerkungen aber bitte nicht missverstehen. Ist kein "ich will das aber so", sondern nur meine persönliche Denke. Die (manchmal ) auch was neues, anders als besser akzeptiert.

Ich bin aber immer noch nicht so weit eine Zeile Code zu schreiben. Dieser Eintrag entsteht just gerade noch in der Firma. Und ob ich dann Zuhause noch Bock habe bezweifel ich jetzt schon.

Gruß Sternthaler

[plusminus]

> http://href.to/fQ3 <-- Hinführung zum Wegfindungs.Thema aus einem Uni-Vorkurs; Ameisen-Algorithmus & Dijkstra
> http://href.to/ki1 <-- Dijkstra mathematisch
> http://href.to/Yh3 <-- AStar Sehr einfach erklärt

grtz

[Sternthaler]

Hallo plusminus,
gute Lektüre (der letzte Link ist von mare_crisium schon am 13.09.2007 angegeben worden. Ähnliche Version)
Die Vorlesung aus dem ersten Link habe ich mal überflogen und kann dem ganzen sogar folgen. Was ich beim 2-ten Link zu dieser Stunde nicht mehr sagen kann.
Kleine Frage: Wie lange brauchen Ameisen eigendlich von Imstadt nach Oppenheim?

Jetzt gehe ich aber doch erst mal in's Bett.
Morgen berichte ich dann mal von meinen ersten Codezeilen zur Umsetzungen der mare_crisium-Version zum Zielanfahren. (Werden aber erst einmal mehr Fragen als Antworten.)

Gute Nacht, und/oder guten Morgen.

[plusminus]

gedopte Ameisen bitte

[Sternthaler]

Hhhmmm, dann tippe ich darauf, das die Fahräder haben.

[Sternthaler]

Hier nun mal im Telegrammstil meine bisherigen Überlegungen: (beim Asuro, bei einer vorgegeben Odometriehardware)

- Bestimmung der Geschwindigkeit v= m/s

Wird m als Messwert genutzt, und s ist bekannt, dann liegt m beim Asuro bei ca. 0,15 cm pro Einheit.
Da nur ganzzahlige Einheiten bekannt sind, ergeben sich somit von Einheit zu Einheit relativ große Fahrstrecken, die prozentual einen großen Fehler darstellen, wenn in kleinen Zeitintervallen gemessen wird.
Werden die m-Einheiten erst nach einer relativ großen Fahrstrecke ausgewertet, dann ist das Fahrzeig aber auch schon sehr weit 'steuerlos' gefahren.

Deshalb der Ansatz m konstant zu halten und s als Messwert zu nutzen.
Wenn m mit einer Einheit ca. 0,15 cm darstellt, und der schon laufende Timer2-Zähler mit 36 kHz benutzt wird, kann pro Fahreinheit m je nach Geschwindigkeit ein Zählerwert von 100 (ca. 50cm/s) bis 550 (ca 10 cm/s) erwartet werden. Somit ist der Verlust des Nachkommanteils immer kleiner als 1%.
(Der EXCEL-Anhang stellt dies dar.) 2 Berechnungen daraus hier als Bildanhang.


Aber folgendes Problem tritt auf:
Der erkannte Wechsel der SW-Teilung auf der ODO-Scheibe erfolgt auch bei gleichmäßiger Fahrt nicht in gleichen Zeiteinheiten.
Soll heißen, dass der erwartete Wert von beispielsweise 256 bei einer Geschwindigkeit von 20cm/s beim Asuro nicht kontinuirlich zu messen ist.
Dieser Wert schwankt in 2 Zyklen.
1. Die zeitliche Breite von weis und schwarz auf den ODO-Scheiben ist unterschiedlich.
2. Durch wahrscheinlich nicht zentriertes Anbringen der ODO-Scheibe 'eiert' die Zeit pro Umdrehung derselbigen.
Beides hatte waste auch schon mal ermittelt. (Bin relativ sicher, das es waste war)

Hier stellt sich nun die Frage, wie man am besten diese beiden 'Eier'-Werte mitteln könnte, ohne möglichst viel Genauigkeit zu verlieren.
Ich hoffe auf reichliche Integrale und Ableitungen

[mare_crisium]

SternTahler,

nein, heute wird nicht integriert!

Ich bin mit Deiner Tabelle nicht ganz klar gekommen; deshalb erzähle ich mal, wie ich Dich verstanden habe:

Du versuchst bei der Odometrie eine bessere Messgenauigkeit zu erreichen, indem Du anstelle der Anzahl Sektoren pro Zeiteinheit, die Zeiteinheiten zwischen zwei Sektorenflanken misst. Diese Zeitspanne ist genau definiert, während man bei der anderen Methode nie so recht weiss, an welcher Stelle zwischen zwei Sektoren man sich zum Zeitpunkt der Messung gerade befindet. - Richtig? Mit der Zeitmessung kann man auch sehr gut die aktuelle Umdrehungszahl des Rades abschätzen und im Prinzip daraus zu jedem beliebigen Zeitpunkt den aktuellen Drehwinkel des Rades, d.h. den zurückgelegten Weg, angeben.

Beim Messen der Zeitdifferenzen hast Du eine Streuung festgestellt, die Du auf einen Zentrierfehler zwischen den Mittelpunkten der Sektorenscheibe und des Zahnrades zurückführst. - So, wie die Konstruktion des ASURO auf den den Fotos aussieht, hast Du wahrscheinlich recht.

Die angehängte Tabelle zeigt, wie sich der Zentrierfehler (Zentrum der Sektorenscheibe ist um einen einstellbare Entfernung und einer einstellbaren Richtung vom Zentrum des Zahnrades verschoben) auf den Zeitpunkt der Sektorflanke auswirkt. Alle Zahlen in den grün unterlegten Zellen können verändert werden. Die letzte Spalte zeigt für jeden Sektor die vom Zentrierfehler verursachte Zeitdifferenz.

Im ASURO-Wiki

http://www.asurowiki.de/pmwiki/pmwik...Main/Odometrie

ist auch ein Link auf den Thread im Roboternetz, in dem waste sich zu dem Problem äussert und eine Lösung für das Geradeausfahrt-Problem angibt.

Ehrlich gesagt, der Zentrierfehler sollte nicht so stark durchschlagen. Er mittelt sich ja bei Geradeausfahrt auch über jdede volle Umdrehung wieder aus. Das wird erst anders, wenn der ASURO seine Fahrtrichtung sehr schnell ändert. Ich tippe eher auf die mechanischen Einflüsse, die in dem Thread erwähnt werden (Zahnradspiel, Motoraufhängung usw.).

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

[Sternthaler]

Hallo mare_crisium.

nein, heute wird nicht integriert!

Uff, noch mal Glück gehabt.

... Du versuchst bei der Odometrie eine bessere Messgenauigkeit zu erreichen, ....

Hast du ja doch alles verstanden, was ich mit den Tabellen ausdrücken wollte. (Habe ich genau so bei dir erhofft.)

... eine Streuung festgestellt ...
hast Du wahrscheinlich recht.

Ist mir durch den Beitrag von waste erst bewust geworden. (Den Beitrag werde ich bestimmt noch mal wiederfinden. Es war definitiv nicht der aus dem von dir angegeben Wiki-Beitrag.)
Scheint aber tatsächlich so zu sein, da ich seine Messungen auch nachvollziehen kann.
Genau hier setzte ja nun meine Frage nach Intergralen und Ableitungen an.
Wenn ich es mir so überlege, müsste aber dieser ganze Fehlerkram über eine Anpassung beim I-Wert für einem Regler der Geschwindigkeit ausgebügelt werden können. (Ich glaube, dass I für 'ungleichmäßige' Veränderungen zuständig ist. Namentlich 'integriert', müsste es doch Flächen unter Kurven 'zusammenmitteln' und somit 'flatternde' Änderungen irgendwie glätten.)

Bei deiner Tabelle kann ich bis auf Eingaben <> 0 in E4 "Winkel <x-Achse|Mitte_Odo_Scheibe>" gut folgen. (Auch Spalte E macht mir Kummer, wenn bei negativem Bogenmaß noch 180 Grad addiert werden.)
Aber, ja, genau die in Spalte H ermittelte Zeitdifferenz ist das Problem, welche durch einen Regler 'gefiltert' werden muss.
Gerade die Zeitdifferenzen in der von dir ausgerechneten Spalte H sind meine 'Bauchschmerzen'. (Nix Mathe; Bauch ist bei mir der Maßstab. Pizza mit vielen Pilzen [fest und flüßig] kann ich immer vertragen. )

Im ASURO-Wiki ...

Schade, das in dem von dir angegeben Wiki-Beitrag 2 Links auf die gleiche Seite zeigen. Hat aber nichts mit meiner Haarspalterei zu tun.

Ehrlich gesagt, der Zentrierfehler sollte nicht so stark durchschlagen.

Ja, ja, ja, das genau wollte ich hören.

Ich werde also die weiteren Programmstückchen erst einmal mit diesen 'Bauchschmerzen' fortführen und weiter berichten/fragen.

Noch eine ruhige Nacht wünscht
Sternthaler

[mare_crisium]

Sternthaler,

so, jetzt kann ich die korrigierte Tabelle schicken. Mit der Eingabe "Winkel <x-Achse|Mitte_Odo_Scheibe>" wollte ich berücksichtigen, in welche Richtung die Sektorscheibe, relativ zur x-Achse, verschoben ist. Das habe ich jetzt einfach weggelassen, weil dieser Winkel das "Eiern" nur in der Phase verschiebt; die Grösse der maximalen Wegdifferenz bleibt davon unbeeinflusst. Die Addiererei mit 2*pi() usw. kommt von der Mehrdeutigkeit des arctan und sollte Dich nicht weiter beschäftigen. Oben habe ich jetzt die Summe der Wegdifferenzen über eine volle Radumdrehung eingestellt: Sie ist immer Null, wie Du schon vermutetest.

Das bedeutet: Bei Geradeausfahrt kann der ASURO wohl ein bisschen schlängeln, aber es geht nix schief. Aber wenn's um die Kurve geht und ein Rad schneller dreht als das andere, dann mitteln sich die Fehler nicht mehr aus. Am Ende der Kurve bleibt ein Restfehler, dessen Betrag ungefähr zur Differenz der Umdrehungsgeschwindigkeiten, also zum Kurvenradius, proportional ist.

Wenn Du das ausgleichen willst, musst Du nicht am Regler basteln, sondern an der Wegmessung (Odometrie): Der Fehler ist abhängig davon, welche Stellung die Räder beim Einleiten und am Ende der Kurvenfahrt hatten. Du müsstest also nicht nur die Umdrehungsgeschwindigkeit erfassen, sondern den echten Drehwinkel jeweils für jedes Rad. Das lässt sich bewerkstelligen, indem Du den ASURO immer mitzählen lässt, welche Nummer der Sektor hat, den seine Lichtschanken gerade erfassen. Dann müsstest Du ihm für jedes Rad eine Tabelle mitgeben, die für jeden Sektor die zurückgelegte Wegdifferenz angibt. Der ASURO muss dann bei einem Sektorwechsel anhand der Nummer des aktuellen und des vorhergehenden Sektors in der Tabelle nachgucken, welche Wegstrecke diesem Wechsel entspricht und die dann zum bereits zurückgelegten Weg dazuzählen. Im Grunde ist das einfach eine kalibrierte Wegstreckenmessung.

Das zu Programmieren ist eigentlich kein Kunststück. Aber zu diesem Zeitpunkt in Deinem Projekt geht's ja mehr um das Prinzip, als um den letzten Millimeter an Genauigkeit. Deshalb rate ich, diesen Schritt erst am Ende einzubauen, wenn sicher ist, dass alles andere richtig funktioniert.

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

[Sternthaler]

Hallo mare_crisium,
damit es nicht langweilig wird, hier jetzt auch mal ein paar Messdaten.

Daten in den einzelnen Blättern:
daten-01:
Die Spannungsmesswerte der ODO-Sensoren bei ASURO-Speed 180

daten-02 bis daten-04:
Zeitwerte zwischen 2 Tik-Wechseln bei ASURO-Speed 180

daten-05 bis daten-07:
Zeitwerte zwischen 2 Tik-Wechseln bei ASURO-Speed 255 (Maximum)

Wie man sehen kann, ist die linke Sensorik (immer in blau dargestellt) nicht so gut wie die rechte Seite. Da habe ich schon zu viel an der Messscheibe 'herrumgemacht' für andere Test's.

Bei den daten-02 bis daten-07 habe ich die X-Achse mal in 16er-Schritte geteilt, da dies ja bei mir die Anzahl Tik's pro Umdrehung ist.
Hier kann man nun, vor allem auf der rechten/roten Seite, sehr schön sehen, dass die Scheibe 'eiert'.
Und natürlich sieht man bei dem kontinuierlichen hoch und runter der Messwerte, dass die Zeiten zwischen der weissen und schwarzen 'Messfläche' lustig vor sich hin hüpfen.

Um heute auch noch etwas kurz auf deinen Beitrag einzugehen:
Dieses 'hin und her hüpfen' der Messdaten wollte ich eventuell von dem Regler ausgleichen lassen. Das der Asuro keine Präzisionswege fahren kann, hatte ich schon beim Nikolausfahren festgestellt.
Im übrigen ist dein zuletzt geposteter Anhang sehr aufschlußreich was die zu erwartenden Fehler angeht. Ist ja nicht die Welt, so dass man hier auf alle Fälle weitermachen kann ohne nicht ein bisschen Erfolg (in Zukunft) zu erhaschen.

Zum staunen hier ein, von Manf an anderer Stelle geposteter Link, über fahrende CPU's: http://www.spiegel.de/videoplayer/0,6298,22553,00.html

Nächtliche/Morgendliche Grüße von
Sternthaler