Momentan beiße ich mir die Zähne an den Gyroalgorithmen aus, irgendwie will das bei mir nicht funktionieren. Sieht so aus als würde das noch länger dauern, ich muss mein Mathewissen wohl erst einmal ein paar Semester höher schrauben

Falls jemand weiß wie man aus 2 Winkelwerten eines Gyros den "Summenwinkel" berechnen kann, also die Wahre Neigung des Sensors, dann wäre ich für einen Tipp dankbar. Quaternions nimmt man dafür, nur leider klappt das irgendwie bei mir nicht richtig, meine realen Messwerte weichen von den berechneten ab.

Louis

Geändert von Neil am 30. Juni 2014 um 13:14

Hast du dir mal angeguckt wie das bei Telemega von Altusmetrum gemacht wird, die müssten doch genau das selbe Problem haben.

Geändert von Neil am 30. Juni 2014 um 13:14

Deren Algorithmus liefert bei mir falsche Daten, fast richtig, aber eben nicht ganz richtig.
Ausserdem kriege ich damit in bestimmten Fällen division durch 0 Fälle.

Konkret geht es bei diesem Problem darum, dass die Rakete im Normallfall über 2 Achsen dreht. Die Drehung um die "Z-Achse", also die, die durch die Rakete geht, ist uns egal.

Wenn ich einen Gyrosensor nur über eine Achse drehe ist alles fein, dann habe ich einen Winkel. Kippe ich ihn über 2 Achsen gleichzeitig sind die einzelnen Achsensoren gekippt, sie liefern dann nur einen Teilwinkel.
Die Kombination dieser beiden Teilwinkel muss ich in die Gesamtneigung umrechnen, was leider nicht so einfach geht wie ich das erhofft hatte.

Als Beipiel: Wenn ich mein Sensor über Eck von Senkrecht auf Waagercht kippe zeigen die X- und Y-Achsen eine Drehung von ca. 60° an, real liegt das Teil aber dann 90° gekippt auf dem Tisch. Normalerweise rechnet man dass mit Quaternions, aber irgendwie ergibt dieser Fall dort immer nur 78°, nicht 90° wie es sein sollte. Auch liefert die Altus-Lösung bei Drehung über eine Achse von 90° einen Winkel von 88°, was schon mal nicht stimmen kann. Das müsste exakt 90° sein.


Louis

Geändert von Neil am 30. Juni 2014 um 13:14

Das wäre doch mal ein Fall für einen schweizer Mathematik-Professor....... !

Ich könnte mir vorstellen das Andreas Müller dafür eine Erklärung bzw. Lösung hat ......!?

Viel Erfolg !

Andreas

Geändert von Neil am 30. Juni 2014 um 13:14

Das mag für diesen konkreten Fall egal sein, aber allgemein vermute ich mal dass Du den dritten Winkel nicht komplett ignorieren darfst, denn wenn sich die Rakete dreht, kann derselbe Drehwinkel um eine bestimmte Körperachse für die Lage im Raum völlig unterschiedliche Dinge bedeuten.

Du kannst hier ja mal etwas genauer darstellen, wie Dein Algorithmus zz. aussieht.

Oliver

Geändert von Neil am 30. Juni 2014 um 13:14

Hallo,

ich habe mal ein eigenes Thema aufgemacht, wei ldas hier bestimmt etwas größere Ausmaße annehmen wird.
Zu dem Problem,

Ich denke auch das die Z-Achse (parallel zur Raketenachse) berücksichtigt werden muss. Das wäre aber ein späterer Schritt. hier ist wohl auch noch die Rollrate zu berücksichtigen.

Um von vorn herein Sensorfehler auszuschließen, würde sich ein Drehtisch anbieten um die Sensore zu testen. Kippen um 90° ist gut, liefert aber evtl. nicht eine Aussage über die Rollrate. Man müsste da schneller und langsamer kippen um zu sehen ob immer das gleiche heraus kommt. Daher ein Drehtisch wo man die Geschwindigkeit einstellen kann, und der ziemlich genau läuft.
Ich würde hier ein Plattenspieler nehmen. Das sind die Dinger wo die schwarzen Platten drauf kommen.
Dem Altimax dann eine Software und LED verpassen so das diese immer nach genau 360° kurz aufleuchtet. Wenn der Sensor richtig misst, sollte dies immer an der gleichen Stelle vom Plattenspieler geschehen. Man kann dann mal den aufbau etwas länger laufen lassen um zu sehen ob dieser Punkt wandert. Wenn ja, Gain ändern.
Dann den Spaß bei einer anderen Geschwindigkeit noch mal durchführen. Wenn Sensor und software richtig arbeiten, muss das Gleiche heraus kommen. Wenn nicht, hat die Messkette eine Geschwindigkeitsabhängigen Fehler.
Alles natürlich für alle drei Achsen machen.
Wenn man die Testsoftware etwas aufwendiger gestalten will, kann man auch, wenn vorhanden, die Magnetfeldsensoren als Marker nehmen. Diese sollten ein sinusförmiges Signal liefern. Wenn man dann den Magnetfeldsensor Wert speichert in dem Augenblick wo der Altimax meint genau eine Runde gedreht zu haben, sollten die Messwerte über die Zeit betrachtet konstant sein. Sollte da ein sinusförmiger Verlauf drin sein, so misst er nicht alle 360°.

Wenn das Alles funktioniert,, würde ich nochmal mit der Altrussoftware ran gehen und schauen ob da dann der Wert raus kommt den man erwartet.

Gruß

Neil

Geändert von Neil am 30. Juni 2014 um 13:29

Ich habe die Altus-Software in ein Delphi-Programm umgewandelt, dort kann ich die Algorithmen am PC durchtesten, ich kann da verschiedenen Werte in das "Filter" eingeben.
Da zeigt sich schon schnell, dass da etwas im Argen ist, wenn ich da für eine einzige Achse 10,00° Drehung eingebe kommt als Gesamtwinkel 9° heraus, wobei es 10° sein müssten.
Rundungsfehler schließe ich hier mal aus, der Datentyp ist genauer als der bei Altos verwendete.

Ich habe das den ganzen Sonntag geprüft, es ist eine exakte 1:1 Übersetzung des Altus-Codes nach Pascal. Ich suche jetzt nach dem Fehler, irgendwo muss der ja sein.

Drehtisch wäre natürlich toll, momentan kann ich aber die Genaugkeit ziemlich gut garantieren, wenn ich die ganze Mimik senkrecht hinstelle, auf 0 setze und dann 90° auf den Tisch kippe zeigt mein Roh-Winkel 90° an, das stimmt also schon mal.

Andreas Müller hatte mir schon geantwortet, er hat Drehmatrizen vorgeschlagen, eine erste versuchsweise Umsetzung von mir war leider nix, ich hoffe er hilft mir da noch ein bisschen weiter, wer ihn kennt, kennt seine umfassenden von höherer Mathematik strotzenden Antworten, ich komme da meist nicht mehr mit


Louis

Ich habe es anscheinend gefunden, bzw. Andreas hat mich drauf gebracht: Ich habe mit zu großen Winkeln probiert, also gleich 60° genommen anstatt 60x1° Drehung zu rechnen.
Dann klappts mit den Drehmatrizen, und zwar exakt :-)

In Wirklichkeit rufe ich ja alle 5ms den Drehwert aus, integriere ihn und speise ihn dann in den Algorithmus ein. In so kleinen Häppchen klappt das prima, zumindest in Excel.

Edit: Telemega-Code funktioniert jetzt auch, es war ein Fehler in meinem Code, ich habe fälschlicherweise
GRADTORAD benutzt, nicht DEGTORAD, das war der Grund für die falschen Ergebnisse. Also Asche auf mein Haupt, mein Fehler, beim Altus-Os ist alles ok.

Also konzentriere ich mich erst einmal weiter auf Andreas Lösung, die sich auch eleganter berechnen lässt.

There is always hope :-)

Louis

Geändert von Lschreyer am 01. Juli 2014 um 18:42

Zitat:

---

GRADTORAD benutzt, nicht DEGTORAD

---

So etwas sind die schlimmsten Fehler da man sie nicht findet. Der Compiller mault nicht, der Code sieht logisch und richtig aus. Erst wenn man aus Verzweifelung sämtliche Funktionsbeschreibungen durch liest kommt man dann auf so etwas.
Kenne ich leider nur zu gut.

Bezüglich Z-Achse mit in die Betrachtung nehmen, verweise ich hier mal auf den Bambus Helicopter Thread. die dinger zeigen ja sehr gut, das ein Kippen auf der X oder Y Achse bei einer kompletten Umdrehung der Z Achse ausgeglichen wird.

Gruß

Neil

Z ist mit drin, leider braucht die ganze Berechnung noch zu lange Rechenzeit, da muss ich noch optimieren.