![]() |
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
1 Attachment(s)
In the past, our major problem with brainstorming was that we just didn't spend enough time on it. Often we'd skip right over considering the game and strategy straight to robot design, and even then not really plan what we were trying to achieve. (Note: always set and document quantifiable/testable requirements. Always. And then work to them. ;)) We're working on it and are going to hold a practice kickoff soon with a different game to practice what we've learned.
Most important lesson: slow down. Brainstorming and requirement setting is a very important process. Give it the time it deserves. Attached is the picture I use to convey this to my design teams in college. :) (borrowed with permission: Penn State Systems Engineering) Quote:
If it works better for your team, consider using the Einstein verbiage, "everything should be made as simple as possible, but no simpler". Or even Saint-Exupéry's, "perfection is reached not when there is nothing left to add, but when there is nothing left to take away". |
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
Here is a really great link on strategic design and implementation.
http://www.simbotics.org/files/first...Strategies.pdf I was fortunate enough to get to see Karthik present this material at the Championship. READ IT. ::rtm:: Have your team review it, in a meeting. Take time to understand his Golden Rules. They are the pitfalls of most unsuccessful robots. I can't stress how great it is that a Championship caliber team like 1114 is willing to share information like this. For many teams, the most important thing to remember is the difference between staying comfortable, stretching, and over-reaching. Staying in your comfort zone will often limit your potential. Over-reaching will often end falling flat on your face. Stretching is the balance. Just like with sports, the more often you stretch, typically the farther you can stretch, and the better you will know your limits. |
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
There are a few of things that I feel my team seems to fall for almost every year.
1. The Importance of a drive train. Each year we try and focus so much on the manipulator, that the drivetrain is neglected and throw together. Ultimately this hinders overall design and performance. 2. It might not be a bad things in some cases, but the team becomes overzealous. It seems that we jump into development of prototypes a bit too early, and when those prototypes go south, we wonder why we didn't see very basic issues. 3. Not making a second robot. For the past couple of years, my team has not made a second robot, or one to practice with after ship date. This isn't because of want, but primarily because we have 2 designs we take all the way to the end, and we can't devote enough resources to developing two full, distinct robots and also creating a copy of one. 4. This one is key, but some people seem to under estimate what other teams will do. While brainstorming, some mentors/students immediately take the mindset that if we are able to score about 5-6 goals, then that's good cause barely anyone will get those. Had we stuck with this mindset, not only would it have sorely effected our design, but we would've had a rude awakening once we got to worlds where they were scoring 10+ goals almost every match! - Sunny |
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
Quote:
Quote:
Also there is a point where you have to start cutting chips so you can get something together for testing. Even if it doesn't work the way you intended you will learn from the failure and be able to move on to something that works better. Shameless copying of mechanisms that did something well in the past that you need to accomplish tasks for this years game is encouraged. Why reinvent something when you have a solution that works well. I can point out 2-3 mechanism variations that we use almost every year on my team because they are ready solutions in our arsenal that we know will be reliable. Finally reliability is king. Never underestimate the value of not breaking in the middle of a match/elimination tourney/regional. It takes 20-25 matches to win the championship 10-15 of which are in the elimination tournament alone. Assume you have to do this with minimal maintainence to be competitive, because you can't play if you don't get out to the field everytime. |
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
Some people think the secret to a great robot is a full team of engineers and a small mountain of corporate money, it isn't.
The secret is prototyping. Whatever you're going to do, you need to play around with it, test it, tweak it, and learn if you're idea is a good one LONG before you try to execute it. Follow a design process, for success. The most successful teams in FIRST all rock the prototypes... |
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
Quote:
|
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
Quote:
So an hour became a day, a day became a week, a week became a month, and a month became a year. |
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
Quote:
Innovating for the sake of innovating, reinventing the wheel is probably the second biggest pitfall you can fall into when designing an FRC robot, if the wheel is already a very optimized, good solution. During the initial brainstorming, say anything you think of. Don't limit yourself at the VERY beginning, but be practical. Make sure it is something you can do. --- By far the biggest pitfall I've seen is doing more than a team is capable of. It takes far less than you think to be competitive in an FRC game, especially considering the alliance structure, but you have to do that task well. It doesn't even matter if it's the RIGHT task; if you do it well you'll be successful. If your team was a turreted shooter in 2009, or your team tried to hang before you finished your ball possession, you probably know what I'm talking about. For 2791 this year, we're going to figure out the best successful strategy that involved our robot doing as little as possible, and we're going to perfect that. There is always a way to score a number of points relatively easily that is simpler than perhaps the most obvious method. In 2009, anyone who dumped beat 75% of shooters. In 2010, shockingly few teams were adept at scoring from the front zone, which was literally just pushing a soccer ball up a ramp. Sure it's "easy", but what if your robot was like 910, 971, 359, or many of the other great front robots this year? They took the "easy" objective and dominated it. -------- The other big catch I see is not focusing on the right parts of the game. How many people designed their robots to "kick and hang" this year? When you really look at the problem, you learn that before you can kick, you need ball control. In order to score a lot of points, you'll probably need to change zones. When you identify the problem, make sure you identify the WHOLE problem. |
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
Here are some of the pitfalls we experienced (in no particular order):
1) We took pride in our ability to figure out the game and come up with the basic layout of the robot really fast - like Saturday afternoon - so we would have plenty of time to prototype and build the ill-conceived fruit of our haste. Faster isn't always better. 2) We built parts and subassemblies (gearboxes, etc.) when we could have used kit parts or bought suitable COTS parts. Its tough to admit that our home-grown ideas aren't always the best way to go. 3) We built the "low cost team field elements" and didn't consider how they differed from the "real" ones. For example, in 2010 we only looked at the steel crossbar on the tower when thinking about our lift concept. The wooden 4x4 support posts didn't inspire any thoughts about a curling lifter. 4) During brainstorming, we restricted our technical approach to concepts that were "possible". "Possible" was defined as something we already knew how to do. This is where the rookies really help. Reality hasn't beaten the creativity out of them yet :D. 5) We tried to be too sophisticated, and built machines with too many potential weak links. They were pretty useless unless everything was working perfectly - which was rare. KISS! 6) Our robots were hard to drive and operate. They made unrealistic demands on operator skills and cooperation in a match situation. KISS again. Hopefully, we learned something from our past mistakes. However, its still hard to tell the difference between "great", "good enough", and "fail" during build season. We can study rules, develop a strategy, list desirable capabilities of the robot, and build prototypes. Like most teams we go through this process in a mild vacuum and we won't know if the machine we decided to build was the right one for the game until we get to the competition. In general, the best robots do the essential tasks quickly, reliably, under difficult circumstances, and are easy to operate. KISS (done properly) is one common thread that ties these all together. Ingenuity is another, but we haven't figured out how to impose that one on ourselves yet. |
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
I'd have to quote the whole thread, it contains so much excellent wisdom. Thanks!
Quote:
|
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
Quote:
Other years we get the first two parts right, but we settle for good enough without realizing that other teams are building better machines behind closed doors. We don't realize it until after ship. The past two years we have been able to fix our deficiencies by making modifications at events, but other years we aren't able to overcome the poor decisions we made in the first couple weeks. We haven't figured out how to fix the problems yet. Maybe we'll get it right this year. |
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
I'd have to say that one of our team's downfalls has been the "Did you see how Team XXX is doing that? They just posted some vid/pics on CD!" syndrome. Lack of confidence in our own ideas and designs and feeling like we have to try what others are successfully doing drives the creative process into a ditch. And while I'm not saying that researching what others are sharing on CD is a bad thing, there's something to be said about executing on your plan with confidence and learning something new.
|
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
If there are loose, spherical objects on the field, the majority of them will come to rest against the edge of the field. Be able to pick them up there! Year after year teams struggle with this, and it never gets any better...
For less experienced teams (or those without good software people) -- do not anticipate, or rely upon complex software solutions. Keep It Simple, Keep It Mechanical. We had great software guys (one of them had wonderful stories about working on the Apollo program), but we never finished the mechanical stuff early enough to give them adequate time to test. Speed. Whatever you do, do it well, and do it fast, so you can do it more times in a match. You (and everyone else) will probably overestimate the average good robot. It has been my experience that typically a robot that can reliably score the starting load is an eliminations worthy robot. I think that's a good starting point. I also think pretty much any team could benefit from building more simple prototypes. I think $300 spent on an extra drill battery (or two), some 1/2" steel shaft, PVC piping, 1/2" plywood, 2x4s and sheetrock screws, a couple of pulleys and small stash of polycord is some of the most effective money a team can spend. |
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
Quote:
Since then, teams haven't been able to pick up in that area very well. 2010 was kind of an anomaly, because you couldn't really slurp the balls in, but 2009 and 2006 had a lot near the edge. |
Re: Pitfalls to avoid when brainstorming the 2011 game and robot
Here's a few things our team needs to improve on:
|
| All times are GMT -5. The time now is 13:06. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi