borg

Ein beheizbares Gehäuse sollte nicht notwendig sein, dafür kalibrieren wir ja schließlich mit unterschiedlichen Temperaturen. Bezüglich der Motoren musst du befürchte ich einfach testen. Wenn das Magnetometer wirklich unbrauchbar ist kannst du immernoch den Beschleunigungssensor und das Gyroskop auslesen und darüber die Lage bestimmen. Nur nicht die Richtung, dafür brauchst du halt das Magnetometer.

Wir kalibrieren die IMU für eine Umgebung ohne externes magnetisches Feld. Sobald die IMU irgendwo verbaut wird wo ein Magnet in der nähe ist (z.B. in der Nähe eines Motors) muss der Magnetometer neu kalibriert werden (der Magnetometer lässt sich aber glücklicherweise einfach kalibrieren). Die Kalibrierung des Beschleunigungssensors würde ich nicht anfassen und der Gyroskop Bias ist wie du schon sagst nur mit zusätzlicher Mechanik möglich, würde ich also auch nicht anfassen. Der Gyroskop Gain ist extrem Temperaturabhängig, wenn du da eine spezifische Temperatur hast könnte es sich lohnen einen der Stützwerte mit dieser Temperatur neu zu kalibrieren.

Beim start von brickv sollte sowas kommen wie "XXX Plugin found" oder "Exception in XXX plugin". Kann es sein das du zweiteres bekommst? Wenn ja, hast du alle Abhängigkeiten installiert (vor allem qwt)? Abhängigkeiten: python python-qt4 python-qwt5 python-matplotlib python-scipy python-opengl python-numpy python-qt4-gl

Wenn die Bindings nicht autogeneriert sind, sind sie für uns halt nicht wartbar. Wir können unmöglich bei jeder Änderung die wir vornehmen bzgl neuer API etc. alle Bindings von Hand abändern. Das würde nur dazu führen das wir absolut starr werden mit der Funktionalität, weil der Aufwand einfach nicht zu bewältigen wäre. Daher geht um die Autogenerierung nichts drumherum. Aber wenn du sagst das du eine Device Klasse hast in der die meiste Funktionalität drin ist und nur noch kleine Brick/Bricklet Klassen zu machen sind, ist das doch eine hervorragende Ausgangssituation fürs Autogenerieren. Es müssen ja schließlich nur die kleinen Brick/Bricklet Klassen erzeugt werden.

mit float kann ich 0.3 Lux z.B. nicht darstellen, d.h. ich kann z.B. auch nicht testen ob ich bei 1000 Messungen im Schnitt absolut 3 Lux hatte: >>> x = 0 >>> for i in range(1000): ... x += 3/10.0 ... >>> x == 300.0 False Da müsste ich jetzt wieder anfangen mit: if x < 300.0 + epsilon and x > 300.0 - epsilon Warum würde ich das vorziehen wollen?

Im Moment ist es vermutlich am einfachsten wenn du entweder die Knöpfe runterlötest und dann Kabel auf die Pads lötest. Alternativ versuchst du die Kabel links und rechts vom Schalter dran zu löten, das ist leider ein bisschen gefummel. Wir hatten die Diskussion hier schonmal: http://www.tinkerunity.org/forum/index.php?topic=445.0 und sind zu dem Schluss gekommen das es für zukünftige Versionen am besten ist zusätzlich eine optionale Stiftleiste zu haben für externe Knöpfe.

Die Pinne dürfen sich ruhig berühren, die passen ja passend zueinander .

OK, dann ist ja ziemlich klar woran es liegt (Browsersprache wird nicht richtig erkannt).

Naja, wenn wir eine Auflösung von 1/10 Lux haben macht es einfach sehr viel Sinn die Werte auch in 1/10 Lux zu übertragen, bringt doch sonst nur nachteile (Präzisionsverlust etc). Anders ist das z.B. bei den Quaternionen beim IMU Brick, die übertragen wir entsprechend aber auch in float.

Ich hab die Maximal Dateianhanggröße mal auf 10MB gestellt. Warum ist das denn selbst ohne das compilierte so fürchterlich groß? Kann man die LabVIEW Bindings auf dauer überhaupt autogenerieren?

Ich würde mir erstmal eine Programmiersprache aussuchen, dafür eine Entwicklungsumgebung aufsetzen und ein erstes "Hallo Welt" Programm schreiben. Danach kannst du dann ja mit einem unserer Beispiele Anfangen und das erweitern.

Sollte jetzt gehen, das war mir noch gar nicht aufgefallen und war eine Standardeinstellung hier im Forum.

Dieses Thema wurde verschoben nach Allgemeine Diskussionen. [iurl]http://www.tinkerunity.org/forum/index.php?topic=479.0[/iurl]

3D CAD Dateien haben wir leider nicht. Die Abbildungen auf der Startseite wurden mit einem 3D Modelling Programm nach Augenmaß gemacht. Die wurden schon erstellt bevor wir die ersten Prototypen hatten . KiCAD (das Programm mit dem wir das Leiterplattendesign machen) kann zwar 3D Darstellungen, die Informationen über die Höhe der Bauteile ist allerdings nirgends hinterlegt, das bringt also nichts.

Huch? Welchen Link klickt ihr denn? Den oben rechts bei uns auf der Homepage? Der sollte eigentlich auf de.blog oder en.blog verzweigen, jenachdem was an Sprache eingestellt ist. Kann mal einer von euch versuchen zuerst auf eine der Flaggen zu klicken? Vielleicht funktioniert die Erkennung der Default Sprache bei den mobilen Geräten nicht. Wundert mich allerdings.

Kannst du mal gucken ob bei den Bricklet Steckern irgendwo in Pin Krum ist und vielleicht einen Kurzschluss macht?

Verstehst du richtig. Ein Master, Eine WIFI Extension und eine Temperature Bricklet (+ Stromversorgung) reichen z.B. aus um per Handy Schnurlos die Temperatur zu lesen (kein Brick Daemon benötigt!)

Ich schreibe heute Abend im Blog nochmal etwas genaueres zu den Gründen etc. @Paul: Die WLAN Extension wird ad hoc Modus unterstützen. D.h. du kannst z.B. direkt vom Android/Iphone/Windows Phone Handy auf die Bricks zugreifen ohne AP und ohne Brick Daemon um etwas in den Alpen zu steuern. Das ist IMO besser geeignet um mit wenig Equipment etwas zu betreiben als die Chibi Lösung!

Oh, also wieder ein Problem mit induktiven Lasten. Ich glaube das letzte mal sind wir zu dem Schluss gekommen das zwischen Relay und Last ein "Snubber" benötigt wird: http://de.wikipedia.org/wiki/Snubber Wir hatten uns auch schon überlegt ob wir das nicht direkt aufs Relay Bricklet setzen, aber dadurch würden wir natürlich die Schaltgeschwindigkeiten auch für nicht-induktive Lasten verändern. Mhhh.

Counting the stepper motor steps will definitely have a better accuracy. The problem is that the timing of the sending of the USB package depends on the scheduler of your operating system. So instead of a message every ms you might get a message in 0.8ms and the next one in 1.3ms and the next one in 0.9ms and so on. There is nothing we can do about that as long as the programming is done on one of the modern operating systems (linux/macos/windows). If you want to calculate your postion with the IMU data, these timing differences will destroy your accuracy. The calculations would have to be _very_ precise. In theory we could do the position calculations on the Brick itself. I already looked at that and tried some things. The problem is: If you use the IMU Brick together with two demanding bricklets (e.g. IO 16), we are already at the absolute limit of calculations we can do with the 64Mhz.

Neue Distance IR Firmware ist online: http://download.tinkerforge.com/firmwares/bricklets/distance_ir/ Ich habs nur ganz kurz getestet, war aber sehr zufrieden mit dem Ergebnis. Beachte: Es ist weiterhin so das nur dann ein Callback kommt wenn sich der Wert seit dem letzten Callback verändert hat. Es ist jetzt aber so das er 1x pro ms kommt wenn sich der (gleitende Mittel-)Wert auch wirklich in der letzten ms verändert hat.

Da der Joystick analog ausgelesen wird sollte das keine Probleme machen können. Kannst du mal versuchen das Problem nur mit Temeprature und LCD Bricklet nachzustellen? Und welche Firmware Versionen haben die Bricklets? Ist da alles aktuell? Klingt für mich nach einem fixbaren Software Problem.

Es gibt welche von Phoenix Contact die kompatibel sind zu unseren (sind nicht genau die gleichen, aber passen): http://de.farnell.com/phoenix-contact/fmc-1-5-4-st-3-5/stecker-frei-feder-3-5mm-4polig/dp/1792971 Conrad hat zwar reichlich Phoenix Contact Stecker im Angebot aber die kann ich auf die schnelle nicht finden im Katalog, musst du mal gucken.

In der Tat, warum bin ich da noch nicht selber drauf gekommen? Ich hab insgesamt 250 Byte pro Bricklet Plugin zur Verfügung, ich denke das Distance IR benutzt momentan sowas wie 150, da sollte also etwas machbar sein. Danke für den Tipp!

Ah, ich sehe was das Problem ist. Ich rechne bei dem Distance IR Bricklet mit Durchschnittswerten über 50 Messungen. dadurch wird der Callback nur alle 20ms aufgerufen, weil sich nur alle 20ms der Wert ändert. Die Sharp IR Sensoren haben ein starkes rauschen, deswegen die lange Durchschnittsbildung. Ich könnte allerdings ohne Probleme API hinzufügen um die Länge über die der Durchschnitt berechnet wird zu setzen. Ich baue das am Wochenende mal ein, ich meld mich dann hier nochmal wenn die neue Version hochgeladen ist.