Holding Down Buttons on the Remote

[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

[Tim Arnold]

Originally Posted by ay2b

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



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

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

[seanl]

Originally Posted by Tim Arnold

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.

[Uberbots]

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?

[RyanW]

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.