Emulating a Joystick

[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.

[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?

[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.

[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.

[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.

[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.

[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.