godot daydream controller udp

Godot access to Google Daydream controller's values. Currently including:

1. button press values (volume up, volume down, touchpad button, app button, daydream button)

2. gyroscope (x,y,z)

3. accelerometer (x,y,z)

4. magnetometer (x,y,z)

5. touchpad touched coordinates (x,y)

Platforms

Only tested to work on Linux, using dbus extracted values generated by Bluez.

The UUIDs and bit representations should be the same on other platforms so making this work would just require using the existing mappings tied to whatever your platform does to interface with Bluetooth.

Getting the controller data ready to transmit generally

Make sure that the daydream controller is "connected", meaning that Bluetooth not only knows it exists but is also not in "disconnected" state. OpenSuse seemed to require that I forcibly forget the daydream controller and reassociate it every time. Arch seems to be able to cleanly connect and disconnect without requiring from-scratch re-association. So your results may vary depending on your distro, even with Bluez being a common factor between them.

Echoing the controller data to command line rather than transmitting it anywhere

run python/controller_values.py directly. This will provide a rapidfire series of current status messages whether you push buttons or not.

Using udev to deal with controller data

You'll need python-evdev. On Arch this is found in a package called python-evdev.

Run python/control_value_sender.py with parameter --udev=true. You'll likely need to run it as root unless your system allows non-root to create devices.

verifying udev generated controller data at the command line

run python/udev_evdev_listener.py. It will only echo status when you press or release buttons, as opposed to the very noisy status of running python/controller_values.py directly

Seeing the controller values, via udev, in Godot

Launch the daydream controller Godot project located in demos/UDev. The Node2D scene labels will tell you the daydream controller values. The response if very zippy and likely fast enough to work well for a playable game.

Using a udp socket to transmit the controller data

start python/con (or python/control_value_sender.py if you want to use a different port and/or hostname)

Seeing the controller values, via udp socket, echoed outside Godot

start python/serv (or python/valrec_server.py if you want to use a different port and/or hostname). For me, this approach echos values without any noticeable lag.

Seeing the controller values in Godot via udp socket

Launch the daydream controller Godot project located in demos/PureGDScript. The Node2D scene labels will tell you the daydream controller values. For some reason at the moment there's a very noticeable lag between controller state change and the value showing up in Godot, so there's a big need for performance tuning to get the responsiveness high enough for these controller values to be zippy enough to be part of a playable game. At the moment the lag is big enough that if you try to make a game with it you'll probably end up wanting to throw your controller across the room. It's possible that the stream lag is inherent to a GDScript approach and switching the data stream to GDNative is enough to solve it. Hopefully I'll have the code for that soon.

Notes

1. In writing this I got some value from https://hackernoon.com/how-i-hacked-google-daydream-controller-c4619ef318e4 but I was never able to find associated code for it and some of the bit positions didn't match what I was seeing while I was bluetooth sniffing, requiring that I re-derive at least some of it, so it's possible Google moved bits around since that article series was published.

2. The button values are easily verified, and are working correctly for me. The gyro, mag, and accel values are harder for me to be sure of so take all of them with big grains of salt for now.

3. The current data stream never maps to an "actual" controller/joystick/joypad , so you won't be successful if you try to tie the daydream controller to game logic using the InputMap

4. Likewise the accelerometer, magnetometer, and gyroscope also never make it to the Input level, so even though Input has associated methods (Input.get_accelerometer(), Input.get_gyroscope(), Input.get_magnetometer()), none of those methods will retrieve the daydream controller data.

5. This repository is all about direct data from the Daydream controller, and doesn't do anything with respect to other parts of the Daydream ecosystem. Aka, there's nothing here about HMDs or other peripheral bits.

6. With respect to HMDs, my personal use case is going to be to use the ARVR Server Interface "Native mobile" with the daydream controller serving the controller's role. It should also be possible in theory to use something like the godot_oculus interface (ARVR Server Interface name "Oculus") or other server interfaces. If you use a specialized server interface then you can have fun adding the daydream controller as an additional controller on top of whatever controller(s) your specialized interface already imports automatically.

7. Apparently it's also possible to get independent data streams from multiple daydream controllers, to support a "left hand" and "right hand" simultaneous approach (see for instance https://hackernoon.com/how-i-hacked-google-daydream-controller-part-iii-12e75adc4829 ), but I only have one controller so if someone else wants to extend this for two-handedness they're welcome to.

8. It's kludgy that Main.tscn is essentially copy/pasted between the GDScript demo and the UDev demo. I spent some time trying to make Main.tscn a template scene but wasn't able to figure out how to do that. It should be refactored to take that approach so that it's the same scene visually (without replication) and just has a different script controlling it.