Ziel ist die Realisierung eines drahtlosen Betriebs eines LeapMotion-Steuergeräts. Wie so üblich, soll die Lösung:
Vorgesehen ist
Ein Raumscanner mit 2 Infrarotkameras und ca. 10..30 cm Arbeitsabstand. Dazu eine Bilderkennung, die Fingergesten erkennt. Kostenpunkt 100 Euro. Sehr preiswert, aber der Treiber erweist sich als ressourcenhungig, will mindestens Windows 7 und nervt mit Updates. Auf dem Testrechner mit > 100 ms Verzug eigentlich viel zu träge, um damit etwas ordentliches anfangen zu können. Ein typisches Crowdfunding-Projekt: Viel heiße Luft. Tolle Verpackung. Funktioniert prinzipiell. Hübsche Spielchen mitgeliefert. Das war's.
Der USB-3.0-Anschluss ist nur vorgetäuscht, und damit ist das gesamte Gerät nicht USB-konform. Aha. Von USB steht ja auch kein Sterbenswörtchen in der Anleitung. So wäscht sich die Firma ihre Hände in Unschuld.
Wenn nicht anders erwähnt fanden alle Vorversuche auf einem Desktop-PC mit Pentium 4 3,2 GHz (Dual Core) und Windows 7 – 32 bit namens „Mauersberger“ statt.
Dieses Open-Source-Projekt wurde nicht näher betrachtet, da es nicht die Virtualisierung von USB beinhaltet.
Dieses Gerät ist ausschließlich für Infocus-Projektoren gedacht und funktioniert solo überhaupt nicht. Leider ist Retour ist im gewerblichen Umfeld nicht möglich. Also teurer Elektronikschrott.
Dieses Gerät funktioniert prinzipiell, erweist sich jedoch als unzuverlässig. Das heißt, die LeapMotion-Treibersoftware erkennt einen LeapMotion-Sensor. Aber eben nur dann, wenn die Verbindung als solche steht (ein grüner Punkt im Meldungsbereich der Taskleiste angezeigt wird). Das klappt nur zu etwa 30 %. Neuer Versuch nur nach Reboot. Etwas höhere (gefühlte) Funktionswahrscheinlichkeit unter Windows XP als unter Windows 7.
Eine Bildübertragung war jedoch niemals möglich, erkennbar daran, dass keinerlei Fingergestenerkennung möglich war. Auch wenn „Niedriger Ressourcenverbrauch“ angekreuzt war.
Wahrscheinlich ist die Funkdatenübertragung zu langsam.
Dieses einem Universal-Anzeigeprogramm für System-Kameras Marke Eigenbau zeigt ein schwarzes Bild. Beim Start des Programms werden 3 tiefrote LEDs aktiviert (man sieht sie kaum) und gehen nicht wieder aus.
Stromaufnahme:
Mit dem vorgesehenen 4500-mAh-Akku wäre die Laufzeit (ohne den Raspberry Pi) 30 h. Der Raspberry schluckt ca. 200 mA. Macht 12,8 h. Reicht geradeso.
Es könnte doch sein, dass das Gerät selbst SuperSpeed-fähig ist? Das Kabel ist es jedenfalls nicht. Also Kabel tauschen und prüfen:
Also ein Fake sowohl beim Kabel als auch beim Gerät.
Da die Bilddaten mit zig Megabyte pro Sekunde anfallen, ist es erstrebenswert, diese Datenmenge „vor Ort“, also so nah wie möglich an der Kamera zu erledigen. Sonst hat man unweigerlich das Problem, die riesige Datenmenge sicher durch die Luft zu schaufeln. Ungerichtet, versteht sich. In freien Frequenzbändern. (Gerichtet wäre es kein Problem, siehe Satellitenfernsehen.) Mit Kabel ist das Problem weitaus weniger prekär.
Die Beispielprogramme wird man wohl wegen der unbekannten Treiberschnittstelle nicht auf dem Applikationsrechner zum Laufen bekommen. Aber das interessiert nicht. Hauptsache man hat irgendeinen Zugang zu den Koordinaten der Fingerknöchel.
Bleibt man beim (sehr aufwändigen) Treiber, muss ein Embedded PC her, auf dem Windows 7 läuft, um die EDV zu lösen. Wegen Closed Source.
Wurde schon mal realisiert. Ist also nichts neues.
Erfordert Bilderkennungs-Treiber für die jeweilige Architektur. Nahezu aussichtslos. Viel Reverse-Engineering. Wahrscheinlich sogar für Billigstlohnländer zu teuer.
Ebenfalls Reverse-Engineering wie oben.
Im Prinzip kann man dann auch das ganze LeapMotion neu entwerfen und auf die USB-Schnittstelle verzichten. Daraus folgt noch strikteres Echtzeitverhalten, da der FPGA dann die Bildverarbeitung scanzeilenweise abzuarbeiten vermag.
Zusammenfassend kann man so feststellen, dass mit dem LeapMotion-Gerät, so wie es ist, keine drahtlose „richtige Lösung“ möglich ist.
Alle anderen Lösungen zielen darauf ab, die Datenmenge irgendwie durch die Luft zu wursteln.
Wenn nicht anders erwähnt fanden alle Versuche auf einem Desktop-PC mit Pentium 4 3,2 GHz (Dual Core) und Windows 7 – 64 bit namens „e-simotion“ statt.
Ist natürlich keine Endlösung! Ausprobiert: VirtualHere und Ethernetkabel: Verbindung kommt zustande, aber versuchsweises Hand-Tracking schlägt fehl.
Für VirtualHere existieren fertige Binärdateien für Windows (Client) und ARMv7l = RaspberryPi = BananaPi (Server). Es ist sehr einfach anwendbar, funktioniert prompt und bietet kostenfrei die „Verlängerung“ genau eines USB-Gerätes ohne weitere Beschränkungen. Allerdings ist es keine Open-Source-Lösung, man wäre für die Zukunft auf Gedeih und Verderb mit einer weiteren Closed-Source-Quelle abhängig.
Wie oben. Der BananaPi hat ein Gigabit-Ethernet-Interface, der Versuchs-PC auch. Hier funktionierte auch das Hand-Tracking!
BananaPi + VirtualHere + Ethernetkabel ist eine gute Lösung, um mit wenig Aufwand das USB-Kabel zur LeapMotion-Kamera zu „verlängern“.
Klar, dass das zu langsam ist. Auch mit der Banane. Diese Konstellation wurde benutzt, um einen AccessPoint auf der Himbeere zu installieren. Laut Wikipedia kommt ein Ad-Hoc-Netzwerk für hohe Datenraten nicht in Frage.
Hier wurde viel experimentiert, siehe Loseblattsammlung. Immerhin wurde ein Accesspoint erfolgreich in Betrieb genommen. VirtualHere hat auch funktioniert, und erwartungsgemäß kam keine Gestenerkennung zu Stande.
Das 5-GHz-Frequenzband bietet mehr als die 108 MBit/s des Realtek-Chips. Hier wurde nicht weiter experimentiert.
Hier scheiterte die Installation des Treibers. Siehe unten.
Linux: Ethernetport konfigurieren
ifconfig eth0 netmask 255.255.255.0 broadcast _._._.255 route add default gw _._._.1
Windows: PING-Antwort aktivieren
netsh advfirewall firewall set rule name="Datei- und Druckerfreigabe (Echoanforderung - ICMP4 eingehend" new enable=yes
Accesspoint einrichten
sudo apt-get install hostapd iw hostapd.conf erstellen network/interfaces
Fehler: nl80211 not found
Eigenes hostapd compilieren
WLAN-Adapter EW-7811, Chip RTL8188CUS Weitere Versuche einen passendenden Treiber zu compilieren scheiterten am Verständnis was zu tun ist. Schließlich ging's irgendwie auch ohne, ich weiß nicht mehr wie.
Ein Paar moderner WLAN-Sticks mit USB 3.0 sowie kurze USB-3.0-Verlängerungsleitungen zum problemlosen Anschluss der zu breiten Sticks wurde beschafft:
Linksys WUSB6300 VID=13B1 PID=003F
Dazu ist ein Treiber zu compilieren, siehe unten. Es scheitert aber am Download von "linux-headers-$(uname -r)"! Ich konnte das (an sich primitive) Problem nicht lösen.
Wenn alle Stricke reißen, wäre es wohl noch möglich, einen zusätzlichen externen Accesspoint im 5-GHz-Frequenzband (803.11a) an der Gigabit-Ethernet-Schnittstelle des BananaPi zu betreiben.
Muss gesondert recherchiert werden. Selbst wenn das funktioniert verkompliziert sich die Stromversorgung erheblich.