Em’s Monday Night Build / Strategy Thoughts

Awesome work today guys. You’ve done a lot of thinking which is fantastic. Before we decide on what we want to design in detail and build, let’s spend some time thinking about strategy and specific elements of the game:

Ball Loading: You can do this by human or by having your robot pick them up.

For a human to do it, the disadvantage is tha you HAVE to be at your loading zone in order to load it up, and please look at the FIELD ELEMENT drawing (click here) – you might need a sharp shooter and a big basket for that person to aim into. The advantage is that it is a passive system and easy to build.

For the machine to do it, you need to invest time in building a robust system. And then you may need to figure out where the balls get queued up after they get fed into your robot.

Ball herding: You can definitely push the balls around, but you can’t have something on your robot that looks like a wedge (see rule Section 5 Page 6 – am I the only one actually READING the rules? The answer better not be yes!)

Ball hoarding: There are a finite number of balls on the field in every match (like 80). What happens if you built an awesome ball hoarder and were able to DOCK with the strongest robot on your alliance and transfer the balls to that robot?. I know this is a defensive strategy, but it can be an offensive one too.

Ball dumping: Once you have collected a number of balls, do you plan to try to dump them into the corner goal? The advantage of this is that this can be as simple as lifting up or dropping a wall. Not a lot of mechanisms that you need to design robustly.

Ball shooting: Okay, lots of talk here. This is a tough one. We NEED to understand how the CMU camera works and how it interfaces with the robot. I mean, this is enough to keep ONE MENTOR busy the entire season and I swear by that. US FIRST has already written code for us and has provided us with a ‘Camera Pan/Tilt Bracket Kit’ which means structurally, I’m not sure what it assumes as it relates to the given code. We had some great ideas like making the robot like a tank, and fixing the angle of the shooter and only allow it to spin on a turret. However, the CMU camera package may already presume more than one degree of rotation.

Let’s look into ways to make sure that we can ACTUALLY build this system in a robust way, by putting clear constraints on what we want to do with the camera. Please read the programming / brain blog for more thoughts on the camera.

So here are some potential combinations that I think we would be able to accomplish well (starting from easiest no duh):

- Human loading, strong defensive blocker, ball dumping into corner goals, solid autonomous code for dumping up to 10 balls into the corner goals

- Human loading, ball shooter

- Machine loading, ball herder and ball dumping into the corner goals

- Machine loading, machine transfers balls to subsystem for machine shooting, ball shooting (this is hard because we have two subsystems and a way to transfer balls from one subsystem to the other – we *might* not get this to work at all).

Don’t even try to do everything. If you do, I am NOT going to mentor you anymore because I will die trying to help you out. There are other combinations, but by the end of this week, I’d like you to think about what you want to do.

In terms of mechanisms: All sounds great. My biggest flag is that for spinning motors, you need to remember that they need to be ‘spun up’ to the right speed before you feed anything through it. That means you have to GATE the balls so they don’t touch the wheels before they spin up AND you have to have a loading mechanism to LOAD the balls when the wheels are spun up.

Okay, on to programming blog . . .

- Em