LeapMotion

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:

• MaxPower = 500 mA im USB Configuration Descriptor
• 122 mA im Normalbetrieb (idle)
• 125 mA im Betrieb mit kamera.exe (siehe oben)
• 137 mA mit roten LEDs
• 14x mA beim Zugriff (Betrieb der LeapMotion-Treibersoftware mit Testprogramm)

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:

• Das Gerät gibt sich weiterhin als High-Speed aus, lt. UsbTreeView Sowohl unter Windows XP als auch unter Windows 7.

Also ein Fake sowohl beim Kabel als auch beim Gerät.

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.

• Geringes Datenübertragungsvolumen, daraus folgend sieherer Betrieb bspw. mit Bluetooth oder ZigBee statt WLAN
• Riesen-Akku erforderlich

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.

• Offener Quelltext der Bildverarbeitung
• Kleinerer Riesen-Akku

Ebenfalls Reverse-Engineering wie oben.

• Offener Quelltext der Bildverarbeitung
• Höchster Entwicklungsaufwand
• Aufwand bei der Platinenproduktion, da üblicherweise keine Eval-Boards verfügbar
• Teurer FPGA-Schaltkreis
• Hervorragendes Echtzeitverhalten
• Minimale(!) Akkugröße

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.

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.

• RaspberryPi
  • login=pi, Password=pi
• BananaPi
  • login=root, Password=bananapi
  • login=Henrik Haftmann (heha), Password=exe2bin (beim Start der GUI)

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

broadcast
up iptables
wireless-mode: managed?

dnsmasq.conf

interface=…
no_dhcp_interface=…
dhcp_range=…

Fehler: nl80211 not found

Eigenes hostapd compilieren

• FEHLER: kein genl.h → apt-get install libul.dev
• FEHLER: kein openssl/ssl.h → libssl-dev
• FEHLER: Alles für die Katz: lsmod → kein mac80211

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.