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
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/index.php?_a=viewProd&productId=33
which behaves like a standard joystick.
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 [strike]stupid[/strike] 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.
What terrible suggestions:mad:
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.
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.
I just stumbled upon this as well, and think it will be our best option, thanks!
… 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.
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.
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…)
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.
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.
It would be nice to test it in a field environment, but why wouldn’t putting it on blocks and making sure the arm, etc, are cleared not be enough (and run it through a practice round)?
Sure, it could potentially be dangerous, but as long as no one’s in the way and it can’t move, it’s just as good (they shouldn’t have an insanely wide reach, anyway).