Robocoach signals loophole?
 

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?

Re: Robocoach signals loophole?
 

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

Re: Robocoach signals loophole?
 

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.

Re: Robocoach signals loophole?
 

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. :(

Re: Robocoach signals loophole?
 

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.

Re: Robocoach signals loophole?
 

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.

Re: Robocoach signals loophole?
 

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

Re: Robocoach signals loophole?
 

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

Re: Robocoach signals loophole?
 

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

Re: Robocoach signals loophole?
 

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.

Re: Robocoach signals loophole?
 

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.

Re: Robocoach signals loophole?
 

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.

Re: Robocoach signals loophole?
 

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.

Re: Robocoach signals loophole?
 

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

Re: Robocoach signals loophole?
 

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

Re: Robocoach signals loophole?
 

Of course! That's why you can use four buttons.

Re: Robocoach signals loophole?
 

I'm guessing as long as you only use four buttons, which you can press in any order, and all act independently, you should be okay. If each button could execute some random program, you culd do whatever you wanted.

Re: Robocoach signals loophole?
 

I hope so! This will lead to a very interesting discussion at our meeting...

This could make the hybrid mode a fun time this year.

Re: Robocoach signals loophole?
 

<G01> HYBRID PERIOD - The HYBRID PERIOD is the 15-second period at the start of the
MATCH. Driver control of the ROBOT is not permitted at this time. During this period, the
ROBOTS may react only to sensor inputs and commands programmed into the onboard
control system. The only external signals that may be received by the ROBOT are those
sent from ALLIANCE ROBOCOACHES. No external signals are permitted from any other
source. The ROBOT may react to no more than four distinct external commands provided by
the ROBOCOACH. All ROBOT safety rules are still applicable during the HYBRID PERIOD.
The HYBRID PERIOD ends when the arena timer displays zero seconds left in the period.


It looks to me that this means your entire alliance can send commands to your robot :) Think of the possibility if theres 12 commands

Re: Robocoach signals loophole?
 

I am thinking how much time would you have to program each of the remotes to your robots? Once we start playing with the IR and programming it, we can see how easy it can be programmed.

Re: Robocoach signals loophole?
 

I believe this is against the spirit of the rules, and therefore I will not be pursuing it. However,

What is stop you from treating one of the buttons as an enter button? For instance, say you are using 1, 2, 3, and 4. In that case, you could press 1, then 2 then 4 (enter), and the robot would do whatever "12" tells it to. This gives you 9 combinations. Or, if you'd like the robot just to pause for 2 seconds while you enter it and get rid of the "enter" button, you could have sequences like 1-3-2-4-2.

Take that a step further and pick up a programmable remote with LCD screen from radio shack. These allow a single button press to send out multiple signals. You could program one to completely control your robot.

Again - I'm not pursuing this. But it is something we discussed until we decided it was against the spirit of what First meant the rule to mean.

Re: Robocoach signals loophole?
 

This is illegal Via <G01> and <R69> which state only four commands, and no changing the set of 4 avalible

Re: Robocoach signals loophole?
 

<R65> & <R69> in Section 8 of the manual gives a really go overview of what the SIGNALING DEVICE can be and what it CAN and CAN NOT do. I think everyone should go back and give it a nice good read, it should clear up a lot of questions.

Re: Robocoach signals loophole?
 

Does this put limits on state changes? For example...could 1 button be used to start and stop the action? What about holding down the button instead of just tapping it? Would this count as a separate command? It seems like this is a gray area at the moment.

Re: Robocoach signals loophole?
 

I believe that it is pretty apparent that the GDC wants us to use the four commands as just that -- commands. I interpret the rules stating that any sort of command to do any one thing is permitted (eg. drive straight; turn left; or an entire autonomous mode), so that the buttons could be used to select a list of commands, however complex those commands are. However, I believe that any sort of stepping command, or combinations of buttons are not permitted.

Re: Robocoach signals loophole?
 

Using the rules quoted above:

You may have FOUR buttons (any four) set to trigger FOUR routines. From Dave's example of the Mars rover, they can tell it to "investigate this rock and then come back". That can involve multiple actions.

Your 3"x5" card is to say what routines the robot will run if the right buttons are used.

My impression follows; I find nothing against this: You may as usual have multiple auto programs. Each may have a different set of routines. If this is the case, I'd advise you to have multiple cards, labeled on one side for the mode.

Re: Robocoach signals loophole?
 

This potential loop-hole is blocked in section 8 <R65>. "signaling devices shall... communicate no more than four messages, states or conditions to the ROBOT" A signal sent by pressing multiple buttons would be a 5th message, and any action 5th action would be a 5th state or condition. There is no loop-hole with this rule.

Re: Robocoach signals loophole?
 

We're using an Apple remote. It has the typical circle of four buttons with one in the middle.

Top: Increment speed (both motors)
Bottom: Decrement speed
Right: Increment right motor speed (for turning)
Left: Decrement right motor speed

Is that legal?

Re: Robocoach signals loophole?
 

yeah but aren't there controls that have programmable buttons?

cant you just say this button
but that button would include a series of programed keys

Re: Robocoach signals loophole?
 

This is not true you robot can only recive 4 diffrent encodings so all the teams can send your robot orders but there will only be 4

Re: Robocoach signals loophole?
 

That's not a message sent from the device, that's the interpretation done by the controller.

Re: Robocoach signals loophole?
 

but what if your button setup was something like this...

button 0 : toggle bit 0 high or low
button 1: toggle bit 1 high or low

and so on, which would allow for 2^4 - 1 combinations of events.

technically, i don't think that is actually encoding a message from the remote, nor is it dynamically changing the rule set.
but still, i think it is probably illegal... and probably dumb idea considering that the robocoach would get confused very easily.

Dave's advice from the kickoff of having the control do something extremely high level is really good advice... i think (keyword...) we are pursuing a completely autonomous robot that can be 'nudged' by the robocoach.

Re: Robocoach signals loophole?
 

Think about the board though. That board only has four outputs, so you would have to talk your alliance partners into giving you their IR boards to mount on your robot for the match.

Nevermind, <R69> expressly prohibits that anyway.

Re: Robocoach signals loophole?
 

while it's very clear that you can only send 4 commands... what I don't think is clear, but is implied, is that these commands do not have to be single-step operations. For example, you can have the robot autonomously drive full-bore until you hit a button, which then slows your robot down to 3 f/s, then pops a piston up to knock a ball off, pulls the piston back down, and resumes speed.

In the past, we've put a on-board switch bank on our robot connected to digital i/o that would allow us to switch between different auton modes depending on what our alliance partners needed. You can also write separate hybrid mode routines that remap what the IR commands do, but those have to be chosen before the match, and you need to make sure that the correct command card is brought up to the field before the match starts.

I'm not saying we're doing that, but we're tossing around the idea :)

Re: Robocoach signals loophole?
 

Glad I read this thread ... we were considering using the 4 commands for the first portion of the Hybrid mode, then changing states for the final seconds of the Hybrid mode so the 4 commands would perform something different.

After re-reading <R65> this appears to NOT be legal.

Then, reading <R69> it's confirmed to be a No No.

<R69> Reaction of the ROBOT to communications received from the SIGNALING DEVICE must meet all of the following criteria:
• For a single MATCH, the ROBOT shall be limited to react to a maximum of four distinct commands - either through hardware or software limitations, or a combination of the two.
• The ROBOT shall not dynamically change the recognized command set during a MATCH.

Re: Robocoach signals loophole?
 

I was thinking about having a control set up so that if no signals were being recived it would stop. Would this be legal?

example: button 1 - drive forward
2 - turn right
3 - turn left
4 - fire piston
none being pressed - stop

Does that stop count as a fifth command?

Re: Robocoach signals loophole?
 

Can you do the following using your RoboCoach:

Hybrid starts and by pressing signal 1, 2 or 3 you communicate to the robot which position your trackball is in. Meaning, you call up a routine that will start a series of preprogramed auton actions to remove the trackball from any of the three positions.

Yes, I read the sections, I just do not understand them in plain terms.

Thankyou for your help!

Re: Robocoach signals loophole?
 

Note: this whole post is based on my potentially fallible interpretation of the rules
I think that would be legal, since each of your modes could be explicitly written as "bump out ball 1, bump out ball 2, bump out ball 3, etc"

I don't think so, since each one would depend on the previous internal state of the software in terms of speed. It could be argued that you're dynamically changing your 'top' response from "go to speed 137" to "go to speed 147" to "go to speed 157", etc. after each button press.

I think that'd violate R69: your robot would be reacting to more than 4 distinct commands, and it'd have to store its state from previous button presses. Also, it'd be dynamically changing its command set depending on what other buttons had been pressed earlier: if b1 was set and button 3 was pressed, the command that button 3 represent would have changed.

You'd need 3 IR boards though, since you can't train your team's board to recognize more then 4 commands. You could distribute remotes to all your alliance partners I guess so they could control yours as well when it is in their corner, but I imagine that is banned by some rule regarding how many SIGNALLING DEVICEs alliance robocoaches may carry. I should emphasize though that there may not be such a rule, I'm not sure.

I don't think this would be legal because you'd be dynamically changing your command set. Button 1 would be "drive forward" at one point, and "drive backwards" at another.

I think a good rule of thumb for your button assignments would be "if you have to write the word 'if' on your 3x5 card, then you probably broke a rule". Another thing to think of is to imagine that all your internal state variables get reset upon each IR signal, so you can't respond to your current state.

Re: Robocoach signals loophole?
 

yeah, but the distinct commands are flipping the bits...

Re: Robocoach signals loophole?
 

Disclaimer: These are just my interpretations, the official QA forum is a better place for discussions like this.

But by flipping the bits, you're still doing a different action depending on your robot's state. Suppose button 1 flips bit 1. If bit 1 is 0, then button 1 sets bit 1 = 1. If bit 1 is 1, then button 1 sets bit 1 to 0. So there, you have two possible actions for button 1: "set bit 1 to 0" and "set bit 1 to 1".

I think you may also conflict with this clause from R65:
So by doing this bit-flipping stuff, you'd essentially be transmitting a larger message by remembering the robot state in your bitstring.

Another way to look at it is to look at your button press sequence as a large message. Let's say you used buttons 1, 2, and 3 to modify bits, and button 4 as a 'end of command' button. Then your keypress sequence would essentially end up being button-button-button-<enter>, which seems clearly against the spirit of the rules.

Just like dave said at the kickoff, you're not supposed to be able to drive the robot with the remote, you're supposed to give it high level commands and then it does some heavy autonomous work. You shouldn't need 8 commands since there really aren't that many things to do. Plus, you have to consider that driving the robot by IR will probably be impossible anyway. Other robots, 3-foot-wide balls, and parts of your own robot will obscure your IR board, making driving it accurately pretty much impossible.

Re: Robocoach signals loophole?
 

Isn't the camera still legal? since it is not a KOP item, wouldn't it be considered a COTS item? The camera can be used to track a light, but also a color or shape.

Re: Robocoach signals loophole?
 

This Q&A post clarifies a lot: http://forums.usfirst.org/showpost.p...95&postcount=6

So, to sum up my responses to all of the above questions:

• Toggling an arm, bit, etc. is not allowed. Sort of. If you have a variable in your program to toggle, it's not allowed. But if the arm depresses a switch, you are allowed to say, "If the switch is depressed, move the arm up. Else, move it down." So toggling is allowed if it is based solely on sensor inputs.
• To the person above who said increasing speed is not allowed: the Q&A post explicitly says it is.
• I don't think having the robot stop if you press nothing is allowed. R65 says you can't use changes in the signal state to encode longer messages. I think pressing/releasing a button is a change in signal state, so you can't use that as an additionally message.

Re: Robocoach signals loophole?
 

Let's apply the "same thing every time" litmus test to this one. Call the command "drive for 500 milliseconds and then stop". Your robot will do that every time you press the button. As far as I can tell, you are allowed to interrupt an action in progress with another button press. As such, if your robocoach is madly mashing the button, then the robot will continue going. When he stops, the robot stops. The robot performs the same action every time you press the button... you just don't happen to let it complete the action. This sounds legal to me.

Re: Robocoach signals loophole?
 

It's perfectly legal to have an autonomous routine execute when you aren't pressing any buttons down. So, for example, your commands could be "Go forward/back/left/right while this button is pressed", and your default autonomous routine could be "stop".

See this forum post for details:
http://forums.usfirst.org/showthread...ghlight=hybrid

SgtMillhouse648, the CMUCam itself is allowed, but the CMUCAM module given out in previous years is a custom part made specifically for those FIRST competitions. It may not be used. You'd have to get the unmodified CMUCam and mount it on your own.

Re: Robocoach signals loophole?
 

Would this be legal?

You have an IR command that signals the robot to execute command Y after it is finished executing command X, where X could be a routine from another signal or an automated routine.

If the robot is not executing X, it will execute Y immediately, and if it is executing X, it will execute Y when it is finished with X.

Re: Robocoach signals loophole?
 

Yes. I believe that very situation has been addressed by Q&A.

Re: Robocoach signals loophole?
 

The first sentence is true, but the second one is false. The CMUCam that came in the 2007 KoP is still available from IFI, so it is considered a COTS part, and is legal under <R35>. The 2006 CMUCam is not available COTS, and is specifically prohibited by <R36>, so it is not allowed.

Re: Robocoach signals loophole?
 

A couple of interesting Robocoach-related Q&A responses came out today:
http://forums.usfirst.org/showthread.php?t=8460
http://forums.usfirst.org/showthread.php?t=8455

Re: Robocoach signals loophole?
 

I thought of an interesting "loophole" in the rules...

A remote like the Logitech Harmony series allows you to program some of the buttons on the computer. Now, the GDC wants you to have 1 button push correspond to one action, with a max of 4, and they don't want you to encode longer messages by pushing multiple buttons, which rules out the idea someone had of using encoded messages to help stave off interference from other teams.

But what if you programmed a remote to send multiple number messages for each push? You only use 4 buttons, and those 4 buttons only activate 4 activities on the robot. each single button press leads to one action on the robot. But you're sending a string of signals with each press to avoid interference with other robocoaches.

From update 3, this may be allowed (i think we'll draft a question to the GDC about it, so i'm not really looking for approval here, just opinions):

So one button push transmits one message, and multiple button pushes don't encode other messages... I don't know, what do you guys think? Am i going out on a limb here?

Re: Robocoach signals loophole?
 

You're on a limb, but it's a relatively thick one. Get that question asked to confirm. (And the post here is a pretty good base for it.)

If I had to make a ruling, here and now, with the information available, I would say legal. I am, however, not on the GDC.

Re: Robocoach signals loophole?
 

If you are using a standard commercial IR remote control, you are already doing this.

When you mash the "3" button on an IR remote, the device does not just send "3" out over the IR LED. That information is actually buried inside a larger packet of information that is sent each time a button is pushed. The packet will typically contain (as a minimum) synch pulses, the target device address, an encoded version of the data, and termination pulses.

Depending on the device being used, the actual "data" content can be a small fraction of the total transmitted packet. For example, if the remote uses the Control-S protocol (used by Sony - the two most common protocols are from Sony and NEC), you get a header pulse, a seven-bit data block, a five- eight- or thirteen-bit target block, and a trailing pulse. Of the data block, only 10 of the 256 seven-bit permutations correspond to the numbers on the remote. All the rest of the packet space is used by the remote to encode other information that is used by the receiver to decode and direct the data.

So what is being proposed as an advantageous "loophole" is, in fact, already in place and the rules support and accommodate it.

-dave



.

Re: Robocoach signals loophole?
 

Yeah, i understand how a remote typically works - the only real difference between programming a remote to send multiple signals every button press and that is the possibility for interference. There are only so many manufacturers, and each of them only has a few different types of signals they use (if you look at the instructions for a programmable remote, they usually have a lookup table by brand with at most 50 or so values). By using a standard remote with a standard (single) signal for each button, you risk that someone else is using the same type of remote, or is programmed for the same brand and you risk their commands telling your robot what to do. With the sizes of the regionals, odds are this'll happen to someone at each regional... by encoding longer messages, you significantly reduce or even eliminate this risk, and that is really the part that isn't already contained within the general understanding of the rule.