Controller - device communication groundwork

[cboulay]

We will use hidapi for Linux and Mac. hidapi also supports Windows, so we will use that initially, but the plan is to use the MS APIs for Windows instead of hidapi.

A list of feature reports can be found here.

Some hidapi notes:

• hidapi no longer works properly on Windows 10. See here. I plan to update this in my fork

Some Windows HID notes:

• Maybe this is a good place to start. Scroll down to "The HID Application Programming Interface (API)"

[brendanwalker]

The other option would be to use libusb to get/ser the hid reports directly. HID report requests are really just a wrapper on top of USB control requests. Here is an example of using libusb to make hid report requests: http://janaxelson.com/code/generic_hid.c
That way we could avoid having os dependant hid report code paths.

[cboulay]

I think the 'hidapi problem' is a symptom of the OS more than it is of hidapi itself. I'm sure I'm butchering the vocabulary, but I think Windows exposes the bluetooth-connected PSMove controller as 3 devices, whether it's enumerated via libusb or hidapi, and those 3 devices have different feature reports. I'll try to put together a quick test to confirm that's true.

My hope is that the Windows API somehow corrects for this. If it doesn't then we're no better off using the Windows API than we are using a patched hidapi.

[cboulay]

Collecting some Vendor IDs (VIDs) and Product IDs (PIDs) on my Mac as returned by libusb:

• PS3 Eye when using PS3EYEDriver
  • VID: 0x1415 == 5141
  • PID: 0x2000 == 8192
• PSMove over USB
  • VID: 0x054c == 1356
  • PID: 0x03d5 == 981
• New things when PSMove connected to Mac via Bluetooth ("MotionController")
  • Broadcom Bluetooth USB Transport 20702B0
    • VID: 0x05aC == 1452 (Apple)
    • PID: 0x8289 == 33417 (Broadcom 20702B0)
  • BRCM20702 Hub
    • VID: 0x0a5C == 2652 (Broadcom)
    • PID: 0x4500 == 17664 (BCM2046B1 Bluetooth <-> USB hub)
• Note that, whether or not I have the PSMove connected VIA bluetooth, I have 3 other devices with VID 0x05aC; PIDs = 0x0262 (kb/trackpad), 0x7e13, 0x7e13

Edit:
I tried with libusb a few different ways on my Mac but I couldn't identify the BT-connected controller. hidapi/mac/hid.c does not use libusb, it uses Apple's API. hidapi does have a version that wraps libusb, but that seems to only be for certain flavours of Unix (incl. Android).

Also, I realized that hidapi/windows/hid.c uses the Microsoft API that I was planning to use. I guess it'll be better for me to patch it to work with Win 10 than for me to redo all of its efforts.

[cboulay]

I thought I was done with the controller communication, but then I just realized that I completely forgot about the internal sensor calibration that needs to be copied from the controller when connected by USB then saved to a file, and loaded from the file on subsequent Bluetooth connections.

[cboulay]

Also TODO
hidapi gets the button&sensor data asynchronously and, via a callback, stores the result into an internal buffer. hid_read() merely gets the oldest frame in this buffer.

Unfortunately, I can't seem to find any sort of timestamp for when the frames were received. There is an int16 timestamp and a int4 sequence number so the frames can be put in some order and the time between frames can be saved.

I need to make a member variable that is a FIFO buffer of controller states (std::dequeue) and fill the buffer with all available states each time the read function is called.

[cboulay]

Before I can finish this, we need a standardized way of reading and writing configuration data to files. I thought this could be handled by a class something like /psmoveservice/FileManager/FileManager.h & .cpp

But boost probably has some utilities for this too. Brendan, do you have any ideas on how you would like config data to be saved/loaded from disk?

[brendanwalker]

It looks like boost has a pretty easy to use set of utility classes for loading and saving hierarchical configuration data: http://theboostcpplibraries.com/boost.propertytree
Here is a debug settings example: http://www.boost.org/doc/libs/1_41_0/libs/property_tree/examples/debug_settings.cpp
That api lets you save as .ini, .json, and .xml formatted data. I like simple .ini files for simple key-value pair storage. If we have any configuration that needs more structure I personally like storing it as JSON.

[cboulay]

I have the config save/load working properly for the controller calibration data. The controller has to be accessed via bluetooth at least once to write its calibration data to disk.

I'm going to close this issue because basic controller functionality is done enough that the controller can be brought into a PSMoveFusion class that uses controller data and tracker data, and their histories, to get the current (or even predicted future) pose.

One thing that still needs to be done in the controller class is the magnetometer, but I want to open a separate issue for that.