Autonomous Planning

[kamocat]

With the goal of making a robot fully autonomous:

How should robot actions be planned?

What sorts of actions should be planned? (how high-level?)

[kamocat]

Here's a couple examples of high-level things to be planned.

• Where should I move next?
• Is now a good time to kick, or will that robot get in the way?
• Should I block or score?
• Is it worth it to go over the bump?
• Will I get penalized if I go into that section of the field?

Are any of these answerable?
What information would you need to answer them?
(For how to get the information, please post in the autonomous perception thread)

[Jon Stratis]

That's an extremely tough question... made even harder because you don't know what the game will be next year! Let me give you an example for this year's game:

Lets say you have a robot with the following qualities: a suction mechanism to firmly hold onto the ball, regardless of how you drive around with it. A variable-distance kicking mechanism.

Now, such a robot could, in theory, be pretty good at scoring balls from anywhere on the field. So, the robot's managed to find a ball, and it knows it has one. What does it do with it?

Well, that depends on what else it knows. Lets say you've managed to integrate encoders, accelerometers, and gyro's with an algorithm that can constantly run in another thread to provide you with your exact current location and direction. Needless to say, that's no easy task... but without it, it's going to be incredibly hard to score that ball.

So now you have to find the goal you want to shoot at - easy, right? after all, they have big targets above the goals for you. And you aim at it, calculate the distance, adjust the kicker...

What happens if a robot is sitting there blocking that goal? Do you detect that? Do you change targets and line up to shoot at the other goal?

What happens if a defending robot is hurtling towards you from the other side of the field... does your robot know that? Does it hurry to get off a shot, or take the time to try to avoid the defending robot and line up for the shot later?


Before you can start to define how the actions should be planned, you need to know a fairly large number of things:
- What the game is
- how you want the robot to play the game
- what the robots capabilities are
- How the game is played, what sort of robot-robot interactions can be expected
- what sort of information you'll need to make an intelligent choice on the field


Like any time you're writing code, you should break everything up into small, discrete chunks. Stringing those chunks together into robot actions and strategy really depends on how your robot is making its decisions, what sort of information it has available.

[davidthefat]

Balls to the wall, go for it, no regrets...

[Radical Pi]

A lot of these questions depend on knowing the current score. For example, should I block or score? If the other alliance has been scoring rapidly, go for block. If you are losing but the other alliance isn't scoring too much then you should go for scoring.

For the "is a bot blocking the goal" problem, a simple color detection below the target should be enough. If you detect a nice big rectangle of your team's color below the target, odds are you have an open goal.

A score counter could also be useful for the goal choosing. If the robot kicks and doesn't see a ball scored within a certain period of time regularly, maybe it should switch to the other goal.

[ideasrule]

Originally Posted by Radical Pi

A lot of these questions depend on knowing the current score. For example, should I block or score? If the other alliance has been scoring rapidly, go for block. If you are losing but the other alliance isn't scoring too much then you should go for scoring.

The robot can get this info the same way a human can: by looking at the big TV screen. Possible?

[theprgramerdude]

The FMS could, in theory, be programmed to allow robots access to the current score. Just an idea, or a camera on the Operator console could be pointed at the screen, and then its just a contrast function to analyze the numbers for scoring.

IMO, Knowing where you robot is would be big. The camera could use contrast to determine what an object is, where it begins and ends, and where its going. A ball against the backdrop of the field is very noticeable, so a virtual representation could be built from it. This would be essential to any long-term planning, i.e. more than 10 seconds, or any decent strategy.

[reversed_rocker]

Well lets just say that we are going to play a fully autonomous robot for this years game. Many games have the same theme involving a ball that needs to be picked up, thrown, tossed, ect. so some of the same ideas are likely to apply

First thing, find a ball.
You could have 4 sonic rangers across the front of the ball on the front of the robot. These sensors would be spaced apart just under the diameter of a ball. What you could do is have it so that the robot spins until there is an object that gives approximately the same distance for two and only two of the sensors, this would be a ball.

Getting the ball
For this robot it would be difficult to guide the robot so that the ball would hit a particular point to be picked up by a vacuum or small ball roller, so i would suggest a double ball roller that runs as far across the robot as possible (I'm thinking a robot very simular to 1918 or 1986). When the robot finds something that it thinks is a ball, it would stop spinning and drive forward. On the both sides of robot you could have 2 photo transistors lined up parallel to the ball roller about 1.5-2 in inside the frame. This way the robot could tell when it has a ball and approximately where on the robot the ball has stuck (we use the same sensor to detect when a ball is in our vacuum, easy to use and very reliable).

Shooting the ball
Since the photo transistors aren't that accurate, you would have the code split the ball roller into 3 sections: left side of the robot, middle of the robot, right side of the robot. The robot would then spin until the camera sees the goal. The gyro would have to be set at the beginning of the match so that the robot knows which side of the field to shoot at. Once the robot sees the target, you can line up your shot using the camera again and fire. Then you start over with the ball collection phase of the code

special considerations:
This would take some playing around with, you would probly have to throw in some timing aspects so that the robot doesnt get stuck on one part of the code. Things like "if you saw a ball 10 seconds ago and you havent picked it up, go back to finding balls" or "if you dont have a ball anymore, go back to finding balls" or "if it takes your more than 5 seconds to find the goal, drive forward and try again". The sonic rangers could be used for basic driving manuevers, If more than 2 of the sonic rangers sees an object less than 3 feet away then it would turn around.

[kamocat]

Eagle33199, you've brought up some very good points.
Perhaps we need a standard way of describing a robot's strategy.

What are the roles a robot can play in this game?

• Scoring
• Blocking
• Passing

What general situations can occur?
I guess this has to be divided into properties:

• What region of the field am I in?
• How available are the gamepieces?
• What is the current score?
• Are there any 'bots blocking me?
• Are there any 'bot helping me?

So, assuming those roles are discrete, that means you have 5 factors (so far) in choosing between what role to play.

[davidthefat]

Originally Posted by kamocat

Eagle33199, you've brought up some very good points.
Perhaps we need a standard way of describing a robot's strategy.

What are the roles a robot can play in this game?

• Scoring
• Blocking
• Passing

What general situations can occur?
I guess this has to be divided into properties:

• What region of the field am I in?
• How available are the gamepieces?
• What is the current score?
• Are there any 'bots blocking me?
• Are there any 'bot helping me?

So, assuming those roles are discrete, that means you have 5 factors (so far) in choosing between what role to play.

Jack Of All Trades, be the Chuck Norris of robots, thats your ultimate goal, since you are autonomous, you really can't communicate with your team, so you have to kick $@#$@#$@# your self

[reversed_rocker]

I was thinking that the robot would play best in a passing role. Something where you wouldnt have to necessarily be accurate but still could be useful. Defense i think would be hard because more likely than not it will be necessary to track other robots. tracking robots would be hard because they can be so different, what happens when your robot is looking for rectangles when its up against a robot shaped like an octagon?

[kamocat]

David, I think you're missing the idea of inter-robot communication:
Robots can send data about what they're doing, in a standard form, to other robots, so that robots may function as an alliance.

[kamocat]

Originally Posted by reversed_rocker

Well lets just say that we are going to play a fully autonomous robot for this years game. Many games have the same theme involving a ball that needs to be picked up, thrown, tossed, ect. so some of the same ideas are likely to apply

First thing, find a ball.
You could have 4 sonic rangers across the front of the ball on the front of the robot. These sensors would be spaced apart just under the diameter of a ball. What you could do is have it so that the robot spins until there is an object that gives approximately the same distance for two and only two of the sensors, this would be a ball.

Getting the ball
For this robot it would be difficult to guide the robot so that the ball would hit a particular point to be picked up by a vacuum or small ball roller, so i would suggest a double ball roller that runs as far across the robot as possible (I'm thinking a robot very simular to 1918 or 1986). When the robot finds something that it thinks is a ball, it would stop spinning and drive forward. On the both sides of robot you could have 2 photo transistors lined up parallel to the ball roller about 1.5-2 in inside the frame. This way the robot could tell when it has a ball and approximately where on the robot the ball has stuck (we use the same sensor to detect when a ball is in our vacuum, easy to use and very reliable).

Shooting the ball
Since the photo transistors aren't that accurate, you would have the code split the ball roller into 3 sections: left side of the robot, middle of the robot, right side of the robot. The robot would then spin until the camera sees the goal. The gyro would have to be set at the beginning of the match so that the robot knows which side of the field to shoot at. Once the robot sees the target, you can line up your shot using the camera again and fire. Then you start over with the ball collection phase of the code

special considerations:
This would take some playing around with, you would probly have to throw in some timing aspects so that the robot doesnt get stuck on one part of the code. Things like "if you saw a ball 10 seconds ago and you havent picked it up, go back to finding balls" or "if you dont have a ball anymore, go back to finding balls" or "if it takes your more than 5 seconds to find the goal, drive forward and try again". The sonic rangers could be used for basic driving manuevers, If more than 2 of the sonic rangers sees an object less than 3 feet away then it would turn around.

reversed_rocker, I feel like I overlooked your posts.
Could you copy your sensor ideas to the Autonomous Perception thread?

You said the passing feature would be the easiest to implement, because you would not need to track other robots?
I think you're right.
I think it also narrows down the information we need to two things:

• What zone am I in
• Where are the gamepieces around me?

We could probably say that a robot should only be in the "passing" role if it is in the middle or far zone, and there are game pieces near.

I just realized that there are situations where a robot does not fit any of the three roles I've mentioned so far. It's when the robot is moving to a different area because there's nothing to do where it is.
Although it usually only happens once or twice in a match, it's an important strategic decision. (If you're scoring, and you run out of game pieces, are you supposed to just sit there and wait until another 'bot brings you some more?)

[davidthefat]

I want it to be so highlevel that I want the only think to get called is Pwn(); in the teleop mode... Quite possibly take in what button is triggered in a custom button panel that has multiple buttons for the different types of strategies and the manuel over drive in some kind of the button with the flip up cover would be cool

[kamocat]

Originally Posted by davidthefat

I want it to be so highlevel that I want the only think to get called is Pwn(); in the teleop mode... Quite possibly take in what button is triggered in a custom button panel that has multiple buttons for the different types of strategies and the manuel over drive in some kind of the button with the flip up cover would be cool

Hey, isn't that semi-autonomous?