borg

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.

Mh, der String sollte entweder genau 20 Zeichen lang sein oder ein \0 am Ende haben. Auffüllen ist mit der Momentan verwendeten Firmware auf den LCD Bricklets nicht notwendig, würde ich aber empfehlen. Vielleicht wird es mi der WIFI Extension notwendig werden das wir "Sanity Checks" einführen für TCP/IP Paketgrößen, die gibt es im Moment nicht. An der Stelle merkt man das wir nur eine Dokumentation für alle Sprachen und TCP/IP haben, bei den Sprachen übernehmen die Bindings das Auffüllen.

Du musst dich auf den Enumerate Callback registrieren und jedesmal wenn wenn ein Brick/Bricklet Deenumeriert und dann wieder Enumeriert wird die Verbindung zum Brick/Bricklet neu erstellen und auch die Konfigurationen die nicht auf dem Brick gespeichert werden neu machen!

Das IPhone/IPad braucht eine Verbindung mit dem Brick Daemon, richtig. Der kann auf einem PC sein, oder auch z.B. auf einem Router (im Prinzip überall wo Linux läuft). Mit dem WLAN Modul ist eine direkte Verbindung von IPhone zu Brick möglich, auch richtig .

Ich werde die Dokumentation am Montag erweitern um ein Paar Formeln zum Umrechnen für die wichtigsten Sachen. Was du vor hast ist auf jedenfall möglich, geht aber nicht gut über die Eulerwinkel (getOrientation). Solche Fragen werden jetzt wohl öfter kommen, wir haben ja einige IMUs verschickt. Ich vermute im Moment setzen wir ein bisschen zuviel Mathematik voraus! Bzgl. der Convergence Speed: Wenn du die auf 0 setzt und die Gyroskope auch nur einen absolut minimalen Fehler im Stillstand haben (was sie immer haben, das geht gar nicht anders) addiert sich dieser Fehler auf und die IMU dreht sich um die fehlerhafte Achse des Gyroskops.

Aha! Die 1.0er und 1.1er Versionen sind zueinander inkompatibel: http://de.blog.tinkerforge.com/2012/2/26/neue-firmwares Wenn du da nicht unbedingt am Wochenende dran rumbasteln willst kannst du bis Montag warten. Wir bringen Montag eine neue Brick Viewer Version raus die Bricks und Bricklets flashen kann und sich die Firmwares direkt bei uns vom Server holt! Damit sollte das dann alles in 2 Minuten geupdatet sein .

Hier hatte jemand ähnliche Probleme: http://www.tinkerunity.org/forum/index.php/topic,243.msg1101.html Vermutlich fehlt dem Brick bei dir auch der Treiber für den Bootloader.

Mh. Welche Firmware Versionen haben denn die Bricklets und die anderen Bricks?

"Im Bootloader" heißt das er in einem Modus ist in dem man in flashen kann. In diesem Modus kommst du wenn du den Erase Knopf drückst während der Master Brick startet und du kommst auch erst wieder raus wenn du ihn neu geflasht hast.

Als was wird der Master Brick denn erkannt? Kann es sein das er im Bootloader ist? Dann musst du ihn einfach neu flashen. Im Moment geht das flashen nur über SAM-BA: http://www.tinkerforge.com/doc/Software/Firmwares_And_Plugins.html#flash-firmware-on-a-brick wir arbeiten aber gerade dadran das flashen von Bricks auf dem Brick Viewer beizubringen, das werden wir sehr wahrscheinlich schon Montag veröffentlichen!

Ja, wenn du die Convergence Speed auf 0 setzt wird der Magnetometer nicht mehr verwendet! Da ist der Fehler den du hattest zu erwarten. Roll Pitch und Yaw sind Eulerwinkel, d.h. die haben eine feste Reihenfolge in der sie angewendet werden: http://de.wikipedia.org/wiki/Eulersche_Winkel Du kannst nicht einfach einen der Werte losgelöst von den anderen beiden betrachten. Man kann das allerdings in der Tat rausrechnen. Ich hab die Rechnung für yaw hier damals schon einmal getan: http://www.tinkerunity.org/forum/index.php/topic,162.msg549.html#msg549 Du multiplizierst einfach den Quaternion mit einem Vektor der auf die Y-Achse zeigt. Nach der Multiplikation kannst du den Winkel zwischen der X und Y-Komponente des resultierenden Quaternion ausrechenen (atan2) und schon hast du einen super Kompass gebaut. Da werden dann auch Drehungen um andere Achsen rausgerechnet, was nicht der Fall ist wenn du nur einen Magnetometer hast! Wenn man bedenkt wieviel Mathematik man normalerweise brauch um sowas aus Beschleunigungssensor/Magnetormeter Werten zu berechnen ist das richtig Cool . Pseudocode: q = getQuaternion() v1 = Vector3d(0, 1, 0) v2 = q*v1 angle = atan2(v2.x, v2.y)

@adrianbernhard: Wir unterstützen den KS0073 und den HD44780 LCD Controller. Bei deinem Link steht "ST7066U", da hab ich noch nie von gehört. Da müsste man erst Datenblätter vergleichen um zu gucken ob der Kompatibel ist!

Funktioniert es denn wenn du es einfach einzeln per USB anschließt (ohne die Motoren in der nähe zu haben,wie M4ST3R schon sagt) und es dir am Brick Viewer anguckst?

Das LCD selber kaufen wir zu. da gibt es so Standardgrößen, die können wir nicht beeinflussen. Solche LCDs gibt es ja z.B. auch bei Reichelt: http://www.reichelt.de/Hintergrund-blau/LCD-204B-BL/3/index.html?;ACTION=3;LA=2;ARTICLE=53952;GROUPID=3006;artnr=LCD+204B+BL;SID=10T3tYQH8AAAIAAEB3MR8e821ed4e6254421970b9fd7baa3c1280 Das könntest du ohne Probleme mit unserem austauschen obwohl es von einer anderen Firma ist.

Huch. Fangen wir mal mit dem ersten Problem an: Wenn du den Joystick an die IMU ansteckst und dann die IMU einfach per USB, macht das schon Probleme? Wenn ja, machen andere analoge Bricklets auch Probleme (z.B. Ambient Light)? Bzgl. des Servo Bricks: Wenn du den Joystick wegnimmst geht der Servo? Edit: Wenn du eine Step-Down Power Supply da hast, kannst du mal Probieren den Stack damit zu versorgen? Vielleicht gibt der USB Port den du benutzt nicht genug Strom.

Die IMU sollte mit 9mm Abstandshaltern kommen, genauso wie der Master. Damit sollte das eigentlich passen.

arm-none-eabi ist genau richtig!

So, ich hab mal eine kleine Timeline in die Dokumentation gepackt: http://www.tinkerforge.com/doc/Timeline.html Die Idee ist das wir dort oft etwas ändern, Sachen verschieben wenn wir Lieferzeitpunkte haben, Features austauschen wenn wir Probleme mit Prototypen haben etc. D.h. die Timeline beinhaltet keine festen Termine auf die man sich verlassen sollte, sondern gibt einen Überblick über die grobe Planung die wir haben und ist ständig im Fluss!

Wenn ich aus dem mittleren && ein || mache bekommst du aber die in den Ecken zusätzlich! Edit: Wo ich AuronX recht gebe: Wenn wir 'i' so festhalten wie es ist, sollte das 'o' eigentlich "not 'i'" sein und damit so wie AuronX sagt. Das bezieht sich nur auf den Joystick, da wir sonst nirgends diese Threshold-Geschichte für zwei Werte haben, d.h. das kann ich gerade ändern. Edit: Ich hab aus dem mittleren && erstmal ein || gemacht, einfach weil es logischer so ist (1.1.3): http://download.tinkerforge.com/firmwares/bricklets/joystick/

Ich bin absolut verwirrt Also die Stelle in der Firmware sieht folgendermaßen aus: if(((BC->threshold_option[i] == 'o') && ((value1 < BC->threshold_min1[i]) || (value1 > BC->threshold_max1[i])) && ((value2 < BC->threshold_min2[i]) || (value2 > BC->threshold_max2[i]))) || ((BC->threshold_option[i] == 'i') && ((value1 > BC->threshold_min1[i]) && (value1 < BC->threshold_max1[i])) && ((value2 > BC->threshold_min2[i]) && (value2 < BC->threshold_max2[i])))) { Du möchtest das der callback auch getriggert wird wenn nur der threshold nur für X oder Y eingehalten wird? Kannst du mal ein Paar Beispielwerte geben die Callbacks verursachen sollen, es aber nicht tun (oder umgekehrt)?

Oh. Der Link den es hier gibt hat mal direkt zur Download Seite geführt: http://www.tinkerforge.com/doc/Software/Firmwares_And_Plugins.html#build-a-brick-firmware Aber sieht so aus als müsste man sich da neuerdings erst einen Account machen . Geht folgender Link bei dir: https://sourcery.mentor.com/GNUToolchain/release2032 ? Oder geht der bei mir nur weil ich einen Account hab? Edit: Und bzgl. der 400€: Der CodeSourcery GCC und alle Tools drum herum sind GPL und müssen entsprechend immer Open Source und kostenlos bleiben! Was du bei CodeSourcery kaufen kannst ist eine GUI dafür, im Prinzip. Es gibt Leute die die CodeSourcery Toolchain mit Visual Studio nutzen: http://www.tinkerforge.com/doc/Software/Firmwares_And_Plugins.html#build-a-brick-firmware Ich weiß aber nicht wieviel Gefummel das ist. Ich benutze hier unter Linux Eclipse + CDT + Eclim (CDT für C Unterstützung und Eclim erlaubt mir Vim Tastenkombinationen zu nutzen in Eclipse).

Kann Objective C irgendwie feststellen dass der Callback aus einem anderen Thread heraus aufgerufen wird? Z.b. in Qt sind GUI Elemente nicht thread-safe und eine Änderung aus einem Callback heraus könnte sogar zu einem Segfault führen. Allerdings kann das in dem Fall der Compiler natürlich nicht erkennen!