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?

So I checked out the brick viewer on my windows 7 PC and also on windows 7 via VMWare virtual machine on my mac. On the PC the opengl version was 4.2.  I updated the Nvidia driver to the latest 295.73 but it made no difference (and didn't update the opengl version).  If I press save orientation it makes no difference.  The image very occasionally appears for a fraction of a second.

 

On the virtual machine version of windows 7 it's running opengl 2.1 and it's working perfectly on that.

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.

While you're in a great problem solving frame of mind can you think of an easy way to do the save orientation (just on yaw) in python?  I'd like the orientation to be set when I turn on the robot as the zero point.  I can do it by basically using the get orientation and subtracting or adding it from the  current reading to zero.  I wondered whether there was a more system based way to do it so it thinks it's now calibrated to the new yaw position correctly?  But don't see a function that does this specifically.

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 :-).

1. I've downloaded the latest brick viewer but when connected to the IMU the image of it appears for a fraction of a second and then vanishes.  The background is just black most of the time.  Occasionally it flickers back for a micro-second.  I'm using Windows 7  - any suggestions?

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?

2. I'm most interested in the yaw value at present (robotics purpose) but not getting expected results. The results are as follows:

 

a - yaw ranges from 0 - 85 or 86 not 0 - 90 as expected.

b - I thought it might give me 0 - 360 degrees but if align to the zero position and then spin it anti-clockwise it goes from the zero up to 85 (at -90degrees) and then back to 0 at 180 degrees and then to -85 at -270 degrees and then back down to zero at the starting position.

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.

3. If I keep it perfectly still the yaw value will vary by 1-2 degree at times.  I've tried playing with the convergence values and it's not improved the situation - temperature is pretty stable.  I haven't tried calibrating as yet but I'd have thought that as it's stationery then the values would be a lot more stable.

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!

Wie wärs mit einem Bricklet-Hub Brick der einen Stack um einige Bricklet Ports erweitert?

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.

I'm thinking of doing the same thing if I can lay my hands on a raspberry and some bricks, but... If you connect the raspberry to a master brick via usb wouldn't you be powering the stack directly from the power supply as well as indirectly from the power supply to the raspberry to the master brick. Wouldn't that cause problems?

 

Would a possible solution be to disconnect the power wire from the usb cable?

 

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.