Holy

Das Dual Relay Bricklet ist schonmal drin. Den DC Brick werde ich auch noch reinmachen, kann dir aber nicht versprechen wann es diese Woche noch wird. Mit welcher LabVIEW Version arbeitest du? http://www.tinkerunity.org/forum/index.php/topic,491.msg4180.html#msg4180

Im "Handle Message.vi" muss der entsprechende Code für die Decodierung dieser Funktion hinzugefügt werden. Und an dieser Stelle wird das Variant dann auch mit den gewünschten Daten gefüllt. Ich habe das Dual Relay Bricklet noch händisch hinzugefügt und den Code angefügt. LV_Tinkerforge_-_LV2010_-_1.0.0.3.zip

Die bisher existenten Klassen sind noch nicht für alle Bricks und Bricklets. Hatte erstmal angefangen Code für die Autogenerierung der Bindings zu schreiben. Aus Zeitgründen ist das aktuell aber nur teilweise fertig. Solltest du noch paar andere Bricks bzw. Bricklets brauchen könnte ich die auch noch händisch erzeugen.

Ja natürlich! Würde mich über Feedback freuen. Sollten bei der Verwendung Fragen auftreten beantworte ich die gerne direkt hier oder ggf. per PM. LV_Tinkerforge_-_LV2010.zip

Hab mittlerweile nochmal Zeit gefunden die händisch geschriebenen Klassen durchzutesten. Somit sind erstmal folgende Bricklets für Testzwecke verfügbar: Ambient Light Bricklet Humidity Bricklet Temperature IR Bricklet Distance IR Bricklet IO-4 Bricklet Weiterhin ist in der Library ein Tree.vi enthalten, welches einen ersten Hinweis auf die Verwendung geben soll. Mit der Autogenerierung habe ich schonmal angefangen und hoffe das es zügig vorran geht. Ist aber wie schon angedeutet leider etwas umfangreicher aber trotzdem sehr spannendes Thema, was ich mittlerweile seit Jahren schonmal angehen wollte. LV_Tinkerforge.zip

Wäre als Höhensensor nicht auch ein Distance IR vorstellbar? Diesen könnte man nach unten ausrichten und somit die Höhe bestimmen.

Beantworte meine Frage mal selbst: if i < 0 or name[0:i].replace('-', ' ') != self.add_dev.expected_name.replace('-', ' '): Wird separat behandelt in den Bindings also so gewollt/bekannt.

Mir ist aufgefallen, dass das Temperature IR Bricklet von Get_Stack_ID als "Temperature-IR Bricklet x.x" bezeichnet wird. Ist das so gewollt oder nur Zufall? Bin darüber gestolpert da ich davon ausgegangen bin, dass die Namen genau wie in der Dokumentation sind.

Eine reine Wegfindung ist denke ich einfacher wie eine Erkundung. Bei einer Wegfindung fährst einfach direkt auf das Ziel zu und musst Objekten nur ausweichen und immer versuchen den kürzesten Weg zum Ziel zu finden. Ist erstens vom Algorithmus her "einfacher" und benötigt primär Messungen in Fahrtrichtung. Evtl. lohnen auch auch Messungen +-30° zur Fahrrichtung um ggf. den kürzesten Weg zum Ziel bestimmen zu können. Eine Erkundung, bzw. das was ich jetzt darunter verstehe, ist da sicher aufwändiger. Entweder du fährst das interessante Gebiet komplett ab und vermisst es immer in Fahrtrichtung oder fährst unterschiedliche Punkte innerhalb des Gebietes an um dann Rundum-Messungen durchzuführen. Die Mitellung der Werte könntest z.B. auch abhängig von der gemessenen Entfernung machen. D.h. wenn du ein Objekt findest die Entfernung genauer vermessen und wenn dort nichts ist dann reicht eine Einzelmessung. Analog kann man dies auch für den Verfahrwinkel machen.

Der Distance IR ist da sehr gut geeignet für die Kollisionsvermeidung. Die muss eigentlich auch nicht sehr genau messen und daher sollten dann auch nen einzelner Messwert ausreichen. Soll deine Kiste dann im "freien Gelände" (Zimmer etc.) fahren oder in einer definierten Umgebung (http://www.tu-chemnitz.de/etit/proaut/lehre/rsrc/roboterUndBoje.jpg)? Bei letzterem kann man die Abstandssensoren dann nicht nur für die Kollisionsvermeidung sondern auch zur Erkundung verwenden. Da sind genauere Entfernungsangaben evtl. interessant.

Ich selbst benutze die Version 2011 SP1. Ich kann es aber auf jeden Fall runterspeichern. Gibt aber leider eine Stelle die ich dann anders implementieren muss, da es in LV 2011 ein paar neue Primitivies gab. Grafische Programmieransätze gibt es einige, z.B. VEEpro von Agilent oder auch die Robotics-Suite (?) von Microsoft.

Ich habe erstmal per Hand noch die Klassen für Distance IR Bricklet, Temperature IR Bricklet, Humidity Bricklet und IO-4 Bricklet erzeugt. Das werde ich jetzt erstmal alles auf Herz und Nieren durchtesten. Danach mach ich mich an die Programmierung des Generators und wenn der funktioniert dann die Parsingroutinen für die Konfigurationsdateien. Sobald die Tests des aktuellen Standes fertig sind werde ich diesen nochmal hochladen und würde mich freuen wenn sich jemand Zwecks Verbesserungsvorschlägen, Bugs, etc. das mal anschauen könnte. Mir ist aber auch klar das die Anzahl derer die LabVIEW zur Verfügung haben wohl eher gering ist. Alternativ würde sich aber auch noch die 30-Tage Evaluierungsversion anbieten.

Ja, Gleitkommazahlen sollte man nie auf Gleichheit prüfen. Mal unabhängig ob Integer oder Float macht ein solcher Vergleich relativ wenig Sinn da bei der Messung von analogen Signalen immer ein Rauschen vorhanden ist. Damit kannst auch das nicht auf Gleichheit prüfen.

Der Präzisionsverlust bei einer Umrechnung innerhalb der Bindings ist denke ich doch zu vernachlässigen, besonders bei 1/10. Wenn ich das richtig sehe ist das Signalrauschen der analogen Werte sowieso meist größer als 1/10.

Gute Frage was dort in den Dateien alles drin ist. Ohne groß Inhalt fängts bei knapp 20KB je VI (Funktion) bzw. Typdefinition an. Die Autogenerierung ist auf jeden Fall möglich da mitells VI Scripting programmatisch Code erzeugt werden kann. Primär läuft es darauf hinaus eine Template-Klasse zu erzeugen und dann einfach eine neue Kopie zu erstellen und die jeweils spezifischen API-Funktionen automatisch zu generieren sowie den spezifischen Message-Handler der Klasse. Aktuell bin ich mir noch nicht sicher ob der Aufwand lohnt den Codegenerator zu schreiben. Ich würde schätzen die 23 noch ausstehenden Brick/Bricklet Klassen per Hand zu erzeugen dauert maximal 1 bis 2 Tage. Der Codegenerator wird wohl schnell mal 1 Woche Entwicklungszeit schlucken. Das kommt insoweit auch zu tragen da ich die Device-Klasse soweit wie möglich mit Code versehen habe und die Brick/Bricklet-Klassen jeweils nur ihre spezifischen Sachen machen und sonst nur ihre Eltern-Klasse aufrufen und somit Änderungen dann nur an 1 Stelle fällig sind. Zum Thema DLL: Denke ich ist kein sinnvoller Weg da dort für jede einzelne Funktion ein Wrapper-VI geschrieben werden muss. Die Autogenerierung der Bindings hat ja primär bei den Brick/Bricklet Klassen Vorteile. Die IPConnection Klasse ist auch bei allen anderen Bindings handgeschrieben. Man gewinnt durch die DLL somit leider nicht wirklich was.

Double ist wohl mittlerweile der Standardweg, ausser vielleicht auf embedded. Ein Beispiel für Probleme ist z.B. auf ein Single Precision Float kann man auf Zahlen größer ~16384 nicht mehr 0,0005 aufaddieren (Zeitwert des jeweiligen Samples in Sekunden bei einer Samplingrate von 2kHz). Hat mich mal bei einer kumulativen Zeitinformation für Messwerte erwischt

Die Ambient Light Bricklet Klasse ist insgesamt 700 KB groß, unkomprimiert. Es gibt noch 23 weitere Brick und Bricklets mit jeweils mehr oder weniger API-Funktionen. Wird in Summe dann schon einiges. Ich habe auch schonmal probiert den kompilierten Code rauszutrennen aber das würde gerade mal 50 KB je Klasse bringen.

Das sieht dann folgendermaßen aus: Gegenüber der normalen Entwicklungsumgebung dann mit erheblich weniger Möglichkeiten. Ist denke ich aber für die Zielgruppe bei den Mindstorms genau richtig.

Danke für den Vorschlag. Hilft aber leider nicht so wie notwendig Sind dann statt 1053 KB trotzdem noch 707 KB und das ist für das Forum immer noch viel zu viel. Eine Variante ist noch splitten aber das ist denke ich nicht wirklich toll.

Gezippt sind es aktuell 1 MB.

Mich würde mal interessieren warum die analogen Werte in den Bindings nicht direkt in die jeweilige Einheit umgerechnet werden? D.h. 1/10 Lux bei z.B. AmbientLight.get_illuminance() statt direkt ein Float in Lux. Ich denke spätestens in den Bindings hätte es gewisse Vorteile diese Umrechnungen vorzunehmen: 1. muss nicht jedes mal durch den Nutzer gemacht werden 2. Änderungen an der Wertigkeit brechen den User-Code, z.B. 1/100 statt 1/10 weil der Sensor genauer ist... Oder gibt es hier gute Gründe für die mir bisher nicht aufgefallen sind?

Ich habe mich mal an die Implementierung von Bindings auf Basis LabVIEW gemacht. Der bisherige Stand besteht aus den Haupklassen IPConnection und Device. Weiterhin ist die Klasse für das Ambient Light Bricklet komplett implementiert. Da ich aufgrund der Größenbeschränkung von 192KB den Quellcode nicht hochladen kann erstmal 2 Screenshots damit ihr erstmal nen ersten Eindruck davon bekommen könnt. http://www.tinkerunity.org/forum/index.php/topic,235.msg2585.html#msg2585 Wenn Interesse besteht kann ich die Quellen dann über das Tinkerforge-Repository im Github bereitstellen. Edit: Quellcode angehängt. Danke an borg für die Erhöhung des Limits LV_Tinkerforge.zip

Mittels LabVIEW könnte die grafische Programmierung folgendermaßen aussehen: Das zugehörige GUI sieht dann folgendermaßen aus: Das ist hierbei die direkte LabVIEW Entwicklungsumgebung. Gerade für die Mindstorms wurde seitens des Herstellers das UI angepasst und eine spezielle kindgerechte Version bereitgestellt.

10kHz wären 10000 Pakete je Sekunde und nicht nur 100. Wenn du schreibst unter einer Millisekunde geht nix wäre das entsprechend schon 1000 Pakete je Sekunde. Die 20 Werte pro Sekunde dann im letzten Post entsprechen dann 50 Hz. Leider etwas verwirrend was du jetzt eigentlich erreichst und was dein Ziel ist?!