Day 5, 6, 7

FRC is a process that takes time. We focus on the schedule and try to bend time to our will. It works for a team that has appeared on Einstein 6 times in a row, why not try it ourselves?

Progress

Too late for new ideas? No, never too late for new ideas! Thursday started with our head coach and one of our student leads calmly walking into our classroom, announcing they scrapped 90% of our previous designs, discussions, whiteboard drawings, etc, and created a brand new robot from scratch. And, its better than everything we conceptualized these past few days. And, and, they did all this in less than 30 minutes. We are clearly all a bunch of boneheads for not seeing how simple it all was. (Problem was, it was actually a really good new idea. Like, really good. The math checked out. It met our requirements. It didn't include a DART. We could name it something absurd. All requirements met.) Saturday is our robot design review, and we will solidify the final overall structure of the robot. After that, it will be too late for full-redraws. But it's never too late for new ideas. (For those keeping score at home, we are +2 days on last year... At least we started manufacturing our wheel blocks...)

Our additional teams are still progressing forward. Our field elements are getting measured and cut. Our software team is preparing the base framework and libraries to be used this year. Our other software team is working with the Limelight. Software is going to play a very important role for many reasons this year. We have run cameras for our drivers for the past 3 years, and have seen latency, frame drops, and more. Already our team is focused on measuring and managing our network bandwidth. Our business team is arranging our annual items. They have started sending invites for our 5th week Unveiling Ceremony. They are collecting data from this year and adding it to our existing business and outreach binders. And they too are in brainstorming mode: how do we tell our story to chairmans and other judges? I really enjoy looking back on just how many of our team members are involved in so many community outreach events. Combined, they might actually put in more hours than the head coach... maybe... (Team update: he's still a maniac.) We also have our team rookies writing blog posts, one per week. Definitely check them out, I enjoyed the first one, and am looking forward to the next!

Management and Scrum

Number one goal for this year is schedule. Number one mantra is speed. Put that together: fast schedule!

<goes back to the top and re-reads the first section>

Oh.

As a mentor overseeing systems development and integration, I also get the fun task of assisting in project management. Setting dates, and firing kids. Ha, if only. (ponders...) Our largest reason for success last year was our ability to shakedown the robot and train our drivers early and often. Schedule is our number one priority. Last year we had our system complete robot finished by day 29 of build season. Day 30 was our target day for a number of reasons. One, we stole this date from another team. Two, due dates can be somewhat arbitrary. If FIRST gave teams 5 weeks, or 7 weeks, or 10 weeks of build, team would finish their robots in 5 weeks, or 7 weeks, or 10 weeks. Teams will take the time they are given. Hence, if we constrain the schedule, and maintain the schedule, our robot will be finished by day 30.

From that, our overall schedule now has 3 concrete dates: kick-off, full-system running robot, and stop build day. Defining the schedule between running robot and stop build say is very fluid. Software gets robot time for tuning, drive team gets robot time for practice. When the robot or strategy breaks, we analyze the failure, iterate on the design, generally try to make everything go faster, rinse and repeat until the robot gets into a bag. Then we keep doing the same with our practice robot. The schedule between kick-off and running-robot day requires much more specificity. And hand-waving. Given our 5 year history, we have 5 years of machining and assembly experience on which to draw. Wiring the robot for electrical and pneumatics takes a full day. Chassis can be cut, bent, and assembled in 3 days. Wheel blocks take one week to cut and thread. Intake mechanisms can generally be fabricated and assembled in 3-4 days. We take all these hard known numbers, and chart them against our student and machine availability, writing in which tasks can be run in parallel. With this, we can create a 2-4 day window in our schedule to be CAD complete/manufacture start. This creates another milestone, usually 7-9 days before robot complete day. Our last few "known" days are the first days after kickoff. Day 1 rules and strategy. Sometimes we get further, also describing our robot requirements. Day 2 is playtesting strategy, starting to think about past games and ideas that have already been created to solve issues. Days 3-5 are where we start conceptualizing mechanisms, identifying strengths and weaknesses for ideas, and splitting into our subteam groups. This generates the last window of our schedule, roughly day 5 to day 20 (plus or minus 2 days). These days are all about prototyping, CAD-ing, synchronizing packaging and testing information, and integrating all of the subsystem components. This is now our second year using this crunched schedule, though we know other teams have had similar for years. If it continues to work for us, we'll keep on using it. Build what you know.

All that being said, every year is a little different, and this is a very high level overview of the schedule, omitting items such as bumpers, field elements, our software due dates, and our business team items. But thats OK, if we did exactly the same thing every year, we wouldn't have room to create, develop, and grow.

For my day-to-day experiences, the biggest part of all of this is simply facilitating communication. Every day we have a sync meeting, we roughly call scrum. Each subsystem lead takes 2 minutes to describe the system progress for the past day, the plan for the current day, and if they are blocked or need to get requirements from another team. I take notes on what conversations need to happen. Once the meeting is done, I look through my notes with our student engineering lead and prioritize follow-up conversations using our robot requirements (live and die by that document). We talk to the highest priority team, see about solving the downstream teams needs, rinse and repeat. While that plan sounds great on paper (on... internets?) it very very rarely happens that way. Communication is key, so as long as the leads communicate their changes and the engineering lead keeps the macro view in mind, systems generally get built to work together. As long as we don't forget about bumpers...

Analysis Paralysis

This year, in accordance with the law of "plan and prepare, then watch it all go out the window", we took our day 3-5 mechanism concept and whiteboard design period, and... intentionally added a few more days. There were a number of known risks with adding this. Mainly, the risk of me going crazy re-drawing the season schedule in my notebook. Another major risk we face, having a lot of very creative people, and some very scrutinous people, is analysis paralysis. We generate a huge list of concepts, blow holes in each of them, create more concepts, weigh more odds, erase the whiteboard again and start over, and so on. Analysis paralysis is taking so much time to analyze and understand every facet of every option, that you self-paralyze and never actually make forward progress. Once again, a balancing act is required. You need to take time to generate ideas and weigh pros and cons of design decisions, but it can't be at the expense of consuming your actual design and build phases. There will most likely come a time to simply understand that a system will have drawbacks. Use your prioritized robot requirement list, make the best decision you can, and keep progress moving forward.

Head Coach quote of the day:

Mike: We have got to get PTO one of these years.

Me: I would take more PTO.