Build season week 1
 

Hey guys, i'm wondering what does week 1 of build season look like for different teams. Any comments would be appreciated. Typically the team i'm a part of will look through the manual, explore the rules, split into sub teams, and start coming up with basic designs either by CAD or sketches.

Re: Build season week 1
 

We split up into sections of two or three people each, doing 10-20 pages each. We'll do some analysis of all of the different scoring options, but we don't talk about robot design at all at this point. We find the most efficient scoring system for us, then we start designing a robot, usually until Wednesday where we settle on a design. We go for the quantity over quality in the beginning so that some ideas can transfer onto a more sane robot.

Re: Build season week 1
 

We send several students to the kickoff at San Jose State, and we got together with 4904 (another local team) to watch the video. The students that went to the kickoff then joined us after having picked up the KOP. We then watched the reveal a few times, then split into groups to read the manual. We then went back to our school to go over the manual again.

The next day we taped out the dimensions of a whole field on the floor in our main building, and set up mock field elements. We than went through simulated matches with students and mentors pretended to be robots until lunchtime to get a feel for the game play. We then all met together, went through the manual, and then identified several different concepts we could pursue. We split up in to groups about concepts we cared about, developed a presentation, and then each group presented to the team. We all voted, and chose the low goal/ball resupply/breacher concept.

The next week was spent building defenses and a partial castle, building the AM14U3, and prototyping, both physically and in CAD.

I'll upload some photos of the whole process when I get home.

Re: Build season week 1
 

1836 has done a bit of a different thing each year, however last year was definetly our most successful beginning of build season. After the typical game manual readthrough and dicsussion, we immediately got to building. At about week 1.5/2, we had a fully functional super sketchy stronghold prototype robot (driving, intaking, and shooting all in one). Everyone involved was so impressed by our prototype robot, and that robot drove our design process for the rest of build season.

Re: Build season week 1
 

It's been a bit different every year. For 2016, Saturday and Monday were pure rules and strategy. Tuesday and Thursday we began concept designs and prototyping (both CAD and real-world). By early in the second week we had a solid chassis design, and the manipulators were down to a couple of candidates each. This worked well for us, and we're going to shoot for about the same schedule (or just a hair faster so we can fall back to this) for 2017.

Obviously an edit:
Same here -- it is difficult to imagine our strategy and early design process without whiteboards and cellphone cameras. Chalkboards were available going back several generations, but film and development was expensive - Polaroid was around long before FRC, but even more expensive! If you wanted to keep records of brainstorming sessions before about 1990, you were probably using flip charts and marks-a-lots. (really large pads of paper and sharpies for those too young to know those terms).

Re: Build season week 1
 

Here's a video of our "super sketchy stronghold prototype" and how it evolved.

Re: Build season week 1
 

Our team spends an all-day meeting for kickoff, rules discussion (understanding them) and then get to thinking about how we want to attack the game. We discuss our preferred strategy first, so we figure out what we want to be able to do.

Throughout week 1, our whiteboards get extensively dirty drawing up concepts up to about Monday/Tuesday of week 2, when we have a list of subsystems to build already.

Re: Build season week 1
 

For us, the first 1.5 days or so is all about the rules. We spend most of kickoff just digesting the rules and then analyze what we think are the most valuable aspects of the game from a rules perspective. By the end of Sunday we have a ranked list of all the tasks in the game. We then spend most of the week prototyping, prototyping, prototyping, prototyping. (By the way you should really prototype during week 1 if I wasn't clear before. :D ) But seriously, prototyping is super important. By the end of week one we have a general idea of all of the mechanisms on the robot and spend the next few weeks refining the robot. So, this year for example, we were pretty sure that we were going to have a wheeled shooter on a tank drive chassis with pneumatic wheels and some sort of intake by the second Saturday. At this point we will also seriously start to CAD.

We also spend some time (this year A LOT of time) on building field elements during the first week. We also usually make sure to order a few things that we know we will need/will sell out quickly/game pieces early in the week, so we don't have to worry about it later and risk long lead times.

Re: Build season week 1
 

A few of our students wrote about our different process above and I wanted to elaborate on it. A few years back we had a really hard time making decisions off of your typical white board drawings and strategic discussions. I know that this works for many teams but ultimately we felt we ended up making bad decisions because we did not have enough information. We changed our decision making process to first get as much information as possible through prototyping instead of on speculations on how the game will be played. We did our best to prototype everything. Our prototypes told us a lot about what we as a team would be capable of and helped us to build within our resources. Having some product very early in build season is very rewarding.

Re: Build season week 1
 

These are good things to talk about before the season gets close and all teams should have a game plan for where they want to be at the end of week. Always remember though, each team is different and just because someone has finished all of their prototyping by the end of week 1 doesn't mean you should be too. Come up with a plan that works for you!

By the end of week one I'd like to see our key field elements built so we can be testing our prototypes & strategy. The team should have a grasp on the rules and understand basic gameplay. Most teams try to have their strategy nailed down during this week but I've found for us it typically doesn't happen until week two or later. This past year it wasn't until week four that we had a defined strategy and spent the initial weeks with a more aggressive strategy but kept our options open to pursue a few robot styles. In a "normal" year we try to have our drivebase in stone/begin the CAD model by the end of the week but years like 2016 require more testing and prototyping.

Usually before the season the design team has already discussed what we can learn from the previous season so we can learn from our mistakes or iterate what we found successful. This encompasses all aspects from strategy, design, prototyping, manufacturing, practice, etc.

Re: Build season week 1
 

I wouldn't pretend to be an expert on this topic, but I do have several years experience with it, and I've done a lot of thinking on it.
My dad and I made a power point for a seminar on the topic of the first week a while back and you may find it helpful.

https://docs.google.com/presentation...it?usp=sharing

Let me know what you think!

Re: Build season week 1
 

Our week 1 of build season is pretty hectic. On day 1, we split everybody into 6-7 groups of 4-6 people and each group is in charge of a certain section of the manual we assign to them. Then, we take one person from each of those groups and create new groups, and they share out in their new groups what they've learned from their section of the manual. This allows for people to get a well rounded view of the game without have to read the whole manual themselves (granted, a lot of people on our team do that anyways!:] ) Day 1 we usually start to discuss the What? question: What do we want our robot to accomplish? We try to restrict the ideas of robots because that can get a little to hectic. Then we go to our gym and do a game simulation using people as our robots to get a feel for the game play. Day 2 is where we start to introduce the How Question: How do we want the robot to accomplish the Whats from Day 1. Everybody shares their ideas on a whiteboard, and we usually let the rookies go first so they don't get drowned out. From there, we assign people to prototype different sets of ideas and by the end of week 1, we try to have a basic design of what our robot should look like.

Re: Build season week 1
 

We tested this platform last year and I believe we will continue it:

Day 1: We watch the kick-off. This allows people to get ideas in our head, but we don't allow people to talk about robot design or gameplay until we split off into premade groups.

Day 2-5 (?): We continue discussing in small groups to allow people who are shyer and would be less willing to speak in a whole team discussion be more comfortable sharing their ideas.

Day 5 ( I believe it's the 5th day): We meet as a team and each group presents their "prototype robot." This robot can be a CAD, a google sketch up, or just explanations with no drawings.

The team then decides which is best feasible design with our mechanical knowledge, time, resources, how we believe the game will be played and how we can maximize OPR and be most useful to our alliance.

Re: Build season week 1
 

we gathered up to watch the game broadcast (in israel it was broadcasted at 17:30) and then spent the rest of the evening and the following day figuring out the game and translating the rules to hebrew, and then we decided what our robot will do, and about 2-3 after kickoff we started to sketch some sub-systems and stuff so by the end of the week we had a based idea for a complete robot, and at the weekend we have started to build the field.

Re: Build season week 1
 

I realized that it is not clear from my earlier post, but our week 1 prototyping was primarily for the purpose of determining the "difficulty" of various manipulator approaches. Of course, we always want to remember the key points were from these efforts!

As I read through the responses, I realize that someone should more clearly state that the design process should generally run:

1. Understand the rules (requirements)
2. Plan your strategy (that is: which requirements/rules/scoring opportunities take priority)
3. Prepare two or more designs
4. Evaluate designs against your strategy and priorities; pick a design.
5. As problems emerge, evaluate proposed design changes against your strategy and real-world findings

Most teams should probably be in step 3-5 overall at the end of the first week; we have been both significantly ahead of and significantly behind this in various years. We currently strive to be at step 5 for the drive system and step 3 or 4 for manipulators by the end of week 1.