I can't believe that a usb controlled rocket launcher hasn't fallen into the hands of a programmer before. So I'm determined to make this work. I have a usb data sniffer and got a bunch of data for each of the rocket launcher's movements, but don't know how to translate that into libusb calls.

I see the usb_control_msg function in libusb and I think I can work that out, but I don't know what the "Class-Specific Request" stuff is... and it looks important. Can someone help me interpret these?

Here is the data I gathered for moving the launcher arm up. Under the "Class-specific request" section where the 8 bytes of data have a 1 for the first byte signify the up movement. down is 2, right is 4 and left is 8.

138321: Class-Specific Request (DOWN), 17.12.2006 22:15:36.6081536 +0.0
Destination: Inrterface, Index 0
Reserved Bits: 34
Request: 0x9
Value: 0x200
Send 0x8 bytes to the device

00 00 00 00 00 00 00 00 ........

138322: Control Transfer (UP), 17.12.2006 22:15:36.6081536 +0.0
Pipe Handle: 0xff8e65c8

00 00 00 00 00 00 00 00 ........
Setup Packet
21 09 00 02 00 00 08 00 !.......
Recipient: Inrterface
Request Type: Class
Direction: Host->Device
Request: 0x9 (Unknown)
Value: 0x200
Index: 0x0
Length: 0x8

138323: Class-Specific Request (DOWN), 17.12.2006 22:15:36.6081536 +0.0
Destination: Inrterface, Index 0
Reserved Bits: 34
Request: 0x9
Value: 0x200
Send 0x8 bytes to the device

01 00 00 00 00 00 00 00 ........

138324: Control Transfer (UP), 17.12.2006 22:15:36.6081536 +0.0
Pipe Handle: 0xff8e65c8

01 00 00 00 00 00 00 00 ........
Setup Packet
21 09 00 02 00 00 08 00 !.......
Recipient: Inrterface
Request Type: Class
Direction: Host->Device
Request: 0x9 (Unknown)
Value: 0x200
Index: 0x0
Length: 0x8

138329: Class-Specific Request (DOWN), 17.12.2006 22:15:36.6482112 +0.0100144
Destination: Inrterface, Index 0
Reserved Bits: 34
Request: 0x9
Value: 0x200
Send 0x8 bytes to the device

00 00 00 00 00 00 00 00 ........

138330: Control Transfer (UP), 17.12.2006 22:15:36.6482112 +0.0
Pipe Handle: 0xff8e65c8

00 00 00 00 00 00 00 00 ........
Setup Packet
21 09 00 02 00 00 08 00 !.......
Recipient: Inrterface
Request Type: Class
Direction: Host->Device
Request: 0x9 (Unknown)
Value: 0x200
Index: 0x0
Length: 0x8

Thanks so much,
Jim

Have you considered this for getting more help on this subject

allowing links

okay...now that i can use links in my post

http://www.beyondlogic.org/usbnutshell/usb1.htm

the above link has an overview of the USB standard which may be of use to you. I have been working on the same project for a few hours and am finding that my only block at the moment is that the documentation for libusb is so terrible that it seems as though randomly hitting buttons until something works would be almost as effective.

okay...i can control the thing now. let me know if you want the code.

I'm sure that would help. What device are you trying to make work?

I thought about scraping the libusb program and going for a device driver and noticed that the kernel functions were pretty much the same. I was able to find several documents on creating usb device drivers. This also lets me keep track of the device so I don't have to reset it before every use to put it in a "known" state and position... We are talking about nerf-like rockets... I need precision.

If I had the libusb program, I'm sure I could convert it to a driver.

Thanks for your help. Let me know how I can peek at the code.

Jim

I'll post the source code and an explanation this afternoon. Look for it at

http://www.amctrl.com/rocketlauncher.html

and by afternoon i mean before lunch. its up now

Wouldn't you know I didn't bring my rocket launcher home... I have to wait until tomorrow to try it out. I'll be shooting my co-workers yet!

I think my problem might have been a bad vendor ID. I read it 3 times from that stupid sniffer, but it might have been pointed at a device between us. I also had the index value wrong for the first and third packet. Otherwise I think the rest looks pretty much the same. Well, I won't be getting my work done tomorrow.

Thanks for your help.

Jim

ok, it doesn't work for me. It fails when trying to claim the interface. Do you have any ideas? Do I need to release the device from a driver? I tried the libusb call to usb_detach_kernel_driver_np but it fails as well.

I also noticed that my vendor id was a hex 1941 which is the same as your decimal 6465... so the only difference was the index value. That and I can't claim the interface.

Do you have the device on a USB hub?

I have read numerous reports that the device does not like to work unless it is physically plugged into the ports on the back of the machine. Even ports on the front tend to be problematic. There doesnt seem to be a solution to that problem.

If not, then I have no idea. My understanding of USB is poor at best and the first time I tried to claim the interface I had no issues so I moved onto other things. I'll look into it bit more.

On a final note, I have always been running the program as root. This shouldn't affect anything, though, as the whole point of libusb is to allow non-root users tha ability to use usb devices.

-edit-> what error do you get when claiming the interface?

ok, I have success... sort of. It does work as root when plugged into the machine itself. As a regular user I get a -1 returned from the call to claim the interface. I'm still trying to figure out where the "-EBUSY" and "-ENOMEM" that libusb's api talk about are defined.

I guess if I'm just going to turn around and do a kernel driver for this, it might just be a moot issue. This is cool though.

Jim

well...the root hub thing seems to be a manufacturing flaw, so there isnt really anything to about that.

My research (e.g. running strerror() on +1) indicaties that a return of -1 means that there is a permissions error. I don't know which devices are USB, but I would look there and make sure that non-root users have usb read and write permissions.

-ADDENDUM-

if you have usbfs enabled in your kernel, you can set permissions in /proc/bus/usb/

I noticed (at least on Fedora Core 6) that when I plug in the rocket launcher the kernel assigns a driver to it. I have to release the kernel driver with the usb_detach_kernel_driver_np function.

Regardless for whatever reason it assigns the user/group for usb devices to root/root with a mode of 644 and have not had the chance to research how to make it respect my authority. I assume this is the reason root needs to be the one to claim the interface. I hate it when my computer tries to think for me. This is why I don't like Windows.

I got my program working, mostly. I was just going for movement first and will work on firing (charging seperate from firing) and a reset function to put it into a known position. Then I'll play more with a kernel driver.

I noticed that the control messages with the index of 1 and the all-0 message is not needed and actually errors, so I changed mine to send nothing to the device until you tell it to and then sends all 0 message, the command, then all 0 message all with an index of 0.

Very cool, thanks again for your help.

Jim

hi there!
i'm stucked too with the claiming of the device - i receive -16 as return code - any ideas?
it's the same with user or root permissions.

many thanks!

-> update: was able to implement the detach-thingy and was finally able to claim the device as root. but now, the movements & everything is not working...