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

Hi

Zitat:

---

jeffry hat folgendes geschrieben::
y=Kp*(ek+Kd/Ta*(ek-e(k-1))+Ki*Ta*Sum(ei))
Ist bestimmt nicht für meine Augen gedacht

---

doch eigentlich scho.
damit kannst du dann deine neuen regelparameter ausrechnen, wenn sich ta ändert, musst natürlich schauen, wie waste damals den regler implementiert hat.
mfg jeffrey

Hallo Jeffrey,
na gut, wenn ich das Verstehen soll, muss ich aber erst mal 'ein kleines bisschen' Fragen.

Zum sparen der Umblätterei:

Zitat:

---

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.

---

- sind die Ks die Reglerverstärkungen
Damit sind Kp, Ki und Kd gemeint, nicht eine neue Variable?

- Ta die Abtastzeit.
Sind das die besagten 2ms, oder tatsächlich die Zeiten, die sich durch die Tik's ergeben?
Ich tippe eher auf die 2ms.

- und die ks Indizes
Soll bestimmt auch eher k's sein? (k in Mehrzahl)

- Kp*(ek+Kd/Ta*(ek-e(k-1))
Hier verstehe ich die Multiplikation mit dem Kp nicht. Warum wird die gesamte Klammer, die den Reglerwert Kd enthält, auch mit Kp multipliziert?
Aufgelöst gibt das ja:
Kp*ek + Kp*(Kd/Ta*(e(k)-e(k-1))
Proportionaler Faktor mit Differenziellem Faktor multiplizieren?
Ich glaube, hier liegt überhaupt mein Problem, dass mir die Reglergrundlagen so verflixt, 'nur im Prinzip, geläufig sind.

- mit deinen alten Werten von K
Was sind alte Werte von K? Wo kommen neue Werte her? Bis jetzt hast du in der Formel ein y ausgerechnet, von dem ich annehme, dass es die 'Stellgröße' ist, die den Motor (oder was auch immer) so beeinflusst, dass alles am Ende gut ist.

- das reglerverhalten ausrechnen
ähm, muss ich ein Reglerverhalten ausrechnen? Wird das Verhalten nicht durch die PID-Parameter eingestellt? Klar, dass ich die erst ausrechnen muss, aber doch nicht mit der angegeben Formel. (Da bin ich mir relativ sicher.)

- das reglerverhalten ausrechenen, und damit auch, wie du deine Verstärkungen ändern musst
Ja genau, aber da stehe ich ziemlich auf dem Schlauch.

- ek, e(k-1) und Sum(ei)
Ist ek ein e(k)?
Was sind e und ei?
e(k) hört sich nach aktuellem error an. e(k-1) nach letztem error.
ei hört sich nach einem error-integrier-wert an.
Ist total geraten!

So, ich glaube, dass ich bewiesen habe, das ich erst einmal einen Grundlagenkurs benötige ;-).
Für mich aber bitte aktuell nicht deine Zeit verschwenden. Wahrscheinlich ist das alles ganz einfach, wenn man nur ein bisschen in der Materie steckt.
Ich werde erst einmal die Mathematik von mare_crisium umsetzen.

Zitat:

---

Zitat von mare_crisium

als die Regler noch mit Druckluft liefen (Tatsache, kein Schmäh!) sehr zuverlässig.

---

Dazu kenne ich einen OT aus meiner Jugend.
- Lagersteuerung in England.
- Telefonische Fehlermeldung auf Englisch. (Geht so gerade, siehe unten ;-))
- Hubtisch wurde nicht angesteuert. Software von meiner Firma.
- In der Software nichts entdeckt.
- Hatte empfohlen, das die Jungs mal den Druckluftschlauch prüfen sollten.
-- Treffer. Da war ich ganz stolz, dass ich als Softwarefutzi an die Hardware gedacht hatte.

Gruß Sternthaler

Hi,
fürs raten war das ziemlich gut. Du hättest heute Lotto spielen sollen. Wären mindestens 6 richtige gewesen, ob es für die richtige Zusatzzahl auch noch gereicht hätte, muss ich mir mal morgen anschauen ;-)
Habe hier mal die Formel als Bild, so sollte es verständlicher sein. Wie gewünscht dieses mal Kp nicht vor der Klammer, ist völlig egal, dann hat man halt ein anderes Kd, bzw. Ki für das gleiche Reglerverhalten, das ist das gleiche, was ich meine, wie sich die Konstanten ändern, wenn man die Abtastzeit ändert.
e sind die Abweichungen vom Sollwert zum Zeitpunkt k, bzw k-1.
So jetzt dann aber gute Nacht.
Gruß Jeffrey

Hallo Jeffrey,
ich hasse Werte, die man einfach so frei nach Schnauze ändern darf, und ich nicht weiß warum :Haue. Aber so erklärt, kann ich es verstehen, dass man auf ein gleiches Reglerverhalten kommt.

Auch eine ruhige, gute Nacht.
Gruß Sterntahler

hi,

Zitat:

---

Wären mindestens 6 richtige gewesen, ob es für die richtige Zusatzzahl auch noch gereicht hätte, muss ich mir mal morgen anschauen

---

seh grad was ich da für ein schwachsinn geschrieben hab, soll natürlich superzahl heißen, net zusatzzahl, war ja aber au scho spät ;-)

so jetzt aber zurück zum thema:
ich habe jetzt ers mal eine frage zu deiner realisierung vom d-anteil? du bekommst ja nur ca alle 10 regler durchläufe einen neuen messwert, hoff ich hab mich jetzt net verrechnet. das bedeutet ja, bei 9 durchläufen ist die änderung zum vorherigen 0, also der d-anteil auch 0, hast du das irgendwie kompensiert? sonst kannst du den d-anteil ja eigentlich gleich weg lassen.
so jetzt zum verändern der abtastzeit(das sind die 2ms). wenn du jetzt z.b. auf 20ms gehst, also Ta_neu=10*Ta_alt, dann musst du halt auch Kd und Ki verändern. Also Kd_neu=10*Kd_alt und Ki_neu=Ki_alt/10 K_alt sind die Reglerparameter, die du in deinem Programm verwendest, bei 2ms abtastzeit. K_neu sind dann die, die du verwenden solltest, wenn du die abtastzeit auf 20ms erhöhst. diese rechnung stimmt natürlich nur, wenn der regler nach der oben beschrieben gleichung arbeitet. aber das hat waste bestimmt beschrieben, welche gleichung er verwendet.
Ich hoffe, das war jetzt einigermaßen verständlich, ich wollte hier nur beschreiben, wie du da drauf kommen konntest. ich hoffe es hilft dir.
mfg jeffrey

Hallo zusammen (es scheint sich nun bei 4-ren einzupendeln).
Alle Mitleser sind natürlich auch gegrüßt.

Um erst mal sicherzustellen, was ich immer mit dem waste-Regler meine:
Asuro: Linienfolger mit PD-Regler
So, das wäre erst einmal klargestellt.

Jetzt die Ungereimtheiten:
- Der Thread heisst "PD-Regler", ist aber ein waschechter PID-Regler geworden.
- Alle weiteren Ungereimtheiten gelten nicht.

Ein paar Einsprungpunkte zum Thread, von denen ich glaube, dass die irgendwie wichtig sind:
Hier ist der Messaufbau von Manf zum Ermitteln des Trägheitsmomentes in Drehrichtung. (Heisst das so?)
Hier berechnet Manf aus seinen Messungen das Trägheitsmoment.
Hier setzte waste Bode-Diagramme in PID-Werte um.
Hier werden die Ergebnisse von waste in ein Programmiermodell umgesetzt. Da müsste sich ja die eigendliche Formel von waste am einfachsten finden lassen.
Hier ist die letzte, von mir gefundene, Programm-Version von waste für den Asuro.

Und wie ich gerade sehe Jeffrey, kennst du den Thread ja auch auswendig ;-)
Jeffrey was here

Deiner Ausführung Jeffrey, zur Änderung an der Abtastzeit, konnte ich wohl folgen. Aber auch nun wieder mein Problem, dass ich nicht nachvollziehen kann, dass es überhaupt erlaubt sein soll so zu rechnen. Macht aber nix.
Vielleicht mal zum Unterschied zu dem, was ich von mare_crisium bis jetzt gelesen habe: Das habe ich verstanden, da dort Geometrie mit der Mathematik formuliert ist. Bei solchen Sachen kann ich mir das irgendwie vorstellen.

Gruß Sternthaler

Hallo,
oh, das ist ja schon ne ganze weile her. aber geht es da nicht um die linienverfolgung?
denke mal es wurde die reglergleichung verwendet, die steht auch im wiki.
probier doch mal aus, was passiert, wenn du die zeit veränderst und die parameter anpasst.
wie hast du denn jetzt das problem mit dem d-anteil und der langsamen messung gelöst?
mfg jeffrey

Hallo,
ich bin´s nochmal. Diesmal habe ich paar Fragen an mare_crisium zum Koppelnavigation_Algorithmus_V03.pdf. habe es mir gerade mal angschaut. Kann es sein, dass bei der Berechnung von vl und vr ein geteilt durch delta_t fehlt?
warum nimmt du für die winkelabweichung das kreuzprodukt, also den sinus? warum nicht einfach direkt die winkeldifferenz?
und dann noch ne frage zum anfahren eines punktes mit richtungsvorgabe. dieses regelungskonzept funktioniert aber nur, wenn der richtung ungfäh aus der richtung kommt, in die er den punkt durchfahren soll. unterscheiden sich die richtungen ist glaube ich doch eine bahnplanung notwendig. aber von der idee her nicht schlecht.
gute nacht jeffrey

@Jeffrey
Es geht hier, in diesem Thread, nicht um die Parameter aus dem Linienverfolgungs-Regler!
Das ein Regeler hier mal benutzt werden soll, wurde erwähnt, um eine 'sanfte Kurve' hinzubekommen, um den Asuro (oder jedes andere Fahrzeug, oder auch Arme) von Punkt A zu Punkt B zu bewegen, ohne dass 'per Handbremse' oder 'mit schleuderndem Heck' um die Ecke gefahren werden muss.

Allerdings ist Programmcode zum Algorithmus eines PID-Reglers im Linienverfolgungs-Thread vorhanden. Der soll nur benutzt werden.
Neue Parameter wird dann mare_crisium irgendwann in Zukunft machen, oder, so wie er es vorgeschlagen hat, von mir durch 'Versuch, macht klug' geraten werden.

Gruß Sternthaler.

jeffrey,

mit fehlenden der Division durch delta_t bei der Berechnung von v_r und v_l hast Du allerdings recht. Die neue, korrigierte Version ist schon in der Mache. - Danke für den Hinweis! :-)

Das Kreuzprodukt ist der wirkliche Clou an der Geschichte: Erstens ist es im Bereich kleiner Winkelabweichungen praktisch proportional zur Winkelabweichung; d.h. die Fein-Navigation wird sehr gut funktionieren. Zweitens kann man's in Assembler berechnen (ohne Winkelfunktionen bemühen zu müssen). Drittens spart man sich die grauen Haare, die es immer gibt, wenn man die Ist- und Sollwinkel in Grad rechnet und beide auf verschiedenen Seiten der 360°-Grenze liegen ;-).

Der einzige Nachteil ist das Abnehmen der Regelabweichung, wenn die Winkelabweichung 90° über- bzw. -90° unterschreitet. Das kann man aber auch richten, indem man als Regelabweichung die 1 nimmt, wenn das Skalarprodukt der Ist- und der Sollrichtung kleiner gleich 0 ist. Das Skalarprodukt ist auch wieder ein rein linearer Zusammenhang, wenn man Einheitsvektoren verwendet; also kriegt man's wieder ohne Winkelfunktionen hin.

@SternThaler,

yup, das "Versuch macht kluch" - Verfahren zum Ermitteln der Regelparameter werden wir dann anwenden. Meiner Erfahrung nach ist es schneller als wenn man erst ein mathematisches Modell entwirft, und es liefert robustere Einstellungen.

Ciao,

mare_crisium

Sersn

ich muss mal ganz doof fragen ob es doch tatsächlich so super schwer ist einer Linie zu folgen? Hab mir ein paar Sourcecodes durchgelesen und das scheint ja in der Tat doch schwerer zu sein als ich erwartet hatte (und ja ich hab immer noch keinen µC daheim liegen und dümpel in der theorie rum) ^^

BlackDevil,

doof ist Deine Frage auf gar keinen Fall :-). Mit Linienfolgern habe ich mich noch nicht beschäftigt und hier kümmern wir uns darum, ein Fahrzeug ganz ohne Linie zu vorbestimmten Wegepunkten fahren zu lassen. Wenn Du das Thema Linienfolger von der mathematischen Seite her aufziehen willst, solltest Du einen separaten Thread in diesem KI-Forum aufmachen. Ich würde mich beteiligen und Du kriegtest bestimmt auch Unterstützung von Leuten, die das Problem schonmal durchdacht und gelöst haben.

Meiner Meinung nach hängt der Schwierigkeitsgrad stark von der Art der Sensoren ab, mit der man die relative Lage von Fahrzeug-Längsachse und Linie misst: Oft sieht man nur drei Reflektions-Lichtschranken - das ist schwierig. Wenn man einen kompletten Liniensensor verwendet, etwa aus einem Scanner - das macht es viel einfacher. -

Ciao,

mare_crisium

Zitat:

---

Zitat von BlackDevil

... fragen ob es ... schwer ist einer Linie zu folgen?

---

Also es ist wirklich garnicht einfach. Beispiele: Das Allereinfachste - versuche mal GENAU auf der Mittellinie der Strasse zu fahren (bitte NUR wenn weit und breit kein anderes Fahrzeug da ist und Du noch VIEL Strasse einsehen kannst). Ich hab schon immer Schwierigkeiten in der Autowaschanlage, einigermassen die Mitte zu finden. Oder, nimm Dir nen Flieger (es reicht ein Flugsimulator) und fliege NUR nach dem CDI (Kursablaganzeiger, CDI = Course Deviation Indicator). Das ist eine Nadel, die anzeigt, ob Du links oder rechts vom Leitstrahl bist. Und da braucht man schon sehr viel Gefühl für die Trägheit des Dings, um wieder auf den Strahl zu kommen. Das Gleiche gilt für die Höhe über oder unterm Leitstrahl. Ähnliche Probleme, fast noch gravierender, hat man im U-Boot, wenn man eine bestimmte Höhe (ist ja auch ne Linie) halten will.

Jetzt haben wir aber einen roboter mit SEHR eingeschränkter Sensorik. Ich glaube das ist Dir dann ganz ohne Mathe klar, dass da ein Problem auftaucht. Als Mensch ist das einfach zu lösen: Du hast komplexe optische Sensoren, taktile (Deine Füsse wissen schon recht gut, ob DU linkslastig oder rechtslastig gehst), Gleichgewichtssinn (schwanke ich ...), eine komplexe "Datenverarbeitung" . . . Ich will das jetzt nicht zu sehr ausbreiten. Du verstehst es sicher.

Wie sehen jetzt Lösungen aus? Eine besonders pfiffige Lösung kenn ich vom U-Boot. Es ist von der Physik her praktisch eine Art Wurfparabel, die vorhersagt, in welcher Höhe ich in - sagen wir mal - in 20 Sekunden bin. Diese einfache Vorhersage erlaubt eine dramatisch verbesserte Steuerbarkeit. Und solche Vorhersagestrategien sind für die genaue Einhaltung einer Route das Thema des Threads: Algorithmen zur Bahnplanung. Natürlich gehört die Erfassung der Situation dazu:

Zitat:

---

Zitat von mare_crisium

... hängt der Schwierigkeitsgrad stark von der Art der Sensoren ab, mit der man die relative Lage von Fahrzeug-Längsachse und Linie misst: ...

---

Daher auch einige Diskussionen über Weg- und Geschwindigkeitsmessung hier. Aber diese Fragen sind lösbar - mehr oder weniger gut.

@Alle,

so, jetzt ist die neue Version V06 fertig, allerdings noch ohne die Ergänzungen für die SternThaler-Methode zur Drehwinkelmessung an den Rädern. Dafür berücksichtigt sie die Korrektur von jeffrey und gibt auch eine modifizierte Rechenvorschrift für erhöhte Schätzgenauigkeit an.

Ciao,

mare_crisium

Edit1: Habe den Anhang "Koppelnavigation_Algorithmus_V06.pdf" gelöscht. Die korrigierte Version V07 ist im Post vom 28.11.2007 zu finden.

Okay vielen dank. Wusste gar nich das das insgesamt so aufwendig wird, also Mathematisch...
Ich denke ich mach im laufe des Tages mal nen Mathethread auf hehe

Hallo alle zusammen,
ja, es wird so langsam Weihnachten.

Genau aus diesem Grund, und weil der erste Ansatz nun im Asuro steckt, hier mal auf die schnelle das ganze Zeug.

Die rechnende Funktion als Ausschnitt aus asuro_st.c:

Code:

---

/*****************************************************************************
  FUNKTION:  NaviCalc
  Aufgabe:    Funktion zur Berechnung der Navigationswerte.
              Diese Funktion wird im ADC-Interrupt aufgerufen um die aktuellen
              Positions-Koordinaten und Richtung vom Asuro anhand der Daten
              der Odometrie zu berechnen.
              Ausgewertet werden die globalen Variablen count36kHz_l .._r
              Die Ergenisse werden in einer globalen Datenstruktur fuer die
              Anwendung zur Verfuegung gestellt.
  Parameter:  seite    Angabe, an welcher Rad-Seite der Tik gerade
                        aufgetreten war.
  Global:    count36kHz_l
              count36kHz_r
  V011    26.11.2007  Sternthaler
                        Funktion in erster Version
*****************************************************************************/
        unsigned char  NaviCalc (
        unsigned char  seite)
{
static            double speed_last_l = 0;
static            double speed_last_r = 0;
                  double speed_l;
                  double speed_r;
                  double speed, omega, zeit;
                  double omega_zeit = 0, speed_zeit = 0;
static            double phase_x = 0;
static            double phase_y = 1;
static            double pos_x = 0;
static            double pos_y = 0;

  if (seite == RECHTS)
  {
      speed_l      = speed_last_l;
      speed_r      = 10789.0 / count36kHz_r;
      speed_last_r = speed_r;
      zeit        = count36kHz_r / 36000.0;
      count36kHz_r = 0;
  }
  else
  {
      speed_l      = 10789.0 / count36kHz_l;
      speed_r      = speed_last_r;
      speed_last_l = speed_l;
      zeit        = count36kHz_l / 36000.0;
      count36kHz_l = 0;
  }

  /*
      Mittelere Geschwindigkeit
  */
  speed = (speed_r + speed_l) / 2;

  /*
      Drehwinkel. Die 10.36 sind der Radabstand.
  */
  omega = (speed_r - speed_l) / 10.36;

  /*
      Neue Phasenwerte berechnen
  */
  omega_zeit = omega * zeit;
  phase_x = phase_x - phase_y * omega_zeit;
  phase_y = phase_y + phase_x * omega_zeit;

  /*
      Und endlich auch die neuen X- und Y-Positonen
  */
  speed_zeit = speed * zeit;
  pos_x = pos_x + phase_x * speed_zeit;
  pos_y = pos_y + phase_y * speed_zeit;

  MD_RAD_POS_HIST ((int)(pos_x * 100), (int)(pos_y * 100));
 
  return 0;
}

---

Ich weiß. Noch wird mit Fließkomma gerechnet. Noch sind nicht alle notwendigen Rechenschritte vorhanden. Und auch bei der Berücksichtigung der beiden Tik-Zeiten-Zähler ist bestimmt noch ein dicker Fehler vorhanden.
Aber, das Ergebnis ist schon nicht allzu schlecht.

Die besten Zahlen stecken zur Anschauung im Excel-Diagramm.

@mare_crisium
Deine neueste Version V06 ist noch nicht gelesen. Ich schätze, dass ich somit um das Schätzen dann demnächst auch nicht herrumkommen werde. Ich schätze aber, dass dies auch wieder etwas dauern wird :Ostern .

Zitat:

---

Zitat von oberallgeier

... für die Trägheit des Dings, ...

---

Ich fühle mich geradezu angesprochen. :cheesy:
P.S.: Ich glaube, der Asuro mit Taucheranzug ist noch nicht gebaut worden ;-). Du erklärst die Probleme immer sehr schön bildlich. Klasse.

So, viel Spaß mit dem Codehaufen.
Gruß Sternthaler

Wie gut das mein Visual C++ auch C lesen kann :)
Dann les ich mal.

Generell in der Theorie würde mich das mal Interessieren. Ich bin nich doof oder sowas aber für das obige Scriptbeispiel muss man Maschbau oder Physik Studieren ums zu verstehen oder :D Ich weis Grob was da abgeht, Vektoren und so, das Verlässt aber mein Bisschen Hochschulwissen das dafür Ausreicht irgendwelche lustigen Elektronen in irgendwelchen Feldern zu Berechnen, Theoretisch... Felder kommen erst nächstes Semester ^^

Hallo BlackDevil,
toll, dass C++ lesen kann ;-)

Wenn du alle Beiträge in diesem Thread auswendig kennst, dann kannst du das auch nachvollziehen. ;-)
Schlieslich habe ich es auch (teilweise) geschafft aus den guten, hier gegeben, Bedienungsanleitungen diesen Code zusammenzustricken.
Als kleiner Hinweis, woher die da angegeben Zahlen herkommen:

- 10789.0 [cm/s^2 (glaube ich)] ist ein Faktor, der die Geometrie vom Asuro an der ODO-Scheibe darstellt. In dem hinterlegtem EXCEL-Blatt, im Reiter 'v und Zählerberechnung', wird der Wert in Anhängigkeit zwischen Raddurchmesser, und Tik-Anzahl pro Radumdrehung, berechnet.

- 36000.0 [1/s] sind die 36 kHz, mit der ein Timer im Asuro rennt. Dieser liefert die Zählwerte zwischen 2 Tik's.

- 13.36 [cm] ist einfach der Radabstand. In mare_crisium's Ausführungen sind das 2*a.

Der Rest ist meine künstlerische Variante der Umsetzung aus dem Koppelnavigation_Algorithmus von mare_crisium.

Ich hoffe, das dies etwas hilft. Und lass die Elektronen schön an ihren Plätzen, nicht dass die Welt auseinander bröselt ;-).

Gruß Sternthaler

Zitat:

---

Zitat von Sternthaler

... Und lass die Elektronen schön an ihren Plätzen, nicht dass die Welt auseinander bröselt ;-)...

---

Ja, wenn das nur ginge. Die Elektronen sind doch die, die alles durcheinanderbringen. Rennen von einem Pol zum anderen, kaum setzt man ihnen ein bisschen Widerstand entgegen, sind sie auf 180 und mehr aber wenn sie mal direkt aufeinandertreffen - also leider ist das Netzteile meines "Hauptrechners" gerade den Hitzetod gestorben (wo der vor 10 Tagen schon die SystemHDD unbrauchbar gemacht hatte).

Die Neutronen sinds, die´s bringen. DIE halten das Universum zusammen. Und dabei sind sie kaum zu erkennen . . . beneidenswert!

Sternthaler, eigentlich wollte ich mit "Danke für das Lob" anfangen. Aber ich neige eben zu solchen OT-Abschweifungen.

Ach ja - wieviel Tics pro Radumdrehung sind beim Asuro üblich? Ich frage nur, weil ich für mein Miniprojektchen die erforderliche Auflösung abschätzen möchte.

Mir gings ja nich um die Direkte Umsetzung sondern die Überlegung

Problem --> Mathematik <--> Physik ==> Gleichungen

Nehmen wir mal das Beispiel das ich einen Motor mit dem Drehmoment M=2Nm, zwei Angetriebene Räder mit dem Durchmesser d=10cm, eine Strecke von s=1m habe wobei ich 56° um die Kurve fahren will welche eine länge von 20cm hat. Jetz hab ich ja eigentlich alles was ich wissen muss um mir Gleichungen aufzustellen.

v lässt sich aus der Frequenz der Räder errechnen. Ferner nehmen wir mal an das die räder Zylinder sind. Das machts einfacher das Trägheitsmoment auszurechnen.

Wenn wir v und s haben als Gleichung können wir wunderhübsch ausrechnen wielange wir zur Kurve brauchen.

Ab dann Verlässt mich die Überlegung.

So meinte ich das (= Wie man das denn am besten umsetzt. Klar hab ich meine "Algorithmen" wie ich bei sowas vorgehe, die Versagen nur bei Manchen Aufgaben in Physik.

JOa^^


edit: Ich glaube das Universum fände es schon nich so schön wenn ein C Atom oder ein O Atom aufeinma 2 ELektronen weniger und ein anderes dafür 2 Elektronen mehr hat ;)

Zitat:

---

Zitat von BlackDevil

Nehmen wir mal das Beispiel das ich einen Motor mit dem Drehmoment ... ... Jetz hab ich ja eigentlich alles was ich wissen muss um mir Gleichungen aufzustellen.

---

Ach weisst DU, das ist nicht sooo schwer - wenn man mal einen Ansatz für den Weg hat. Das wirst Du üben und dann hinkriegen. Zu Deiner Aufgabe oben (Problem --> ...) gehe ich so ran: (1) mechanisches Modell - (2) physikalisches Ersatzmodell - (3) Gleichungsansätze (erst ab hier ist Mathe angesagt) - (4) Lösung der Gleichungen - (5) technische Möglichkeiten - (6) Realisierung/Umsetzung. Manchmal sollte man (2) schon mit einem Blick auf (5) bearbeiten oder ähnliche Seitenblicke riskieren. Die Ausarbeitung von mare_crisium ist ja ein schönes Beispiel dazu. Negativ: Ich hatte mal eine Ausarbeitung von einer Uni zu einem schwingenden System (eine bestimmte, reale Maschine). Die hatten 22 Freiheitsgrade gefunden - das war vermutlich nicht falsch, trotzdem war es eine unsinnige, unnötige Arbeit, weil kein Mensch 30 bis 40 Parameter oder Randbedingungen bestimmen wird. Ich hatte daraus einen viergängigen Schwinger gemacht :). Und in Basic die Lösung der DGLn geschrieben.

Aber jetzt stehe ich an: kann kein C und will damit die AVR´s programmieren :( - nee, nicht so, eher :) :) :), dann gehts leichter.

Zitat:

---

Zitat von BlackDevil

Ich glaube das Universum fände es schon nich so schön wenn ein C Atom oder ein O Atom aufeinma 2 ELektronen weniger und ein anderes dafür 2 Elektronen mehr hat ;)

---

Hast Du in der Schule Chemie gehabt? Beim Thema "Ionen" warst Du vermutlich beim Billardspielen - wie ich dauernd in Geo!? Ich wollte das OT vorhin nicht ausbreiten, aber die Elektronen sind wirklich DAUERND Störenfriede. Wissen oft nicht, zu welchem Atom/Molekül sie gehören, hüpfen von einer Schale auf die andere, man hat auch nur eine UNGEFÄHRE Ahnung wo die sind (E-Wolke) usw usf - aber dem Universum ist das schnurzegal. Es besteht trotzdem.

Ja aber die Anzahl Atome innerhalb eines Bestimmten ist trotzdem rel. bestimmt. Und wenn dem C atom ein Elektron Fehlt ist das ähnlich uncool als wenn ein Neutron fehlt. Oder ;)?

Auch in einem ELektrischen Leiter herrscht nur Ladungsträger Austausch

Hallo oberallgeier
Grin, wir wissen doch alle, dass dies wahrscheinlich der Thread mit dem höchsten OT-Aufkommen ist.
Aber musstest du denn zur Bestrafung vom Netzteil gleich zum Kurzschlußstecker greifen, nur weil es deine Platte gegrillt hatte? ;-)

Ob es bei der Tik-Anzahl am Asuro einen Standard gibt, möchte ich bezweifeln. (Wahrscheinlich gibt es aber nur relativ wenige Varianten.)
Meiner wurde mit 2 Scheibenpaaren ausgeliefert. (2,5 Jahre alt)
je 8 schwarz- + weiss-Flächen -> 16'er-Scheiben
je 4 schwarz- + weiss-Flächen -> 8'er-Scheiben
Dann glaube ich noch irgendwo gelesen zu haben, dass es auch 12'er und 24'er gibt.
Da beim Asuro 'danach' noch eine Getriebstufe von 5:1 kommt, haben wir somit 16*5 oder 8*5 Tik's pro Raddrehung, wenn jeder Farbwechsel als Tik interpretieret wird.
Genau für diesen Thread nutze ich aber, wegen der unterschiedlichen Zeiten bei der schwarzen und weißen Fläche, nur die Wechsel von schwarz nach weiss. Also Tik-Anzahl halbiert. (Ich habe die 16'er-Scheiben drauf)

Hier kann man noch 2 Besonderheiten finden:
Probleme mit 22er-Lochscheiben
Verschiedene Muster für die Odometriescheiben
(Da ich bei beiden erwähnt werden, verfestigt sich so langsam mein Bild über mich selbst: Da habe ich wohl eine Manie ;-))

Hallo BlackDevil
Was du dir für Fragen stellt ;-) Bei mir ist das gaaanz, gaaanz anders.
Auch ich habe ab und zu das Problem, dass die Formeln manchmal versagen. (Bei mir liegt es dann aber eher daran, dass ich Elekronen und Neutronen durcheinander bringe. Äh, meine natürlich Äpfel und Birnen.)
Ja, du hast schon Recht. Erst mal Überlegen und dann Umsetzen, auch ich bin da meistens so orientiert.

Und natürlich auch ein Hallo an dich, mare_crisium
So, ich habe gerade deine Version 6 gelesen. Das wird ja eine richtige Vorlesung für Asuro-Kapitäne-und-Heizer. (Vor allem für Heizer, da die das ja nun auch verstehen können.)
Kleine Frage zur Formel direkt vor der modifizierten Formel (8a), in der v(i) * omega(i) berechnet werden.
Ist es da richtig, dass als Indice für R, n und N immer nur r angegeben ist? Beim Einsetzen von dem Zeug um (8a) zu bekommen würde ich jetzt Indice l vermissen.
(Irgendwie hätte ich bei PI * ( ((Rr*nr) / Nr) + ((Rr*nr) / Nr)) * (PI/a) * (....) hinter dem + bzw. - in den Klammern eher etwas mit Indice l erwartet.)

Ha, und dann noch die Angabe, dass man bei der Berechnung einer Zielfahrt, bei Richtingsabweichungen von mehr als 90Grad, höllisch aufpassen muss. (Wenn man bei deltaP = 0 in die falsche Richtung schaut, steht man ja vor einem dummen Problem.)
Diese Beschreibung kann ja nur direkt für mich gemacht worden sein. Danke.
Und zum Schluß: Du hast einen schönen, zusammenfassenden Schluß gefunden, der die Vorteile dieser Art der Wegberechnung, die ja eher eine Fahr-einfach-zum-Ziel-Berechnung ist, aufführt.
Echt Klasse.

Gruß Sternthaler

P.S.: Ich bin wieder zu lahm. 2 Beiträge seitdem ich hier tippe.
Fehlende Elektronen kann nur bedeuten, dass die noch bei mir im Akku sind. Somit fährt mein Asuro noch ;-)

hi,
@sternthaler: was war denn bei der fahrt, für die du die daten aufgezeichnet hast der sollwert? welcher zielpunkt und welcher winkel. kannst du mal bei einem nächsten versuch die wirklich gefahrene strecke messen. also zum beispiel als ziel einen punkt in 2m entfernung, und als winkel 80° und dann mal den punkt vom startpunkt aus ausmessen, damit wir mal sehen, wie gut er den punkt trifft. und den winkel nachmessen.
mfg jeffrey

@SternThaler und @Oberallgeier,

danke für Eure Anmerkungen zu V06. Ich habe sowohl die Formel vor (8a) jetzt korrigiert, als auch die Vorzeichen-Vereinbarung für den Richtungswinkel der üblichen mathematischen Konvention angepasst (negativ entspricht dem Uhrzeigersinn und umgekehrt). - Nachdenken war in der letzten Woche etwas erschwert wegen der zwei Weisheitszähne, von denen ich mich verabschiedet habe... jetzt geht's aber wieder. Die neue Version V07 hänge ich an und lösche dafür die V06, der Upload-Quota wegen ;-).

mare_crisium

Zitat:

---

Zitat von jeffrey

@sternthaler: was war denn bei der fahrt, für die du die daten aufgezeichnet hast der sollwert?

---

- Keine Koordinaten-Sollwert-Vorgabe.
- Ziel war es, Messdaten bzw. Rechenergebnisse für die ersten 100 gefahrenene Tik's zu sammeln.
- Vorgegeben Fahrt waren 100Tik's * 3 mm/Tik.
--- Erste Fahrt: 100 Tik's geradeaus
-----> Die berechnete Abweichung ist zu groß.
--- Zweite Fahrt: 25 Tik's geradeaus. Den Rest in einem Linksbogen
-----> Die berechnete Abweichung ist zu groß. Der Bogen wurde nicht so weit gefahren.


Hallo mare_crisium,
ich hoffe, dass du die Weisheitszahn-Verabschiedung ohne Komplikationen überstanden hast. Auf alle Fälle wünsche ich dir eine Gute Besserung, und keine weiteren Zahnschmerzen. (P.S.: V07 ist schon kopiert)
Gruß, der Mitfühlende

Zitat:

---

Zitat von oberallgeier

.. aber dem Universum ist das schnurzegal. Es besteht trotzdem.

---

Hoffentlich aber nicht in einer Nußschale, wie von Stephen postuliert. 8)

Tschaui, Sternthaler

@SternThaler,

vielen Dank für Deine guten Genesungswünsche! Sie haben auch noch für die anschliessende Pflicht-Grippe gereicht :-)!

Also, hier ist eine nocheinmal überholte Version, in der ich versucht habe, die Idee mit der verbesserten Schätzgenauigkeit graphisch zu erklären.

Die Daten, die Du mit Jeffrey diskutiert hast, sind die schon mit dem Algorithmus gefahren? Wenn ja, dann hift vielleicht die Verbesserung noch ein bisschen, die Genauigkeit Deinen Vorstellungen näher zu bringen.

Ciao,

mare_crisium

Holla Mare Crisium,
gut, dass das gute Genesungswünsche waren. Sonst hättest du ja zumindest noch den Schnupfen.
Ich hatte schon Angst, dass dich meine 'Geschwindigkeit', hier etwas umzusetzen, so gelangweilt hat, dass du in einen Dauerschlaf gefallen wärst. ;-)

Wie so üblich bei dir, ist es für mich wieder Verständlich geworden, was du beim Schätzen verbessert hast.
Das trifft sich auch ganz gut, da meine letzte Programmversion ja nur eine Version zum testen der Formeln war. Also, wie oben mit jeffrey, besprochen, noch nichts mit Zielvorgaben.
Außerdem hatte ich erst die einfachste Variante der Berechnung ohne Korrekturen benutzt.

Mittlerweile bin ich mir aber ganz sicher, dass die Abweichung zwischen Fahrt und XY-Berechnung nicht an der Formel liegt, sondern vor allem an meinem Testprogramm.

So mache ich da das Rechnen:

- Timerinterrupt
-- Zähler für beide Seite erhöhen.
-- AD-Wandler abwechselnd für die ODO-Scheiben anwerfen.

- AD-Interrupt
-- Wandlerergebnis auf schwarz-/weiss-Wechsel untersuchen.
-- Bei TIK-Erkennung die XY-Berechnung ausführen.
-- Diese Ergebnisse sammeln

- Hauptprogramm
-- Fahre N Tik’s geradeaus.
-- Fahre M Tik’s im Bogen.
-- Stoppe den Asuro, wenn der Datensammler voll ist.
-- Sende die gesammelten Daten auf Tastendruck zum PC.

Die Fahrt vom Asuro kann ich mir schön ansehen.
Somit weiß ich, was ungefähr berechnet sein sollte.

Die berechneten Daten zeigen aber eine recht hohe Abweichung.

Warum:
Ich hatte schon 'vor ein paar Tagen' geschrieben, dass meine Tests, in Bezug auf die Rechenleistung des AVRs, ausreichen sollte. Ich war so auf maximal 80% CPU-Zeit bei voller Asuro-Geschwindigkeit gekommen.
Also lag der Gedanke nahe, die Rechnung direkt im ADC-Interrupt machen zu lassen. Zeit reicht ja schließlich.
Das ist aber ein fataler Fehler, da dann keine anderen Interrupts mehr ausgeführt werden, und somit die Zähler für die beiden Seiten im Timerinterrupt nicht mehr bearbeitet werden. Dadurch wird kein neuer AD-Wandler gestartet, und dadurch gibt es auch keine Erkennung eines weiteren Tik’s.
Also kommt zu den falschen Zählerwerten auch noch hinzu, dass eventuell 2 Tik’s gefahren werden, aber nur als ein TIK in der nächste Berechnung berücksichtigt wird.

--> Alles durcheinander. Dafür ist das Ergebnis erstaunlich gut. #-o

Also schon mal eine neue Lösung ausgedacht.
Berechnung der XY-Werte außerhalb der Interrupts machen. Das gehört sich ja auch so, da man allgemein weiß, dass Interrupts möglichst schnell fertig sein sollen. Und nicht 80% CPU fressen dürfen.

Na ja, so weit bin ich schon. Habe aber noch keine Zeile Code für den Asuro angefasst, da der Code in der Firma eine höhere Priorität hat. (Die Prio ist nicht auf meinem Mist gewachsen. Wirklich nicht!)

Mal sehen, der nächste Urlaub ist geplant. Vielleicht schaffe ich es diesmal nicht die ersten Tage davon in der Firma rumzulungern. Dann kann es evl. mit dem Asuro weitergehen.

Gute Nacht und
viel Grüße vom Sternthaler.

SternThaler,

... und ausserdem kommt jetzt erstmal Weihnachten.

Ciao,

mare_crisium

Hallo zusammen.
Nun, Weihnachten ist definitiv vorbei.

Also, das Thema ist noch lange nicht vom Tisch und mit der Hartnäckigkeit eines verzweifelten Asurobesitzers geht es nun weiter.

Zur Erinnerung:
- Mathematik zur XY-Berechnung ist vorhanden (Dank mare_crisium)
- Rechenleistung zur Umsetzung im AVR scheint gegeben zu sein.
- Verlagerung in Interrupt steht an. (Sternthaler (ich) behauptet dies.)

Mein Problem ist folgendes:
Das im Anhang vorliegende Testprogramm liefert nicht immer Geschwindigkeitsdaten von 0, wenn die Motoren NICHT drehen. Das ist definitiv falsch. Ich habe aber keine Vorstellung, wo der Fehler steckt.

Vorgehen im Programm:
- Timerinterrupt zählt 1/36000 Sekunden.
- Timerinterrupt startet Odometrie-Messungen (AD-Wandler).
- AD-Interrupt zählt Odometriewechsel .
- Hauptprogramm sendet per asuro_st.c/NaviPrint() Odo-Daten und Zählerdaten alle 500 ms an PC.
- PC wertet diese Daten in Excel aus, und kommt bei stehenden Motoren mit den übertragenen Daten NICHT zum Ergebnis, dass die Motoren stehen.
--> Somit würden XY-Koordinaten berechnet, die falsch sind.

Die Messdaten sind so zustande gekommen, dass die Motoren:
- nicht drehen
- langsam drehen
- nicht drehen
- schnell drehen
- nicht drehen
- langsam drehen
- nicht drehen

In den Exceldaten sieht man aber:
- "nicht; langsam; NICHT nicht; schnell; nicht; mittel; NICHT nicht"
- "nicht; langsam; nicht; schnell; NICHT nicht; langsam; nicht"

In keiner meiner unendlichen Messreihe schaffe ich es, dass beim "nicht drehen" eine Geschwindigkeit von 0 reproduziert werden kann.
So lange die Motoren drehen, scheinen korrekte Daten erzeugt zu werden. Nur bei einer Geschwindigkeit von definitiv 0 werden meistens falsche Daten erzeugt.
Irgendwo ist da von mir ein Wurm eingebaut worden.
HILFE, wer findet den Wurm?

Auch wenn oberallgeier in einem anderen Thread sagt, dass ich "nebenher" noch beschäftigt bin, so ist dieses Thema immer noch eine 'Herzensangelegenheit' bei mir :).
Ich könnte euch mittlerweile auch noch Fotos vom Flur ohne Tapeten beilegen, aber ich glaube, dass ihr schon lange wisst, dass ich gerne und viele neue Tapeten an Wände pappe. (Zumindest will dies meine Frau so.)

Gruß Sternthaler