Plenz

Sorry, ich hab jetzt keine Lust auf Debuggen. Bisher ging jedenfalls alles. Mein Programm, das ich von dem Callback-Beispielprogramm abgeleitet habe, funktioniert nach wie vor. Jedenfalls habe ich jetzt noch mal mit meinem Programm zwei Tests gemacht, wieder einmal waagerecht und einmal um 45° gekippt, und dabei jeweils langsam um 360° rotiert. Etwa alle 5° habe ich x, y, z, w abgespeichert, in Excel übertragen und dort die Formeln eingesetzt. Hier angefügt die Ergebnisse, schön mit Diagrammen dargestellt. Man sieht: keine der Formeln rechnet irgend etwas heraus. Wenn der IMU-Brick gekippt ist, ändern sich bei einer einfachen Drehung sämtliche Winkel. Deshalb noch mal zurück nach oben zu meinem Eintrag mit den Screenshots vom Brick Viewer. Ich habe das dumpfe Gefühl, das in der grafischen Darstellung des IMU-Bricks meine gesuchten Formeln stecken, denn egal wie man den IMU-Brick auf dem Tisch rotiert, das Bild stellt immer "IMU-Brick ist 45° zur Seite gekippt" dar. Also muss es doch irgend eine Formel geben, die ich in meine Excel-Tabelle einfügen kann und die mir in jeder Zeile diese 45° errechnet. IMU_Test.xls

Hüstel... ohne korrekte UID käme gleich am Anfang eine fette Fehlermeldung

Sorry, irgendwas klappt mit dem Programm nicht. Nach "Press key to exit" tut sich überhaupt nichts, erst nach dem Tastendruck kommt einmal "x: 0, y: 0, z:0". Der Code ist ja an sich verständlich, ich kann den Fehler nicht finden.

Nein, leider nicht. Ich habe heute noch mal zwei Versuche gemacht: 1.) IMU-Brick waagerecht gelegt und langsam um 360° gedreht 2.) IMU-Brick ca. 45° gekippt und langsam um 360° gedreht Mit "gekippt" meine ich: USB-Stecker runter, LEDs rauf. Beim Drehen (per Hand) habe ich x,y,z,w mitgeloggt. Diese Werte habe ich in einer Excel-Tabelle gespeichert und mit den bekannten Formeln ergänzt (die drei aus der Doku und die eine von ThomasKl). Ich hänge die Tabelle hier mal dran. Was ich immer noch suche: eine Formel, die mir bei der ersten Drehung konstant "0" ausgibt und bei der zweiten Drehung konstant "45". IMU_Test.xls

OK, mal kurz getestet. IMU-Brick um 45° geneigt (USB-Stecker runter, Richtungs-LED rauf) und dann das Ganze auf dem Tisch hin und her gedreht. w nach der obigen Formel ist bei -180° anders als bei +180°. Wie gesagt, brauche ich aber eine "45", egal wie der Brick auf dem Tisch gedreht ist.

Für mich ist das leider überhaupt nicht einfach mangels jeglicher Kenntnisse über Vektorrechnung. Aber wenn es für dich einfach ist, wäre ich dir für eine nachprogrammierbare Formel sehr dankbar.

Sorry, ich kämpfe gerade auf einer anderen Baustelle (IMU-Brick überreden, die Zahlen auszuspucken, die ich brauche).

Genau! Diese Quaterdinger interessieren mich nämlich überhaupt nicht, mich interessiert nur die Verdrehung gegenüber der Horizontalen. Und die sieht man im Brick Viewer ganz hervorragend. Anbei ein paar Screenshots: 1.) Der IMU-Brick liegt flach auf dem Tisch 2.) Der IMU-Brick um 45° nach rechts gekippt (links hoch, rechts runter) 3.) Den gekippten IMU-Brick um 90° auf den Tisch nach rechts gedreht 4.) Den gekippten IMU-Brick um weitere 90° auf den Tisch nach rechts gedreht Die grafische Darstellung ist im Grunde genommen immer die selbe: ich sehe den IMU-Brick um 45° nach rechts (um die Achse des USB-Steckers) gekippt. Unabhängig von allen anderen Winkeln! Unabhängig von der Drehrichtung! Alles, was ich brauche, ist eine Formel, die mir diese "45°" ausspuckt, und zwar für alle Screenshots 2.) bis 4.) und natürlich noch eine zweite Formel für das Kippen nach vorn/hinten. Die jetzt in der Doku eingebauten drei Formeln liefern das jedenfalls nicht, ich habe es gerade getestet.

Wie gesagt, hatte ich beobachtet, dass sich die Winkel x und y gleichzeitig verändern, auch wenn ich den IMU-Brick nur um eine Achse drehe. Entweder stimmt was mit meiner Kalibration nicht oder mit deinen Formeln oder mit meinem Verständnis. Damit wir von der selben Sache reden, habe ich eine Skizze gemacht. Ein Flugzeug hat Pitch=0°, wenn es normal fliegt, und Pitch=-5°, wenn es landet. Und Roll=0°, wenn es geradeaus fliegt, und Roll=10°, wenn es sich in die Kurve legt. Und das alles völlig unabhängig voneinander. Sollte ich eigentlich mit deinen Formeln genau diese Ergebnisse bekommen? Oder sind dafür doch noch andere Formeln notwendig?

Ich war heute mittag mal kurz zu Hause und habe ein bisschen getestet (hab momentan echt nichts anderes im Kopf als IMU). Und zwar: IMU raus aus allem, Motoren weit weg, Magnetometer kalibiriert und mein Programm so verändert, dass es mir kontinulierlich die "nackten" Werte von x, y, z und w ausgibt. Und dann das Ding waagerecht auf dem Tisch gedreht. Schon mal einfach: z und w sind immer etwa Null. Aber nun der Schock: wenn ich das Ding um 180° nach links drehe, bekomme ich andere Werte für x und y, als wenn ich es um 180° nach rechts drehe! Zweimal haargenau die gleiche Lage, aber verschiedene Werte: -180° x=-0,37 y=+0,93 +/-0° x=-0,97 y=-0,25 +180° x=+0,46 y=-0,88 Weitere Experimente mit genicktem IMU-Brick habe ich mir gleich geschenkt. Das Ding ist einfach zu hoch für meinen armen Verstand. :'(

Noch zwei Gedanken: 1.) die Nick-Drehung bewegt den IMU-Brick leider auch in Richtung zu bzw. von einem der Motoren. Sollte ich versuchen zu minimieren. 2.) Euer Kalibrier-Video... da sind doch auch Motoren direkt neben dem IMU-Brick, also von wegen Raum ohne Magnetfelder...?

Vielen Dank erst mal, ich hab's gerade mal auf die Schnelle ausprobiert. Die schlechte Nachricht: x_angle und y_angle verdrehen sich immer gleichzeitig. Die gute Nachricht: sie sind tatsächlich unabhängig von der Fahrtrichtung. Vielleicht sollte ich das erst mal ohne Motoren in der Nähe testen, aber ich muss ins Büro Ich hoffe, der Zahnarzt hat dich nicht schachmatt gesetzt, und was das Bett betrifft: Schlaf ist völlig überbewertet, in Wirklichkeit ist das nur so ein primitiver Kafee-Ersatz.

Ähh... nicht dass dich das von den IMU-Formeln abhält...!

Autsch, hatte ich geflissentlich übersehen Noch eine blöde Frage: wie ist das mit dem Kalibrieren des Magnetometers gemeint? IMU losschrauben, USB-Kabel anstecken und IMU dort drehen, wo sie eigentlich sitzen sollte? Oder die ganze Apparatur mit IMU und Motoren drehen?

Ich sehe gerade, in der Doku hat sich ja allerhand getan. Nicht nur die zusätzlichen Formeln, sondern auch eine ausdrückliche Empfehlung, den Magnetometer in der Nähe von Motoren neu zu kalibirieren. Das beantwortet zwar nicht meine Verständnisfragen, aber egal - Hauptsache, ich weiß, wie ich weiter vorgehen muss. Ich bin gespannt, was dabei herauskommt...

Du musst nur den Akku über eine Diode mit dem Rest verbinden, dann gibt der Akku automatisch Strom ab, sobald die Netzspannung unter die Akkuspannung sinkt. Die Diode verhindert, dass Netzustrom in den Akku hineinfließt. Das ist völlig simpel. Das Hauptproblem ist die komplizierte Ladeelektronik für moderne Akkus. Da gibt es bei "C" sicherlich Bausätze.

Hast völlig recht, ich werde das mit einem Timer versuchen. Das Auge braucht ja nur ein paar Updates pro Sekunde, während das Programm intern viel schneller arbeiten muss.

Beim Rumspielen mit dem IMU-Brick habe ich jetzt eine grafische Oberfläche gebastelt, die die verschiedenen gemessenen Winkel darstellt. Dabei ist mir aufgefallen, dass das Programm manchmal den Callbacks hinterher läuft. Das mag daran liegen, dass ich alle 50ms ein Callback erzeugen lasse, oder auch an meinem manchmal langsamen Notebook, das vielleicht im Hintergrund mit anderen Dingen beschäftigt ist. Jedenfalls bewege ich den IMU-Brick und nichts passiert... und ein paar Sekunden später werden die gerade durchgeführten Bewegungen zeitversetzt dargestellt. Ich habe versucht, über Variablen den Zustand "Callback-Subroutine ist noch nicht abgearbeitet" festzuhalten, wenn die Subroutine erneut aufgerufen wird, das hat aber nicht geklappt. Offensichtlich wird die Subroutine erst dann wieder aufgerufen, wenn der letzte Aufruf komplett abgearbeitet ist. Wie kann man solche "Hänger" abfangen?

Ich hasse Video-Tutorials. Viel besser ist ein geschriebenes Dokument mit Screenshots, das braucht man nicht zu stoppen und weiterlaufen zu lassen, und interessante Zeilen kann man per Copy und Paste gleich weiterbenutzen.

Sorry, von wegen ernsthaft, aber diesen Hinweis auf die Wichtigkeit eines unverwechselbaren Designs kann ich mir nicht verkneifen: http://www.heise.de/ct/schlagseite/12/13/

Es hapert so ziemlich an allem Mathematik - bei Ebener Trigonometie kann ich noch gut mithalten, aber wenn ich die riesigen Klammern mit wirrem Zeugs in dem Wikipedia-Artikel über Eulersche Zahlen sehe... nee danke! Problematik - Worum geht es überhaupt? Wenn ich Koordinaten von einem System in ein anderes umrechnen will, brauche ich das alles doch gar nicht, oder? Theorie und Praxis - Der ganze Aufwand - dachte ich bisher - dient zur Vermeidung des Gimbal Locks. Das kommt, wenn bei einer dreidimensionalen Kardanaufhängung zwei Achsen die gleiche Richtung einnehmen. Interessiert mich nicht, weil ich nur eine zweidimensionale Kardanaufhängung habe, die sich maximal um 60° nach beiden Seiten verdrehen kann. Scheint aber dennoch irgendwie wichtig zu sein. Technik - für Hubschraubermodelle kann man einfache Gyroskope kaufen, die ermitteln den Yaw-Winkel und steuern den Heckrotor - ohne Magnetometer und höhere Mathematik. Nun dachte ich, wenn ich getOrientation() benutze, tue ich so, als ob in dem IMU-Brick drei solcher Gyroskope eingebaut wären, und den Rest ignoriere ich einfach. Grundlagen - Der IMU-Brick braucht also ein Magnetfeld wegen der Fehlerkompensation. Bei mir sind aber diese störenden Motoren. Braucht er gar nicht das Erdmagnetfeld, sondern einfach nur irgend ein beliebiges Magnetfeld? Dafür wäre ich dir unendlich dankbar. Aber bitte keinen Pseudocode ("addiere einen Vektor"), sondern fertige Formeln, bei denen man nur noch den Syntax der jeweiligen Programmiersprache anpassen muss.

Ich kapier das alles nicht. Ich habe Motoren mit störendem Magnetfeld, also ist es doch naheliegend, Convergence Speed auf Null zu setzen, weil ich den Magnetometer sowieso nicht nutzen kann. Und das mit den Winkeln ist so: wenn du schweres Gepäck in deinen Kofferraum tust, dann geht dein Auto vorn hoch, und dein Abblendlicht blendet alle Leute. Deshalb musst du es um einen Winkel x nach unten korrigieren. Dieser Winkel x ist immer der selbe, auch wenn du nach links oder nach rechts abbiegst. Dieser Winkel interessiert mich - unabhängig von der Fahrtrichtung. Und dann auch noch der Winkel quer dazu, also z.B. wenn der Fahrer 50 kg wiegt und der Beifahrer 150 kg, dann geht der Wagen rechts in die Federn, ebenfalls unabhängig von der Fahrtrichtung. Was ich wirklich am allerwenigsten brauche, ist ein Kompass. Das jetzt mal auf die Schnelle, ich werde heute abend weiter experimentieren. Jedenfalls vielen Dank für die Formel.

Es hat heute morgen bereits funktioniert, d.h. (es geht ja um meinen Kamera-Stabilisator) "roll" ausgeglichen, "pitch" hatte ich noch nicht programmiert. Ich glaube, ich habe die Ursache gefunden: ich hatte irgendwann mal Convergence Speed auf 0 gesetzt. In der Beschreibung steht etwas über Fehler, die dann nicht mehr ausgeglichen werden. Was mir noch auffällt: dass im Brickviewer ständig die X-Beschleunigung um die 60 mG pendelt. (Man könnte ja mal ausrechnen, wie lange es dauert, bis Lichtgeschwindigkeit erreicht ist...) Und noch was: die Werte von Roll, Pitch und Yaw hängen offensichtlich sehr eng miteinander zusammen. Wenn ich den IMU-Brick um 90° pitche and dann um 90° yawe, dann verändert sich auch der Roll-Winkel, obwohl ich eigentlich gar keine Rollbewegung ausgeführt habe. Gibt es irgend eine Möglichkeit, die Yaw-Bewegung zu ignorieren oder herauszurechnen? Sollte ich vielleicht besser mit den Werten von Angular Velocity rechnen?

Ich weiß nicht, was ich gemacht habe - Kabel abgezogen und wieder angeschlossen, mal den Brick Viewer und mal mein Programm benutzt - aber zur Zeit "rotiert" mein IMU-Brick. Das heißt, ich bewege ihn nicht, aber die Werte roll, pitch und yaw beschreiben Vollkreise, jeder mit seiner eigenen Geschwindigkeit. Roll ist am schnellsten, yaw am langsamsten. (Ich benutze den Orientation Callback wegen der nahe angebrachten Motoren, die das Magnetfeld stören.) Gibt es eine Erklärung dafür? Was soll ich tun?

Delegates? Nie gehört. Für mich sind das Ereignisse. Rapid-Q-Bindings müssen gar nicht sein, man bräuchte einfach nur eine DLL, die nicht so objektorientiert angesprochen werden muss wie die Tinkerforce.dll. Ich muss allerdings zugeben: auf Callbacks müsste man vermutlich verzichten.