borg

naja, die Schleife bleibt solange stehen bis du oben bei callbacks das set() aufrufst, das ist ja Sinn der Sache .

Ich vermute das ist irgendwie eine Art Scheduler Problem oder so, du spammst brickd ja regelrecht zu mit den settern. mach mal: from threading import Event cb_event = Event() # Im callback unten: cb_event.set() # In der while Schleife: cb_event.clear() cb_event.wait() Alternativ einfach erstmal ein time.sleep(0.1) oder so in die while Schleife, damit du nicht ununterbrochen Nachrichten sendest (bei dieser Möglichkeit hast du dann natürlich eine Latenz von maximal 100ms).

Mh, am besten du probierst einmal das Analog In Bricklet neu zu flashen. Dazu den Master Brick ohne das angeschlossene Analog In Bricklet starten, dann das Analog In Bricklet anschließen und dann über Advanced Functions im Brick Viewer neu flashen.

Das wird nicht funktionieren, die Latenzen über Funk (ganz egal ob Chibi oder WLAN oder sonstwas) sind einfach zu groß um einen Quadrocopter in der Luft zu halten! Was du brauchst ist ein kleines embedded Board auf dem Copter (Raspberry Pi, Beagle Board o.ä.) der sorgt dafür das die IMU auf der X und Y Achse bei 0 Grad bleiben und dann steckst du einen USB WLAN Stick in das embedded Board und steuerst vom PC aus die eigentliche Bewegung! Edit: Ansonsten sieht das gut aus, IMU um den Copter gerade zu halten und Servo zum steuern der brushless Motoren über einen ESC. Einen Höhenmesser haben wir im Moment noch nicht im Programm leider. Da lässt sich aber vermutlich einer finden der einen Analogen Wert ausgibt den du mit dem Analog In Bricklet auslesen kannst. Edit2: Ein Quadrocopter war eines der Projekte was wir auch anfangs im Kopf hatten wir mit unserem Kram baubar seien sollte. Wenn du sowas wirklich baust würden wir uns definitiv über Videos/Bilder freuen .

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.