Numpad on Driver Station?

[Us3rNam3]

would it be possible to use a usb numpad as controller input? If not what would be a suitable substitute for the maximum amount of buttons?

Please and Thank you

[Mark McLeod]

The Driver station software will not recognize anything other than an HID joystick/game controller and the Cypress I/O board.
A numpad will not work.

The Cypress board gives you a lot of input choices, or you can purchase http://www.estoprobotics.com/estore/...d&productId=33
which behaves like a standard joystick.

[sjspry]

You can set up a custom input scheme if you don't mind doing some programming. In fact, this way you could use practically any USB peripheral -- easiest, however, would be a keyboard or numpad which requires no libraries.

All the rules seem to have to say about this is that all communications must pass through the driver station. And, intuitively, you should only be able to use your custom controls when the robot is active, in teleoperated mode.

EDIT:

I stand corrected, as per rule 75.

The Driver Station software provided on the FRC website (www.usfirst.org/frc/kitofparts) is
the only tool permitted to collate driver/operator inputs and communicate them to the
ROBOT. The Driver Station software must be revision 01.05.11.00 or newer.

This seems to imply you could send automated information to the cRIO bypassing the driver station. You could even lawyer it, and provide a layer of abstraction and cause a program to send automated information to the cRIO based on operator input! I somehow don't think they'll go for that, though.

Either way, this seems like a pretty stupid misinformed rule to me. Sure, you want everything to shut down when you tell it to, but assuming the driving code is within the predefined functions (except the disabled[...] ones), nothing bad would happen. Even with Murphy's Law, I doubt anyone is that unobservant.

You could perhaps demonstrate safety to an inspector (or just not tell them about it), but I wouldn't rely on it. Alternatively, http://headsoft.com.au/index.php?category=vjoy. That's probably the best option.

[Mark McLeod]

What terrible suggestions
Cheating and ignoring the rules to your own benefit or because you just don't feel like it, is not recommended.
It builds the wrong kind of character...

In these forums please work on making valuable contributions I'm sure you're capable of, that benefit impressionable readers (not just the posters) who don't realize your bad advice could get their robot disqualified, their reputation sullied, and their season ruined.

[Vikesrock]

Originally Posted by sjspry

This seems to imply you could send automated information to the cRIO bypassing the driver station.

In addition to flaunting the rules, what purpose would be served by sending automated information from an operator console laptop to the cRIO. Why not just store the information on the cRIO in the first place?

[Alan Anderson]

Originally Posted by Vikesrock

In addition to flaunting the rules, what purpose would be served by sending automated information from an operator console laptop to the cRIO. Why not just store the information on the cRIO in the first place?

Here's a serious answer: it's a lot more convenient to modify a file on the laptop. You wouldn't have to power up the robot and have it online in order to make changes.

[Lightfoot26]

Originally Posted by Mark McLeod

or you can purchase http://www.estoprobotics.com/estore/...d&productId=33
which behaves like a standard joystick.

I just stumbled upon this as well, and think it will be our best option, thanks!

[sjspry]

Originally Posted by Vikesrock

In addition to flaunting the rules, what purpose would be served by sending automated information from an operator console laptop to the cRIO. Why not just store the information on the cRIO in the first place?

... That was a serious suggestion (also, I wasn't flaunting the rules) ...

It's been said before about how hard it is to convey tone through text. And yeah, it's still hard. Regardless of the tone of my post, however, there is no reason which says I must respect the rules, only I must follow them: If I've read them and considered their purpose, I believe I have a valid claim to calling them ridiculous.

I would still suggest trying the virtual joystick software. In my opinion, it beats having to buy new hardware. Another thing I have a problem with is having to use the input devices they tell me to. I can understand them wishing all driver input to go through the station (though, as I said, it doesn't necessarily need to to remain safe), but restricting it to one type of input is absurd and restrictive.

[Vikesrock]

Originally Posted by sjspry

... That was a serious suggestion (also, I wasn't flaunting the rules) ...

It's been said before about how hard it is to convey tone through text. And yeah, it's still hard. Regardless of the tone of my post, however, there is no reason which says I must respect the rules, only I must follow them: If I've read them and considered their purpose, I believe I have a valid claim to calling them ridiculous.

I would still suggest trying the virtual joystick software. In my opinion, it beats having to buy new hardware. Another thing I have a problem with is having to use the input devices they tell me to. I can understand them wishing all driver input to go through the station (though, as I said, it doesn't necessarily need to to remain safe), but restricting it to one type of input is absurd and restrictive.

And I was asking a serious question in response. Alan provided a perfectly valid answer that makes sense.

You can use any USB input device you want. You just have to write the custom USB driver to make it look like a HID joystick or gamepad to the Driver Station software.

[sjspry]

Originally Posted by Vikesrock

And I was asking a serious question in response. Alan provided a perfectly valid answer that makes sense.

You can use any USB input device you want. You just have to write the custom USB driver to make it look like a HID joystick or gamepad to the Driver Station software.

And I was saying there's no reason why that should need to be done.

[Vikesrock]

Originally Posted by sjspry

And I was saying there's no reason why that should need to be done.

So who should be writing the code to support arbitrary input devices if not the teams? How would you propose supporting arbitrary input devices while keeping the DS software closed source?

Note: This is a serious question, not sarcastic.

[sjspry]

Originally Posted by Vikesrock

So who should be writing the code to support arbitrary input devices if not the teams?

This has nothing to do with code-writing. If I want some new input device, I have to buy something to use it, and probably some new hardware. If they'd remove rule 75, there'd be no problem (in relation to this post, he'd be able to use his numpad). Just have an inspector verify that nothing has a chance to move during the disabled stage (and no one would probably set it up this way, due to obvious reasons...)

[Vikesrock]

Originally Posted by sjspry

That's my point. If I want some new input device, I have to buy something to use it, and probably some new hardware.

A device driver is software that you write. You don't have to buy anything as far as I am aware.

[sjspry]

Originally Posted by Vikesrock

A device driver is software that you write. You don't have to buy anything as far as I am aware.

If he wanted to use a numpad/keyboard, he'd have to buy a USB encoder and interface it to the encoder. And perhaps I wish to pre-interpret my USB device's data? There's no provisions for sending it to the robot after that.

[basicxman]

Originally Posted by sjspry

Just have an inspector verify that nothing has a chance to move during the disabled stage (and no one would probably set it up this way, due to obvious reasons...)

Even if you could find an inspector with the time, you would need a field to show him/her that. Pretty much every regional I've ever been to, the practice and competition fields are booked quite solid.