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.
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.
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.
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.
One word - BUMPERS.
Re-quoted for emphasis.
The bumpers offer a very unique problem when dealing with game objects resting along the walls.
-Brando
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
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…
Thank you, Ike. You just provided a post that can be referenced for information regarding the bumpers and the pitfalls. Cool.
Jane
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.
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.
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…
Ike handled your last question exactly as I would have, so I will leave it at that.
Bumpers are somewhat annoying, but its just another part of the game that needs to be accounted for. I think as bumpers have become a staple in FRC, we’ve seen teams slowly start to give them the proper time they require.
When bumpers first appeared, we saw teams that had bumpers falling off left and right, and we saw teams that had bumpers so securely fashioned to their robot that it literally would take an act of god to remove them. Obviously both extremes had huge disadvantages (penalties for bumpers falling off if they were too loose, or hours spent removin/reattaching bumpers to weigh the robot for inspection if they were not easily removable).
As time has progressed, we now see nice and elegant bumper designs popping up everywhere. Most teams now design bumpers so that they can be added/removed in a matter of minutes. We see bumpers that can change from red/blue or vice versa with a flip of a piece of fabric. It’s taken a little while, but teams are falling into a groove now of efficient and elegant bumper design.
Like I said bumpers are somewhat annoying, but its just something teams need to address from the beginning as they are designing their robot. For me, it is painfully obvious when a team hasn’t put much thought into their bumpers when I get to a competition, and I’m sure it’s just as painful for the team to get through the season that way.
-Brando
We make our “object manipulators” removeable. Within the build season we will typically due several prototypes, and a couple “production” manipulators in the search for bettter collecting/control. Then it will likely get tweaked several times (some years more drastic than others) during the competition season. Assuming you have found the “ideal manipulator” is a big pitfall. Event the really good manipulators that I saw got tweaked throughout the season.
Avoid “Not reading the manual” before you start creating a strategy.
Avoid “Designing a robot” before you have an agreed strategy.
Avoid “Not being all together on a strategy” before moving forward with a design.
One key, esspecialy for newer teams, is to understand that the game rule book and design requirements are requirements, not suggestions.
You must fit inside the space requirements.
You must be under the weight requiremets.
You can only use the approved motors, epectronics, wire sizes, etc.
Incorrect, 1(77) out of 12 was a long bot that year. Oddly enough it was the team that said during the concept generation phase of robot design that year, “No widebody has ever made Einstein…”
Wish I was making this up.
Incorrect as well. This robot looks pretty wide. And so does this one. Is that Einstein I see in the background? 
Isn’t that quite a twisted fate?
But the main point that I was making is that it is important to take into consideration the orientation, and how each bot will interact, move, and preform with other robots.
Another key thing that many teams did not notice is that a wide wheel base created a much greater rotational force. Because of the greater distance between the pivot point and the wheels, a much greater torque was in effect, making it easier for wide teams to turn. And in that game, the two driving things that killed were speed and agility.
Ahh, another sometimes unseen effect of one design over another. I am sure some teams thought of this, but for most (103 included), that effect was not brought up at all.
Agreed. Once the game is released we spend a good three hours or so focusing on learning all the rules and quizzing each other on them before brainstorming starts. It makes it a lot easier in the long run.
We found those about 2 weeks into build in '09. :o
We didn’t remember them when the discussion I mentioned took place. Which illustrates the point even better not to fall into the belief that something is the “right” way to do it.