Robocoach signals loophole?

[jacobhurwitz]

The two rules covering robocoach signals are G01 and G49. According to G01, "The ROBOT may react to no more than four distinct external commands provided by the ROBOCOACH." Yet G49 clarifies this: "If the ROBOCOACH will be providing signals to the ROBOT, then prior to the start of each MATCH the ROBOCOACH must place a Signaling Card in the ROBOCOACH STATION. The Signaling Card shall be a 3-inch by 5-inch card listing the one to four actions that can be commanded by the ROBOCOACH."

Notice the varying language between the rules: four commands versus four actions. A command is self-explanatory: for example, the robocoach can send a 1, 2, 3, or 4. However, the rules never explain what an action is. Is an action something physical or something in the program?

Physical actions could include driving straight, turning left, or a series of actions (raise arm, hit ball, then lower arm). Programming actions could be adding a number to a register, or adding a number to a stack or queue. If you interpret the rules to mean that the robocoach can command four different programming actions, then those four programming actions can command more than four different physical actions. For example, you could create 16 physical actions by pressing two buttons in sequence, still using only four programming actions.

Is this loophole valid, or do the rules imply that the four actions must be physical?

[jgannon]

All restrictions that I have seen (<G01>, <G49>, <R65>) restrict the behavior of the signaling device, not the software on the robot controller.

[paulcd2000]

i think you may be overanalyzing. I think what they mean is that there can only be four commands. E.G. Go left, go forward, pick up the ball (not add to a variable or change the stack). YOu can't, for example, use combinations of buttons to make (2^4)-1 (because no buttons can't be a command) commands.

EDIT: i would believe that you can't have sequences. I think the spirit of the rule is that there can only be four commands.

[jacobhurwitz]

I hadn't read section 8 yet. After someone above mentioned R65, I read it and saw this clause that signaling devices shall "not use changes in the signal states to encode or transmit larger messages (e.g. Morse code)." I guess this means that the "loophole" wouldn't work.

[jgannon]

Originally Posted by jacobhurwitz

I hadn't read section 8 yet. After someone above mentioned R65, I read it and saw this clause that signaling devices shall "not use changes in the signal states to encode or transmit larger messages (e.g. Morse code)." I guess this means that the "loophole" wouldn't work.

I still don't know that this is true. That's a restriction on the capabilities of the signaling device, isn't it? I don't see any restrictions whatsoever on the behavior of your software, other than for safety reasons.

[Binome]

If you were really clever, you could implement your four instructions as something like "Virtual Button 1, Virtual Button 2, Next Button Set, Previous Button Set" Technically that would be 4 instructions, but would give you practically unlimited results.

[SgtMillhouse648]

It says four actions, aka pressing button, but can you repeat those actions multiple times like one button for drive straight one for turn left etc, pretty much driving with the remote. Is this a viable option? Also, is it possible for the Robocoach to have something such as a green light? Something the robot can use to find it's position to drive around the field?
Malhon

[teamchallenger]

It is never a good idea to get cute this early in the process. There will be revisions in the rules and clarifications as we go along. I suggest that you think simple so that you can come up with a robo-coach signaling device that will be immune to environmental impact. Worry about more than four simple commands AFTER you have that issue sussed

[Tomasz Bania]

Originally Posted by SgtMillhouse648

It says four actions, aka pressing button, but can you repeat those actions multiple times like one button for drive straight one for turn left etc, pretty much driving with the remote. Is this a viable option? Also, is it possible for the Robocoach to have something such as a green light? Something the robot can use to find it's position to drive around the field?
Malhon

Question: How's your robot going to see your light, or the 2 12" circle-covered balls as mentioned (Forgot where)

[Kevin Sevcik]

Originally Posted by jgannon

I still don't know that this is true. That's a restriction on the capabilities of the signaling device, isn't it? I don't see any restrictions whatsoever on the behavior of your software, other than for safety reasons.

Originally Posted by Binome

If you were really clever, you could implement your four instructions as something like "Virtual Button 1, Virtual Button 2, Next Button Set, Previous Button Set" Technically that would be 4 instructions, but would give you practically unlimited results.

Check <R69>. You're not allowed to react to more than four commands, and the robot isn't allowed to dynamically change the command set during the match. I think the signalling card is for you to list what physical actions, specific state changes, etc., your four buttons will have, and they'd better do those exact things.

[TomZ]

I was thinking that if the IR board can recognize only 4 different commands, could you send strings to it?
i.e.
#1,# of feet to drive forward
#2,(#1(-) or #2(+)),# of positions to move the arm ( if you had presets on the arm.

[jgannon]

Originally Posted by Kevin Sevcik

Check <R69>. You're not allowed to react to more than four commands, and the robot isn't allowed to dynamically change the command set during the match. I think the signalling card is for you to list what physical actions, specific state changes, etc., your four buttons will have, and they'd better do those exact things.

The question is still what defines a command. Can two of my commands be "increment variable c" and "if c=1, do this, if c=2, do that, if c=3, do the other thing"? What about "pwm01 = c"? It seems like if the intent is to be like what Dave demonstrated (two buttons turn, one button goes straight), then there will need to be a lot of clarification, and a lot of auditing to make sure teams are playing legal.

[RyanW]

Well, in that case, what about something like "Move the arm of the robot to its other position"? Or (with Omniwheels) "Change direction of motion 90 degrees counterclockwise"? Each of these represents a fixed change from the current state of the robot, and would involve transmitting only one bit of information, but this could also be seen as "doing more than one thing".

EDIT: To everyone who keeps asking,
You can have no more than four commands being sent (G01/R69). That means no binary, no Morse code, no tapping the button really fast to make it work as a PWM input, etc.

[jacobhurwitz]

The rules actually specfically say no Morse code. The way I now interpret them is that each button has to have a specific task, but it can do more than one thing. For example, toggling the arm could be one button, toggling drive direction could be another. You could also have multi-function buttons, for example, one button to raise arm, move it forward, move it back, and bring it down. But you cannot have a button that sometimes drives forward, and sometimes moves the arm, and sometimes does something else depending on what the robot is now doing. That is, an "advance to the next state" button is not allowed because the rules in section 8 clearly say there can only be four "states."

[Alex Dinsmoor]

This seams crazy but, in automonus mode could you have a button switch between two automonus paths? For example the power button on a TV remote could choose mode a (get laps) and the 1 button could switch to mode b (knock off ball).