Pitfalls to avoid when brainstorming the 2011 game and robot

[BJC]

"Falling into the Pit" comes as a result of not building a robot that solves the problem which is "the game." The first step is to identify the problem your team is going to solve with the robot (there is more than one.) If you don't solve the correct problem then no matter how well you build your robot you will not perform well. Even once you have identified the correct problem and have began to build your robot you must be vigilant that you stay on track. It is easy to sort of wander off course trying to "force" a design to work. This eats up your build season and will result in a lower caliber robot. Because of this, it is important to take a step back every week or so and make sure you're still working your way towards solving your origional problem and not overcomplitating your robot with new problems added along the way. I would say a good rule of thumb is if what your working on doesn't seem like an ellegant or simple design then probably isn't and you need to rethink what you are doing. (I think you'll find that simple ideas generally become more complex once you actually start design/build while complex ideas generally become, well... messy.)

Its also important to consider that often robots that seem very complicated to your team are in fact not to the team that build it. Don't "fall into the pit" of building something that is too complex to finish in one build season. (On my team we have a saying. "Take how long you think it (a part) will take, then double it, then double it again, then you're aproximatly around how long it'll take.") Complex features come as a result of practice and past experience. Those teams don't just decide to build their complicated drivetrain / arm / shooter / ect out of the blue. They have built them before, know how to build them, know what not to do, and have a list of what to do better for next time. As they gain experience their complex feature no longer becomes a big deal because they've got it down to a science. That is the beauty of off-season prototyping.

Just some food for thought.

[Al Skierkiewicz]

Brainstorming cannot be accomplished in one day or even in two. It takes us most of the first week to analyze the game, play the game in our heads and on a mock field to see what is the best strategy. You have to analyze the scoring and what you need to do to win against other robots and what their strategies might be. You have to consider offense and defense and weigh ideas that might come at a price in terms of risky operation. You have to decide what your robot can accomplish it it finds itself as the only alliance partner (due to missing or malfunctioning robots).
Above all, you must get a handle on time. Two minutes can be the blink of an eye when you are trying to maneuver to score the bonus or it can be an eternity when your opponent is scoring like mad and you can't do anything to stop them.

[Taylor]

Something that 330 does that we've adapted (read: stolen) is we play the game the first week. We get the field elements set up, and act as if we're robots with different functionalities and strategies. It really helps us visualize the game play and, as Al said, just how quick 2:00 is.

[Siri]

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)

Originally Posted by davidthefat

Our team took the KISS route last year, I can't say from experience because that was my first year, but looking at archives, our team did better when we went more complex. Like the omnidirectional drive a few years ago, they got an award, we didn't get one last year. The KISS method brought a very generic robot. Sure its robust and "reliable" (Not really, our robot broke down and stuff) but how is that innovative? Sounds more like imitation to me.

You may be confusing KISS with over-simplicity. KISS tends focus on reducing over-engineered systems to more streamlined ones; improving reliability while retaining the same (or better) functionality. This keeps the focus on improve/sustained performance, which is the goal of any innovation. Sure, if resources or experience limit your maximum functionality, your engineering will and should echo that. If you've got the ability though, there's no particular reason KISS should give you a generic robot. Heck, the term was coined by the lead engineer at Skunk Works.

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".

[IKE]

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. 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.

[ttldomination]

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

[Peter Matteson]

Originally Posted by Siri

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.

Originally Posted by Basel A

One issue we've had is jumping into design before strategy is decided. There's usually several ways to implement a strategy, so limiting yourself to a single design generally isn't the way to go.

Highlighted from these two posts to say I think this is the problem I've seen most frequently with teams over my tenure in FIRST. You need to figure out what you have to do before you tried to build it.

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.

[JVN]

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...

[AustinSchuh]

Originally Posted by BJC

On my team we have a saying. "Take how long you think it (a part) will take, then double it, then double it again, then you're aproximatly around how long it'll take."

A fun alternative to that is to take your estimate and multiply it by pi. Seems to work pretty well.

[Ether]

Originally Posted by AustinSchuh

A fun alternative to that is to take your estimate and multiply it by pi. Seems to work pretty well.

At work we would always just take the estimate and bump it up to the next unit.

So an hour became a day, a day became a week, a week became a month, and a month became a year.