borg

Für uns kommt nur ein Modul mit integriertem IP Stack in Frage. Der Zeitaufwand von RS485 und die Probleme mit Chibi haben gezeigt das wir die low-level Protokollebene besser nicht selber implementieren sollten. Der momentane Prototyp basiert auf diesem Modul: http://www.rovingnetworks.com/products/RN_171 Falls jemand von euch dazu einen Alternativvorschlag hat bitte her damit. Noch ließe sich das ändern. Irgendwann ist aber natürlich der Punkt gekommen wo wir soviel Zeit in die Implementierung gesteckt haben das wir nicht mehr wechseln können.

@IPv6: Für Vorschläge von WLAN Modulen mit CE/FCC Abnahme die IPv6 können und in einen 3x3.5cm Platz passen sind wir offen . Ich befürchte sowas gibt es nicht.

Mhhh, so wie es im Moment gedacht ist müsstest du bei der Initialisierung zwei IPConnections aufmachen, könntest aber danach alles so nutzen wie jetzt auch.

Hier gibt es eine Anleitung wie du die C Bindings mit Visual Studio Express zum laufen bekommst: http://www.tinkerforge.com/doc/Software/API_Bindings.html#c-c Du musst den Compiler auf c++ stellen und die ws2_32.lib einbinden. Ich bin mir um ehrlich zu sein nicht sicher wie man das mit Visual Studio in der Kommandozeile tut, könntest du nicht Visual Studio Express installieren und da wie in dem Link beschrieben zum laufen kriegen? Ich vermute man kann sich dann auch irgendwo angucken womit Visual Studio die cl.exe aufruft!

Die Ruby Bindings sind fertig und auf unsere Homepage an den üblichen Stellen zu finden. Über Feedback und Bug Reports von Ruby Experten würden wir uns natürlich freuen, um die Anfangsschwierigkeiten schnell zu überwinden .

So, hab jetzt mal einen Blog Eintrag zu dem Thema verfasst: http://de.blog.tinkerforge.com/2012/5/25/chibi-oder-kein-chibi-das-ist-hier-die-frage

So, hab jetzt mal einen Blog Eintrag zu dem Thema verfasst: http://de.blog.tinkerforge.com/2012/5/25/chibi-oder-kein-chibi-das-ist-hier-die-frage

@tex: Wir würden uns natürlich freuen wenn du da etwas auf die Beine stellst! Schön wäre es wenn wir die dann später auch benutzen könnten um darauf basierend einen Generator zu schreiben, wie wir das jetzt vermutlich mit dem Delphi Bindings von Nic machen.

In der Theorie sollte USB3 abwärtskompatibel zu USB2, wir werden das mal testen.

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?