Ever wondered how device drivers are reverse engineered?

Beautiful, well documented code. Thanks for sharing.

Correct, in this case it's the most common type of USB device/driver, the HID driver. Many devices will present themselves as HID Devices initially and even communicate over the HID protocol since it is one of the few USB classes that doesn't require a special driver to be written for windows to recognize it (other classes such as a serial device require at least an INF to be installed in order for windows to load the correct driver).

> Does this mean there is a default kernel driver on the interface and we must detach it

Yes. Sometimes, and most prominently: A lot of cheap gizmos register themselves as "HID" (human interface devices) which is a class normally reserved for keyboards and mice. Windows, Linux, OSX, ... have default drivers, and the HID protocols implements a channel for arbitrary data to be passed to/from the device (/dev/hidraw* in Linux). In turn it allows people to talk to the "USB rocket launcher" providing a simple executable application, without needing to register a driver.

If you want to talk to the usb device using libusb (or the python bindings) you have to unbind this generic driver. You can either do it from within libusb, or for example, in the sys filesystem.

For a USB ethernet adapter (which I happen to have laying around):

    $ cd /sys/bus/usb/drivers/ax88179_178a
    $ ls
    (...)
    lrwxrwxrwx 1 root root 0 Mar 20 20:33 2-1.1:1.0 -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0
    (...)

...so it's bound to device 2-1.1:1.0 ...

    $ sudo sh -c "echo 2-1.1:1.0 >unbind"

...ethernet interface is now gone, I can, theoretically, now talk to the device using libusb.

Another example: Some programming cables for microcontroller development (similar to, e.g. the Arduino stuff) might have use a standard USB-to-Serial bridge chip. But as you have to talk to it in a non-standard way you'd have to unbind the default usb-to-serial kernel module and talk directly to the usb device.

Out of curiosity, what hardware are you using / drivers are you missing? Given the number of existing flight control boards with decent open source software support, I'm a little surprised that drivers are blocking you, rather than something more interesting like running out of CPU cycles to run a Kalman filter ;)

My experience has been the Bus Pirate is good for ad-hoc sending/receiving data over various protocols when you are working at the level of single recieve/response commands (i.e. you have a data sheet for a part and want to test it out). full-on logic analyzers or USB analyzers are nicer for capturing an entire conversation or trying to understand how data flows relate to each other.