usb: Thu Feb 22 20:31:00 2007

Thu Feb 22 20:31:00 2007

I finally picked up one of the popular USB foam-rocket launchers, http://www.cyberguys.com/templates/searchdetail.asp?productID=13430 and started looking for linux code (and, of course, by preference Python code) to talk to it.

Learned a few things right off:

• the Marks & Spencer one, http://www.thinkgeek.com/geektoys/cubegoodies/86b8/ that started it all, requires batteries, and is harder to find.
• the "DreamCheeky" one is cheaper, doesn't need batteries, and appears to have smaller darts.

There were a few chunks of useful reference material:

• http://dgwilson.wordpress.com/ David Wilson's Mac driver... pretty sophisticated, supports both devices, includes Objective C source which is well commented and readable (the Mac OS X USB APIs are somewhat verbose and help encourage readability, it turns out...)
• http://scott.weston.id.au/software/pymissile-20060126/ has a nice python binding for libusb (pyusb-0.3.1) and a patch to add support for a detachKernelDriver method. It also has an http://excess.org/urwid/ urwid curses-based interface, and support for multiple devices. Sadly, it's very hard code to read because it does things like self.dev.handle.controlMsg(0x21, 0x09, self.INITA, 0x02, 0x01) which gives no hints as to what is actually going on; the usb module has symbolic constants for these, after all. My version is, instead, handle.controlMsg(reqType, usb.REQ_SET_CONFIGURATION, reqBuffer, value=usb.DT_CONFIG, index=0) and that's nearly self-documenting :-)

So, I spent an evening understanding the device (and generic USB) parts from David Wilson's work, and working backwards to python code based on Scott Weston's work. use_launcher_0.py is the "zeroeth" version, most of which is useful for playing with in an interactive shell.

Next step: it turns out that the DreamCheeky relies on the driver for "safety" features; when you hit the edge of the range of motion, the device keeps grinding until you make it stop. It does, however, report the value of the four limit switches via handle.interruptRead(endpoint.address, 8), so you just have to check that every so often while you're commanding it.