borg

Die stehen auf "ausverkauft" weil sie noch nicht da sind. Wir rechnen im Moment damit das wir die neuen Bricklets ab dem 9 März haben (dann machen wir auch Fotos usw, die fehlen ja auch noch).

Cool! Ich nehme an du packst die Bricks und Bricklets in irgendein Gehäuse? Wie sieht das aus? Wir möchten auf dauer auch gerne Gehäuse und Halterungen und sowas anbieten, wir sind uns aber noch nicht ganz einig wie die aussehen müssten. Auf den Bildern auf deiner Homepage sieht es so aus als würdest du Platinen auf Holzbretter in einem (vermutlich wasserdichten) Gehäuse anschrauben. Das könntest du mit unseren Platinen ja so machen wie sie sind, einfach mit den Löchern in den Ecken. Würden dir irgendwelche zusätzlichen Halterungen oder Gehäuse helfen?

We found a lenovo netbook that has the same problem. So we are able to reproduce it now. However, i couldn't figure out what the problem is yet. Well, that is what quaternion multiplications are for: http://www.cprogramming.com/tutorial/3d/quaternions.html In the Brick Viewer, when you press "Save Orientation" i do: self.rel_x = x self.rel_y = y self.rel_z = z self.rel_w = w and whenever i get new quaternion values i do: # conjugate x = -x y = -y z = -z # multiply wn = w * self.rel_w - x * self.rel_x - y * self.rel_y - z * self.rel_z xn = w * self.rel_x + x * self.rel_w + y * self.rel_z - z * self.rel_y yn = w * self.rel_y - x * self.rel_z + y * self.rel_w + z * self.rel_x zn = w * self.rel_z + x * self.rel_y - y * self.rel_x + z * self.rel_w And i work with wn, xn, yn and zn from there on. I suppose you could do the same. On startup you should set the convergence to a high value (like 250) for 2 seconds or so, then the IMU has its position. On a robot you should then be able to go down to something like 5, since you aren't making huge accelerations. Then you should get the current quaternions and save them. And then you are ready to go . We don't have a "save orientation" function in the Brick API itself, since that would need 16 additional floating point multiplications per ms. I would have a hard time to squeeze them in. The microcontroller on the IMU Brick is practically running at its limit. On the PC side the multiplications don't matter at all, even if you use something like a Beagle Board or Raspberry PI.

Hi, me again I couldn't resist, i had to try that. To multiply a quaternion (q) with a 3d vector (v) you have to represent the vector as a quaternion with w=0 (v') and calculate: q*v'*q^-1 (where q^-1 is the conjugate of the quaternion) after that you can calculate the angle with atan2. If you insert (0,1,0,0) for v' and you simplify everything possible you get: int yaw_angle = atan2(-w*y + x*y + y*x - w*w, w*w + y*y - z*y - x*x)*180/PI where x, y, z and w are the quaternion values from the imu. Really neat if you ask me. And there is of course no gimbal lock! edit: I uploaded version 1.0.1 of the IMU firmware with the improved code for direction calculation for the direction leds (implemented as described above).

I thougt a bit about what you wanted to do (discover the direction your robot is facing), i think the "correct" way to do it is as follows: Multiply the quaterions with a vector facing in the y axis, take the x and y component from the result and calculate the angle for the vector. The resulting angle will be exactly what you want. Pseudocode: q = getQuaternion() v1 = Vector3d(0, 1, 0) v2 = q*v1 angle = atan2(v2.x, v2.y) The funny thing is that i could have used that on the IMU Brick to calculate the LED blinking for the direction leds (instead i used the magnetometer values directly). This would have been much better, since it also works if the IMU is not laying plane on the x and y axis. I will change that in the next firmware version.

Im englischen Forum hat jemand ähnliche Probleme, liegt also höchstwahrscheinlich nicht an dir. Ich kann das Problem hier noch nicht reproduzieren. Das Log gibt allerdings einen Anhaltspunkt. Ich gucke es mir an.

We ordered one, not sure if we actually will get one now or if they sold out before we ordered. But we will definitely try to get brickd working on it, the Raspberry Pi is an obvious choice to control Bricks with :-).

I will look into that tomorrow, what happens if you press "Save Orientation"? Edit: I just tried it on Windows 7, unfortunately it worked like expected. Is there some kind of error or something comparable? I am not sure what to do about your problem, i will test all of the windows versions we have in our test VM, perhaps one of them can reproduce this problem. Edit2: Nope, can't reproduce it. The IMU is drawn with OpenGL, could this be the problem? Do you have graphics card drivers installed? Yes. That is the problem with Euler angles. First of all, you are hitting a gimbal lock, that is why you can't reach 90 degree. See here: http://en.wikipedia.org/wiki/Gimbal_lock Second, when you say it goes back to zero (from -90, when it should go to -180), i am sure the roll changes from 180 or -180 to 0 and the pitch changes from 0 to 180 or -180, which means the yaw is correct! Test this: Search for the 0, 0, 0 position with the IMU Brick and the Brick Viewer, memorize the position. Then go to some other position you think the values are incorrect for, there write down the roll, pitch and yaw. Then go to the memorized position and then turn the Brick successively in the roll, pitch and yaw direction by the degrees you wrote down (in that order! Euler angles are not commutative). You will find that you can reach every position as expected, as long as you don't hit a gimbal lock. This gimbal lock concept is not easy to grasp, but there is mathematically no way around it if you use euler angles. Every IMU that gives out euler angles will have this problem. I can only recommend that you try to use quaternions and rotation matrices (which are not easy to understand either), there is no gimbal lock with those. I would try to get the values with a high frequency, with a callback (set the period to 2ms) and average over 50 or 100 values. This way the values will be a lot more stable.

Du brauchst dafür ein SMA Verlängerungskabel, wir benutzen Standard SMA Stecker. Das erste was mir google rausgeschmissen hat ist das hier: http://www.ebay.de/itm/LTE-Kabelverlaengerung-10m-SMA-SMA-RG58-800MHz-/330610690943#ht_894wt_1165 Das sollte eigentlich erheblich günstiger gehen, 10m ist ja auch ein bisschen viel. Wichtig ist das du kein RP-SMA oder Reverse SMA oder manchmal auch WLAN SMA genanntes Verlängerungskabel kaufst, das ist _nicht_ kompatibel! Edit: Hab ein kleineres günstigeres gefunden: http://www.expansys.de/globalsat-sma-male-zu-female-verlangerungskabel-156668/ das sieht auch passend aus

I wrote something in our blog about the range measurement: http://en.blog.tinkerforge.com/2012/2/29/chibi-extension

You should be able to order them now. We are currently extending the descriptions for the Chibi Extension and the Antenna, but you can already order them. We also intend to measure the maximum distance between two Chibi stacks today. It will be interesting to see what we can achieve and if it is near the manufacturer specification of 2km.

Auf den Bricklet Ports liegt 5V, 3.3V, gnd, I2C und 4 Allgemeine IO Pinne. Dafür können wir so ohne weiteres kein Hub machen (über die 4 Allgemeinen Pinne werden z.B. auch direkt analog Werte gemessen). Was mir sonst noch einfällt wäre eine Art "Bricklet Master", der USB aber keine Stack Stecker hat, größer als 4x4cm ist und dann auch ein Dutzend oder mehr Bricklet Stecker haben könnte. Würde dann preislich wieder ungefähr soviel kosten wie der Master, hat aber halt keine Funktionalität für Extensions oder Stacks.

Es ist alles andere als ungeduldig die Frage zu stellen, wir sind selber mehr als unzufrieden mit den Wartezeiten. Leider wurden uns Liefertermine immer und immer wieder verschoben, falls alles so geklappt hätte wie wir uns das erhofft hatten, wäre Mitte Februar ein konservativer Termin gewesen. Die gute Nachricht ist, dass die Produktion jetzt anläuft und wir nun definitiv voran kommen. Es fehlen keine Bauteile mehr und die Leiterplatten sind auch da! Bezüglich der Angaben im Shop: Wir stehen da vor dem Dilemma das wir nicht ständig die Termine verschieben wollen, wir hatten uns eigentlich vorgenommen die nächste Terminangabe auf ein verbindliches Datum zu legen. Vielleicht sollte ich es aber lieber erstmal gegen ein "available again soon" austauschen und sobald wir einen festen Termin haben diesen groß über den Shop schreiben.

Mh, the Stack has all together 80 pins. So we would need a board-to-cable connector that has 80 ports and fits on a 4x4cm board. Then we would need a cable with 80 wires between the two stacks. To me that sounds awfully expensive too. However, if someone knows about connectors and cables that would fit this requirement we would be interested to hear about it!

Naja, da die Bricks in einem Stack ja immer 4x4cm groß seien müssen und auf zwei Seiten die Platine-zu-Platine Stecker sind und auf der anderen Seite die Knöpfe und der USB Stecker, sind die 4 Bricklet Ports eines Masters schon das Maximum. Edit: Was mir dazu noch einfällt: Man könnte ein Brick machen was nur im Stack benutzt werden kann und keine Taster und USB Stecker hat, dann könnte man 8 Bricklet Ports drauf bekommen. Das würde dann preislich allerdings genausoviel wie der Master kosten, keine Ahnung ob es für sowas genug Nachfrage geben würde.

If you have a stack powered over the power supply brick and you have USB plugged into the master at the same time, the stack will use the supply with the highest voltage (which will probably always be the power supply brick). With other words: There is no problem doing that, you don't have to cut the power wire of the USB cable.

Ich sitze gerade an der Implementierung für die RS485 Extension und mir ist gerade aufgefallen das ich gelogen hab als ich gesagt hab die RS485 Extension spricht full duplex. Wir haben alle Pinne die für full duplex benötigt werden würden im Stack liegen, allerdings spricht der RS485 transceiver den wir benutzen nur half duplex (es gehen ja auch nur 3 Kabel raus). Da hatte ich damals nicht richtig drüber nachgedacht.

Das ist wirklich seltsam, wir haben den Brick Viewer eigentlich auf neuinstallierten Windowsen getestet. Mal schauen ob wir das Problem reproduzieren können, sollte aber einfach fixbar sein.

Den Fehler hatten wir noch nicht und ihn hat auch bisher noch keiner berichtet. Kannst du mal versuchen entweder dies (32 bit) oder dies (64 bit) zu installieren? Es wird ein Fehlerlog im Installationsverzeichnis angelegt. Allerdings sieht mir das so aus als würde es schon zu einem Fehler kommen bevor unser eigentliches Programm gestartet wird.

Wir werden dort das gleiche Protokoll sprechen was wir auch im SPI Bus und über Chibi sprechen. Dies ist aber ein einfaches Protokoll und kann auch direkt gesprochen werden, das müssten wir dann nur dokumentieren. Im großen und ganzen wird immer [stack ID, Funktions-Nummer, Länge, Nutzdaten, CRC] übertragen.

RS485 kommt direkt nach der Chibi Extension und dem IMU Brick. Der Bus ist full duplex. Da die Infrastruktur für die Extensions jetzt steht hab ich Hoffnung das ich da schneller voran komme.

Interesting. Can you try to install python-ctypes? opkg install python-ctypes

you need python-twisted for the Brick Daemon, this is independent from the programming language you want to use. You can install the Brick Daemon from source (here is a lik to the zip: https://github.com/Tinkerforge/brickd/zipball/master) Just unzip it somewhere on your beaglebone, go to brickd/src/brickd and start with "python brickd_linux.py nodaemon" as root. As i mentioned before, you can also enable debug output if you install it from source and give me more information this way.

So, ich hab mal einen kleinen Aufsatz im Wiki verfasst. Ich hoffe das ist nicht zu grob und du kannst damit was anfangen. Du wirst allerdings definitiv nicht drum rumkommen dich in die vorhandenen Bindings einzulesen um eine Idee darüber zu bekommen wie diese funktionieren. Ich würde erstmal die Autogenerierung außen vor lassen und überhaupt erstmal eine Socket Verbindung mit Delphi zum brickd aufbauen und versuchen ein Paar Nachrichten auszutauschen. edit: Hab den Link zum Wiki vergessen: http://www.tinkerunity.org/wiki/index.php/BindingsErstellen

Oh, hab deine Antwort übersehen, entschuldige. Ich setze heute Abend mal ein Tutorial darüber auf, melde mich dann.