The First Seven Days of the Season

[ttldomination]

So, through just talking to general people and teams, it's interesting to hear about how teams work for the first few days.

Ultimately it's a mash-up of prototyping, designing, and CADing, but it's interesting when you drill down into the details. Some teams talk about robot design in the first few hours while others don't visit robot design in the first few days. Some seem to settle on a design in a couple of days while others try hard not to focus on a specific design until the first week is out.

I'm just looking to see what other folks are doing out there. I'm interested in all approaches, both successful and unsuccessful, and what the ideal first seven days ought to look like.

- Sunny G.

[marshall]

We had a radically different approach this year and it paid dividends. As soon as we got back to the lab after kickoff we took the game apart using statistical analysis and mathematical modeling.

We realized on day one that the key to a high score was a short cycle time. We also proved that you could reach high scores with high scoring cycles but would end up with less of them and we predicted it would be hard to achieve those scores while maintaining control of the ball. At any rate, we spent the day taking the game apart until we had some nice graphs and charts to look at. We then chose our strategy based on that analysis of the game.

After that, we spent the first week working on the mathematics of the mechanics of the strategy. Basically, feasibility studies of different design ideas. By the end of the week we had a prototype built and were testing.

Overall, this approach lead to a couple of interesting observed behaviors. Breaking down the game mathematically made it so that pretty much everyone agreed unanimously on a strategy which made the design process easier. Performing the mathematical modeling on the game made it so that everyone could see the strategy even though not everyone fully understood the analysis behind it (it wasn't necessary for everyone to).

Performing the calculations of the various designs also made it so that everyone saw the pros/cons and we could easily make a decision about how to move forward.

As a mentor and someone who has been doing this for nearly 10 years, having a group of students that all agree is something that is rare and special. Using math and analysis forced us to all come to an agreement and do it sooner rather than later so we were more focused on what needed to be accomplished sooner in the build season.

It was a good first week for us and a good season overall. I can highly recommend this approach.

[Lil' Lavery]

A general overview of 1712's first week (usually spills over into week 2)

Kick-Off Day:

• Attend Local Kick-off
• Watch broadcast
• Pick up Kit of Parts
• Inventory Kit of Parts
• Discuss game as group until a common understanding of game is reached
• Compile questions about game
• Use rulebook to answer questions
• Scoring/point allocation analysis
• Dicuss/understand purpose of penalties (how to "break game")
• Create list of possible activities/functions for each phase of game
• Discuss possible alliance strategies (strengths/weakness of each)
• Discuss possible/probable robot archetypes (what functions will be popular, what functions compliment each other)

Meeting 2:

• Review game & rules
• Reassess anything we missed/interpreted incorrectly (this year, we didn't understand the hot goals properly during our kickoff meeting, for example)
• Work towards selection of a game strategy
• Develop a priority list (Need/Want/Wish)

Meeting 3-5:

• Create decision matrix
• Design Brainstorming (various iterations and discussions)
• Mechanism prototyping
• More detailed/critical analysis of proposed designs
• Evaluate subsystems in decision matrix
• Attempt to arrive at consensus design
• Start drivetrain assembly

Things don't always go quite as planned, and the schedule can shift around. We don't incorporate as much CAD into the early season as we'd like to, but we also don't know where we'd find the time or manpower.

[Knufire]

For 5188:

Step 1: Read the rules. And then read the rules again. Then, get together as a group and read the rules together. Discuss any of the confusing ones (this years would be how assists are scored) and make sure EVERYONE is on the same page. This usually takes a good chunk of Saturday.

Step 2: Make a list of functions (basic tasks) the robot can do. Put special effort to make sure that the language of the function does not lend itself to a certain design, e.g. saying "put frisbee in high goal" instead of "shoot frisbee in high goal". This list should be extremely exhaustive and include anything you could ever imagine a robot doing in the game. This usually takes up the rest of Saturday and a bit of Sunday.

Step 3: This step can take many forms, anywhere from mathematical models as Marshall mentioned to some pieces of paper and a whiteboard to a bunch of kids in a gym with the game piece. I usually refer to this step as match simulation, but the goal is to really figure out how the game is going to be played. We typically pick a few functions from the list we have generated (figuring out which functions together would make a reasonably feasible robot is one of the hard judgement calls) and attempt to simulate what a match would be like with those robots. We generally break it down into intervals of 15 seconds each in order to make it easier to keep track of what's going on. After the match ends, we attempt to identify the deciding factor of the match/why did the victorious alliance win. This process can go on for multiple days, as we attempt to reach a fairly large consensus on strategy before continuing. We try to finish this up Monday, if not Tuesday.

Step 4: Once we have our strategy solidified, we go back to our list of functions and put more thought towards which of these functions would best accomplish that strategy. Remember, in most games, it's better to play a role than attempt to do everything. We then prioritize the chosen functions (hint: if move isn't #1 on your priority list, you're probably doing it wrong). This is usually finished up by the end of Tuesday.

Step 5: Now that we've decided what we want the robot to do, we start brainstorming actual concepts to execute these functions. Usually I try to break up students into smaller groups, mixed between veteran and new students. They debate these concepts and try to refine them as much as possible. Basic calculations and sketches to determine the feasibility of these concepts is encouraged. Groups will also develop their own prototypes to aid in this process. This usually fills up the rest of the weekdays.

Step 6: Now we will meet back together and list out all the concepts, usually per system, and deliberate between these. Decision matrices are made. Prototypes are demonstrated. Discussion essentially continues until a consensus is once again reached on what the robot should generally look like.

Step 7: Everyone breaks up into subteams, mechanical goes to CAD the robot and further develop prototypes if necessary.

Side note: If you want to try to break the game, it's done in Step 2 and 3.

[mfine]

Can you explain more about the analysis you did? It sounds really interesting

[Abhishek R]

We start prototyping the day after kickoff. We try to come up with as many initial concepts for mechanisms on kickoff itself.

Once the prototypes near completion and we test their efficiency out, we settle on a design and start putting bit by bit a wooden mockup of the robot. We have to run a pretty tight schedule since we build two (as close to as possible without CAD) identical robots, but we don't build them simultaneously. We begin with the practice robot and aim to finish that by week 4, then build the competition robot in the remaining weeks (it goes by faster once we've built the first one).

Something I've noticed we do differently, for better or for worse, is we don't dedicate an entire week or even a day to strategic planning or an attempt to model the game beyond kickoff. This is probably something we may want to think about a bit more as the games get more complex (in most years, it's basically been score max autonomous points, score a lot of teleop points, then accomplish the endgame as fast as possible). This may have led us to rethink the importance of being able to pick up the ball quickly for assists.

[marshall]

Originally Posted by mfine

Can you explain more about the analysis you did? It sounds really interesting

Basically, we broke down the scoring mechanics of the game. I wish I had the charts and graphs to post but I don't at the moment. I might put a student on posting them before too long but they are working on some other number crunching for us at the moment.

The charts aren't anything special really but they forced the conversation for our team to be about optimum scoring strategies rather than the less productive "lets build XXXX".

We used the EWCP TwentyFour blog posts as the basis for a lot of what we did: http://twentyfour.ewcp.org/. This post in particular has been very helpful for breaking down the timing of tasks: http://twentyfour.ewcp.org/post/5892...hat-time-is-it

That whole blog is required reading for many of our students.

Speaking of reading... read the rules and understand them. That's a critical component to being able to analyze the game. One of the objectives on the second or third day for us was a group reading of the rules. It worked out well and I suspect we will be doing that again. Many of the newer students on our team weren't fully familiar with everything and reading the rules gave them additional insight and gave them an opportunity to have their questions answered.

[mklinker]

Day 1: School closed due to snow and cold no robotics

Day 2: School closed due to snow and cold no robotics

Day 3: School closed due to snow and cold no robotics

Day 4: School closed due to snow and cold no robotics

Day 5: School closed due to snow and cold no robotics

Day 6: School closed due to snow and cold no robotics

Day 7: School closed due to snow and cold no robotics

The rest of the season....CRAZY!!!!!!

[Citrus Dad]

Originally Posted by mklinker

Day 1: School closed due to snow and cold no robotics

Day 2: School closed due to snow and cold no robotics

Day 3: School closed due to snow and cold no robotics

Day 4: School closed due to snow and cold no robotics

Day 5: School closed due to snow and cold no robotics

Day 6: School closed due to snow and cold no robotics

Day 7: School closed due to snow and cold no robotics

The rest of the season....CRAZY!!!!!!

Weren't you accumulating the 45 pounds of components that you could take to competition?

[Citrus Dad]

1678 will have a session at our fall workshop addressing this part. We've evolved into a highly structured approach. After we've prepared materials for our workshop, we'll probably share them here in October. Message me then to remind me to post them.

[Oblarg]

Here's roughly what both 449 and 4464 do:

Day 1: Pure strategy discussion. No mention of robot design except to rule out strategies that we're sure we can't build. No design details. The deliverable from this day are the design constraints: What does the robot need to do? How well does it need to be able to do it? How can we evaluate how well a design executes a given strategy? Everyone must know the rules by the end of this day.

Day 2: Rough design outline. Generate coherent robot designs from design constraints determined in day 1. Heavy use of design matrices and similar tools to inform discussion. Decision made on which design(s) to proceed into prototyping with.

Days 3-7: The structure gets looser here; there's generally a mix of prototyping and design reviews to figure out what's feasible and what's not. Eventually we downselect to a single robot concept and set of mechanisms; for mechanisms with identical functionality, we might decide to run with two designs in parallel with the intent of choosing later on once it becomes clear which is superior.

[Riverdance]

This year 1124 did a bit of everything during the first week (before the Polar Vortex took us hostage).
On Kickoff, our superintendent got us the auditorium and we were allowed to play the broadcast on the huge projector screen. Our team, our mentors, and many of our parents piled in to celebrate the occasion.
After the broadcast, our activities for the rest of the day consisted mainly of using sticky notes to write important notes about the game and sticking them under the appropriate columns on the whiteboard in our school's community meeting room. We had everything from the basic rules to robot specifications that everyone else needed to know. We also took to the gymnasium and played a slightly modified version of the game using team members in place of robots to get a good idea of how the game would play out. With our last two hours or so, the team started to come up with basic brainstorming ideas as far as what designs would be efficient for the game.
On Saturday night several team members stayed up and read the entire manual. These members were part of the strategy meeting on Sunday, while the rest of the team headed to the shop to get started on a few prototypes. The strategy members then reported back to the rest of the team in the shop to rule out a couple bot designs that were against some obscure rule or seemed inefficient given the discussion at the meeting.
The next five days were a total mess -- a mashup of prototyping various models, getting more members acquainted with the rules, and, of course, gusset making. It wasn't too long after that our meetings were stalled because snow and because polar vortex, so it was good that we squeezed so much work into that time period and pulled just a couple meetings ahead of schedule.

[M.Kong-Sivert]

Usually, we're not allowed even to touch the parts (except to take inventory) until a week into the season. Week 1 is wholly dedicated to reading the manual and designing the robot.

However, this year, we started assembling the kit drivetrain on the first day so that we could at least have a moving box by the end of day 1. This was so the drivers could practice driving, but we were allowed to suggest other drivetrains for the robot. There was some disagreement among team members as to whether this was a good idea. We did end up using the kit drivetrain, so I think it was very useful.

We also made a rule this year, which I think should have been made a rule long ago, that a member is not allowed to participate in design discussions until he or she has read the entire manual. Thus, most of the first day was spent either assembling or reading, but a few people moved onto designing by the end.

[Charles Boehm]

How it worked for us this year:

Day 1:
-Attend kick-off and get KOP
-Split into 3 groups and discuss ALL POSSIBLE WAYS OF SCORING
-Watch the animation and after segments a few times
-Discuss the game as a group
-Begin discussion on WHAT we want our robot to do, NOT how we want to do it.

Day 2:
-More discussion on WHAT, and some ideas on how
-Discussion on drive trains and what would work well for us(this also kinda happened day 1)

Day 3:
-Team meeting to split up prototype projects
-Begin work on prototypes and CAD models

Day 4:
-Continue prototypes
-Another team meeting to discuss problems or new ideas

Day 5:
-Continue prototypes
-Another team meeting to discuss problems or new ideas
-CAD of drive base(s) close to being done or done

Day 6:
-More prototypes
-Lots of CAD

Day 7:
-I can't remember exactly when this happend but around this point we had a team meeting and came up with the basic design of the robot with all(or most, cant remember) subsystems.

[Monochron]

I'm kind of interested in other team's processes for settling on a "final" design. "Final" just meaning the design that you decide to move forward with after the first week or so.

Do teams decide on this as a large discussion with their whole team? Is it by vote? Does a smaller subset of leads discuss it and then tell the group?