Pitfalls to avoid when brainstorming the 2011 game and robot

FIRST General Forum
#19

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.

#20

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…

#21

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

#22

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.

**

#23

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.

#24

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.

#25

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

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

#26

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.

#27

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.

#28

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.

#29

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.

#30

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

One word - BUMPERS.

#32

Re-quoted for emphasis.

The bumpers offer a very unique problem when dealing with game objects resting along the walls.

-Brando

#33

But what does that mean?

Does that mean the bumpers are annoying or -
does that mean that not enough time and thought is given to them?

How are they a pitfall to be avoided?

Jane

#34

The bumpers are essentially think enough that they keep the robot a bit further off of the wall. For 2010, once you include bumper thickness and 1" of wheel/chassis width, you are essentially at the center-lin of the ball. Contacts at that point tend to actually drive the ball into the wall as opposed from peeling it off of the wall. This is due to wall friction causing the ball to spin away from your bot and into the wall. Even really good collecting mechanisms had trouble with this.
This was especially bad in the corner goals as the padding caused another edge to block the ball from going into the goal. Thus teams struggling to push the ball in those last foot.
Visually this made the robots look quite clumsy and added an unexpected degreee of difficulty to collecting and the “simple task” of pushing a ball into the goal.

The pitfall to avoid here would be testing a prototype or concept without the offset induced by the bumpers. There were a couple ball collecting ideas that were fine in the past (pre-bumper), that would have significant difficulty with the “wall manuever” if they were moved out 3 inches…

#35

Thank you, Ike. You just provided a post that can be referenced for information regarding the bumpers and the pitfalls. Cool.

Jane

#36

This problem had a pretty simple solution for teams with vacuums - just some concave pieces of lexan angled in ever so slightly (10 degrees). That way pushing a ball straight into a goal rolls it toward the center of your robot. In our case that would contact it with the vacuum.

Not particularly sure how this applies to a pincher, if at all, but it was certainly a game feature that could be accounted for and fixed in design. It was probably my favorite robot feature this year for my team.

#37

Another thing that is not really mentioned here:

Robot orientation.

Every year, 103 creates a, “Long,” robot, or one in which the front of the robot is the shorter side. For some games that requires a lot of game pieces to pick up, this is definitely not ideal. If you look at every robot on Einstein in 2009, you will notice that they are, “Wide.” They were the robot that was able to pick up the most balls the fastest, because if you cannot pick up game pieces fast, you cannot possibly score fast.

I hope that for a post season project next year that we can create our first wide bot.

#38

One thing that my team seems to always forget is to make the game object interface as wide as the front of the robot. In 2009, our ball collector was very narrow, and thus only able to accommodate a single ball at a time. To pick up a ball, we had to very carefully move the robot so that the ball was directly in front of the collector before moving to pick it up, no easy feat in a game as rough as Lunacy!

In 2010, we designed our ball handler to hold the ball at a specific point in front of the kicker with two parallel wheels, which would theoretically allow for more accurate kicks. In reality, it simply made acquiring balls in the game environment nearly impossible. During the off-season, we upgraded the ball handler and kicker to be much wider, with astronomically better results.

Of course, this applies mostly to small, ball-shaped objects. Traffic cones, on the other hand, are a far different story…