Holding Down Buttons on the Remote

[jacobhurwitz]

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:

Originally Posted by GDC

The application described violates the intent of the Robocoach signalling rule. The contact with the button should be momentary. By having your command contingent upon the length of the button press, you have encoded a variable "how long" command in addition to the "what" command.

So, we cannot hold down buttons in hybrid mode.

[wt200999]

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.

[RyanW]

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.

[wt200999]

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.

[Jon Stratis]

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.

[RyanW]

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.

[Urban Hawk]

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.

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.

[Tom Line]

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.

[meaubry]

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

[Tom Line]

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.

[Urban Hawk]

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.

[Alan Anderson]

Originally Posted by Urban Hawk

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.

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.

[RyanW]

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

[theprogrammer]

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.

[ay2b]

Originally Posted by theprogrammer

... and we hold the button down.

Please be aware that the GDC has said that you cannot hold the button down.

Originally Posted by GDC

The contact with the button should be momentary. By having your command contingent upon the length of the button press, you have encoded a variable "how long" command in addition to the "what" command.

http://forums.usfirst.org/showthread.php?t=8565