Last year was my team’s rookie year and we only had roughly 12 students on the team. After the build season was completely over, we realized how crucial it is to have a solid schedule to follow especially for the very beginning. Our team this year will supposedly surpass 40 students on the team, so how it is run will be very different. The basic schedule supplied by FIRST (http://www.usfirst.org/sites/default/files/uploadedImages/Robotics_Programs/FRC/Game_and_Season__Info/2013/2013_FRC_team_handbook.pdf Page 31) seems like a good plan to follow for the season, but I am wondering if there is a more detailed schedule for the first few days. We are wondering what is the best process to follow for designing the robot. We want to be able to consider every one’s opinions and ideas, but we also do not want to spend too much time in this stage of the season. Thanks!
Jengles,
The first step to having a successful build season is planning; this sounds like you are under way with this. To be honest, I believe this is the first time I have read that particular schedule that FIRST has provided. The overall general layout is a great launching point. I will share some our own experiences and a few pointers from other teams. Just as a disclaimer, there is no universal formula for build season; you have to find what works for you. We are here to help you learn though.
Our team has imposed a shorter build season on ourselves for the past two seasons. In 2012 we wanted a 5 week robot; in 2013 we wanted a 4 week robot. Neither of these were met, but allowed for some slide in the schedule. We try to front load the build season as much as possible, for several reasons.
Week 1 has a few main outputs - the most important is the “Requirement Analysis” - and is often referred to as the Analysis Phase on our team. On the Saturday of Kickoff we have a team meeting, starting at 8:36am and runs typically until ~4:00pm. Once the game is released we start reading the rules and identifying how FIRST allows us to score points. As an entire team we probably spend about 2 hours doing this; however, we know that at the end of the exercise everyone has read the rules. We will then reenact the game play with students and mentors serving as robots with a specific set of characteristics. Other teams, 33 for example, have used a scaled tabletop version with bagels before - be creative and have fun. then before the students leave we have a small and quick brainstorming session. There are many different methods to brainstorm as a group, For us, a team of about 40, we have typically found it best to use the “6-3-5” method (or a modified version). Essentially you break up the team into groups of 6 team members (mentors and students intermixed) each with a sheet of paper. Each member will then write/draw/sketch/doodle/etc. 3 ideas on the paper. The paper will then be rotated 5 times throughout the group with each person adding to/iterating/modifying the designs that are already on the paper in front of them. This is usually done in about 25-30 minutes. Some other things happen in the background on kickoff as well.
On Sunday we meet to discuss the “Game Level Objectives” (GLO). This is an analysis of how we think the game will be played. Some examples of previous year’s GLO (2012 I believe?) operational requirements, score 12pts in auto, score 21pts in tele-op, shoot from anywhere vs shoot from key, balance every match, go over bump. Some functional/performance requirements, ground clearance, center of gravity, shoot range, accuracy, game piece acquisition speed (lesson learned from 2012), rate of scoring. This is the main thing that happens Sunday, other than parents and a few other volunteers will construct game/field elements. This is important so you can start to see and experiment with some of the interactions.
Monday the drive system requirements are locked down - design can be started at a high level. By Friday all other sub-systems (climber, shooter, intake, storage, etc) requirements shall be defined. This ‘should’ be documented and available for everyone on the team to reference. It is a living document that can and should be updated as the season progresses. On Saturday we review all of the requirements created and established.
Throughout the week we are working on concepts for manipulating the game pieces. The earlier you can get your hands on the game pieces, the better. There are always small things that are overlooked conceptually. The sooner you can identify these and start to develop solutions the better. The big thing in 2013 was jamming of frisbees in the robot.
I will look for the presentation that the mentors are briefed on - it is then their responsibility to further disseminate the information and making sure their students understand the process. I will also look for our preliminary requirements document that we created in 2013. I know I have them both somewhere…
A great resource and another vantage point is Karthik’s [i]Running a FIRST Team presentation. The timeline starts on slide 15.
Please feel free to ask any questions. I will be happy to further explain any of the steps.
Beyond the design, be aware that there is often a “sweet spot” in quantity of robot builders at the build site when you are working. You don’t get much done with too few people…but you also get very little done with too many. With a small team last year, you didn’t likely encounter this problem. But with a much larger team you could easily have days when new members come and either don’t know what to do or don’t have quite the same self-motivation as the core group from last year. We have found (the hard way, of course) that it is imperative to break the build into highly focused sub-teams and meet by sub-teams at different times or different locations. I would recommend creating those sub-teams during your design phase (or some, at least, before kickoff even).
As far as schedules go, I’ve always thought the Cheesy Poofs schedule that they publish is a great example. Obviously the subsystems change year to year for the robot aspect, but in general it stays the same and they do a fantastic job of laying it out. I believe last year they updated the page with the 2013 schedule right after build season ended, so 2014 will probably be released around the same time next year.
Generally my team likes to have a 1 week design phase. This phase looks something like this:
Saturday: After the game is released, we break up into groups and basically get out all of those ideas that are flying around in everybody’s heads. Each group comes up with a robot design, and presents it. The only purpose of doing this is to get all of the excitement out. None of the designs are actually intended for use.
Sunday: Now we start the actual design phase from the beginning. Sunday is devoted to figuring out what we want to do. We break up into groups again, and sometimes use an informal, simplified form of the weighted objective table to rate every possible robot task that we can think of. By the end of the day, we should have a good idea of what we want our robot to do.
Monday-Friday: These days are reserved for prototyping. We come up with different things to prototype, and just do it. That’s about it. Also, people start to think of actual designs for our robot.
Saturday: This is D5 (Drop Dead Design Decision Day). We go in, we have people present their ideas for robot designs, we discuss, and by the time we leave the school, we have decided what our robot is going to look like.
Jengles,
You might want to download the FRC Team Handbook on FIRST’s website.
It has a sample build season timeline and schedule on page 31. It also has a lot of other very useful information on running and managing a team.
Here’s the link:
http://www.usfirst.org/uploadedFiles/Community/FRC/Team_Resources/2013%20FRC%20team%20handbook.pdf
I (and others) have posted on this topic before. Poke around and you’ll find a lot.
The short answer is that no schedule can really be kept perfectly, but without a schedule you’ll find yourself scrambling more than is healthy.
If you learn anything over the years, it’s Design First, Build Second. We all want to get to the solution step, but you need to define what you will do to win the game, what capabilities you need to do that, and what mechanisms you need to get those capabilities.
Only then can you consider building anything.
Give yourself a week to design everything - including prototypes and proofs of concept. Build in weeks 2 and 3, iterate in week 4 to finalize everything. Hand that off to programming, and build another exactly like it but without the ‘mistakes’, and that’s what gets bagged in week 6. If you take ‘exactly’ to heart, your drivers can practice with that first robot (this is the key to a winning team BTW).
Well said. This is the basic timeline for most winning teams.
We make it a pretty big priority to have a 1st robot done by week 4. Even if you don’t have much money to build a 2nd robot, just make the first robot out of old parts, kit bot, wood, etc. Then get it right for a great 2nd bot, the one that goes in the bag.
Also reiterating weeks 7-? seems to be a common winning approach these days as well.
Sure, many of the top tier teams do this. But it is not necessary to be successful. And I would argue that for 95%+ of teams, this is unrealistic. And if your in that 95%+, trying to do this is going to hurt more than help. You will end up rushing your CAD so you can get people to start building. And a practice bot costs a lot of money. It would be better if you just took the time to do things right with one robot. Maybe finish it around week 4-5, and use the rest of the time for programming, driver practice, and iteration. And you can do very well.
Our schedule has been evolving over the years but last year we found/stumbled into a sweet spot for our team. During week one we work on rule comprehension, game point analysis, and basic prototypes to determine difficulty of tasks, we also finalize our drive train and order the cots parts necessary During week two we work hard to prototype all the subsystems and determine one or two designs to peruse for each. Then during week three we finish prototyping and create a semi final cad model, we meet less this week due to finals. During weeks 4 and 5 we kick into high gear and finish our practice Bot and weld it in house to improve the turnaround time, then once we know the design meets our standards we make any necessary changes and then send it out to be welded by our sponsor (much prettier). We then have week six to work on programming and driver practice.
the reason we are able to have a seemingly fast build for the final robots is because we use cots products wherever possible. For example we use the kop drive unless we have a very good reason to do otherwise, we have done swerve drives, mechanum, and custom tank drives in the past but have noticed that our robots over the past 10years have been more successful when using a kop or similar drive.
You would do well to back up your assertions with actual data instead of generalizations.
In product design, there’s a triangle of budget, cost, and schedule-- changing any of them affects everything else. Being able to get a robot done (and build a second robot) is about careful management of your triangle-- in order to fit building two robots into your schedule and budget, it might be necessary to cut back on the scope of what you want to accomplish. For most teams, this is actually probably a good thing-- we call it “KISS!” It may also require more meeting time or more work to be done outside of meetings-- something which may or may not be feasible.
Sure, if most teams tried to build 254’s aptly named “Overkill,” much less two of them, they would most likely not end up in a good way-- but the assumption that you have to build a complex or otherwise “difficult” robot before you can try to build two is one I think is made too often (certainly by me and my team before…)-- if you plan on building two robots before the season starts, it becomes part of your design requirements: “Is this part/mechanism simple and cheap enough that we can make enough for two robots?” Many teams this year probably could have benefited from creating a simple plywood and bucket shooter (like Team 3313’s excellent 2013 robot) and building two robots instead of one more complex robot with a larger “scope.” I would argue that the several extra weeks of “refine-time” would be more beneficial than adding extra functionality or complexity.
Overambitious project requirements are the bane of both FIRST and real engineering projects. Avoid them, especially when you’re designing your own project.
As promised earlier, I have found our Training/Planning Brief that was presented to the student leaders and mentors prior to the 2013 build season.
I have also found our Week 1 Requirements document that we made at the conclusion of week 1 discussions. These were our initial reactions and thoughts about the game.
Let me know if you need any further clarification.
Paul,
We used to believe this as well, but deep investigation found it isn’t true. As cadandcookies wrote, simple is the key. But there’s more:
We don’t have the rest of the team waiting for CAD…everyone is CAD. (But I will admit we build first and document later, kinda backwards from what we would prefer)
The second robot always comes out better than the first, so even if you re-use all the expensive parts from the first robot you would still end up with a better robot in week 6, along with more time for programming. Fabrication goes quickly the second tme.
It is worth repeating: The key to a winning team is driver practice. Good drivers can compensate for a very poor robot.