Just to let everyone know: our team posted a question on the FIRST Q&A forum about holding down buttons in hybrid mode. According to GDC’s response:
So, we cannot hold down buttons in hybrid mode.
So instead have it do something for a very short amount of time. My idea is this, and from what I can see it is 100% legal
Button 4 command is: Robot stops from its regular routine for 1 second.
you could even tie that to an interrupt so that it will work no matter where you are in the code.
So you just keep giving it that command. I don’t know if this will work for your needs, but its an idea.
Is that legal, though?
If you can say “Do this for 1 second”, why not “Do this for 1/2 second” or “Do this for 36.5 ms” (or whatever slow loop time is)? Either no single command may be used with a timer, or there’s some arbitrary dividing line between what interval is legal and what isn’t, or it’s a semantics issue.
Personally, I have no problem with that ruling - though it’d be nice for rookie teams and teams worried about crashing to be able to drive via IR. The point is that we’re supposed to be giving the robot fairly high-level commands, like “The trackball is on the left - go get it”, not just trying to drive with 4 buttons. Unfortunately, it’s easy for teams to think of more and more examples, using tricky wording or clever signaling, that follow the letter but not the spirit of the rules. If this keeps up, future hybrid mode instructions could come with pages of rulings as to just what you can and can’t do with the IR commands. However, that seems like it might be slightly better than the current confusion - we can’t use the exact command they showed at the kickoff (and what about the “Drive Fast” in the human game?)! Hopefully if hybrid continues in future years, there will be a clearer picture of what is allowed.
Going by that quote, they were saying timing on the button push not the actual command. This still would be another command and from that one update that clarified it it looked legal to me. The thing with my idea for the stop is so we have a safety, and if it is pushed we are not stuck for the rest of auton. 
Also, I would use 1 second or something like that just to make it look better for the judges or people like that, and incase you don’t keep getting the signal.
i think the point is that the command or subroutine that is executed by pushing a button isn’t of the form “while the button is being pressed”. Instead, you could have something that says “when the button is pressed, turn left 5 degrees” - naturally, holding down the button will result in this sequence getting called many times. Of a similar nature, you could have a command that says “drive forward 1 foot” - again, if the button is held down, you would execute this command multiple times.
Keep in mind, though - holding down buttons can be bad for you, your teammates, and your opponents. The IR boards are fairly sensitive, and by holding down a button you could flood the other teams out of being able to communicate with their robot. Similarly, if they push a button while you’re holding yours, it could interrupt your signal. For the sake of everyone, it’s much better to break your commands into discrete time chunks and avoid holding buttons.
Actually, we have our own way of avoiding interference…not entirely sure yet how well it’ll work, though.
The idea was to have those commands but only use them for correcting the robot if it was about to crash - for some reason, our president doesn’t have a lot of confidence in the programmers sending the robot running around at high speeds!
My point was actually that this seems more like a matter of semantics than anything - unless we’re not allowed to hold down buttons at all, which is a different issue altogether.
Well what you could do is that rather then having it send the code repeditaly which could cause some problems, have it so it sends the code only when the button is pressed or released. Then have the robot would automaticly repeat the procedure untill the code comes that tells the robot that the button has been released and to stop the procedure. by doing so you would be sending only 2 codes rather then needing to send the same code 20 times. 
Also you cant have more then 4 procedures since u need to write all the procedures u have on that little piece of paper which you are allowed to put only 4 rocedures on. However… you forget about the null pocedure. So in essence there can actually be 5 procedures. :ahh:
The easyest way to use the command buttons is to have one go forward, one to go left, one to go right, one to deploy the mechanism for knocking the ball down, and stop as the null command.
This seems to be a very straight forward ruling.
I suppose it is engineering nature to try and exploit loopholes.
You may set up your robot to interpret a sent command as “go left one foot”. You may then push a button to move left one foot. You may not have a remote control that you can hold down a button that repeatedly sends the signal to move left one foot.
A command should be simple. Along the lines of “descore the ball in the xx position”.
Trying to “drive” your robot with the remote is not what First is looking for.
It would seem to me, that if holding down the IR button renders bad results - such as flooding or blocking other teams signals - AND it is NOT within the intent of the rules as defined by the GRC - I would hope that there is a way to monitor this occurance, and penalize anyone that decides to “hold the button down”. After teams realize that they will be penalized, they might stop using that tactic.
Am I being too pessimistic to think, that by stating “it’s not graciously professional behaviour”, that some teams will stop that tactic?
Since there is a big movement underway like “no robots left behind”, I would hope that the entire FIRST community also embraces the fact that IR signals are intended as single event occurances - not continous events - and that it hurts everyone to “hold the button”.
Mike Aubry
I would wager that no one in the First community would do it on purpose.
However, you must keep in mind that there are a lot of teams that don’t read chief delphi and may not have the benefit of all the questions and discussions that are here.
I’ll bet it DOES happen, specifically because teams may not understand the intent of the rule. Your best bet is to make your robot as “interference unfriendly” as possible.
Well, it is as i said before. If you have it so that the code will be sent only when the button is pressed and when it is released, it wont flood the signals. However the robot will continue to exicute the procedure until the code is sent telling the robot that the button is released. Then it will stop doing the procedure.:ahh:
And the official response is still as the GDC said before. Doing it that way violates the intent of the “only four commands” and “no higher-level encodings” rules.
Well, it looks like our autonomous code is good enough that we don’t need to worry too much about it…We tested at the Play Date yesterday and were consistently getting at least 2 lines (when we weren’t going backwards and getting penalties, that is…)
Currently we do have driving correction type stuff, but it’s now on the order of “Override autonomous and move this way for 1 second”, which should interfere less than holding the button down…
I agree that holding the button down is not particularly nice to other teams. The hope was that we wouldn’t have to do it much, and we certainly wouldn’t be using held-down buttons to drive the robot, and so we weren’t really thinking about interference issues… However, we have moved away from that scheme, and I do think it’s better overall.
Yesterday at the Play Date I saw one team driving by IR command - there are much easier ways to do it if you want to drive that way that don’t involve holding buttons down. So after however much complaining I’ve been doing, I do support GDC’s decision on this issue…
We found a way around your problem, its not perfect but the button does the same thing every time and we hold the button down. For our IR buttons, we used a series of if/else statements with the final else containing a command that sets all of the motors back to neutral. This isnt perfect because our movement is jerky because its continully changed from 255 to 127.
Please be aware that the GDC has said that you cannot hold the button down.
Isn’t holding the button down outputting the same thing as rapidly pressing the button? The remote is emitting pulses even if you hold it down…
that is exactly what i was thinking.
it is sending out pulses. that would be the same as pushing the button really fast.
like for example: if you are sending pulses that drive your robot forward but making the robot “pulse” forward. wouldnt that be legal? because each pulse it doing one action that drives the robot forward a little but. so holding it or pressing it really fast would be the same and drive the bot forward.
one of our earlier autonomous modes worked like this:
it had two vectors: the forward vector and the angular vector
these vectors constantly return to 0 using a linear ramping technique
when a forward signal is received from the IR board, it ramps the speed up 20%. further presses of the button will yield more speed (linearly, 20 40 60 80 100)
when a turn left/right signal is received, it ramps up the turning vectors inverse-exponentially (to improve turning)
there is also a stop command which would reverse the robot for a couple ticks
we ended up ditching it because it was too borderline within the rules, the IR signal dropped out at the other end, and we made a better autonomous mode after that.
I dunno about the rules though… a single button press always does the same “add 20%” thing, and they arent held down in order to do it. any thoughts?
Uberbots,
Seems okay - changing orientation by a fixed amount is legal, and I guess the ramping back would be an autonomous thing.
seanl,
I agree that you could use semantics to get around the “no holding buttons down” rule, but it would be nice to stay within the spirit of GDC’s decisions as well as the letter.