borg

Habs mir mal auf die TODO Liste geschrieben mir das genauer anzugucken.

Edit: Ich hatte Blödsinn geschrieben . Das scheint nicht kompatibel zu RFID zu sein.

Das ist echt komisch. Distance IR und Rotary Poti sollten z.B. elektrisch absolut identisch sein für den Brick. Da weiß ich jetzt auch nicht mehr woran das liegen könnte, wenn du die Bricklet Ports brauchst kann ich dir anbieten das wir den IMU Brick austauschen.

Cool! Ist das generiert oder per Hand geschrieben? Hast du was dagegen das wir einen Generator darauf basierend schreiben und die Bindings offiziell aufnehmen?

Der Viewer konfiguriert auf Input wenn du ihn anmachst. Du sagst ja das es funktioniert wenn du den Viewer anmachst. Das lässt mich vermuten dass bisher immer der Viewer auf Input konfiguriert hat .

Ist denn der Port auf input Konfiguriert? Also set_port_configuration('a', 0xFF, 'i', true)

Mh. Geht denn irgendein Bricklet an der IMU oder funktionieren Bricklets einfach gar nicht mit der IMU?

Wir hatten schonmal ein Captcha drin. Der Captcha von der Forensoftware die wir nutzen scheint allerdings nicht besonders gut zu sein, hat nämlich nichts gebracht . Dann haben wir einfach eine simple zu beantwortende Frage reingestellt (X+Y = Z), was für eine ganze weile ruhe gesorgt hat. Allerdings scheinen die Bots jetzt auch da hintergekommen zu sein. Mal schauen was wir als nächstes machen.

That sounds like a good idea indeed. The big question is: What functions on which Bricks/Bricklets would need such a timer. Having a timer (and reset) for every available function would totally blow up the API.

@FabianB: Eigentlich sollte das in der Tat gehen. Welche Version haben denn deine Java Bindings?

@ROSEDOLA: Oh, das sehe ich ja jetzt erst, dein Ruby Code tut ja schon genau das gleiche . Aber deine Formeln für x,y,z angle entsprechen irgendwie nicht denen die ich hab: x_angle = int(math.atan2(2.0*(y*z - w*x), 1.0 - 2.0*(x*x + y*y))*180/math.pi) y_angle = int(math.atan2(2.0*(x*z + w*y), 1.0 - 2.0*(x*x + y*y))*180/math.pi) z_angle = int(math.atan2(2.0*(x*y + w*z), 1.0 - 2.0*(x*x + z*z))*180/math.pi)

@Plenz: Das neue Beispielprogramm tut was du möchtest, ziemlich sicher. Edit: @ROSEDOLA: Für dich könnte das neue Beispiel auch interessant sein: http://www.tinkerforge.com/doc/Hardware/Bricks/IMU_Brick.html#how-to-get-angles-that-are-independent zumindest die Berechnung von z_angle

Habs gerade nochmal getestet, bei mir funktionierts. D.h. der Callback kommt genau einmal? Funktionieren Callbacks denn im Allgemeinen bei dir? Wenn du das Beispiel mal soweit verkleinerst das nur noch die Callbackperiode und der Callback gesetzt wird, gehts dann? Geht das Beispiel aus der Doku: http://www.tinkerforge.com/doc/Software/Bricks/IMU_Brick_Python.html#imu-brick-python-examples?

Also du hast einmal das Koordinatensystem was die Quaternionen standardmäßig ausgeben. Die "Nullstellung" kannst du einfach suchen indem du dir die Quaternionen ausgeben lässt und guckst wo 0, 0, 0 rauskommt. Das IMU Brick "aufm Kopf" halten und USB Stecker 45° von Norden nach rechts, so ungefähr. Dieses Koordinatensystem ist aber nicht wichtig, da muss man nicht drin rechnen. Das "Weltkoordinatensystem" hab ich jetzt in dem Beispiel "base system" genannt. Dazu speicherst du einfach die Quaternionen an der Stelle wo du die 0, 0, 0 Position haben willst und multiplizierst die dann immer mit dem konjugierten der Quaternionen die du bekommst. Wo für dich unten/oben ist und auch wo die Himmelsrichtungen sind ist ja abhängig davon wie du die IMU einbaust! Aber wie gesagt, die Umrechnung dafür ist nur eine Quaternionen Multiplikation. Wie man dann zu unabhängigen Winkeln kommt ist auch in dem Beispiel drin. Echte Eulerwinkel (die man nacheinander Anwenden kann um zurück zum Nullpunkt zu kommen) gibt es mit der getOrientation Funktion. IMO sollten damit jetzt schon die meiste notwendige Mathematik abgedeckt sein . Edit: Eins noch: Wie man von Quaternionen zu Rotationsmatrizen kommt (z.B. zur Darstellung in Opengl/DirectX oder zur Berechnung von Gimbal Lock freien Winkel ohne Quaternionen) ist in der API Dokumentation zu den jeweiligen Sprachen beschrieben!

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. UID angepasst?

So, nächster Versuch . In dem neuen Beispiel sollte alles untergebracht sein was hier gefragt war: http://www.tinkerforge.com/doc/Hardware/Bricks/IMU_Brick.html#how-to-get-angles-that-are-independent Erst wird eine Bezugsposition festgelegt, diese Position legt fest wo 0 Grad für alle Winkel sind. Danach sollten die Winkel für x, y und z berechnet werden. Gimbal Locks sind bei +90 und -90° bei allen Achsen, in etwa einem 15° Radius um den Gimbal Lock fangen die Werte an ungenau zu werden und beim Überspringen können Achsen um 180° springen (das ist korrektes verhalten). Wenn das nicht ausreicht oder das zu ungenau ist für eure Anwendung müssen entweder Rotationsmatrizen oder direkt die Quaternionen benutzt werden, da geht kein weg dran vorbei. Hab heute den halben Tag rumprobiert, eine bessere Darstellung kriege ich mit Eulerwinkel nicht hin !

@Loetkolben: Hast du irgendeine Vorgehensweise mit der wir das Aufhängen von Master Brick/Brickd reproduzieren können?

@ThomasKI: Damit stellst du aber nur 2 Achsen dar oder? Also wenn ich den IMU Brick jetzt vor mir halte und um die Y Achse drehe verändert sich die Position des USB Steckers ja nicht! Wenn ich jetzt her gehe und zusätzlich zum Vektor (x,y,z) des USB Steckers auch noch eine Drehung angebe um diesen Vektor, dann habe ich Quaternionen!!!! Edit: Vielleicht sollte ich das mit USB Stecker als Bezungspunkt trotzdem mal durchrechnen und dann so bezeichnen, also Position des USB Steckers in eine Würfel mit Ausmaß 1 und Drehung um diesen Vektor. Dann hab ich immernoch eine Darstellung die ich 1:1 wieder zu dem Quaternion umrechnen kann und zurück, aber vielleicht ists einfacher zu benutzen? Das gucke ich mir morgen mal an, kann eigentlich gar nicht schwer sein, ich tue das im Brick Viewer ja quasi schon.

@ROSEDOLA: Ah, das hatte ich nicht genau gelesen. Die Formeln beziehen sich schon auf das Original System. Wenn du alles komplett mit Quaternionen rechnen möchtest (wie ich das z.B. im brickv mache), kannst du so vorgehen. Du könntest jetzt aus dem resultierenden Quaternion einen Vektor (x, y, z) und einen Drehung um diesen Vektor ausrechnen und z.B. diese Drehung ausführen um zurück zu deinem Nullpunkt zu kommen. @Alle: Um das nochmal klarzustellen, die einzelnen Winkel sind nunmal voneinander abhängig, ich werde den Text in der Dokumentation nochmal überarbeiten diesbezüglich, da suggeriere ich im Moment anderes befürchte ich. Nur damit euch klar ist wovon ich rede: Nehmt doch mal die IMU und dreht um die X Achse 45°, dann um die Y Achse 45° und dann zurück um die X Achse 45° und dann zurück um die Y Achse 45°. Nach diesen drehungen hat sich die Z Achse um ein paar Grad verschoben, obwohl ich nie um die Z Achse gedreht hab! Dagegen kann man nichts machen . Sagt mir doch mal bzgl. welchen Koordinatensystems ihr welche Winkel haben wollt, dann versuche ich dafür Formeln aufzustellen. Nochmal anders: Wenn ihr euch im Brick Viewer die Orientation (roll, pitch, yaw) anguckt und aufschreibt und dann in der richtigen Reihenfolge zurückdreht (erst roll, dann yaw, dann pitch), dann kommt ihr wieder zurück zum 0 punkt (also roll, pitch, yaw = 0, 0, 0). Egal welche noch so interessanten Winkel während der Drehung angezeigt werden .

@ROSEDOLA: x_angle, y_angle, z_angle Formeln sind schon direkt für die x, y, z, w die aus getQuaternion kommen! Das ist schon komplett umgestellt und vereinfacht.

Du meinst bei den Euler Winkeln? Dort ist das zu erwarten! Es geht dabei immer um die Lage im Raum, nicht um eine einzelne Achse. D.h. wenn du die 3 Winkel vom Startpunkt in der richtigen Reihenfolge drehst kommt am Ende die Lage des Bricks dabei raus. Dabei bleibt es nicht aus dass sich alle Winkel ändern wenn du nur um einen drehst. Ich hab hier nochmal was dazu geschrieben: http://www.tinkerforge.com/doc/Hardware/Bricks/IMU_Brick.html#quaternions-vs-euler-angles Hehe, das ist bei Quaternionen so, es gibt mehr als eine Darstellung für die gleiche Lage .

Naja, der Grund war einfach eine schlanke API haben zu wollen. Rein technisch könnte es zwei Probleme geben: Nicht genug Flash und zuviel Aufwand die ganzen Callback-Zustände zu checken (ist aber beides beim Servo Brick nicht der Fall, denke ich). Wenn dafür bedarf besteht kann ich solche Callbacks hinzufügen.

zu 2) Ich zitiere einfach mal vom Blog:

Wenn du es richtig kalibrieren willst musst du schon die ganze Apparatur mit Motor drehen . Ich hab mal auf die Schnelle folgendes ausgerechnet: q = getQuaternion() v1 = Vector3d(0, 0, 1) v2 = q*v1 x_angle = atan2(v2.y, v2.z) x_angle = atan2(2*y*z - 2*x*w, w*w + z*z - x*x - y*y)*180/PI q = getQuaternion() v1 = Vector3d(0, 0, 1) v2 = q*v1 y_angle = atan2(v2.x, v2.z) y_angle = atan2(2*w*y + 2*x*z, w*w + z*z -x*x - y*y)*180/PI q = getQuaternion() v1 = Vector3d(0, 1, 0) v2 = q*v1 z_angle = atan2(v2.x, v2.y) z_angle = atan2(-w*y + x*y + y*x - w*w, w*w + y*y - z*y - x*x)*180/PI Dich interessieren diese beiden Zeilen: x_angle = atan2(2*y*z - 2*x*w, w*w + z*z - x*x - y*y)*180/PI y_angle = atan2(2*w*y + 2*x*z, w*w + z*z -x*x - y*y)*180/PI Evtl. noch ein +180 oder ein +360 % 360 hinten dran, je nachdem wo du den 0-Punkt haben willst. Dabei sind x,y,z und w die Quaternionen die du per Getter oder Callback bekommst. Ich hab vor dazu noch genau zu schreiben wie man das herleitet und warum das so ist, damit das einfacher zu verstehen ist. Muss aber morgen früh zum Zahnarzt, wird Zeit das ich ins Bett komme . PS: Hab das gerade auf einem Blatt Papier umgestellt und nicht getestet, also alles ohne Gewähr .

@Wumpus: War der Brick denn im Bootloader? @The_Real_Black: Da kann nichts kaputt gehen, der Bootloader ist fest auf den Bricks und kann nicht gelöscht werden!