Keeping an Eye on the Big Picture

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.

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.

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.

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.

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.

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

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 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:!__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).

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.

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.

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.

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.

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.

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.

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.

Appreciated. :slight_smile: 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.

In order to keep tabs on our design, we have design meetings often during “prototyping season”. I think this part of our design process can be separated into two sections:

When the design is based on the prototypes
And when the prototypes are based on the design.

I know this year we came to one point where we came up with the basic design of how the robot would function.
Before that day, we had prototypes of all sorts of different shooters/hoppers/collectors. After that day, we knew our robot was going to have a linear hopper, we knew we’d be going with the roller collector, and we knew some other subsystems that would be necessary.
After that day, we prototyped better packaging for the shooter, a side belt to bring the discs up to the shooter from the collector, our hanger and hard stop, and how to lift and lower our tray.
After that one design meeting, we knew what each subsystem would have to do, and how it would have to be integrated. We also knew to no longer prototype the bucket hopper, and to no longer prototype the 180 degree shooter.

Another thing that I find helps, is I try to keep the latest CAD model on the projector in the lab most of the time. That way people have a very good vision for what we are building and can see the changes on the fly if I happen to have time to work on it during a meeting. This also gives our students that don’t know Solidworks a pretty good introduction since they can watch me work. We also share the CAD over Google drive so that all of the team has access to the same files.

For the night by night, day by day management of build, the agile development method works quite well. While it was initially focused on software development processes, it can be modified and applied to all aspects of the build. I like to think of the Agile process as a bottom flowing up process. There needs to be a top flowing down process. Scrumming can be very effective but needs dedication by the entire team. It’s easy during the craziness of build to loses focus and discipline.

Madison, Allen (plus anyone else who has a similar process) -

I’m not an engineering mentor, but I am trying to resolve issues around organizing the CAD files, designing a process to maintain good master files, etc.

I like the idea of sharing the CAD live via the projector. We’ve also toyed with the idea of having monitors in our machining area so folks can more easily refer to the design in real time.

Can either of you share how you use cloud sharing and Google Drive specifically to organize the CAD files. One of the things the engineer-types have commented is that there isn’t a way to view the files in Google Drive in native format.

I keep thinking Google drive should work. I think there is also an Autodesk cloud solution, but I don’t know much about that.

Thanks in advance.


True. Several parts are ‘standard’ and can be fabricated right away, as can most drivetrain components. (I wonder if the CAD model might do better at competition though…)

Yeah, I was young once myself, but then I got old and learned how to delegate ruthlessly. And later still I learned that I hated supervising, and I am now quite content and fulfilled as a worker bee.

I just read he Agile Manifesto on Wikipedia; I’d never heard of it before.


Implementing it, to me, means getting everyone together for updates and collaborative decisions. The customer is the drive team.