View Full Version : Start/Stop as one IR function?
citrusapocalyps
30-01-2008, 21:37
What do you think? Would Start/Stop count as one function in Hybrid mode or two?
Branden Ghena
30-01-2008, 21:42
I'm pretty sure with the way they word it, they want each button to only control one function, as in separate buttons for stop and go. But if you can pull it off, you might be able to have stopping as part of your turn function, i.e. turn and stop. So to stop the robot you turn one way and then turn the other. Or make the button drive for one second and then stop.
I think it's two. From Team Update #3:
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.
Jon Stratis
31-01-2008, 10:15
Unfortunately, you can't use that as one state. As answered by the GDC in the Q&A:
Please refer to Team Update #3. With the guidance of the referenced "does it do the same thing every time?" litmus test, using a Signaling Device button to toggle Robot actions would not fit within the intent of Hybrid Mode. Nor would using the Signaling Device to step through a multi-step routine.
The messages sent by the Signaling Device can initiate more complex actions or routines that are completely pre-programmed on the Robot. The Signaling Device can also be used to transmit field state information instead of a specific command or action.
http://forums.usfirst.org/showthread.php?t=8008
From the Q&A responses I believe that it can be done. With the use of sensors you can activate a command that says, if x value is "a" then stop and if x value is "b" go.
This is only my interpretation and I am not a programmer or official answer giver.
efoote868
31-01-2008, 12:28
I think this might be a rule they cannot police, kind of like the re-use of code from year to year, or just fix during your fix it windows, or even like the maximum ball shooter speed in 2006.
Just use GP in determining your decision, and if you think its allowed, then go for it, otherwise don't. But have an alternative in mind if they specifically tell you "no."
I think this might be a rule they cannot police, kind of like the re-use of code from year to year, or just fix during your fix it windows, or even like the maximum ball shooter speed in 2006.
Just use GP in determining your decision, and if you think its allowed, then go for it, otherwise don't. But have an alternative in mind if they specifically tell you "no."
they should ask you during inspection to test robocoach functions. I read this somewhere in the Q&A
GaryVoshol
31-01-2008, 13:03
they should ask you during inspection to test robocoach functions. I read this somewhere in the Q&A
After searching the Q&A for "inspect", "inspects", "inspector", "inspectors", "inspection" and "inspections" I can find no such requirement. Do you have a better reference than "I read this somewhere"?
I'm not sure where I saw it but I am 100% sure I read somewhere that if asked you would have to show the inspector or a ref or a judge your hybrid controls and which button does what
a few rules about this subject:
<R65> Emphasis mine
communicate no more than four messages, states or conditions to the ROBOT (please refer to Rule <R69> and Rule <G01> for additional information) during any single
MATCH.
no more than 4 states I would say that having a button that changes states would count as two of your four messages
<R65> Emphasis mine
be able to switch between no more than four states or conditions (i.e. send no more than four messages)
pretty much the same thing just said again later in the rule
Team update #3 Emphasis mine
For example, consider a programmed sequence of actions such as “start driving forward,” “stop in place,” “turn left,” “raise arm,” “open gripper,” “close gripper,” etc. Each time Button #8 is pressed, the Robot advances one step through the sequence of actions. This would not be allowed.
Start and Stop would be steps and advancing steps is not allowed
Also keep in mind (can't find the quote in the rules for some reason) you must have a 3x5 notecard with all functions of your robocoach remote written on it.
I hope I helped
GaryVoshol
31-01-2008, 23:05
I'm not sure where I saw it but I am 100% sure I read somewhere that if asked you would have to show the inspector or a ref or a judge your hybrid controls and which button does what
Do you mean this rule?
<G49> ROBOCOACH Signaling – If the ROBOCOACH will be providing signals to the ROBOT,
then prior to the start of each MATCH the ROBOCOACH must place a Signaling Card in the
ROBOCOACH STATION. The Signaling Card shall be a 3-inch by 5-inch card listing the
one to four actions that can be commanded by the ROBOCOACH.All you're doing is telling what you might do. You don't have to demonstrate it.
Do you mean this rule?
All you're doing is telling what you might do. You don't have to demonstrate it.
I'm not sure where I read it but I specifically remember reading you will have to show your hybrid functions if asked. But it could have been somewhere in Team Update #3 maybe I was thinking of because I talked about if we were to go up to someone like an inspector and keep pressing the button it would always do the same thing. Sorry for the misunderstanding. My main point is that Start/Stop button IS illegal
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.
Browzilla
01-02-2008, 01:10
I'm not sure about the legality of this, but what if my function were say, x=x+1. And then in the autonomous code was looped
if x is even, stop
else go
That way the button always preforms the same function, adding one, but you can achieve the desired result.
Yes? No?
I'm not sure about the legality of this, but what if my function were say, x=x+1. And then in the autonomous code was looped
if x is even, stop
else go
That way the button always preforms the same function, adding one, but you can achieve the desired result.
Yes? No?I don't think that would pass. You're toggling states.
I don't think that would pass. You're toggling states.
I would have to agree.... technically to task's are being achieved by one button
Browzilla
01-02-2008, 01:46
I suppose that's what I get for trying to think this late.
Yeah, I suppose you're right.
From the Q&A, I hope it helps.
RC Decision-Making during RoboCoach Commands
Background:
1) Team Alpha has created a RoboCoach command for Alphabot called "move Alphabot to correct heading." This RoboCoach command triggers the same sequence of RC commands and decisions every time it is sent:
Quote:
a) Read heading of CMUCam which is successfully tracking a trackball.
b) If trackball heading is left of robot heading, turn robot left until headings are same, then stop.
c) If trackball heading is right of robot heading, turn robot right until headings are same, then stop.
2) Team Beta has created a RoboCoach command for Betabot called "move Betabot's arm to correct position." This RoboCoach command triggers the same sequence of RC commands and decisions every time it is sent:
Quote:
a) Read limit switches at both ends of arm travel.
b) If top limit switch is pressed, lower arm until bottom limit switch is pressed, then stop.
c) If bottom limit switch is pressed, raise arm until top limit switch is pressed, then stop.
Question(s):
1) With respect to the Q&A response at http://forums.usfirst.org/showthread.php?t=8370, due to RC decision-making, neither RoboCoach command will always result in the same robot action. Alphabot's RC may decide to rotate the robot left or right, Betabot's RC may decide to raise or lower the arm. In both cases however, the same RC command and decision sequence is triggered every time the RoboCoach command is sent. Can you comment on the legality of both of these RoboCoach commands?
2) Should it be accepted that Team Beta's RoboCoach command is just a poorly veiled attempt at "toggle arm position" (as described in the referenced Q&A response) and is contrary to the intent of the rules, or is there actually a valid distinction due to the presence of RC decision-making?
Thanks again for all your time and effort in providing the Q&A. It is truly appreciated!!!
Reply With Quote Multi-Quote This Message
Default Re: RC Decision-Making during RoboCoach Commands
The Robocoach commands in both the Alpha and Beta examples satisfy the letter and intent of the rule. Both solutions involve reading sensors on the robot to perform the commanded functions.
Reply With Quote
You might not want to have 'start' and 'stop' actions anyway. If there is interference from your alliance partners or opponents, you will not be able to stop accurately because someone else might be firing an IR message at the same time. Getting some wheel counters on your chassis would allow you to compact it into one action: 'drive x ft and stop' (assuming that the target you want to stop under is the same each match).
I think start/stop would be ok for one button.
It's one function.
If you think it's saying:
If robot is stopped, start it.
If robot is started, stop it
That way is probably against the rules.
But if you were to ask how many functions a TV Remote Power Button has, I believe most people would answer one. To Toggle Power.
My thoughts on this is that 'toggle' is one action. it does the same thing every time. Invert the action that is currently happening. That being said, I still dont think all this talk is even required because you only NEED 4 actions. (Pos 1,2,3, and go to other side)
Your 'get ball from rack' function may not always do exactly the same thing, since its going to use sensors, so why should the ruling be any different for a function called 'toggle' which merely does something based on current conditions.
Jon Stratis
04-02-2008, 08:36
Unfortunately, the GDC has expressly said that a toggle function is not allowed in the Q&A:
Please refer to Team Update #3. With the guidance of the referenced "does it do the same thing every time?" litmus test, using a Signaling Device button to toggle Robot actions would not fit within the intent of Hybrid Mode. Nor would using the Signaling Device to step through a multi-step routine.
The messages sent by the Signaling Device can initiate more complex actions or routines that are completely pre-programmed on the Robot. The Signaling Device can also be used to transmit field state information instead of a specific command or action.
(emphasis mine)
My thoughts on this is that 'toggle' is one action. it does the same thing every time. Invert the action that is currently happening. That being said, I still dont think all this talk is even required because you only NEED 4 actions. (Pos 1,2,3, and go to other side)
Your 'get ball from rack' function may not always do exactly the same thing, since its going to use sensors, so why should the ruling be any different for a function called 'toggle' which merely does something based on current conditions.
The difference is that it relies on sensors to give the state not on/off static states. The answers are there in the Q&A.
What do you think? Would Start/Stop count as one function in Hybrid mode or two?
This is all based on the Q&A response Steve W quoted above at: http://forums.usfirst.org/showthread.php?t=8460
Start/Stop as a single RoboCoach command can be achieved if you use encoders (or any other sensor) to track whether your robot is in motion or not. You can then write a command that will stop a robot in motion, or start a stationary robot, but the RC's decision must be based on input from a sensor on the robot.
You cannot simply save a state in software that keeps track of whether your robot is moving based on when or how many times you've sent the RoboCoach command. i.e. 1st push start, 2nd push stop, toggling back and forth.
It's an important distinction to make between those two scenarios. It is possible to achieve the behaviour you're looking for, but you need to be mindful of how to go about doing it.
My mistake, I was not aware Q&A had actually explicitly mentioned Toggling. Doesn't change my plans, and also, doesn't change my feeling that a toggle function is not required. Furthermore, it doesn't change my opinion that 'toggle' is one action, however, if thats how the GDC wants it, thats fine by me.
Jon Stratis
04-02-2008, 11:55
This is all based on the Q&A response Steve W quoted above at: http://forums.usfirst.org/showthread.php?t=8460
Start/Stop as a single RoboCoach command can be achieved if you use encoders (or any other sensor) to track whether your robot is in motion or not. You can then write a command that will stop a robot in motion, or start a stationary robot, but the RC's decision must be based on input from a sensor on the robot.
You cannot simply save a state in software that keeps track of whether your robot is moving based on when or how many times you've sent the RoboCoach command. i.e. 1st push start, 2nd push stop, toggling back and forth.
It's an important distinction to make between those two scenarios. It is possible to achieve the behaviour you're looking for, but you need to be mindful of how to go about doing it.
According to the GDC, such a thing may not be against the letter of the rules, but it is certainly against the spirit. So, if you're thinking of employing such a system, you should question what is more important for a FIRST team: following the letter and intent of the rules, or finding a sneaky way around them to perform better in the competition? I guess it really comes down to a question of what your teams goal is - to have the best performing robot, or to have the best performing team.
Question:
All of the Robocoach rulings I have read seem to outlaw the notion of software state... the action conveyed by the press of a button should be independent of any previous button presses. However, the actions are allowed to be dependent on sensor readings. Is a hardware device solely intended to keep track of state (such as a servo coupled to a multi-position switch which feeds back to the RC) in order to address a larger set of commands in violation of the letter or spirit of any rules?
Answer:
This would be a violation of the spirit, but not necessarily the letter, of the rules.
efoote868
04-02-2008, 12:24
What if instead you had a "pause" function, where you press pause, and the robot stops its actions for a determined length of time?
That would include both the start and the stop, all in one neat little package.
Also, every time you hit the "pause" button, the robot will remain inactive for 1 second more.
According to the GDC, such a thing may not be against the letter of the rules, but it is certainly against the spirit. So, if you're thinking of employing such a system, you should question what is more important for a FIRST team: following the letter and intent of the rules, or finding a sneaky way around them to perform better in the competition? I guess it really comes down to a question of what your teams goal is - to have the best performing robot, or to have the best performing team.
Yes, but you need to examine both of those GDC responses EXTREMELY carefully. This one http://forums.usfirst.org/showthread.php?t=8460 you'll notice that the sensors are "legitimately" being used, and are within the letter AND intent of the rules. The GDC response to this specific scenario in the Q&A is:
The Robocoach commands in both the Alpha and Beta examples satisfy the letter and intent of the rule. Both solutions involve reading sensors on the robot to perform the commanded functions.
That's right folks, you CAN achieve a "toggling" type action on your arm (as in the Q&A example), but you must do so by legitimately using sensors on your robot, and NOT just by software switching states based on IR remote keypresses, or by replicating those software states with a combination of hardware and sensors.
That's the difference between complying with the intent of the rule or not, and it's an important distinction. It IS forcing teams to take a higher level of autonomy, even if it's trivial to some of us.
By my reading, it should be possible, to create a start/stop behaviour on a single RoboCoach command that is within the letter AND intent of the rules. Whether you comply with the intent of the rule depends critically on whether you use sensors to determine whether your robot is in motion or not.
citrusapocalyps
04-02-2008, 18:04
Wow, thanks for all of the responses! I think the best idea for what I had in mind would be to have the function be to stop for 1 second or something like that, that way it will be sure to pass.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.