Team Update #3

[Gamer930]

Team Update #3 is out

http://www.usfirst.org/community/frc...nt.aspx?id=450

Bunch of info on the RoboCoaches

[GaryVoshol]

Originally Posted by Gamer930

Bunch of info on the RoboCoaches

And all of it good. Great job again, GDC.

[EricH]

Hard to get any clearer as to intent. 4 buttons, 4 command sequences, and no message sequencing.

[seanl]

ah... that clarifies everything.

[pheadxdll]

That absolutely condemns any messaging sequencing. 4 commands and 4 distinct actions it looks like. It seems a little difficult to enforce though so it seems like its up to gracious professionalism on the team's part.

[thefro526]

I like how they've clarified all the robocoach info. I also like how they explained the use of more than one robocoach which theoretically means you can have a robocoach at both ends of the field.

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

[Koko Ed]

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

Must've been written by Dave.

[eshteyn]

GREAT!! there goes all the memory circuitry we built

[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?