LeapMotion

Ziel ist die Realisierung eines drahtlosen Betriebs eines LeapMotion-Steuergeräts. Wie so üblich, soll die Lösung:

Vorgesehen ist

Hauptbearbeiter: Christian Kollatsch

Was ist das?

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.

Vorversuche

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.

DIY Wireless File Transmitter

Dieses Open-Source-Projekt wurde nicht näher betrachtet, da es nicht die Virtualisierung von USB beinhaltet.

Infocus Display Link Adapter

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.

HAMA Wireless USB

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.

Kamera.exe

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.

Messungen

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.

USB SuperSpeed

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.

Richtige Lösung

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.

Mit Embedded x86-PC

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.

Mit Embedded PC (bspw. ARM)

Erfordert Bilderkennungs-Treiber für die jeweilige Architektur. Nahezu aussichtslos. Viel Reverse-Engineering. Wahrscheinlich sogar für Billigstlohnländer zu teuer.

Mit FPGA

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.

Murks-„Lösungen“

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.

RaspberryPi + Ethernetkabel

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.

BananaPi + Ethernetkabel

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“.

RaspberryPi + WLAN 803.11b/g

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.

RaspberryPi + WLAN 803.11a

Das 5-GHz-Frequenzband bietet mehr als die 108 MBit/s des Realtek-Chips. Hier wurde nicht weiter experimentiert.

BananaPi + WLAN 803.11a

Hier scheiterte die Installation des Treibers. Siehe unten.

Loseblattsammlung

Passwörter

EW-7811 als Accesspoint auf RaspberryPi

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
dnsmasq.conf
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.

5 GHz

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.

Letzte Aussicht auf Erfolg

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.

Links