Team Update #3

[ChrisH]

Originally Posted by Scott Carpman

By far the most entertaining lines of the update:

It may be as simple as “stop right now
and wait,” or as complex as “turn left, drive forward, raise the arm, grab the
Trackball, lower the arm, race across the Finish Line, feed the hamster, complete
my calculus homework, then stop.”

I hate it when Q&A gets cute like this. I'm sure somebody will be running around a competition asking about "where is the hamster our robot is supposed to feed?" or "Can your robot help me with my calculus homework?"

[flightofone]

We had programmed our buttons to:
A - turn left 10-degrees, unless already at the stops
B - turn right 10-degrees, unless already at the stops
C - speed up 2fps, unless already at maximum forward speed
D - slow down 2fps, unless already at maximum reverse speed
It seems like this may not meet the letter of the law, since any button-push at the limits will not do anything, and the cases of crossing the zero-speed value reverse the direction of the robot. Any thoughts?

[lukevanoort]

Originally Posted by flightofone

We had programmed our buttons to:
A - turn left 10-degrees, unless already at the stops
B - turn right 10-degrees, unless already at the stops
C - speed up 2fps, unless already at maximum forward speed
D - slow down 2fps, unless already at maximum reverse speed
It seems like this may not meet the letter of the law, since any button-push at the limits will not do anything, and the cases of crossing the zero-speed value reverse the direction of the robot. Any thoughts?

This is something that I don't like about the RoboCoach rules. It seems to me that legality/illegality here is a matter of semantics. If you just have software safety limits that are in constant effect, the buttons seem to fit; they communicate for the robot to do the same thing every time (speed up/slow down/turn), but the default behavior overrides this for safety reasons at certain speeds. It the GDC clarified to make that illegal, then software limits (such as using a limit switch to stop an arm) and all other devices that teams use to keep operator error from damaging their robots become illegal (assuming that they affect something the robocoach controls).

Originally Posted by Dave Flowerday

The way I read it, toggling is not allowed. The litmus test was if the robot will do the same thing every time a button is pressed - this is not the case when toggling. Also, it seems to invalidate the example that was given during kickoff, where one button can start the robot moving and the same robot can stop it.

I would tend to agree, but this seems to become an issue of wording. One could argue (likely a losing argument, but not too far out there) that 'toggle arm position' is a command that will produce the same result every time--a toggling of arm position. Of course, another could then argue that the 'raise arm' and 'lower arm' functions are different actions that result from one command.

[T3_1565]

I think the sum of the robocoach part is:
"The litmus test would be “does sending the same message from the Signaling
Device result in the same action on the Robot every time the message is sent?” If the answer is “no” then it is probably not allowed."

very well put paragraph.

[Mr.G]

Seems like to many things going on in 15 seconds. We are usually happy if the robot even moves. Good luck to all.

[jgannon]

Originally Posted by lukevanoort

This is something that I don't like about the RoboCoach rules. It seems to me that legality/illegality here is a matter of semantics. If you just have software safety limits that are in constant effect, the buttons seem to fit; they communicate for the robot to do the same thing every time (speed up/slow down/turn), but the default behavior overrides this for safety reasons at certain speeds. It the GDC clarified to make that illegal, then software limits (such as using a limit switch to stop an arm) and all other devices that teams use to keep operator error from damaging their robots become illegal (assuming that they affect something the robocoach controls).

I'd have to say that this is still legal.

The commands can also initiate the execution of more complex routines, as long as the routines rely only upon input from sensors and systems on-board the robot (i.e. not using information from the RoboCoach and/or Signaling Device other than “start routine xx”).

You're still sending the same command, but it is doing something different not because of a software state machine, but instead because it is a complex routine that is responding to sensor input (such as a limit switch or a tach). That seems to be exactly the sort of thing they're trying to permit. In light of this, it sounds like Mr. Clayton's software design would pass muster. Am I off-base here?

[Racer26]

...Far as I'm concerned theres no real need for all this lawyering of this rule.

You get FIVE functions to work with. Buttons 1,2,3,4, as well as what to do if no button is pushed.

Which to me, you could have something like

No Action: Run laps around the track, dead reckoning, using sensors, however you like.
Button 1: Get trackball from position 1
Button 2: get trackball from position 2
Button 3: get trackball from position 3
and Button 4: go to other side of track, and wait for one of buttons 1,2,or 3

and thats all you really need, and as such I suspect we're going to see ALOT of veteran teams known for good autonomous modes to have a setup much like this.

I dont think we'll see that the robocoaches signalling device is going to be super reliable, and thus realtime control is more or less out of the question.

Besides which, using a series of keys to issue a realtime operation seems a bit like trying to smash a nail into wood using your face for a hammer, as far as user friendliness goes, never mind that its breaking the rules.

Hybrid mode was not INTENDED for realtime operation. Thats what teleoperated is for. Why you would even want to try to operate one of these robots in real time with just four buttons is completely beyond me.

I race cars on the track in my spare time, I know how to 'lawyer' competition rulebooks, but I don't with respect to FIRST because finding a loophole thats obviously against the spirit of the competition takes away from the fun of solving the challenge, where in the racing world, we don't have this notion of gracious professionalism, rule-lawyering happens all the time by everyone, and to be frank, the only real goal is to be the fastest.

[dlavery]

Originally Posted by Dave Flowerday

The way I read it, toggling is not allowed. The litmus test was if the robot will do the same thing every time a button is pressed - this is not the case when toggling. Also, it seems to invalidate the example that was given during kickoff, where one button can start the robot moving and the same robot can stop it.

During the kickoff broadcast the demonstration used a TV remote for which four functions were programmed: "Drive Forward," "Turn Left," "Turn Right," and "Stop." I do not believe that anything in the rules or in the updates invalidate the demonstration.

-dave

[EricH]

Originally Posted by 1075guy

...Far as I'm concerned theres no real need for all this lawyering of this rule.

You get FIVE functions to work with. Buttons 1,2,3,4, as well as what to do if no button is pushed.

Which to me, you could have something like

No Action: Run laps around the track, dead reckoning, using sensors, however you like.
Button 1: Get trackball from position 1
Button 2: get trackball from position 2
Button 3: get trackball from position 3
and Button 4: go to other side of track, and wait for one of buttons 1,2,or 3

WRONG. Read Update 3, particularly the fifth paragraph, quoted below.

Originally Posted by Update 3 paragraph 5

The actions that the Robot takes in response to the messages received should be repeatable and predictable. In practical terms, this means that when the RoboCoach presses Button #3, Action #3 always occurs. Robot responses that are time-dependent or message sequence dependent are not allowed. For example, programming the Robot so that it initiates Action “A” if Button #3 is pushed during the first five seconds of the Hybrid Period, and it initiates Action “B” if button #3 is
pushed during the second five seconds of the Hybrid Period, etc. would not be allowed. This time-dependent context for the message interpretation is equivalent to the ability to send more than four single, unique messages, and is contrary to the intended RoboCoaching concept.

(emphasis mine)
This is closest to the situation you describe. I thought there was something more specific in there, but there isn't. I would say that having a "time-dependent context" (say, a "if no command received for x seconds do this") also violates the intent.

Please, don't make the GDC make a rule about "No command will be counted as a signal and limit you to three buttons." Partly because that will be unenforceable, partly because it isn't needed with the current rules.

[Travis Hoffman]

Originally Posted by GeeForce

I'm very glad about this update. I've had to debate with several people (mostly programmers) trying to loophole and lawyer the "4 commands" rule.

I would submit that most people are not psychic, and therefore, the rule as originally written was vague enough to warrant the kind of follow-up treatment provided by the GDC "to provide some insight into the rules, what the members of the GDC were thinking
when they were written, and how they will be interpreted." You can only seek to "loophole and lawyer" what you already understand to be true. The uncertainty surrounding this topic prior to Team Update #3 absolves most everyone of trying to skirt a rule whose true intent was shifting around like a ghost in the mist. I myself thought a "jump to next autonomous step" action was a perfectly legal and constant action to apply to a single button press. I now know that the GDC's intent is for that to be a prohibited action. In fact, I would almost bet that that specific clarification exists precisely because I and perhaps others suggested it in these forums in the first place, much like I am also certain the new requirement for the drive team to be behind the line before trackballs are placed in G20 was inserted precisely because I suggested people use the somewhat common feature of operator station-based autonomous select controls to tell the robot where on the field the trackballs were after they were placed on the overpass. Perhaps in the future I should simply keep my mouth shut instead of offering such suggestions of previously legal strategies to the FIRST community as a whole?

I would also submit that many programmers are not so much trying to bend the rules as they are extremely eager in their natural desire to creatively squeeze as much functionality out of this new tool as possible. Having received the needed clarification, they will proceed accordingly, although many will continue to be disappointed by what they feel is an exceedingly restrictive slant on the application of this new technology.

[jgannon]

Originally Posted by EricH

WRONG. Read Update 3, particularly the fifth paragraph

I have to disagree with you on this one, Eric, if I'm understanding 1075guy's post correctly. There is no rule to say that the robot can't start acting at the beginning of the match without a signal from the Robocoach (obviously, since this would disallow full autonomy). If the Robocoach pushes a button, then it will do something different. It will do the same thing every time you push that button, regardless of when you push it. This satisfies the requirements as I understand them. As such, in some sense you can think of this as five actions: a default, and a response to each button. I suspect that many teams will have "do nothing" as their default action, but I also imagine that there will be a number of teams who will start moving at the beginning of the match before the Robocoach presses a button, and they will do so legally.

[dlavery]

Originally Posted by 1075guy

...Far as I'm concerned theres no real need for all this lawyering of this rule.

You get FIVE functions to work with. Buttons 1,2,3,4, as well as what to do if no button is pushed.

Which to me, you could have something like

No Action: Run laps around the track, dead reckoning, using sensors, however you like.
Button 1: Get trackball from position 1
Button 2: get trackball from position 2
Button 3: get trackball from position 3
and Button 4: go to other side of track, and wait for one of buttons 1,2,or 3

and thats all you really need, and as such I suspect we're going to see ALOT of veteran teams known for good autonomous modes to have a setup much like this.

That is the way that I read it also. Of course, for any sort of an official interpretation, you would need to pose the question to the official FIRST Q&A System (my mantra for the year: "NONE of the answers you get outside the official Q&A System have any authority or certification, and will not be considered by the referees"). But your interpretation seems to be reasonable.

-dave


.

[Kevin Sevcik]

I'll toss in about the arm position toggling. I don't think this would be too much of a stretch, but it'd depend on how you implemented it. If you counted how many times the toggle button was pressed, it'd be illegal because it'd depend on a software state. I think it'd be legal if it started a "move arm" routine that depended on the physical position of the arm. Obviously this sounds a lot like arguing semantics, but I think it makes sense.

[GaryVoshol]

Let's change the descriptions a little (my emphasis):

Originally Posted by 1075guy

...Far as I'm concerned theres no real need for all this lawyering of this rule.

You get FIVE functions to work with. Buttons 1,2,3,4, as well as what to do if no button is pushed.

Which to me, you could have something like

Default Autonomous Action: Run laps around the track, dead reckoning, using sensors, however you like.
Button 1: Get trackball from position 1 and then revert to Default
Button 2: get trackball from position 2 and then revert to Default
Button 3: get trackball from position 3 and then revert to Default
and Button 4: go to other side of track, and then stop

Those button commands always have the same associated actions, so there should be no problem. As Dave suggests, ask Q&A if you want to be sure.

[IbleedPink233]

Originally Posted by GaryVoshol

Let's change the descriptions a little (my emphasis):

Those button commands always have the same associated actions, so there should be no problem. As Dave suggests, ask Q&A if you want to be sure.

This makes sense to me, after all, there has to be some allowance for good ol' autonomous programming to come into play. The default is just autonomus programming, is't it? It isn't another signal, so it is perfectly legit.
I don't think that you necessarily need to "revert back to default" for every command to make it legal. You may make it a part of your strategy, but it doesn't make it any more legal.

About arm toggling - I know lots have already commented on it - you'll probably have to Q+A that. From a software standpoint, you could easily make a toggle function that does the same thing every time, but I think that the referees may decide the legitimacy based on the black box approach - where they judge based on the actions of the robot, regardless of how it is programmed. I don't blame them, it is by far the most objective way to do it and doesn't require inside knowledge of the bot.
I'd suggest that you either Q+A it or hope that you can do it, but prepare in case you can't.