IR button coding rules

[theprogrammer]

im currently working on our hybrid code and im not sure if this is legal

else if(rc_dig_in08 ==1 )
{
pwm05 = 255;
if(rc_dig_in09==1&&rc_dig_in10==1)
{
while(counter1<=15)
{
pwm03 = 200;
}
pwm03 = 127;
while(counter2<=10)
{
pwm01 = 255;
pwm02 = 0;
}
the buttons are supposed to do the same thing every time. All I really need teh button to do is to move the motor connected to pwm05, should i reposition the rest of the code so that its legal or am i fine as it is?
The only thing the button actually needs to do is activate the pwm05 motor, the rest of it triggers from both of our digital pressure switches returning positive.
Thanks in advance

[RyanW]

Well, first of all, pwm03 is going to be 127 no matter what counter1 is. You set it to 200, and then immediately to 127 in the same method. It's either going to stall back and forth for 15 loops (if you're using something like WPILIB which calls GetData and PutData in the middle of your routines) or else just stay at 127.

Beyond that,
If you're using rc_dig_in08 to 11 as your IR buttons, this isn't legal. Any individual IR command should only make reference to one of the buttons, UNLESS you use combinations of buttons to minimize interference, and still send EXACTLY four commands. So you need to move if(rc_dig_in09==1&&rc_dig_in10==1) out of your else if.

You're allowed to use timers in your command - you're allowed to use pretty much whatever you want in your command - BUT it has to be internal to the command, or else directly based on sensor inputs from the robot. So if you tell it "Drive straight", and it sees that there's a wall, it can stop based on that information. Your counters are fine as long as they're initialized in the same IR command.

[EricH]

Originally Posted by RyanW

Beyond that,
If you're using rc_dig_in08 to 11 as your IR buttons, this isn't legal. Any individual IR command should only make reference to one of the buttons, UNLESS you use combinations of buttons to minimize interference, and still send EXACTLY four commands. So you need to move if(rc_dig_in09==1&&rc_dig_in10==1) out of your else if.

Sorry, but the bold portion is out. The Q&A has long since eliminated this, as has Update #3. No sequences of buttons.

[RyanW]

Maybe I've been misunderstanding GDC's responses...

According to http://forums.usfirst.org/showthread.php?t=8575 and http://forums.usfirst.org/showthread.php?t=8270, this would not be allowed. I had read some of these posts, but there is some contradictory information.

The following post: http://forums.usfirst.org/showthread.php?t=8314 says that you can use commands to set registers, which would then execute four different commands. This is what I was thinking of when I made the statement quoted above.

[Tom Line]

>>you can use commands to set registers, which would then execute four
>>different commands.

You may be confused. You can not change which commands your 4 IR buttons perform during a match. I.e., if IR button 1 is "move forward", you cannot use another button to change your command set so that the IR button later means "move backward". You also cannot toggle state like this "Press once, go forward. Press again, stop. Press again, go backwards. Press again, stop."

You MAY change what your four buttons do in between matches, assuming you have your index cards filled out with the 4 (four) (IV) commands that the buttons will perform.

Note this part of the GDC response:

>>If there was a one-to-one mapping between the transmitted functions/register settings and the resulting
>>commands/actions, then it would satisfy the signaling requirements.

The rules, as spelled out by the GDC, are extremely clear. One button, one command. It always does the same thing during that particular match.

[theprogrammer]

actually, pwm03 is set to 167 as default because the associated motor doesnt have enough torque to keep our arm in place at neutral so setting it to 127 moves the arm downwards. As for the dig_ins for the IR, we're using 5-8 not 8-11. Also the counters have been changed to Get_Encoder_1-3_Counts which is currently giving us trouble. the dig_ins 9 and 10 arent IR but regular switches mounted inside our claw to tell wether or not its currently gripping a ball.

We are encountering a new problem regarding gear counters, we're using kevins encoder code, it compiles fine but when we try and use code involving the GTS's, we get the red light of doom in programming state meaning there is probably a paradox somewhere that i can't find.

[jacobhurwitz]

We've found that interference can sometimes be a problem. To cut down interference, we were thinking about having to press a sequence of buttons. For example, AAA might do action 1, AAB for action 2, ABA for action 3, and ABB for action 4. Thus, a team would have to press a number of buttons in order for our robot to be accidentally controlled by another team. This seems to violate one rule (cannot use buttons in a sequence) but, as GDC said, there is a one-to-one mapping (and only *four* possible end results). Would this be allowed?

[Tom Line]

Requiring sequenced keypresses is explicitly disallowed.

[RyanW]

Sorry, I guess I misread their response. I interpreted "one-to-one mapping" as "You still can't have more than four commands." Upon rereading, it looks like even what I was describing wouldn't be allowed - you can set variables, but each individual button can only be used to set one thing. Apparently, that hasn't been drummed into my head enough times - even with having to correct other people about it!

Jacob, one-to-one mapping seems to be between variables and results, not between command sets and results. You could set A, B, C, and D, and then have your code execute a different method depending on which of those was true. You couldn't set A and B, and then execute methods based on AA vs. AB vs. BA vs. BB