|
|
|
![]() |
|
|||||||
|
||||||||
| View Poll Results: How much planning goes into your robot? | |||
| Drafting - None or very little pre-assembly planning - Hey, We're Optimistic. |
|
27 | 12.39% |
| Drafting - Moderate - Only essential systems are drawn up. |
|
94 | 43.12% |
| Drafting - Extreme - You could drive the robot before it's been built! |
|
73 | 33.49% |
| Calculations - None or very little - We live on the edge. |
|
18 | 8.26% |
| Calculations - Moderate - Yeah, we did a few to get some things right. |
|
107 | 49.08% |
| Calculations - Extreme - Is that an African or European Swallow? |
|
59 | 27.06% |
| Robot!?!? You mean we're supposed to be building a robot!? |
|
30 | 13.76% |
| Multiple Choice Poll. Voters: 218. You may not vote on this poll | |||
|
|
Thread Tools |
Rating:
|
Display Modes |
|
#25
|
||||
|
||||
|
Re: How much planning goes into your robot?
Well... It all depends on which team I've worked with that we're talking about.
Some of my old teams have sponsors that have their own methods, that range from a mix of student/sponsor design to students stating WHAT they want the robot to do, and the sponsors then fully design a machine for them to manufacture. I'll let them speak for themselves. Now as for "my teams" (the few I'm working with the most), I've provided a "Formal Game Analysis" method to help the *students* mathematically figure out what designs will work, and what probably won't. It looks at a game and *suggests* a range of *possible* tactics and bot designs. (BTW, what it suggested for THIS year blew even ME away!). I could talk about that method, but that's a whole separate thread, and not relevant at this point of the season. Anyway, one way or another we're left with a set of PRIORITIZED GOALS for the machine, AND the overall machine's concept. Next, **THE BIG RULE: "Machine Goals will be accomplished in PRIORITY ORDER". Resources ($$, people, matl's, weight allowance, etc.) shall be shunted from lower goals to achieve higher, as needed."** No sense building something that won't accomplish your #1 goal! Ex: A few years ago, we had: #1 as "Grab Small Balls", and #4 as "Handle Big Ball".Well, during design the Big Ball Arm got in the way of the small ball collector, so it was dropped! We next make the goals CONCRETE, and PRIORITIZE them. Ex: We don't say "It'll score a lot". Instead, concrete actions, speeds, and times within the round are all defined. For example: "In Auto Mode, the machine shall take no longer than <xx> seconds to <move to this position> <do THAT> (or whatever)." That's pretty specific! Of course with a 10 sec auto mode this THEN suggests that "In Auto Mode, the PAYLOAD must require no longer than (10-xx) sec to <do ITS specific thing>", etc. We then do this for ALL actions, at ALL points throughout the game. This yields a VERY specific set of performance specs for the machine, but does NOT say HOW they should be accomplished. At this point, my teams diverge again... Some of my old teams then use "Centralized Design". The entire thing is worked out in ALL detail. CAD drawings are made, etc. The build now progresses like a manufacturing plant. Yea, this works well for some teams, and their sponsor's philosophy. The design is well controlled, Production management tools can be employed, etc. But if you have TOO much of that, I've found it hard to get anyone to show up to BUILD it! If for any reason they haven't felt a part of the decision process (which often happens if you decide AGAINST their "favorite design") they may even *abandon* the project because now they are ONLY "labor for someone else's machine". (Hmmm...) My current team uses a DIFFERENT philosophy. We let the SUBGROUPS make ALL the manufacturing decisions for THEIR part of the problem, DURING the build. After all, they are the ones that have to make it work, they already have a very specific set of design goals in hand it MUST accomplish, and a manufacturing timetable to meet. So let's say for example Drivetrain decides to choose a walker bot over a tank. Our rule: If it can meet ALL of the design specs we laid out (including time, weight and size allocated to it) AND it can be made to work in time, GO FOR IT! This isn't without its own challenges... We often have some verrrrry nervous mentors! But we HAVE "local" mentors in each subgroup to keep an eye on it. You also don't KNOW exactly what you'll end up with when they start! But the advantages are many: 1) We get to building sooner. Once the spec is in place, they GO. 2) It challenges the students. All of the problems have NOT been worked out when they begin. They have to THINK, and there are many opportunities to teach them about how to solve something. 3) It encourages "creative problem solving" on the fly. Some VERY cool stuff has come out of groups to cure certain problems encountered. 4) The design isn't "fixed in stone". If one thing won't work, the local subgroup has the AUTHORITY to change things, whenever needed. For example: If Drivetrain's "super delux 27 wheel drive" they're attempting is overweight, won't work, or parts aren't available for it, AND a basic two wheel two castor drive WILL, Drivetrain group is FREE to change it in the MIDDLE of the build, as long as it won't affect the STRATEGY of the bot. 5) We're free to EXPERIMENT. A subgroup that's ahead of schedule may decide to try another thing, to see if that will work BETTER. (...and if it DOES work better, use THAT instead!) But really, HALF the fun of this method is we DON'T know what the bot it'll LOOK like, until we're done. Yes, we know what it will DO, and when it'll be READY, but the final form is VERY mutable during the build. Also, we all often drop and run over to look when someone comes up with something REALLY cool, which means you don't want to miss ANY build sessions! But the best part is that when you're done, EVERYONE feels ownership. You each know that YOUR decisions made during the build contributed to <this> or <that> ability of the final robot. Now don't get me wrong... I'm not knocking Super-CAD/CAE driven teams at all! Testing a design on a CAE system REALLY helps! And if you have way too large of a student/mentor ratio, having a huge work plan predefined helps. People can just come back when they need more work, and grab "Task #27" off the queue. VERY efficient. But if you don't have a lot of CAD/CAE expertise on hand, giving everyone the freedom to make LOCAL decisions DURING manufacturing DOES work, and may even get you off the starting block a bit sooner. Now IMO, the KEYS for ANY build method are having: - WELL DEFINED GOALS for the robot to accomplish; - A good work schedule defined up front that they MUST meet; - Make sure everyone has the RESOURCES to accomplish (training, matl, money, mentors, etc.); - Someone in EACH group responsible for keeping an eye on the schedule (no getting caught in trivia, we have a schedule to meet!); - Having the GUTS to drop one line of research for another, if needed; - GOOD COMMUNICATIONS, so everyone knows the status - between all subgroups, students/mentors, teams and sponsor's locations, team and school, etc. Does that answer your question? I hope this helps! - Keith |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| serious problem found - robot controller resets when jarred! | KenWittlief | Electrical | 23 | 19-03-2003 13:30 |
| Image Discuss: 810 - Minotaur: Coming to a regional near you. | CD47-Bot | Robot Showcase | 47 | 25-02-2003 16:19 |
| WASH Palm scouting at the Championship | Mike Soukup | Scouting | 2 | 19-04-2002 15:14 |
| Index of team's post about their robot... | Ken Leung | Robot Showcase | 1 | 20-03-2002 17:10 |
| about how Drive Train push the robot... shouldn't the force accelerate the robot? | Ken Leung | Technical Discussion | 12 | 26-11-2001 09:39 |