Keeping an Eye on the Big Picture

[ttldomination]

Hello Everyone,

In my FRC experience, I've largely been a part of teams which discuss general robot design on kickoff, then go into intensive prototyping for 1-2 weeks, and then we start working on how to put the pieces together.

However, after reading the blogs of 1538 and 254, it appears that there is a group that keeps an eye on the bigger picture from day one via strong communication from the prototyping teams.

Now, my question is what does this oversight group look like? Is this group just simply the CAD group that's constantly trying to mesh various prototypes? Or is it a small group of CAD designers and leaders who are working with the prototype results/designs to move forward in the bigger picture?

If this group were to include team leaders and CAD team, do they convene and revisit the big picture after every major design revelation? At the end of every meeting?

Pretty much, how do you keep track of the big picture while you're prototyping?

- Sunny G.

[DonRotolo]

Good thread. We suffer from the same issues. We think we have a plan to deal with it this coming year, but we don't know if we can get it to work.

[themitchshow]

Once a week we gather our team together and each sub group gives a 1-2 minute presentation about what they have been doing the past week, what they are working on now, and what they are going to need from other sub groups in the coming week.

This format allows the entire team to know what's going on in each of the groups, and gives them a chance to ask questions and voice concerns. It also helps get most of the bugs out especially when it comes to integration of all the different group's parts.

[cadandcookies]

Originally Posted by DonRotolo

Good thread. We suffer from the same issues. We think we have a plan to deal with it this coming year, but we don't know if we can get it to work.

My team is in a similar situation. We've taken a step back and are reconsidering and redefining our entire build structure and process with an effort towards focusing more on "engineering" a robot as opposed to "building" a robot.

I'd share more details, but frankly we haven't tested our process at all (other than lots and lots of discussions), but we're actually doing an entire "fall build" season in order to "retrain" the entire team towards our process.

As for the OP's specific situation/problem, my "80% crap" suggestion is that you probably (depending on the team size) need to get your "big picture" designers in a room with your prototyping people (my extrapolation from your post is that these are two distinct subsets in your team) and get a firm picture of where the team as a whole wants to go with the robot. From there break it down into what individual subsystems need to get prototypes and to what requirements those prototypes (and eventually final products) need to be built to. Be prepared to meet often-- the best way to avoid snags in my experience is to talk enough to the people involved that you're all on the same page but avoid talking so much that no work gets done.

[MichaelBick]

We have a mechanical director(me) who handles all of the coordination of the robot build. We start with a general picture of what we want the robot to look like based on our game strategy. This year we came up with a design almost exactly like 1986's robot. We then start prototyping while adjusting our original design based on our prototypes. This year by week 2 we realized a climber was out of our resources. Additionally, we thought that we could build an overall better robot by focusing on cycling, though we left an easy spot for our intake to attach(based on our prototypes). I coordinate this with the design team(which I also head). Design issues need to be dealt with in prototyping and then the new dimensions, design, etc needs to be dictated to the design team.

I recommend that this person is heavily involved in the design team. Designers tend to know the current design, design issues, dimensions needed, etc. In addition this person can coordinate with manufacturing and programming.

[dellagd]

Originally Posted by DonRotolo

Good thread. We suffer from the same issues. We think we have a plan to deal with it this coming year, but we don't know if we can get it to work.

Same situation on 2607. We fail grandly on this last year.

[Madison]

Everything robot-related comes through me. It's not the best system, I'm sure, but it's the most effective one we've found. I am often overwhelmed by the amount of tasks that need attention.

I do what I can to keep the rest of the team informed about how things are progressing. I try to do a "state of the robot" discussion at the beginning of every other meeting or so that keeps everyone in the loop with respect to what we've learned, what decisions we've made, why, etc. Folks that are prototyping jump in during that discussion to talk about their progress as well.

[weberr]

We use QFD, or quality function deployment, to boil down what is the necessary attributes & scoring opportunities versus the robot characteristics. Check out our web page and downloadable info:

http://www.theflyingtoasters.org/#!__qfd

This is usually done the monday night after kick off, and by the end we know what is the most important relationships needed to have a successful robot. Then our team goes to work prototyping, coming up with solutions, doing research, etc. and by the following week (the next monday) we check any solutions back to the QFD and rank them using the QFD. So in essence, the QFD becomes our anchor to keep the whole team focused and moving in the right direction.

The revision we are looking to incorporate this year in our QFD is the addition of of a "Probable Scoring Rate" that takes in consideration time versus point earned. We are still in the development stage on this aspect. Stay Tuned.

For those who do not know what QFD is, it is a way that major corporation use to address customer concerns, product details, manufacturing processes, etc. so that the end result is "built in quality" for the final product. Car companies have used this process to achieve JD Power & Associates awards and thus more market share (and customer satisfaction).

[ttldomination]

Originally Posted by MICHAELABICK

We have a mechanical director(me) who handles all of the coordination of the robot build. We start with a general picture of what we want the robot to look like based on our game strategy. This year we came up with a design almost exactly like 1986's robot. We then start prototyping while adjusting our original design based on our prototypes. This year by week 2 we realized a climber was out of our resources. Additionally, we thought that we could build an overall better robot by focusing on cycling, though we left an easy spot for our intake to attach(based on our prototypes). I coordinate this with the design team(which I also head). Design issues need to be dealt with in prototyping and then the new dimensions, design, etc needs to be dictated to the design team.

Originally Posted by Madison

Everything robot-related comes through me. It's not the best system, I'm sure, but it's the most effective one we've found. I am often overwhelmed by the amount of tasks that need attention.

So these are some good suggestions. I sort of attempted to fill this role on my team this past season. Now, I wasn't dictating design, but I was taking information from all the sub-teams and attempting to make sure things sync.

However, this approach can get messy. Like Madison, I was often bogged down and overwhelmed. Ultimately, I felt burnt out by the end of week 2. I also feel like this "overseer" role(s) should be shared between mentors and students. Now, that may be a slightly idealistic view of the role, but I believe the best solution ought to be a tactical collective between mentors and students.

- Sunny G.

[rsisk]

Originally Posted by themitchshow

Once a week we gather our team together and each sub group gives a 1-2 minute presentation about what they have been doing the past week, what they are working on now, and what they are going to need from other sub groups in the coming week.

This format allows the entire team to know what's going on in each of the groups, and gives them a chance to ask questions and voice concerns. It also helps get most of the bugs out especially when it comes to integration of all the different group's parts.

A very AGILE process. We use this at work when we develop major software projects. The only thing I would add is a brief meeting (15m or less) at the beginning of each meeting to discuss what teams are working on and if there are any roadblocks.

[DonRotolo]

Originally Posted by themitchshow

Once a week we gather our team together and each sub group gives a 1-2 minute presentation

Once a week didn't work for us when we tried it. There was so much progress in a week things were already out of hand.

Originally Posted by weberr

We use QFD, or quality function deployment, to boil down what is the necessary attributes & scoring opportunities versus the robot characteristics.

That's great for design, and for guiding design changes/decisions when things don't go well. But that's the design phase. Our "problem" is in the fabrication phase.

The real issue is that we have the concept and basic design set, but the details - precise dimensions for example - are determined empirically during fabrication. What we end up with is several subsystems that don't work well together, and design decisions from one sub-team that absolutely preclude many possible solutions for another sub-team's problems.

On the other hand, running everything through one person seems like an awful lot of work for that one person. My condolences Madison.

Our idea is to have a small committee of mentors and students take on the 'overseer' role. This way one 'entity' really knows what is really going on and can (hopefully) see and spot conflicts, while not being terribly overwhelming for one person.

We also see a far greater role for CAD. In the past, they were documenting designs after the fact. This year, if I see a CAD kid with a ruler in their hands, I'll know we failed. I hope to see a final design in CAD before the first piece of metal is cut. This gives me the most worry: I don't know if we are disciplined enough to do that.

I'll let you know if it works.

[sanddrag]

Originally Posted by DonRotolo

I hope to see a final design in CAD before the first piece of metal is cut. This gives me the most worry: I don't know if we are disciplined enough to do that.

What gives me worry is doing just that. Our final CAD design was not done until around week 5. We start cutting metal on Day 2, before CAD has even started, for certain parts we know we'll use no matter what the design ends up being (sprockets for instance).

If you wait to finish the CAD model before cutting any metal at all, you might have only a CAD model to compete with.

[AllenGregoryIV]

Originally Posted by Madison

Everything robot-related comes through me. It's not the best system, I'm sure, but it's the most effective one we've found. I am often overwhelmed by the amount of tasks that need attention.

I do what I can to keep the rest of the team informed about how things are progressing. I try to do a "state of the robot" discussion at the beginning of every other meeting or so that keeps everyone in the loop with respect to what we've learned, what decisions we've made, why, etc. Folks that are prototyping jump in during that discussion to talk about their progress as well.

We have a similar system. I keep tabs on everything and then it goes out to the team every night in the form of our build blog and an email to the team with more details than go out to public. This often includes a screenshot of the current CAD and pictures of prototypes. This is normally supplemented with discussions at the end of most build days during clean up with the core group of students that are normally around that late.

[jimwick]

We have an all hands meeting after a (usually delicious) pot-luck lunch every Saturday.

Each "squad" does a show and tell of what they are doing. A sketch of some kind of the total robot is drawn on the board. Conflicts and problems are talked out.

We try not to end the meeting until a new or updated plausible "total solution" has been agreed on. Sometimes there are parallel tracks. Needless to say, these solutions are fairly vague in the beginning, but get sharpened up and more detailed as time goes on.

Very often apparent conflicts get modeled in cardboard or something after the meeting.

[Madison]

Originally Posted by DonRotolo

On the other hand, running everything through one person seems like an awful lot of work for that one person. My condolences Madison.

Appreciated. It's my own fault, of course. I am terrible and delegating tasks I think I can handle myself.

For 2014, there are a few students who are up to speed on CAD and have gained a lot of experience with design via past FRC seasons, running FTC teams and summer internships. If I am not the only one with access to and understanding of the CAD model, hopefully that means I'm not the only one who can answer questions about fit and function. Also, for the first time in more than a decade, I don't have a laptop. That means that I'll have to be more diligent about sharing the CAD data in the cloud so that I can pull it down at our lab.

Years ago, when I had more energy and more free time, I was able to prepare work packets in advance of each meeting that laid out, in detail, what needed to get done / which materials to use / what requirements to meet / etc. These days, I do that on the fly. That doesn't work as well.

I know there are lots of different methodologies for running FRC teams and they each have their merits. In my experience, though, most teams that build successful robots year after year have one person (or maybe a small handful) making decisions about how things will go together.