OT: Suche Hilfe bei Koordinatentransformation

Falls sich hier niemand findet der das uebernehmen kann und moechte, mir fallen dazu zwei Leute ein: Jon Kirwan aus USA und Al (Onestone) aus Australien. Beide mischen in der Yahoo MSP430 Gruppe mit, Jon auch auf s.e.design. Wenn Du deren private Email brauchst sage Bescheid, schicke ich Dir dann.

Du könntest es mal bei

Ich würde es allerdings ganz normal mit float erstmal ausprobieren (lassen). Ein ARM9 mit 125 MHz ist wirklich schnell genug, in Anbetracht dessen, daß du aus normalen Beschleunigungssensoren sowieso nicht mehr als 100 Hz Änderungsrate herausbekommst. Hängt aber natürlich davon ab, wie weit der ARM schon ausgelastet ist, aber kann man dann ja immer noch nach Fixedpoint konvertieren oder die Updaterate senken, falls möglich.

Nachtrag: Frage mal Frank Buss aus dieser NG. Er hat m.W. schon Sachen mit Beschleuigungssensoren gemacht, weiss nur nicht ob er Zeit haette:

Danke, hat er schon gemacht. Ich habe aber erst wieder Anfang nächstes Jahr für neue Projekte Zeit, da ich wochentags aktuell Vollzeit bei einem Kunden vor Ort arbeite und am Wochenende nicht auch noch an kommerziellen Projekten arbeiten möchte, soweit möglich (also z.B. wenn es kein dringendes Altkundenprojekt ist). Obwohl interessant wäre es schon, aber meine ersten Gehversuche mit Quarternionen in Second Life sind schon was her, sodaß es auch länger dauern könnte, als bei einem, der das täglich macht und besser in Mathematik ist.

Die Spec müsste schon genauer formuliert sein.

Sensor liefert kartesische Koordinaten die man gerne polar hätte ?

Ganz ohne letztere wirds kaum gehen. (Knickarm-)Kleinroboter liefern oft über Tacho Winkel am Gelenk ( d.h. polar ) den man gerne gleichzeitig kartesisch hätte. Meine Lösung für 68HC08 wird wohl ca. so aussehen:

D.h. man kann grosse/genau Tabellen in externem seriellen EEPROM ablegen. Das erleichtert die Trigonometrie. Alternativ zur kompletten Neuberechnung gibt es Tracking-Algorithmen die von Resolvern abgeleitet sind. Das dämpft den Verbrauch an Rechenzeit.

In Bild 22,23 ist auch noch die bekannte Achsenrotation um einen Teilwinkel dargestellt die technisch ähnlich ist.

Als Alternativen ist auch CORIC erwähnt: wurde explizit für Koordinatenwandler erfunden. Scheint in meiner Anwendung aber auf 68HC08 nicht so attraktiv.

MfG JRD

------------

PS: ich benutze jetzt Arcor, denn nun haben wirs von t-online amtlich: \ Da die Bedeutung des Usenet als Kommunikationsplattform \ in den letzten Jahren stark abgenommen hat - v. a. \ zugunsten von Foren - wird die Telekom den bisher für \ unsere Kunden betriebenen Newsserver news.t-online.de \ voraussichtlich zum 31.03.2011 abschalten.

Wie oft und welche Genauigkeit?

Meinst du natürlich, dass 1g trotzdem da ist, also das Fahrzeug kein Satelit im Weltraum ist. Also dann, wenn die Karre steht oder aus anderem Grunde zufällig sqrt(ax^2 + ay^2 + az^2) == 1?

Kommentar unten.

Es ist eine "Teufel im Detail" Aufgabe. Grundsätzlich ist erstmal trivial einen Koordinatensystem in einen anderen zu überführen. Etwas sinus und cosinus, kann man in Tabellen ablegen und schon sind wir fertisch, Quaternionen sind nicht mal nötig, solange man nicht integrieren oder differenzieren möchte. Allerdings real existierende Sensoren haben eine blöde Eigenschaft zu rauschen und zu schwimmen. Mehr oder weniger, aber immer. Um den echten Aufwand abzuschätzen wären noch die Randbedingungen interessant: Abtastrate, die geforderte Genauigkeit und die Parameter der Sensoren. Daraus ergibt sich nämlich auch ein Ergebnis: fast trivial bis unmöglich.

Jetzt noch mal zum Verständnis. Du schreibst:

Ich nehme mal an: habe einen Zeitpunkt erwischt, wo die resultierende Beschleunigung auf das Fahrzeug 1g beträgt und ich habe daraus meine Koordinaten des Sensors bzw. des Fahrzeugs bestimmt. Ich nehme an, dass dieser Sensor fix mit der Karre verbunden ist. Soll ich dann ALLE Werte, die darauf folgen überführen, oder die davor oder irgendwelche Trajektorie basteln? Diese 1G-Messpunkte werden wohl ziemlich zufällig da sein, je nach dem, ob und wie sich das Fahrzeug bewegt.

Ich glaube um den Aufwand für solchen Algorithmus abzuschätzen sollen diese Fragen geklärt werden.

Habe etwas Hokus-Pokus mit Beschleunigungssensoren gemacht, auch Koordinatentransformation und Trajektorienberechnung (geht fast nie ohne Zusatzinfo), allerdings nur Offline.

Waldemar

Für die Akten: Da ist wohl ein Typo drin, es ist wohl der CORDIC gemeint. Der hat den Vorteil, dass er ohne Multiplikationen/Divisionen, nur mit Shifts auskommt.

Gruß Henning