Hi, my name is Ben Carson, and I’m a sophomore on team 461, Westside Boiler Invasion. Technically this is my second year on the team, but i joined the second day of build season for “Breakaway”. Unfortunately because of this, I was unable to experience that “first thought” about the game along with some of the design process, partially a result of an extreme lack of knowledge about robots 
. But this year i’ve learned tons of new stuff and im almost ready to go for this year’s kickoff. Basically what im trying to ask is, from an experienced student/mentor/coach’s perspective, do you have any tips or advice as to how to go about the process of analyzing the game and appendages or special features of the robot. I understand this is kind of a vague question so bear with me, but for instance we figured out towards the end of Breakaway hanging was no where near as important as it seemed in the beginning. So what advice could you give to be able to recognize that before it’s too late? (besides making a field) Also what do you think is a good time frame/schedule for discussion time, design/CAD time, building time, driving practice time, etc.
Thank you very much and good luck to all the teams out there.
I recommend making sure you don’t lose sight of your goals for the season. Early on, find out the easiest and fastest way to score the most points as possible, and make that your focus. Other side things (like hanging in 2010, empty cells in 2009, etc.) should wait until your primary objectives are complete. I would check out this whitepaper, by JVN.
I also recommend taking a look at this thread, and look for team’s build journals if they are available in-season. This could help you gauge where you are in the build/design process in relation to other teams, and possibly help you improve your own design with some information on other teams experimentation. Even now you can learn stuff, a great example is this whitepaper, on chain vs. belts.
I would recommend reading these:
http://www.chiefdelphi.com/media/papers/2360
http://www.chiefdelphi.com/media/papers/2303
http://www.chiefdelphi.com/media/papers/2250
Highly informative and very interesting!
-RC
The #1 most important thing to do in design is to figure out your strategy. Strategy, Strategy, Strategy. Good strategy + good implementation = good robot. Lousy strategy + great implementation = sitting on the sidelines on Saturday afternoon.
To go along with that, what one element will win the game? Can you beat it? Now, how do you beat the beating method? Repeat.
Good idea: Play the game, as closely as you can, with humans as robots. Slow them down if you have to. Do this as full-scale as you can (or grab an empty FLL table and make scaled-down “robots” of cardboard). Just play–use washers or poker chips or racquetballs or whatever you have lying around the shop as game objects. What wins repeatably is probably a good strategy; now come up with a way to block it.
Understand your chosen strategy inside and out before you build anything other than the Kitbot. Then design your robot to play the strategy.
Typically, for every team that I’ve been on, the following process occurs:
Everyone who has any sort of idea writes it down and develops it on a piece of poster paper. Each idea is categorized (drive train, game piece manipulator, specialized scoring device), and KEPT SEPARATE (i.e. a drive train idea is not on the same poster paper as a manipulator), but it is noted on each idea which of the other ideas it works best with (ex. this claw works best with the 6-wheel-drive-omni design (see Drive #3)).
There is no limit to the number of these posters, and anyone on the team can create them (usually we wind up with ~20 ideas in total.)
After everyone has their ideas out on paper (usually by the end of day 1 or 2), we hang up all of the posters and start talking about the ideas. At this point we try to figure out how to combine ideas (i.e. 3 similar manipulators might be combined into one “super” idea!) At this point, it is also decided if some ideas are completely not feasible (BEWARE! Do not throw out ideas simply because they seem too outlandish. Some of the greatest ideas seem really insane at first!)
Once we have these consolidated ideas (say, perhaps 3 in each category), we decide on a plan of attack (which we’d like to take to the prototype stage to try out, etc). Usually out of 3 ideas in a category, one will become apparently non-feasable through the creation of the prototype, and then the other two will have completed prototypes.
At this point (week 2.5/3?) an evaluation needs to be made as to which prototype from each category will be kept and run with.
I hope this helps!
Jacob
Being one of the teammates who helped throw out the ball redirector design last year… listen to this guy. 
Ironically enough, I was almost going to site the ball redirector by name, but chose not to :]
From my experiences (going into my 3rd year as a member), theres a few highlights and strong points our team does during build. Hopefully these help…
We Rank certain ‘keys to the game.’ Like mentioned above, we also play a human version of the game. We try to develop a strategy before a robot. Creating a robot and making your strategy around the 'bot idea is where you could go wrong.* After we weight the keys to the game, we start developing our robot ideas. (any robot idea) Once we have our robot ideas, we narrow them down using a decision matrix. We rank the designed robots in each key to the game. The keys are weighted and we times the key weight by the robot expected performance for each robot and each category. we then add up the totals and it leaves us with a good idea of which bot to go for.
*- Just because your team made something in the offseason, does not mean you have to use it. If it applies to your stategy, then awesome and go for it. But dont get caught with an idea that doesnt fit your strategy.
As for time frames, we usually discuss rules and game keys and strategies first 3 days in that order. We spend up to a week or 2 more to choose the design we want to go for. Once we have narrowed the bot choice to a few we typically have prototyped/mocked up the designs we have it between. Ever since the beginning of robot idea producing, we start basic cads. the Cads get more complex as we narrow the feild of bots down. Then, we try to get a prototype drive running (last year, we modifyed our offseason 80/20 swerve drive to match the format we would have for this years bot [we also used that chassis to test our kicker while we fabricated the actually robot chassis.])
A good thing to try to do after that is get the final bot completed with as many days lefts as possible, without rushing through anything. The more practice time the better, and a good rule of thumb is to actually try to break your robot during build season, so you can learn how to fix it during build rather than at the competition. Getting your bot done with time to spare also gives you a chance to improve it during build. (example: In 2009, we added a couple of bars to direct the moon rocks out of our dumper after we saw we had balls getting stuck in our hopper.)
One last thing, the more practice time the drivers get, the better. Try to go to as many practice matches as possible and try to get as much drive time as possible during build.
I hope this helps, and good luck this season!
-Matt G
Essentially, the first two days are about stategy and determining what we want our robot to do. during the first two, our team will brainstorm every idea we can possibly think of, and then decide which ones are realistic. Then we put these aside and work on stategy. What elements of the game are most important, what do we think is the best way to approach the game, keeping in mind that a robot that tries to do everything is only effective if it does everything really well…which often doesnt happen.
After we come up with a good starting strategy, we apply the brainstormed ideas and figure out which design will work best. After we have a better understanding of what the robot will do, what functions are the most important and how we will go about the game (after lots of game discussion with the previous strategy discussion) we will run through multiple human simulations of the game applying different strategies.
The actual layout and shcedule of this plan varies from year to year, but it all happens within the first two days. Also, each member of our team recieves a copy of the rules so that we can have them for reference and general discussion. Hope this helps! If you need any clarification let me know!
After kickoff, our team will regroup, at a local restaurant’s hall, have lunch, inventory our KOP, and then start to determine how points and penalties are scored. We’ll review the video, of the game, and then start a human simulation of the game. We’ll use whatever chairs, tables, people, etc. are available, for the simulation, so we can get a better grasp of the tasks involved. Keep in mind, co-opertition points, for scoring scenarios. Hopefully, there will be a change, so as to prevent any 6 vs. 0 matches. After do our simulations, we’ll start a " What do we NEED the robot to do " list and a " What would we LIKE the robot to do " list. Last year, we needed the robot, to navigate over the bumps in the field, but we did not need it to elevate itself above the platform, even though we’d like it to. After brainstorming these ideas, we’ll develop a driving strategy for the different situations we think that we’ll encounter. We’ll then move onto the different chassis configurations and drive train designs. Here is where we’ll use CAD ( Cardboard Aided Design ). We’ll start doing, some more simulations, with our cardboard chassis and pretend drivetrain, to narrow down the options. We’ll also determine what we want our mechanism to do, using the NEED to and LIKE to lists.
Thanks for all the tips! Just one more question: once you agree on a concept, do you split up into groups to focus on design for specific aspects or do you keep it a collective effort? For example, this year, did you split into a hanging mechanism group, a kicker group, a drivetrain group, etc. Or did you all work on it together. Thanks
Ben, our team worked, on the design, of last season’s robot, as a group. We chose to go over the bumps, instead of going thru the tunnels. Our decision was based on the observation that the tunnels could be blocked, and/or we could get stuck in them. So we avoided the tunnels. We kicked around several drivetrain ideas, for going over the bumps, and, as a group, decided that we’d ( for the first time ever ) use tank threads. As it turned out, we used snowmobile track. We zoned out our robot, for the tank treads, for the kicking device, and for the electrical system. We chose NOT to hang from the tower. We felt that there was too much risk, for too little reward, in hanging. We felt that 5 things could happen, 2 were good, 1 was bad, and 2 were disaterous, so we avoided it. As it turned out, our robot went over the bumps TOO fast, and had to be geared down. By doing this, we lost speed, which was OK, and gained torque. Nobody pushed us around. We did the pushing. At the Wisconsin regional, in qualifying, we won 7 matches, lost 1, and tied 2. We ended up 10th out of 50 teams, in coopertition points. We moved up to the 8th position, as elimination alliances were chosen. We have NEVER been in the position, to do the picking, and we were totally unprepared to do so. The alliance partners we chose, were based on non-objective data, and we ended up losing our 2 elimination matches.
Duke,
Be sure to be at the meetings this Wednesday and Thursday, they will both be dedicated to design process training by myself and nitbaj. We’ll be doing a dry-run breakdown of a more-than-four-year-old game using 461’s design philosophies up to the point at which the concepts would be handed off to the tech team for further development. We do it pretty much like most teams in FIRST, including the JVN methods mentioned earlier.
Basically we:
- Breakdown the elements of the game and identify keys to the game.
- List all possible basic robot tasks and determine their priority.
- Convert the game keys to performance specifications.
- Evaluate the robot tasks as compared to the specifications using a decision matrix.
- Brainstorm ways to complete the chosen tasks.
At this point, the mechanism concepts are evaluated using a variety of metrics, including feasibility given the team resources (personnel, available fabrication) and the kit (motor usage, pneumatic go/no go). At this point the team design process is complete and the viable concepts are handed off to the tech subteams for technical development.
Of course, none of this works unless you can be creative, open-mined, impartial and cooperative. You and the 461 kids are all of those things, therefore, Rowdy12 will be awesome.
I hope everyone else’s robots are awesome too! I love seeing great robots at competition, the more the better.
Rollers/ rotary motion > oscillating motion.
motors > pneumatics
corrugated lexan is excellent.
center of gravity is everything
choose the proper gear ratios
when analyzing the game, try and break the game into many small steps, preferably only absolutely essential ones. for instance, a dribbler bar was often not necessary for breakaway, and one of the best teams did not have a dribbler bar or a kicker.
focus on drive train more than anything, if it drives well, it will do well.
As others have said, it’s all about strategy and figuring out how to play the game. Once we figure out how the game is played, we develop a list of *requirements *for our robot. This list doesn’t tell us how to build our robot, it just tells us what’s important. Take Breakaway for example:
- score balls
- move balls over the bumps
- hang
- be able to travel over the bump
- be able to travel under the tunnel
- be agile (sacrifice pushing power for this)
Next, as we go through our development process, we look at these requirements every day. After a week or so, we realized that we had a great way to hang, but in order to do it, we wouldn’t be able to go under the ramp. At that point we knew we could go over the bump without too much trouble, so we crossed the tunnel off the list - it was no longer a requirement that our robot be able to go under the tunnel.
Having a list like this posted on the wall helps tremendously in keeping the team focused on what is important for the season, instead of what is “cool”, but ultimately not important.
I would highly recommend paying attention to the best of the best.
1114 has (in my opinion) the best “strategy” paper I have seen:
http://www.simbotics.org/workshops
A couple points that they re-iterate and I cannot emphasize enough:
- Build within your teams ability. (if it is your first year, and you didn’t do any pre-season prototypes, co-axial swerve drive is probably too much of a stretch).
- Its better to be good at 1-2 things than it is too be poor at a lot of things. There were only a couple of really goood teams last year that could:
Go over the bump
Under the tunnel
Hang
Kick from all three zones
The rest of the best opted out of doing one to several of these attributes.
build it right the first time so no troubleshooting is required
get it to the programmers two weeks ahead of competiton so the code works
make sure it will NEVER COME APART during competition
Brian you haven’t even done a build season yet haha. (sigh noob 
)
and its a lot harder to get it right the first time in FRC.
It’s also easier to make your robot stronger in Vex frenchie. Things we didnt have on the Vex bot like chains can be a problem as you saw at C.A.G.E. match.
Thank you for the simbotics link I read the entire thing that was very helpful. Yeah i think the main problem we had this year was trying to accomplish a lot of aspects. We really should’ve scrapped the hanging mechanism and focused more on the kicking aspect
Another key aspect to designing your strategy to go along with the kind of robot you want to build is the strengths of your programmers. You can build a robot that can hang and kick from all 3 zones and traverse the bump but if you cant start from auto from any of the zones, you are S.O.L. What I’m trying to say is just know your team’s abilities before-hand.