borg

Wenn etwas defekt ist tauschen wir das natürlich aus. Es ist allerdings unwahrscheinlich das so viele Bricklets defekt sind, die Frage hier ist also woran es liegt. Hast du schonmal einen anderen Port am Master probiert?

Die Default Kalibrierung sollte definitiv funktionieren. Zurück zum Default kannst du im Notfall immer kommen indem du das Brick neu flasht. Der Analog zu Digital Wandler vom Master Brick sollte eigentlich keine Probleme machen. Was verstehst du denn unter "Diese zeigen immer den default"? Sie geben immer 0 zurück o.ä.? Welche Firmware Versionen zeigt der Brick Viewer denn an für die Bricklets? Der Master Brick sollte im ausgelieferten Zustand 1.1.1 und die Bricklets 1.1.0 haben.

Wenn du sagst "Werte erst nach Kalibrierung", was meinst du mit kalibrieren? Wenn du einen Brick anschließt und auf "Advanced Functions" klickst im Brick Viewer, was steht dann bei Gain und Offset? Das "Calibrate" da ist allgemein für den Analog zu Digital Wandler auf Bricks, nicht für einzelne Bricklets. Gain sollte in der nähe von 4095 sein und Offset in der nähe von 0. Um das zu kalibrieren kannst du deinen Rotary Poti anschließen, komplett nach links drehen, "Calibrate" klicken, dann komplett nach rechts drehen und wieder "Calibrate" klicken. Hier steht was dazu: http://www.tinkerforge.com/doc/Software/Brickv.html#brick-adc-calibration Da hatten schon mehrere Probleme mit, wir sollten das vermutlich direkt im Brick Viewer dokumentieren. Was meinst du mit "DC: Initialisiert Master"? Wenn du das DC Brick einfach per USB anschließt taucht es nicht auf im Brick Viewer? Wenn du einen Stack bauen willst muss der Master immer unten sitzen und du musst das DC Brick nicht zusätzlich per USB anschließen! Edit: Bzgl der UID beim rotary poti: Das ist komisch, scheint als hast du die Original UID beim updaten überschrieben? Ist aber nicht weiter schlimm, du kannst die UID da auf einen bel. Base58 String setzen, muss nur eindeutig sein in deinem System. Edit2: Ah, mit "DC" meinst du die Step-Down Powersupply? Wenn du den Stack über die Step-Down Powersupply betreibst und dann USB anschließt musst du einmal auf Reset drücken damit es neu initialisiert wird. Wenn du keine Treiber Bricks (Servo, Stepper, DC) oder Extensions verwendest ist die Step-Down Powersupply allerdings eigentlich nicht notwendig.

So, ich hab mal eine firmware gebaut wo Chibi Slave mit einem USB Netzteil funktionieren sollte: http://download.tinkerforge.com/firmwares/bricks/master/brick_master_firmware_1_1_2.bin Bitte sofort bescheid sagen falls es Probleme mit der Firmware gibt (vor allem wenn kein Chibi verwendet wird). Ich hab die USB Initialisierung im Code nach vorne verschoben damit der Startup nicht länger braucht. Da die USB Timings aber leider bei jeder Betriebssystemkonfiguration die es so gibt unterschiedlich sind ist sowas immer gefährlich. Falls es Probleme gibt kann ich den kram wieder zurück schieben und einfach die Startup Phase um eine Sekunde oder so verlängern.

You can flash the Bricklets on Linux and use them on windows, if you need them urgently . We have a macbook with dozens of Windows VMs that we use for testing and compiling of the binary, but i don't have that here currently and my colleague is busy. So i can't compile a new binary and test it at the moment. PS: We have a working version of the Brick Viewer for OS X and a nearly working version of the Brick Daemon for OS X (the USB hotplug doesn't work yet). So, we will probably make a first version of that available soon .

Öh, könntest du nicht sowas machen: public static void addTempListener(final String name, BrickletTemperature temp) { temp.addListener(new BrickletTemperature.TemperatureListener() { private final String temp_name = name; public void temperature(short temperature) { messwert m = new messwert(); m.setSensor(null); m.setTime(new Timestamp(System.currentTimeMillis())); m.setWert(temperature / 100.0f); queue.put(m); System.out.println("name: " + temp_name); System.out.println("Temperature: " + temperature/100.0 + " °C"); } }); } und dann aufrufen mit addTempListener("Sensor 1", temp1); addTempListener("Sensor 2", temp2); (ungetestet)

Holy Moly! We just tested your scenario on Windows (i tested on Linux before) and had similar problems. The problem is with the Brick Viewer version for Windows. On windows a read() in python ends as soon as it finds an EOF character, therefore you are only writing a part of the firmware. That should be fixable by just reading in binary mode, we will test that extensively now to be sure that everything works on Windows after the change. That bug was in the Brick Viewer since the very first version. Incredible that it didn't get noticed until now.

OK, first i compared md5sums of firmwares that are online with md5sums of firmwares from my pc that i used to flash the new Bricks and Bricklets: They are all the same. Then i flashed firmware 1.1.0 to a Distance IR 1.0 and firmware 1.1.1 to an Master Brick 1.0 and everything works as expected. You wrote that the piezzo buzzer now does work, did you do something different when you updated that (compared to the other Bricklets)?

Uh, that is confusing. First of all: The hardware version should be totally irrelevant, we only changed minor things in the placement, removed unused pads and added fiducials for the circuit board assembly process. The only thing where we changed something that is now incompatible is the Voltage Bricklet, but we called the successor Analog In Bricklet, so there can't be any confusion there. So it seems you have a different firmware on the Brick we send you then on your old Bricks, that you updated yourself. Does that mean the firmwares on http://download.tinkerforge.com/firmwares/ are broken and the ones i have locally here not? I will try that out. If you like you can try to flash the new Brick with the same firmware that you flashed on the old Bricks and see if that doesn't work either. I will come back when i tried the different firmware version with different hardware versions.

Yes, you can use the XL-Maxsonar EZ4 with the Analog In Bricklet. We have an eye on this sensor already, the problem is that it is quite expensive for us to make a Bricklet for this in big quantaties (you can see the price of the sensor). We kind of stretched our financial means with the newest production. However, we will very likely have a Bricklet for one of the Maxsonar thingies by at least June.

Uh, von der Hardware her geht das. Und es ist eine gute Idee um eine Platine zu sparen. Die Heuristik die das Master Brick benutzt um herauszufinden ob es Chibi im Slave oder Master Modus betreiben muss ist: "Bin ich per USB angeschlossen". D.h. mit der im Moment neuesten Master Firmware würde die Chibi Kommunikation nicht so laufen wie du dir das vorstellst. Allerdings macht die Idee soviel Sinn das ich mir das heute Abend mal angucke. Vielleicht kann ich sowas implementieren wie: "Betreibe Chibi im Master Modus wenn ich mit einem PC kommunizieren kann". Ich melde mich dann nochmal.

Die Step-Down Powersupply erzeugt die 5V und der Stepper bekommt die vollen 12V, ja.

Der Stepper Brick kann leider keine 5V für den Stack erstellen, da muss also noch eine Step-Down Powersupply her. Es sei denn du schließt den Master Brick per USB an den PC an, dann wird der Stack über USB mit Strom versorgt.

This probably means that the Bricklet firmware update somehow didn't work correctly and the Brick crashes when it tries to run the Bricklet plugin. You should try the follow: Connect the Brick to USB Wait until it is started Connect the Bricklet Start Brick Viewer and go to "Advanced Functions" Flash the Bricklet again Or with other words: You can connect a Bricklet after the Brick started if you want to update it. This is indeed needed if the Bricklets are fresh from production and the EEPROM is empty. If it still doesn't work, can you tell me what Bricklet and what Brick you are using? Perhaps i added some kind of bug and i can reproduce it here.

Schick mal eine Email an info@tinkerforge.com (mit deinem Accountnamen und Bestellnr.). Ich kann dir einen Gutschein über die Versandkosten machen und wir verschicken die beiden Bestellungen dann zusammen.

Das ist komisch, wenn sonst alles funktioniert ignoriere das Fehlerlog einfach.

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