To strategize, or not to strategize? That is the question...

[Sachiel7]

Well, I can't entirely explain the title...yet. I'm waiting for the white papers to come back up to post my "paper" (book ) on the robot design process. Basically, it's the design process we're (my team) using this year. And I made it.
It's a bit different view on "strategy" as you know it. In a nutshell, it employs my rule that "You're building a machine to play the game, not a strategy"
To some of you, that might not make sense. One basic example is right in front of you : Your hand. Your hand was not designed specifically for stacking 20 bins, right? But your brain can control it to do so. That's the basis of my strategic approach. The strategy must come from the user end, not the hardware. So, when designing your robot, you're trying to decide which functions are useful for your robot to have at it's disposal. These are decided through some Plays, Detective work, and finally filtration. Also, when you finally have your functions, you might instantly have your design! or, you might even have half of it done before you begin designing. This is done through our Pre-Season design methods, which also value the strength of good designs over unused ones. There's a very different approach in this design strategy, though. I outline many "Illusions" that FIRST has set up in the flow of the competition to "deter" you from building a sucessful robot (This is just my POV)
There's also a few constant functions of a good robot in there, etc.
Anyway, I'm hoping to get the paper up when the time comes. With the aid of this method, we plan to have our robot designed the day of kickoff. Though...we don't want to rush things. Oh, you'll just have to read the paper.
Oh, and there's a little extra blip at the end on drive team strategy. When I came up with these methods I lauged my pants off at some of the teams (ours included ) that spent hours "strategizing".
Anyway, I'll post a link to the paper once it's up.
(PS: please excuse my spelling! I don't have the time to edit the post, I gotta run!)

[Ben Mitchell]

Err, you need to know what aspect of the game you want to design a robot to perform, otherwise you are building without an objective.

You should come up with at least a strategy of how you want your robot to score points, otherwise, there is no purpose of even building a robot, since you'd basically be putting parts together with no idea what to do with the thing once it is finished.

Strategy is important to the game. I have no idea what you are attempting to convey with your post - it seems you consider yourself an expert in the field of robot design, and I highly doubt you can design your robot in 24 hours.

I think that if a team wants to be successful, they need to consider how they want thier robot to fit in the overall strategy of the game, how they want to score points, and finally, how they want to play it. This considers the game and what points would be the best option for a team to try and score.

And the hand analogy was meaningless: the human hand was designed to do a multitude of tasks, including manipulating objects, so in a sense, they were deisgned to stack bins.

[Joe Matt]

I THINK he is refering to when people design a robot, they have one idea of a strategy, and build around that. A good example would be Sparky 3, MOEhawk, and all the ramp blockers. Their strategy was to controll the game, and the robot was build around just that. What he says should happen is that the robot should be build to play the game, not so that it would complete some odd-ball non-flexable strategy that we have come up with.

But I guess we have to wait to see his white paper. Why don't just upload it to the thread while it's down?

[Sachiel7]

Youre taking the "no strategy" thing a little to literally. Yes, there is a strategy, but it comes from the operator end. In other words, you choose what functions in-game would be wise to have at your disposal, and you design (or adapt designs) that perform them.
The big issue is that robots designed for one strategy aren't flexible with anything else about the game. You did, in fact, assist my example with the hand. My point was that it's not built ONLY for stacking bins. If your hands could only stack bins, what would happen if you had to pick up a ball? If youre hands are designed to have flexible device(s) that can perform several of those tasks, then the choice (ie, strategy) can come from the brain controlling it. The robot is like a remote arm in the game. It has the ability to do certain things, what it does is based on strategies coming from the user end.
My statement that we plan to have our robot designed in 24 hours doesn't imply that I'm a genius when it comes to design. It's part of my Design Process, utilizing pre-season design methods to have adaptable device designs to fit the functions decided upon by your team. We plan on taking a vote on our drive/chassis at our december meeting. What this means is that we spread out the designs we have in our pre-season design library and choose one. We vote "to use that design unless the game reveals a reason not too".
So, when kickoff comes around, if we feel like we want to use the drive we agreed on pre-season, we have half our robot done. The only thing left is the sub-systems. What will the robot be able to interact with in the game? You don't have to come up with a bunch of strategies and so-forth, there's a 5-step method that ends up with 5 or less (hopefully less) functions for your robot to perform in the game. They are ranked in importance. Then you group the functions by device, this is where you start thinking of basic ideas to accomplish a task. This will let you know that one device may be able to serve 2 functions. This is one of the steps that keeps this 'simple' factor. Then, before you start coming up with ideas for devices out of thin air, you once again utilize the pre-season design library and see in any systems in it can be adapted to fit your tasks. If so, that speeds up the project.
That's how we beleive we can have our robot designed in one day. It has been done many times. All we'll need is the sub-systems. Finding out the correct funtions for our robot doesn't take too long, and with the aid of pre-season design we hope that most of our designs can be pulled straight from the design library.
Just read the paper and you should understand. Anyway, I tried attaching it in this post. Enjoy!