Algorithmen zur Bahnplanung

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