How do you approach the design process? (+video)

[Bongle]

With the season now over, it’s time to start thinking of next year!

During one of my design courses, we watched this video about a company called Ideo. The company doesn’t make anything but ideas, often on a tight deadline, and rarely the same idea twice. I thought the video and the ideas within it could apply to FIRST teams, as our goals are similar and I’ve long thought that the “sit in a room and chat about how our robot should look” design process is not optimal. Also, I’ve noticed that of the top-tier teams who have hinted at or described their design processes, a common thread is that they have a documented design process with various stages.

Anyway, here is the video: http://www.ideo.com/images/media/nightline.mov

This thread isn’t just about the video, I’m also curious: does your team have a process to how you design? Do you just go into a room and talk about how your robot will look? Does everyone submit an idea and vote? Is it a group decision? Does someone have veto power? Is it all students that design? All mentors? A mix? How long does it take? I’m curious how different teams approach it, and especially how perennially successful teams do it.

[MGoelz]

Cyber Blue 234 does have a process we follow when it comes to designing. We start off in a room talking, but that’s not where we stay nor where we end up.
We start off by having a meeting the Sunday after kick-off. This meeting is to solely go over the game rules (which we are all required to download, print, and absorb the day of kick-off). We make sure there are no misinterpretations, or questionable rules. Following this, we begin strategizing. We figure out all the possible ways there are to play the game, and which ways will provide optimum scoring possibilities. From here, we take a vote and decide on the best strategy to work for.

For example, last year, we decided to be only a scorer, but with the capability of climbing up to 30-degree inclines. This year, we decided to hurdle.

After that, we begin to brainstorm ways to achieve our goal. We start basic: what type of drive will we need? We normally tend to agree rather unanimously on this one. If there is any dissent, the person or party has the opportunity to discuss why they do not feel this would be the best decision.

Then we move on to the manipulator. This is where we throw out all kinds of ideas. We are also asked to go home and research. We look at construction equipment, industrial machinery and robots, robots from previous years, other teams robots from previous years, etc.

We come back in and present what we found. At this point we break down the possible ideas into 5 or 6 categories. For example this year we broke down into lift, arm, catapult, basket, and something else. Then, we break up into equal-sized groups with varying levels of experience. ( We equally disperse the people with 3 yrs. experience, 2yrs, 1 yr, and new members, and people in manufacturing, inventor, programming, and electronics, so nobody is at a disadvatage). In those groups we start coming up with detailed designs. We then present those ideas to the group. Oftentimes we need some visual aids. So each group makes its own mock-up of its design, in addition to laying out the designs in Inventor.

As a team, we narrow down our choices through a voting process. Sometimes we are able to finalize a choice then and there, but most of the time we get it down to 2 or 3 choices. We then write down and discuss the pros and cons of each choice. We make detailed drawings of the ones we are having trouble deciding between. Then we build prototypes.

We vote again. By this time we have seen what looks like it will work and what seems undesirable. We have now finalized a design choice.

We then enter the Inventor stage. Up until now, all that we have done has probably consumed about a week of our time.
Note: All along we have had the chassis idea finalized and have made those drawings in Inventor and the design in ready for manufacturing by this point.

As the Inventor subteam begins detailed, cadding of the design, the manufacturing subteam is able to begin making the chassis. As we make it in Inventor, we often come across some issues that need to be addressed. So, we go back, redesign it, modify it, and continue. As we confirm that parts are ready to be made, the chassis is probably done.

It is probably around this point that we attend our CDR. CDR stands for Critical Design Review. During this we take our drawings, ideas, and whatever prototypes, mock-ups, and actual parts we have made with us to Rolls-Royce to be critiqued by the engineers from Rolls-Royce and Allison. The students present everything. It is our goal to not to have to be supported whatsoever by the mentors on our team. We are trained to answer any questions that may be thrown at us with grace, professionalism, and confidence. We carefully consider any suggestions, and sometimes they warrant a trip back to modifying the design. The engineers always have a lot of helpful advice and it gives us an opportunity to show them what we are doing and where we are going and helps us work on our presentation skills.

The manufacturing subteam can then begin work on the rest of the robot. Sometimes there are issues we come across, even at this stage, and it requires us to go back to the drawing board, and make necessary changes to maximize our robot’s design and manufacturing flawlessness.

Once we have it assembled in Inventor and have allocated space for the electronics board, that subteam can get to work. In addition, we use the previous year’s robot (providing it has the same type of drivetrain) to start some programming. By the time the manufacturing and electronics team has finished building and wiring the robot, all the programming subteam needs to do is transfer the code and make necessary tweaks.

The day before we ship the robot we hold an Open House for the community. We invite the school, principals, township, school board, parents, friends, family, sponsors, local government officials, and area residents to come check out our robot for that year. We hold demos and teach them about the game and what each subteam has accomplished. This year we also brought in the VEX fields we made for the Children’s Museum, and allowed anyone to come and try driving the VEX robots on their own. We also display the FTC and Lego robots from the teams that the students of Cyber Blue run and mentor.

Then we compete. After the competition season is complete, we give everyone some time off to reflect on the season.

Then we hold a Season In Review series of meeting where we analyze the positives and negatives of our season ranging from the robot design and accomplishments to team dynamics and recruitment for next season. We use Ishikawa diagrams, Root cause/corrective action, and we compile lists of what we did well, what we could do better but need to keep doing, and what we did poorly on. We address the issues, find solutions, and improve the team for the next season.

Hope that helps.

And I attached some files about our design process. The diagram is a little rough. I adapted it at the beginning of the season. We decided it wasn’t a circle, because we weren’t going back to where we started, we were building on it, so it’s an endless swirling process.

Also you can find more info at our site:Cyber Blue 234

Design Process.pdf (132 KB)
Cyber Blue 234 Design Process.doc (21 KB)


Design Process.pdf (132 KB)
Cyber Blue 234 Design Process.doc (21 KB)

[Dan_Lavoie]

Blue Lightning’s design process isn’t quite as complex as 234’s, but we have some pride in it. As our team uses a lot of 80-20 in our robot, we are very big on Pareto and the 80-20 rule.
On the day of the kickoff, the team has a meeting immediately following the webcast, for about 4 hours, where all members of the team are involved in a preliminary design session. We outline the most basic roles in the game first. (This year, we had offense, defense, and hybrid, and under offense we had hurdling, herding, and lapping.) Then we have the team all decide which area(s) we wanted to focus on the most with a Pareto vote.
How a Pareto vote works, is each member of the team is given multiple votes they are allowed to use (3-5). We let everyone vote with all their votes, and they can vote multiple times on one thing. The end result is a lot of votes stacked in one or 2 columns, with only a few votes in the others. In other words, 80 percent of the votes go to 20 percent of the options usually, hence the name Pareto vote.
Once a focus is determined, we have the team get into groups, and we do activities to generate ideas for accomplishing the task. One example is having everyone go around in a circle from A to Z naming a method beginning with that letter. So when coming up with hurdling ideas, we might get Arm, Bump, Catapult, etc. There are obviously some stupid sounding ones, but it generates a lot of unique ideas.
After the first idea session, it’s down to the subteam responsible for building the robot to make the other decisions. They look at all the ideas, do some calculations and simulations to find out what works the best, and pick a method. Then they start some drawings in CAD and build prototypes for the proof of concept.
We try to be done as early as possible, but like many teams we are always in a time crunch inevitably. We are always looking for ways to improve our design process.