Using Switches on the Operator Interface

I know it has been done many times. I know it’s often very handy. But how do you install switches and buttons on the OI? I want my robot to dump balls into the corner goals when I push a button or flip a switch. The OI, unlike the RC, does not seem to have convenient digital input connections, only serial ports. How, then, would I connect something like a three-way switch (to control a spike, for instance) to the OI? Please don’t tell me to use the buttons on the joysticks. I know how to do that. I’m interested in wiring an actual switch or button to the OI. I know lots of people have done it, but how do you do it?

Use the pinout of the serial port to make your own connector (put a switch between ground and one of the buttons).

See pages 7-10 of http://www.ifirobotics.com/docs/oi-ref-guide-11-21-05.pdf.

Using a custom control box in addition to the drive joysticks is a great idea, we are also building one at the moment.

The pinout diagrams for the OI ports are available from IFI in the OI reference guide (they have not changed since 2005/05 I beleive) - http://www.ifirobotics.com/oi.shtml

The pinout chart gives the pin number for the OI digital and analog inputs, as well as the LED feedback drivers, and the IFI aliases for those inputs/outputs.

You will need 15 pin solder cups [male and female] and some basic wiring skills, but its quite simple to do. For switches - wire them between the input pin and any ground pin of that port.

good luck, have fun.

So as not to confuse the reader, the 15 pin connectors on the OI are gameports not serial ports. They are compatible with the oldstyle game port joysticks found on PC’s from long ago. (In computer years, that is.)

Yea, I still have one of those joysticks. I think I might use it for the robot actually. Will joysticks that did not come in the kit work for controlling the robot? It’s not joystick-dependent, is it?

Can someone please give me a less technical explanation of what everyone said about the pinouts and so on? I may be an experienced computer programmer, but I am fairly close to a newbie at robot programming. I’m not sure I know anything about the pins in the gameports.

A gameport joystick will usually work, however there exist some non-standard implementations that may not function quite as expected. In general, any simple 2-axis, 2-button gameport joystick will work.

The 15 pin connector that goes to a joystick - each pin corresponds to a particular function in the program. The document linked to earlier has the pinout description of what each does. To use a digital switch, for example, connect one terminal of the switch to ground and the other to one of the pins that corresponds to, say, p1_sw_trig (assuming your switchbox is plugged into port 1).

Then, in the program, whenever you access p1_sw_trig, you are actually getting the value of your switch.

Okay, that works. Now what if I have a multi-way switch? Can I plug it into the pin corresponding to p4_x, let’s say, under port 4, and get a value from 0 to 255, where 0 will be one position, 1 will be another, and 2 will be another? And how will the switch know which position should be 0 and which should be 2? Or is it going to return 1,0, and -1, thus throwing my unsigned char data type off balance?

Well, p4_x is an analog variable, so you’d have to rig up some resistors in varying amounts to get different values for the switch positions. (I’m not entirely sure on the values of the resistors, so I won’t guess.) Alternatively, you could wire it to two different digital inputs.

So, in a word, to get a binary switch working, I can simply wire it to the right pins, but to get a 0-255 thing working (analog), I’m actually going to have to build resistors or get potentiometers?

Correct.

Well, I think I’ll just wire several binary switches and ask the computer to compute values using binary. Like if I want to select between 4 things, I’ll convert input from 2 binary switches to a number from 0-3, and attach a printed label sheet to the operator interface so my team members can know what’s going on. No problem, I guess. Binary math is easy.

Binary math may be easy, but I’d avoid it on the OI.

Last season, I was field coach for 1293 during their short (two-match, if I recall) reign as #1 seed at Palmetto. I wasn’t even doing the driving, and my mind had a million things going (time remaining, which goals were ours, which goals needed to be ours, is anyone in the loading zones, et cetera). Trying to throw in much of any sort of math would’ve had dire consequences.

The general thing you’ll see on most OI panels is that they’re simple. A driver should be able to judge what’s going on by touch or a brief glance. This, in turn, gives them more time to figure out how to do more important things, like moving around those two 120-pound hunks of machinery blocking your path to the goal. (Of course, if your two switches corresponded to something visual on the robot, such as a left and right ball sucker, then by all means go for it.)

That said, binary is perfectly fine on the robot side for things like setting an autonomous mode. Even the most tense field coach in the world can figure that sort of thing out.

Hope this helps!

Yes - simple is really good! :slight_smile:

Last year, we decided that to make driver reaction faster, we would only use momentary large (coin op arcade-style) push buttons on our operator interface (besides the joysticks of course). We would then use code to make them emulate toggle switches. (Such as hit it once to start a function, and hit it again to stop it).

This may not be perfectly suited for every application, but I can tell from experience (I was the co-driver for my team last year), that not having to look down at the button when you push it really helps. As you can see, our 2005 operator interface was about as simple at you could get. http://www.simtropolis.com/idealbb/images/smilies/10.gif

http://www.chiefdelphi.com/media/img/b29/b2914f88985067c3bf2983872d3cdcfc_m.jpg](http://www.chiefdelphi.com/media/photos/8571)

Well, I plan on having a driver and a switch-pushing person. But the system is very intuitive I think

Switch 1 - Conveyor belt on/off
Switch 2 - Conveyor belt forward/backward. If Switch 1 is open, Switch 2 does nothing and conveyor belt does not move.
Switch 3 and 4 - create a 0-3 number for setting autonomous mode. Set before match.

Why not incorperate Switch 1 and 2 into a single switch? You can use a SPDT (or would it be SPTP?) toggle switch with a center neutral position. That way, when you push the switch up, it goes forward. When you put it in the down position, the conveyor goes in reverse. And when you put it back to the center position, it goes off. This would simplify things for the drivers. :slight_smile:

Here are some pictures of the switches I’m refering to:

http://www.switchchannel.com/products/rocker/orl/ORL31ABB_pho.JPG http://www.switchchannel.com/products/rocker/dr/DR32EBB_pho.jpg

If I use a three way switch, I even have one right now, how would I wire it?

You should be able to do this by grounding the center pin, and then connecting each of the two sides to a different wire on the joysticks - such as p1_sw_aux1 and p1_sw_aux2. If you get leave the switch in the center, there will be no signal. If you move the toggle switch in one direction, you get signal back in either the aux1 or aux2. If you move the toggle switch in the other direction, you will get back a signal from the other aux port.

Example:

       /-\
/-------------\
|   Toggle    |
|   Switch    |
+-------------+
   |   |   |
   1   2   3

Wire #1 contact to p1_sw_aux1, wire #2 to ground, and wire #3 to p1_sw_aux2.

Awesome. Thanks, I’ll try that.