How long does your team plan?

[Dan Petrovic]

We are going through some drastic changes between this year and previous years for our build schedule. 2005 we were working at BAE systems, but the entire first week was held in a classroom at the high school brainstorming. The final design wasn't even created then.

This past year, we brainstormed for the shooter and tried to agree on which design to use. Both of these design phases have been done with a committee involving the entire team.

However, this upcoming year, we are going to have a smaller design group with 8-10 students and maybe 3-4 mentors. They will be making all the decisions as far as the robot design goes. Anyone can give input, but the final design will be created by this crew. We plan to start on Monday and end on Friday, then present the final design to the entire team. I have a feeling the manipulator will be designed earlier on so prototyping can begin for those who are not on the design team.

So basically. Saturday of Kickoff and Sunday is spent with the team learning the rules and simulating the game so we can agree on VERY general functions of the robot. Using 2006 as an example, the team would decide that the robot picks up from the floor and shoots in the high goal.
Then Monday - Friday is design/field element construction/prototyping
Saturday week 2 onwards for maybe a week - Protyping and build
Week 3,4 and most likely 5 - build
maybe 5 and 6 - practice and software integration.
Our schedule says that we should have a completely and fully funtional robot by 2/7. That's a reasonable goal, right? It gives us a good, challenging goal, and some fudge time incase things don't go exactly our way, which seems to be the case every year.

I hope that answered your question.

[ChrisH]

Originally Posted by EricH

In 2005, we didn't start until week 5, and we were complete other than some modifications to our arm's grabbing end and painting by ship date. 2006, we had a drivable frame before the shooter was locked down.

Actually we started cutting metal on Saturday of Week 4 but by then we had a pretty darn good idea of what we were building. At that point we were still thinking about which of two drive train concepts to use. We didn't finalize the drive train until Week 5 when we had a working prototype of the riskier one. The frame was designed to accomodate both.

One of the keys is knowing what you can do and how long it will take. We could spend that time figuring out what we were going to do because we knew that it would take about a day to cut the frame, another to weld it, and two or three to integrate it all. So we could start with a well defined design and still get it to the programming guys about the middle of week 5.

Another key is spiral development. Some things you can decide early and lock in. Others will take more time to figure out so you wait. For example, in most cases the drive is the most important subsystem. The nature of the drive is determined in large part by the field and how you want to interact with it. So we will pick a concept fairly early and have some people working on the final drive design while we are still figuring out some other item like the ball pickup or shooter. Some flexibility is left in the frame to accomodate different mounting options for subsystems.

One advantage of a spiral approach is you get the important things done first. Also if you make individuals reponsible for one subsystem then they are only stressed during the time that system is taking "center stage". So the drive train team might be working hot and heavy for 2 weeks, but when it is done then they are done. They can help with other systems or go put their life back together. It greatly reduces individual stress.

One thing to remember about FRC, the process is as important as the machine. The teams that do well year after year have good management of their product development process. This is the real contribution of engineering mentors, they understand this and do it almost instinctively because that is how they work in the everyday world.

[Cory]

Originally Posted by EricH

So am I. Guys, think first, then build. Strategy is everything. Spend a day or two (even a week) working out a strategy

You guys really spend a full seven days discussing strategy? That seems beyond excessive to me. I can't recall any game I've competed in that would require a solid week just to figure out what to do to score points.

[Donut]

Originally Posted by Cory

Im kind of surprised at how many people don't meet to brainstorm strategy/design after kickoff on sat and/or on sunday.

Some might and just don't mention it (like ours). We take the kit back after kickoff on Saturday, inventory it, and start discussing design. We never meet on Sundays, so that doesn't happen. This meeting is usually at someone's house though, not where we work.

[65_Xero_Huskie]

Originally Posted by Cory

You guys really spend a full seven days discussing strategy? That seems beyond excessive to me. I can't recall any game I've competed in that would require a solid week just to figure out what to do to score points.

We take the Whole first week discussing strategy.

I think you need to take a while to discuss this because you need to figure out what would be the best way to build your robot.

For example, in 2005 we had to figure out how we would get the tetras on the top of the goals (we figure out a telescope idea ), and how to carry the tetras on the arm ( we had a grabber, which didnt work, so we scrapped it to a skewer). then we had to figure out how we would put the tetras on to get the most points and the best strategy for getting rows. Everyone on the team had an idea and we needed to figure out how we would get the best one and incorporate the ones we could.

I think you cant spend only one day on strategy, maybe 2 if you really focus and get a simple game. but last year we spent 3 days on a giant fan idea....

[Cory]

Originally Posted by 65_Xero_Huskie

We take the Whole first week discussing strategy.

I think you need to take a while to discuss this because you need to figure out what would be the best way to build your robot.

For example, in 2005 we had to figure out how we would get the tetras on the top of the goals (we figure out a telescope idea ), and how to carry the tetras on the arm ( we had a grabber, which didnt work, so we scrapped it to a skewer). then we had to figure out how we would put the tetras on to get the most points and the best strategy for getting rows. Everyone on the team had an idea and we needed to figure out how we would get the best one and incorporate the ones we could.

I think you cant spend only one day on strategy, maybe 2 if you really focus and get a simple game. but last year we spent 3 days on a giant fan idea....

Now I see the problem is I have a different definition of strategy than other people, it seems.

Lets look at 2006. I'd define strategy as deciding whether to shoot for the center goal, or roll balls in the lower goal. Shoot from ontop the ramp or on the bottom of the ramp. Stuff like that. What I want the robot to do, not how I want to do it.

[65_Xero_Huskie]

Originally Posted by Cory

Now I see the problem is I have a different definition of strategy than other people, it seems.

Lets look at 2006. I'd define strategy as deciding whether to shoot for the center goal, or roll balls in the lower goal. Shoot from ontop the ramp or on the bottom of the ramp. Stuff like that. What I want the robot to do, not how I want to do it.

Ah, well if thats it, then yes, thats something that shouldnt take more than a day or 2

[Lil' Lavery]

I'll give a bit more detail on 116s process.
Kick-off: Full team meets (along with alumni, members of the community and school) to watch the kick-off. Short discussion afterwards. Most of the team goes home, but some stay (mainly leadership and alumni) to mock-up game pieces field elements. EVERYONE is expected to have read sections 3, 4 & 5 (typically the Game, Robot, and Tournament) of the manual by the next day.

Day 2: Full team meeting. Begins with brief recap of game. Most of the day is spent playing "Stu-Bots" (where students enact potential designs and strategies) and discussing (lots of discussing) the results.

The remainder of Week 1 is spent broken into small groups brainstorming and going through basic designs.

Week 2 is reaching a final design. It involves selecting a robot and strategy (as each group has assessed the game differently, but the "strategy team" often has great weight in determining which design we select). Our actual design typically involves systems from different designs to maximize the total effect. Detailed design on components begins at the end of the week.

Week 3 is component design (and the beginning of fabrication if time permits). Each subgroup produces designs for their system, and feeds them to a central "integration" (CAD) group to ensure there are no conflicts with other systems. We should also have our frame welded by the end of week 3.

Weeks 4 is almost purely fabrication (with some assembly if we use off the shelf or KoP parts).

Week 5 is finishing fabrication, assembly, and integration of the systems.

Week 6 is finishing assembly and integration, testing, and driver training.


We try to get a lot accomplished during the first weekend for several reasons. One of the key ones being that many alumni are in town before their next semester start, and often like to attend meetings. They are a terrific resource for both doing manual labor (such as field construction) and robot and strategy design. More we can abuse them, the better!

[ChrisH]

Originally Posted by Cory

Now I see the problem is I have a different definition of strategy than other people, it seems.

Lets look at 2006. I'd define strategy as deciding whether to shoot for the center goal, or roll balls in the lower goal. Shoot from ontop the ramp or on the bottom of the ramp. Stuff like that. What I want the robot to do, not how I want to do it.

We take so long because we tend to get more detailed than that. We ask questions like "How many should we shoot in auto mode?" "Where should we shoot from to have the best accuracy?" "What is the minimum number of balls to shoot to guarantee the win in Automode (including an assement of what we think other teams will do)"

Last year we decided to shoot from the floor partly because we weren't sure we could get on the ramp accurately in automode. That decision was made before we started designing the robot and strongly influenced our shooter design.

Our team is having a session on Systems Engineering this evening. Our "wrong" turns last year will be a major part of the discussion. There were definitely some areas where we made wrong choices and others where we over estimated our capabilities or pursued a solution long after it had become obvious it wasn't working the way it needed to.

Each year has its own subtleties. For 2005 we specifically designed our robot to be good not just at placing tetras, but at placing tetras on the far corner goal, because we felt that was the most strategic position. We could mess up as many as three rows with a single tetra. This could lead to wild swings in the score, especially towards the end of the match when our opponents had limited time to counter. It is difficult to do the sort of detailed analysis that leads to this sort of conclusion in just a couple of hours.

Especially if the Game Design Committee is doing their job right.

ChrisH

[Lil' Lavery]

Originally Posted by ChrisH

Each year has its own subtleties...It is difficult to do the sort of detailed analysis that leads to this sort of conclusion in just a couple of hours.

Another mentality that many teams pursue is the adaptation of their strategy once other teams reveal their designs. There is, and always will be, something you didn't think of that another team did. The logic many teams have is leaving their strategy and design open ended and flexible enough that they can account for and adapt to the game playing out in a way they didn't anticipate.

[Bethany Mc.]

This year, off-season, we meet one night a week for 2 hours, build crew sometimes more depending on what our college mentor has in store for us
We also help out a Lego league team, we help when ever they have meetings.

In past years during build season, we met 2-3 times a week for 2 hours. As ship date got closer it became a little more. This year I think that we will be meeting a little more, only so we aren't drilling holes in our robot at 1 AM or later on ship date.

I can not wait until January 6th!! Good luck to everyone as you start imaging your robot.

[Doug G]

Getting back to the poll at hand.... Its a kinda of a vague question and the results will depend on the resources and experience of your team. For some rookie teams, I'd encourage getting something built within the first couple of weeks. Veteran teams and those with more resources can spend 3 weeks "planning" before they start building. In 2003, our third year, we spent the first 2 weeks planning and designing and CAD the entire bot - it was cool and our robot came out looking cool, but just didn't perform that well. It's also the only year we never made it to the championship rounds at any of the three regionals we attended.

So now we focus heavily on prototyping our ideas and possible designs in weeks 1 and 2. By week 3 we shift into the actual robot design and some CAD where needed. Depending on the CAD ability of my students, only some of the robot is done in CAD. Last year we had an overall inventor model, with detailed modeling done of the transmissions and such. By Week 4 the robot frame is will get finished and fabricate any manipulators. Week 5, finish manipulators and assemble it together. By Thursday of Week 6, the robot should be complete and wired. The next four days are spent practicing and programming.

I can't stress the importance that building actual working prototypes during the design process has had on our robots the past few years. Use wood and pvc to mock up a shooter or arm. We have FP motors and their plastic transmissions ready with sprockets already bolted on to their output hubs, ready for testing out ideas and designs. We also have a protobot that is a kit bot drive base with extra speed controllers, relays, soleniods and air tanks already in place so that if we want to see how an arm may behave we can quickly clamp it or bolt it on the protobot and test in just one day.

[Cuog]

Thanks again for the input everyone,

Doug G, I don't think its a vague question, I was curious and wondered how much time teams spend planning, I'm not asking for a recommendation on how long my team should plan, just how long your team spends planning.

[Doug G]

Coug, it's just my opinion that "planning" refers to a lot of specific benchmarks by many teams, which probably helps explain the results of the poll. Planning could be brainstorming, pencil and paper sketches, strategy, CAD/Inventor/3DS modeling, purchasing, prototyping, etc... I interpretted the question to involve all of this. I think some interpretted the question as just first few items on my list which is why there is much discussion on how much teams do during their "planning". Good question and has brought about a lot of dialogue

[Astronouth7303]

One day at a time, one day at a time...

We're just a little disorganized.