borg

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!

Dafür gibt es im Moment keine Möglichkeit. Gibt es Sensoren die PH Werte auslesen und Analogwerte ausgeben? Dafür könntest du dann das Analog In Bricklet nehmen!

Es sollten gestern Abend eine ganze Menge Versandemails rausgegangen sein . Das Video lade ich gerade hoch, dauert ein wenig. Edit: Video ist da:

Oh ja, da sollten wir etwas zu schreiben. Bei der IO4 nutzen wir ja direkt Pinne vom Microcontroller, das Datenblatt sagt dazu: Das bezieht sich jetzt auf _alle_ 100 Pinne vom Microcontroller. D.h. grob gesagt: Es steht sehr wenig Strom zur Verfügung . Ist jetzt nicht ganz einfach da einen konkreten Wert anzugeben, ist ja schließlich auch abhängig davon wieviele Bricklets angeschlossen sind etc.

We can't do this in general because the WIFI Extension won't be able to do this efficiently (utilizing two sockets). It would be possible to make this behavior configurable for brickd, i suppose.

Der Name Stack ID ist nicht besonders gut gewählt. Die Stack ID beschreibt eine eindeutige 8bit Zahl mit der man nachdem das System intern enummeriert wurde Bricks und Bricklets ansprechen kann (siehe TCP/IP-Protokoll Beschreibung). Ein besserer Name wäre vermutlich "System ID" oder "System Participant ID"

# Ist die StackID. Es ist nur über die UID möglich herauszufinden um welches Bricklet es sich handelt.

Für hotplug fehlt dir python-gudev. Ich kann auf die schnelle kein Arch Linux Paket dafür finden, vielleicht kriegst du es aus dem Source zum laufen: https://github.com/nzjrs/python-gudev

@Nitram: Diese WLAN Module mit integriertem IP Stack sind ja eigentlich gerade für industrielle zwecke gedacht: und gerade in diesem Umfeld (Maschinen über Ethernet steuern etc) ist IPv6 leider so gut wie gar nicht verbreitet. Deswegen gibt es da auch noch keine Unterstützung. Dazu sollte man auch noch anmerken dass der Hersteller des Moduls (Roving Networks) dem RN-171 jederzeit IPv6 per Softwareupdate beibringen kann. Der IP Stack auf dem Modul ist ja ganz normal in Software auf einem ARM7 implementiert und Updates dafür gibt es alle paar Wochen. Bevor IPv4 anfängt nicht mehr nutzbar zu sein weil alle umgestiegen sind gibt es da sicherlich ein Firmware Update .

Es sollte an der Stelle eine Tinkerforge.TimeoutException geworfen werden. Wenn die da nicht kommt ist das definitiv ein Bug! Gucken ich mir morgen mal an!

Das ist die StackID, ja. Und ich gebe dir recht, sollte vermutlich auch so heißen . Wir fummeln sowieso gerade am Brick Viewer rum, ich ändere das entsprechend.

Hab ich mir kurz angeguckt, das ist möglich, ist aber nicht so einfach. Einige Servo Pinne werden per PWM Hardwareeinheit und einige per Timer Counter Hardwareeinheit gesteuert (der Mikroprozessor hat keine 7 PWM Pinne). Wenn ich das richtig sehe ist der kleinste gemeinsame Nenner bzgl der Periode von TC und PWM ein Minimum von 125us als Periode. Ich hab als ich das programmiert hatte nicht damit gerechnet das jemand eine Periode von weniger als 2ms braucht (das wäre für Servos sehr ungewöhnlich). Ich nehme an du willst das PWM für etwas anderes nutzen? Hab ich auch schnell getestet, 100% Duty Cycle funktioniert.

naja, die Schleife bleibt solange stehen bis du oben bei callbacks das set() aufrufst, das ist ja Sinn der Sache .