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?
Actually, you are looking to emulate the HID Joystick class. DirectInput is just Microsoft’s method of reading from this class.
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?
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/2008-2009-FIRST-Robotics/Build-Season/Week-6-20909-21509/1010689/475664423_SWiHf-M.jpg)
We used this Microchip board (PIC18F87J50) as a basis:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=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:
Bonus Points for Awesomeness.
Can you please post the code you wrote?
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
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.
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.
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
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.
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.
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.
Maybe something like this? Usb Sniffer for Windows download | SourceForge.net
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?
LabVIEW makes that very easy if you have HID working. Otherwise, you need something like what Tom linked.
If you’re using Windows XP, go into the Control Panel and select Game Controllers (under Printers and Other Hardware if you have category view selected). It will show a list of any joysticks or gamepads, and if you click on one and click Properties it will show you the axes and buttons and their states in real time.
I believe you would be disappointed at the very next step if R60N didn’t exist and you were to try use the Cypress board for what you are talking about. You would find out that the USB interface has nothing to do with the PSoC and that Cypress does not release the code for the processor that does. The First Touch Kit 3 board cannot implement HID (given the publicly available resources). The interface had to be implemented in a very non-generic way and the other end of this binary interface (the Driver Station software) you have no access to change. Because of this, allowing you to customize the firmware would gain rather little flexibility compared with the opportunity for frustration and failure. I don’t believe the idea was simply to play Draco for the sake of it.
However, I could send the data to the FirstTouch board over something like SPI and totally avoid using USB HID, which would be amazing in this case because I’m getting frustrated trying to understand how HID descriptors work.
On another note… Anyone know why WPILib doesn’t have sliders for HID devices?
What I was referring to with the binary interface is that if you come up with some new data to send from som SPI or I2C source, there is no field going back to the robot for you to put that data into. You would have to replace, for instance, some of the analog input channels or something. In any case, it wouldn’t be clean or supportable.
Not sure what you’re talking about here. Can you be more specific or elaborate? Are you using WPILib in LabVIEW, I guess? There is no HID on the robot, so are you talking about the dashboard? Please be more detailed.
You must talk HID to the Classmate. Downstream of that you can do whatever you want. As Joe said, if you want to use the FirstTouch board (which you cannot, according to the rules) you would have to box up all of your data into the fields that already exist.