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.