Robocoach functions that change as the match progresses??

[kylelanman]

I have read the rules. I do realize that technically what I want to do is against the rules. But I believe there is a purpose to the rule and with what I'm doing won't be against it.

Is it permissible to have one button correspond to each ball location. ex.
Button1 The ball is left go get it.
Button2 The ball is center go get it.
Button3 The ball is right go get it.
Button4 Drive half a lap based on position of the ball we knocked off to be in the center

The problem lies where after one ball is knocked off we drive around and try to get the other ball. On the second run through the "Get The Ball(location b1,b2,b3)" we would skip the first step of the routine which is drive away from the wall before doing anything. This therefore results in buttons 1-3 doing something different depending on the point in the match.

The purpose to the rule is so people don't make menu systems and won't be able to tell there robot multiple things through morris code and what not. They are encouraging autonomy. Provided I can pull it off. Are my commands run from buttons 1-3 high level enough that the small change that actually takes place won't be noticed in terms of the rule the button has to do the same thing through the match???




Kyle

[EricH]

Originally Posted by kylelanman

I have read the rules. I do realize that technically what I want to do is against the rules. But I believe there is a purpose to the rule and with what I'm doing won't be against it.

Is it permissible to have one button correspond to each ball location. ex.
Button1 The ball is left go get it.
Button2 The ball is center go get it.
Button3 The ball is right go get it.
Button4 Drive half a lap based on position of the ball we knocked off to be in the center

The problem lies where after one ball is knocked off we drive around and try to get the other ball. On the second run through the "Get The Ball(location b1,b2,b3)" we would skip the first step of the routine which is drive away from the wall before doing anything. This therefore results in buttons 1-3 doing something different depending on the point in the match.

The purpose to the rule is so people don't make menu systems and won't be able to tell there robot multiple things through morris code and what not. They are encouraging autonomy. Provided I can pull it off. Are my commands run from buttons 1-3 high level enough that the small change that actually takes place won't be noticed in terms of the rule the button has to do the same thing through the match???




Kyle

They way the GDC has been calling the RoboCoach signals, I would not do that. They would tell you the same thing.

The only way I can see is if you had the code written such that the robot would go to the point where you started from at the other end of the field, or very close to it. Then I would say legal. Otherwise, not legal.

[Doug Leppard]

We had a discussion on this. Basically:

Button
1 = left
2 = middle
3 = right

Those buttons always get the left middle right ball that are in front of the bot.

It is marginal and some refs might call against it. I would ask in the official QA if it is legal or not.

[GaryVoshol]

I personally think this is OK. You are telling the robot to go to a location under the overpass, and then knock off the ball that is there. Presuming that you use on-board sensors so the robot knows where it is starting from, when you push button "3" the robot executes code to get it to position "3". The only way the robot knows where it is on the other side of the field is if it had some sort of location sensing. If you use that sensing the same way on both sides of the field (with your starting position being a virtual 0,0 position) I believe you are doing as the rule intended.

It would be different if the first half of the program got you to your overpass by dead reckoning, and then the robot switched to sensors to find the other overpass. In that case the first push of "3" tells the robot where to go initially. The second push of "3" would then tell your robot, "Now that you have gotten the first ball down, use your sensors to find the overpass on the other side of the field." That's a different response to the same IR command.

[meaubry]

If the second button push to get the second ball off the other overpass, requires a different sub-routine to execute it - that would be considered an additional button push.

The way I interpret the rule is that each button push represents a unique sub-routine to be executed. So, if the second button push of the same button executes a different sub-routine it is then not considered to be the same button push as the first one.

But, in your original scenario, you will push 1 button to start off with on your side of the field once you recognize which position the ball you are going after is at, then a 2nd button to get to the ball off the other side. The problem as I see it, is if you aren't using the camera or on board sensors to know where the other overpass is - and you are only relying on encoders from the drive system, you will not know "how far to go" - once you determine the correct location button to push, because you are at a different starting point.

Anyways, all that assumes that you are able to navigate around other robots that have parked waiting for the tele-operated part of the match to begin. Good luck with your program, I hope you get it figured out.

Mike

[Manoel]

Kyle,

A couple of days ago I posted a very similar question (pretty much identical) to the Q&A system, once it's replied I'll link it on this topic.

We have similar ideas on this subject; it certainly appears to be within the intent of the rules, it's the letter that may prevent us from doing so.

[Jon Stratis]

The rules clearly state that you can send either commands or field state information via the robocoach during the hybrid period. You're wording is in terms of commands, and as such wouldn't be allowed. If, instead, you worded it like:

1. Ball is on left side of rack
2. Ball is on right side of rack
3. Ball is in middle of rack

Then you're sending field state information, and that should be 100% within the letter and intent of the rules

[kylelanman]

So in terms of how I have it programmed it is fine I just need to make sure I word what each button does on the Index card that lists our functions?

[bduddy]

Originally Posted by kylelanman

So in terms of how I have it programmed it is fine I just need to make sure I word what each button does on the Index card that lists our functions?

It should be fine-that sounds exactly like what (I think) the GDC intended. On your index card, I would write something like this:

1-Tells robot ball is on left side of rack
2-Tells robot ball is in middle of rack
3-Tells robot ball is on right side of rack
4-Tells robot to drive around track

I don't think anyone will have a problem with that.

[EricH]

Originally Posted by bduddy

It should be fine-that sounds exactly like what (I think) the GDC intended. On your index card, I would write something like this:

1-Tells robot ball is on left side of rack
2-Tells robot ball is in middle of rack
3-Tells robot ball is on right side of rack
4-Tells robot to drive around track

I don't think anyone will have a problem with that.

That would be acceptable by the rules. It's field state information.

You would need to code the robot such that it would know where it was in relation to the Overpass after it turned the corner, but that shouldn't be too hard with a few sensors.

[kylelanman]

Originally Posted by EricH

That would be acceptable by the rules. It's field state information.

You would need to code the robot such that it would know where it was in relation to the Overpass after it turned the corner, but that shouldn't be too hard with a few sensors.

Do you mind telling me what kind of sensors you had in mind. I was planning on relying solely on a timing routine and hoping that we don't get hit by another robot that would mess us up but sensors would be great. I was thinking ultrasonic but I kinda thought that the range wouldn't be high enough to sense sides of the track and what not.

[EricH]

Originally Posted by kylelanman

Do you mind telling me what kind of sensors you had in mind. I was planning on relying solely on a timing routine and hoping that we don't get hit by another robot that would mess us up but sensors would be great. I was thinking ultrasonic but I kinda thought that the range wouldn't be high enough to sense sides of the track and what not.

You choose. I'm not a programmer, but when I program, my weapon of choice is an RCX rotation sensor...

Encoders or infinite-turn pots in the drive would probably work, as would ultrasonic, light sensor, timer... Choose your method.

[SteveJanesch]

We're working on something similar now, but our commands are "Get Ball 1/2/3" and "Stop", with a repeating default of running half a lap. We assume there'll be contact, and want to prevent damage to ourselves or others if possible.

As far as sensors go, we're trying to incorporate a gyro for orientation, wheel coders (with the gyro) to accumulate x,y position on the field, ultrasonic rangefinders looking left and right for position in the lane, and a range finder looking up to detect the overpass. The problem we'll face in incorporating it all is what to believe when - if no 'bots or balls are next to us in the lane, the sum of the rangefinder readings should be 13.5 feet less the width of our robot. That'll happen occasionally at best - the rest of the time the sum will be less, unless we get spun out. Should be interesting.

Steve

[Manoel]

Originally Posted by Manoel

Kyle,

A couple of days ago I posted a very similar question (pretty much identical) to the Q&A system, once it's replied I'll link it on this topic.

We have similar ideas on this subject; it certainly appears to be within the intent of the rules, it's the letter that may prevent us from doing so.

Well, turns out they had already answered it and the "new posts" section on the Q&A Forum isn't working properly.

Here's the answer to our question.