Pitfalls to avoid when brainstorming the 2011 game and robot

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

[Chris is me]

Originally Posted by davidthefat

With that in mind, that is one reason for having such ambitious goals this year: Not to be ordinary. "Innovate not imitate" is one phrase that really stuck with me from the whole FIRST experience; I am taking that to heart.

Your simple robots didn't do well because they broke, you said it in your post. So obviously they weren't simple and robust enough. To be completely blunt, if your simple robot wasn't successful enough, what makes you think a complex robot will be more robust and successful? Because you'll get a trophy for a gimmick?

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.

[Wayne TenBrink]

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 .

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.

[DonRotolo]

I'd have to quote the whole thread, it contains so much excellent wisdom. Thanks!

Originally Posted by maverickfan138

Our last three robots have had a minimum of moving parts, yet were extremely offensive.

I can attest to this, I for one was extremely offended when I saw their 'bot(s). ;-)

[Mike Soukup]

Originally Posted by Jay TenBrink

What are some of the painful pitfalls your team has fallen into when brainstorming the game/robot that you know to avoid now that you're older and wiser? What will you do to avoid these pitfalls in the future?

Over the years, we've built a few robots that haven't lived up to our pre-season expectations. The major reason for our failures has been that we underestimated what was necessary to be a top tier player of the game. During brainstorming, we sometimes dismiss ideas as not being possible only to find out later that the best teams successfully built the impossible. Sometimes our brainstorming process fails to lock in on the single most important element of the game (ball control in 2010, hurdle cycle time in 2008) and we don't properly prioritize it.

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.

[keericks]

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.

[Ian Curtis]

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.

[EricH]

Originally Posted by iCurtis

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

No. Kidding. Back in 2000-2002, the balls started against the walls and rails. Teams slurped them right up--I remember 330 in 2000 (2001 and 2002 didn't handle small balls) being able to go straight up to the far wall and slurp in 3-4 balls that were resting up against it, no problem. Dump them into a goal, repeat for another minute fifteen, and use the remaining 30 seconds to hang, because that was the game that year.

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.

[TD912]

Here's a few things our team needs to improve on:

• Although every part of the robot needs to function well, focus on the parts that will allow you to score. (Although this may sound obvious, our team focused on our drivetrain a bit too much last year, while our kicker and hanger were a mess)
• Sometimes you should just use a KoP or COTS part instead of wasting time making your own.
• Think of how easy controlling the robot will be for the driver. The simple change of the layout of buttons on a joystick or gamepad can make a big difference. (Also try automating some things in programming so the driver doesn't have to concentrate on too much at once)
• Test every feature of the robot a lot! Even if it is as trivial as driving around in circles or picking up a gamepiece! We failed to test some of the most basic things in our rush to tack on more ideas.
• You can make it complex as long as you can finish building it and make sure it works.