Quote:
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).
Quote:
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.