Emulating a Joystick

[Geek 2.0]

As far as I understand, the FIRST Control System requires joysticks to use the DirectInput API. I know it would be an extremely complex task, but would anyone know how I could go about making an external microcontroller look like a joystick to the driver's station? My point being I want to be able to communicate via USB with the driver's station, sending digital and analog data, NOT going through the FirstTouch I/O board (because of data size/speed limitations). Anyone know where to start?

[EricVanWyk]

Actually, you are looking to emulate the HID Joystick class. DirectInput is just Microsoft's method of reading from this class.

[Geek 2.0]

Oh! I thought DirectInput was on both sides, the firmware and the software. I've done a lot of looking at HID, but I still can't for the life of me find a good resource for learning it. Is there a better way than reading the 200 page USB documentation?

[heydowns]

Originally Posted by Geek 2.0

As far as I understand, the FIRST Control System requires joysticks to use the DirectInput API. I know it would be an extremely complex task, but would anyone know how I could go about making an external microcontroller look like a joystick to the driver's station? My point being I want to be able to communicate via USB with the driver's station, sending digital and analog data, NOT going through the FirstTouch I/O board (because of data size/speed limitations). Anyone know where to start?

Our team did this last year, with the blue box, because we ran out of I/O for our operator interface console (pic: http://rollingthunder.smugmug.com/20...23_SWiHf-M.jpg)

We used this Microchip board (PIC18F87J50) as a basis:
http://www.microchip.com/stellent/id...ame =en532010

We then wrote firmware for it to talk USB HID (their SDK comes with an example that acts like a mouse - we changed to act like a gamepad).

Caution, however - this little device was a pain to wire to because of the pin-out.

Here's a pic of the underside of our operator console, held by the student that put it together; the pic device is on the right in the picture:
http://rollingthunder.smugmug.com/20...50_LMRhS-M.jpg

[EricVanWyk]

Originally Posted by heydowns

Our team did this last year, with the blue box, because we ran out of I/O for our operator interface console (pic: http://rollingthunder.smugmug.com/20...23_SWiHf-M.jpg)

We used this Microchip board (PIC18F87J50) as a basis:
http://www.microchip.com/stellent/id...ame =en532010

We then wrote firmware for it to talk USB HID (their SDK comes with an example that acts like a mouse - we changed to act like a gamepad).

Caution, however - this little device was a pain to wire to because of the pin-out.

Here's a pic of the underside of our operator console, held by the student that put it together; the pic device is on the right in the picture:
http://rollingthunder.smugmug.com/20...50_LMRhS-M.jpg

Bonus Points for Awesomeness.

Can you please post the code you wrote?

[Greg McKaskle]

Just to clarify, the I/O board and joystick data are sent in the same packet to the robot. Meaning that while you will have additional fields, they are all read at 50Hz -- even the joystick buttons and axes.

Greg McKaskle

[Geek 2.0]

I realize that it'll still update at 50Hz, but the reason I need to have faster updating is because I can send MORE data. If you do a parallel bitbang, the more data you have the longer it takes, to a pretty ridiculous level. Thanks for the help, I'll take a look at that. And yes, code examples would help!


Edit: I'm thinking about using V-USB... It'll take some digging around to figure out how to work it, but I think it'll do what I need fairly well.
http://www.obdev.at/products/vusb/index.html

[heydowns]

Originally Posted by EricVanWyk

Bonus Points for Awesomeness.

Can you please post the code you wrote?

I'd like to, but we based it on code provided by MicroChip, and the license for that is pretty unclear as to if posting it publicly would be ok.
I'll gladly provide our changes to their base code to anyone interested though. Just PM me.

[jhersh]

Originally Posted by Geek 2.0

I realize that it'll still update at 50Hz, but the reason I need to have faster updating is because I can send MORE data. If you do a parallel bitbang, the more data you have the longer it takes, to a pretty ridiculous level. Thanks for the help, I'll take a look at that. And yes, code examples would help!


Edit: I'm thinking about using V-USB... It'll take some digging around to figure out how to work it, but I think it'll do what I need fairly well.
http://www.obdev.at/products/vusb/index.html

I'm REALLY curious what it is that you are hooking up to. What is it that can't be wired directly to the Cypress I/O board?

Don't get me wrong... I'm not trying to discourage you from making a USB joystick emulator, cause that's a cool project, but I also want to make sure you are aware of all your options.

Cheers!
-Joe

[Geek 2.0]

We (being a few students independently) have been designing and prototyping for a modular button box. All the modules communicate to the master module over I2C, which (in some way) communicates with the driver station. There are a few reasons why we are doing this. First of all, it is reusable. Whether we use it on a FIRST robot, an off-season robot, or anything for that matter, we control the data. So if FIRST changes something, we only need to make minimal changes to reuse the system. Also, if a module goes "bad" at a competition, we can always just pop it out and throw a new one in. We can customize HOW the data is obtained, and what from (like an SPI device, or a device with multiple analog/digital outputs, eg. blackberry trackball). We aren't limited by the number of analog/digital I/O pins that FIRST decides will be enough. Each module has 4 analog/digital inputs. There are going to be about 12 modules. Also, each module has a unique address. So if you want to rearrange the board, you don't need to reprogram.

That's the "short" version of what we're planning.

[Tom Bottiglieri]

Is the source for FIRST's default implementation of the Cypress PSoC board available anywhere? Is it against the rules to modify the default firmware on that board?

There is no reason you can't set up a simple system that uses an I2C controller and HID comms on the PSoC board. If we are not able to get our hands on the default firmware, you can check out this article for a start: http://www.cypress.com/?rID=39404

[Geek 2.0]

Originally Posted by TomBot

Is the source for FIRST's default implementation of the Cypress PSoC board available anywhere? Is it against the rules to modify the default firmware on that board?

There is no reason you can't set up a simple system that uses an I2C controller and HID comms on the PSoC board. If we are not able to get our hands on the default firmware, you can check out this article for a start: http://www.cypress.com/?rID=39404

Actually, it is against the rules. I had the same idea, but for some reason they want to keep it locked down. See rule <R60N>


Another question... Is there an application or something that I can use to see the output of a usb joystick? I need something for testing, and I don't have any way of telling what the joystick is actually outputting.

[EricVanWyk]

Originally Posted by TomBot

Is the source for FIRST's default implementation of the Cypress PSoC board available anywhere? Is it against the rules to modify the default firmware on that board?

There is no reason you can't set up a simple system that uses an I2C controller and HID comms on the PSoC board. If we are not able to get our hands on the default firmware, you can check out this article for a start: http://www.cypress.com/?rID=39404

Unfortunately, it is against the rules to modify it. Hopefully we'll get more flexibility in that department next year. Although I wish we had the capability, I can half see the GDC's point - there are a lot of new toys this year.

However, it is legal to use just about anything else you want in this capacity.

[Tom Bottiglieri]

Originally Posted by Geek 2.0

Actually, it is against the rules. I had the same idea, but for some reason they want to keep it locked down. See rule <R60N>


Another question... Is there an application or something that I can use to see the output of a usb joystick? I need something for testing, and I don't have any way of telling what the joystick is actually outputting.

Maybe something like this? http://sourceforge.net/projects/usbsnoop/

Also, R60N seems kind of silly. According to the rules, I can buy or build any HID compliant USB device to hook up to the driver's station, but I cannot use the FirstTouch (which is most likely a safer/easier avenue than building any custom electronics). Why the draconian restriction?

[Joe Ross]

Originally Posted by Geek 2.0

Another question... Is there an application or something that I can use to see the output of a usb joystick? I need something for testing, and I don't have any way of telling what the joystick is actually outputting.

LabVIEW makes that very easy if you have HID working. Otherwise, you need something like what Tom linked.