borg

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!

Mh. Sowas ist im Moment nicht vorgesehen. Mir gefällt aber die Idee das einfach zu regeln in dem man min und max umdreht . Vielleicht baue ich das ein wenn ich mich um die Periodeneinstellung kümmere, die sollte mehr Werte erlauben.

Wir haben inoffiziell schonmal Version 1.1.0 des Brick Viewer hochgeladen: http://download.tinkerforge.com/tools/brickv/ Diese Version sollte es erlauben Bricklets sowie Bricks zu flashen und dies automatisch bei uns vom Server, ohne das die passende Firmware händisch heruntergeladen werden muss. Damit fällt jetzt SAM-BA als notwendiges "Drittanbieter-Tool" weg. Gefühlt hat das Atmel Tool viele Probleme gemacht und es gab auch keine Mac OS X Version. Desweiteren haben wir einige Sachen neu implementiert um Abhängigkeiten loszuwerden, so gibt es jetzt keine pylab, scipy und matplotlib Abhängigkeiten mehr für den brickv, was die Installation auf embedded Geräten und obskuren Linux Distributionen einfacher machen sollte! Dokumentation und sowas fehlt noch, kommt aber morgen hinterher. Wer lust hat kann es ja schonmal ausprobieren. Soweit wir wissen ist dies das erste Tool was existiert mit dem man die Atmel Cortex M3 Microcontroller unter Mac OS X flashen kann!

f-secure hat schon geantwortet: Muss ich jetzt die anderen Antivirenhersteller auch noch anschreiben? Vermutlich...

Öh, ich hab noch nichts an der IMU Dokumentation geändert, die ist schon ein paar Wochen so wie sie gerade ist . Ich kümmere mich heute Abend um die Formeln.

Wir haben unsere Build Maschine überprüfen lassen und wir können definitiv kein Virenbefall o.ä. feststellen . Ich hab mal f-secure eine "false positive" Meldung geschickt, mal schauen was die Antworten. Ich befürchte aber dass das Wochen dauert bis wir von denen etwas hören.

Mh. Also Fakt ist, dass in brickd kein "pwstealer" drin ist . Ich gehe davon aus dass das ein zufälliger Signaturmatch ist. Aber was tun wir nun dagegen?

Mh, ich nehme an dass die Anlage irgendwo in der Steckdose steckt? Wenn ja heißt das Buzzword nach dem du suchen musst "USV" (unterbrechungsfreie Stromversorgung). Also sowas hier: http://www.amazon.de/Bluewalker-PowerWalker-VFD-600-schwarz/dp/B000OXEPBS/ref=sr_1_21?s=computers&ie=UTF8&qid=1338762542&sr=1-21

@FabianB: Die Idee finde ich definitiv cool, kann ich mir auch viele Anwendungsfälle für vorstellen.

Ich kann den Wunsch nachvollziehen, bin aber absolut kein Fan von "schlechter security", was das wäre. Ich werde das morgen mal mit den anderen TFlern hier diskutieren, die können mich dann überstimmen . @Einstein: Das RN-171 Modul (welches unser Momentan aktueller Prototyp nutzt) kann leider kein Enterprise WPA-PSK

Oh, Fehler im brickv. Habs gefixt: https://github.com/Tinkerforge/brickv/commit/d1cd3827e169ba310ce04793d2ac8c7754351e4e Wird sowieso morgen eine neue brickv Version mit ein paar neuen Features geben, da ist der Fix dann drin!

Die gehen durch, es dürfte auch eine Schraube mit 2mm Gewinde durchgehen.

Einen Master Brick brauchst du nicht. Falls deine DMS einen Analog Wert ausgibt kannst du das Analog In Bricklet dafür nehmen, klar. Das Voltage Bricklet wurde durch das Analog In Bricklet ersetzt, es hatte eine geringere Auflösung. Ich hab das mal aus dem Shop genommen, hat da eigentlich nichts mehr drin zu suchen.

Ich hab mal ein Bild mit den Ausmaßen auf der Produktseite hinzugefügt: https://shop.tinkerforge.com/accessories/micro-switch.html Edit: Hab beim Schiebeschalter auch Maße hinzugefügt: https://shop.tinkerforge.com/accessories/slide-switch.html

Eine robustere Firmware ist definitiv geplant und wir sind auch schon Stück für Stück dabei den kram robuster zu machen. Um zu verhindern das Pakete die ausversehen an den brickd Port geschickt werden etwas zum abstürzen bringen, brauchen wir kein zusätzliches Passwort. Wenn es dir nicht um "safety" sondern um "security" geht, hilft kein Passwort was als Plaintext an das Paket angehängt wird. So ein Passwort würde Sicherheit vortäuschen aber keine bringen. Die WLAN Extension wird WPA2 können, das bringt Sicherheit. Wenn du über das Internet etwas steuern möchtest und den Port nach außen frei gibst, gibt es Möglichkeiten wie VPNs oder SSH Tunnel. Um das nochmal klar zu machen: Wenn wir an unsere Produkte schreiben das sie "mit Passwort kommen" und Zugriffe von dritten verhindern etc. müssen sie auch echten Angriffen statthalten können. Um das wirklich sicherzustellen müsste man schon eines der bekannten Verschlüsselungsverfahren verwenden (AES, Blowfish etc). Da fehlt uns dann aber wiederum die Expertise um das richtig zu tun (guckt euch einfach an wie oft auch jetzt noch Fehler in openSSL gefunden werden). Also: Wenn es nicht um "safety" sondern um "security" geht, bitte sowas wie WPA, SSH oder VPN verwenden! Möglichkeiten eine TCP/IP Verbindung sicher zu machen existieren wie Sand am Meer.