|
Re: To strategize, or not to strategize? That is the question...
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!
__________________
-=Sachiel7=-

There's no such thing as being too simple!
Look for Team #1132, RAPTAR Robotics at the VCU Regional this year!
|