Emulating a Joystick

[Dave Flowerday]

Originally Posted by Geek 2.0

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.

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.

[jhersh]

Originally Posted by TomBot

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?

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.

[Geek 2.0]

Originally Posted by jhersh

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?

[jhersh]

Originally Posted by Geek 2.0

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.

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.

Originally Posted by Geek 2.0

On another note... Anyone know why WPILib doesn't have sliders for HID devices?

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.

[Tom Bottiglieri]

Originally Posted by Geek 2.0

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.

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.

[virtuald]

For my senior design project 2 years ago we used one of the Cypress PSoC boards to communication via USB. It was reasonably easy to setup once you figured out how their design workflow was laid out.

[jhersh]

Originally Posted by virtuald

For my senior design project 2 years ago we used one of the Cypress PSoC boards to communication via USB. It was reasonably easy to setup once you figured out how their design workflow was laid out.

The problem here is that the First Touch Kit 3 board does not have the USB connector wired to the PSoC, so you can't use the USB IP that is in the PSoC. The USB connector just goes to a SWD interface chip for debugging and programming the PSoC. The board was not designed to expose USB to the application on the PSoC. We basically had to go way outside the scope of the design to make it work for FIRST's requirements.

[Geek 2.0]

Originally Posted by jhersh

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.

USB HID supports analog values that are not one of the 6 axes (called Sliders), meaning you can send more than 6 analog values. The WPILib does not check joysticks for these. I would assume it's to keep the packet size from getting too large, but I'm not sure. I was hoping to use USB because I originally thought it wouldn't limit the amount of data we can send, but apparently it still does (6 analogs and 12 digitals).

[Greg McKaskle]

Not to discourage your interfacing project here, but the enhanced I/O API for the cypress is packed with goodies. I saw a video of a team just a few days ago who made their own Wii-mote from the cypress board and were tilt driving.

Out of curiosity, what is it that you want to connect that requires this amount of interfacing?

Greg McKaskle

[jhersh]

Originally Posted by Greg McKaskle

Not to discourage your interfacing project here, but the enhanced I/O API for the cypress is packed with goodies. I saw a video of a team just a few days ago who made their own Wii-mote from the cypress board and were tilt driving.

Out of curiosity, what is it that you want to connect that requires this amount of interfacing?

Greg McKaskle

http://www.chiefdelphi.com/forums/sh...4&postcount=10

[Geek 2.0]

Originally Posted by Greg McKaskle

Not to discourage your interfacing project here, but the enhanced I/O API for the cypress is packed with goodies. I saw a video of a team just a few days ago who made their own Wii-mote from the cypress board and were tilt driving.

Out of curiosity, what is it that you want to connect that requires this amount of interfacing?

Greg McKaskle

I didn't see all that much in the enhanced I/O. I understand that there are a lot of goodies ON the board, and we COULD utilize them, but the point is that we're looking to communicate to the robot from our control system, and the cypress does not make a good intermediate device.

[jhersh]

Originally Posted by Geek 2.0

I didn't see all that much in the enhanced I/O. I understand that there are a lot of goodies ON the board, and we COULD utilize them, but the point is that we're looking to communicate to the robot from our control system, and the cypress does not make a good intermediate device.

There isn't any reason something like this couldn't be supported, it simply wasn't a use case I considered to be useful to most teams. Perhaps for next year something like this could be. Can you describe the requirements you would have? Would it be helpful if all it did is interface with your other circuit and did not expose any other features?

[Geek 2.0]

Originally Posted by jhersh

There isn't any reason something like this couldn't be supported, it simply wasn't a use case I considered to be useful to most teams. Perhaps for next year something like this could be. Can you describe the requirements you would have? Would it be helpful if all it did is interface with your other circuit and did not expose any other features?

That would be nice, but I realize that that isn't the best solution for all teams. I think some communication (like SPI, I2C, UART, etc.) would eliminate any bottlenecks in the design.