How do you design your robot?

[Joe Matt]

Originally posted by nuggetsyl
weapon i think you are in the wrong competition for that

Notice the parentheses? It's what we call our accessories, but more aptly describe it. Accessories sounds like we're making a purse and some nice shoes to go along with it.

[nuggetsyl]

lol

[Sachiel7]

Hmm...Robots with Purses....
Heh, just a funny thought.
Funny post JosephM...

[Madison]

I've just been taught about a number of different design processes and philosophies, but rather than reiterate them here, I'll just give you a link or two.

I don't really like democracy in robotics teams because I think it's limiting to what the team can accomplish when a leader emerges and directs people's efforts efficiently. That said, I usually prefer to be the one who's leading, too, so that may give you some idea about why I feel that way.

It's a balancing act and there's no right solution. If students aren't given enough involvement or input in the design process, they may begin to resent that or feel unneeded. If a single person has the organizational skill and time available to them to oversee the entire design themselves, with criticism taken and considered, the team may build a robot that far exceeds their expectations.

At least, so I think.

[ChrisH]

Ken did a great job of explaining the basics of the engineering process. I would have said the same things but didn't have time at that moment. But I think he missed a key point, budgets. He probably left it out in the interest of brevity.

When we are ready to move from the What stage to the How stage we set budgets for weight and sometimes cost before we get to the design. We also set aside "overhead weight" for those minor items like the RC, battery, and light. The budget reflects somewhat the relative importance of the subsystem in our game strategy.

Last year's budget was something like this:
Overhead 30lbs
Frame 20 lbs (includes sidewalls)
Drive 20 lbs
Wedges (small arms to grip ramp) 30lbs (includes most pnuematics and compressor)
Arm and gripper 25 lbs

Notice: we have only budgeted 125 lbs in this example. Systems NEVER come in under budget so allow for "growth". Actually we usually budget to 115 lbs, but in this example I stayed closer to actual weights.

We also start our subsytem designs from the interface to the next system. (Remember "He who designs the interface first wins!") So if we have a lifting arm joined to the frame, the first thing is to define how the arm interfaces and "fix" that. The frame and arm are then designed around the interface. The frame doesn't care much what the gripper end of the arm looks like. This way the frame builders can get busy and build the robot while the arm guys flail around trying to get their gripper to work. This way, even if the arm guys fail entirely we can still drive.

Budgeting also provides something of a reality check. If you can't figure out a design that stays within budget then maybe you shouldn't be doing that function.

Finally we have a System Engineering function that ensures that ALL the interface requirements are defined and communicated to the relevant groups. (System Engineer: "No, we can't add that limit switch, it's not on the list and besides we have to ship tomorrow"). The Systems Engineers also track weight and cost to ensure that each system stays within budget, both cost and weight. They also monitor progress. If a subsystem isn't done a week before ship we will either funnel a massive effort towards finishing it or scrap it.

We usually have a mentor and a student who are dedicated to this vital function. They have other jobs in the team and participate in building the robot, but their PRIMARY responsibility is making sure we finish on time and within budget.

It's not necessarily fun, but it is important. Properly executed, a Systems Engineering approach enables many more people to participate in the design process while still staying co-ordinated. It lowers the individual work load, so that people have more time to think about what they are doing and do it right the first time. It is also how most major systems (ie aircraft, satellites, etc) are designed today. Such systems are far too complex for a single person to comprehend in detail, let alone design.

[skrussel]

Regarding comments about fewer than 10 kids doing most of the robot construction.........after 7 years in FIRST, I find that happens regularly, and I believe that it is okay. Kids seem to find their niches on the team, some participating more than others, some contributing more than others, some spending more time than others. That's okay, too.

Actually, more than 7-10 kids who actually have their hands on the robot can be too many.

I totally agree with Ken that the PROBLEM needs to be worked out first, then figure out how to construct the robot to solve the problem. One of the best pieces of advice ever. Learned this one the hard way!

[Steve Shade]

I'll try to keep this short because Ken and Chris have stated most of my process.

Ken's team uses something similar to what i have been doing for about 3-4 years now with my teams. To extend Ken's line of thinking to link Chris' line, you have to go form asking WHAT are we going to do, to HOW are we going to do WHAT we said, and then ask HOW MUCH will each function/system cost and benefit WHAT we are doing? By cost I mean things like weight, time, personnel resources to design and manufacture, etc. You can also use some of these costs as a way to figure out the trade-offs between which systems you choose to build. For example, if you have 20 people on the team, and your drive system will take 3 weeks to design and build with 10 people working on it, then you have to cut back somewhere else.

My only other additional comment is let the numbers guide your decisions. Ken gave a good example of this. You can find many ways to play the game by breaking down the scoring at the beginning and trying to compare the bets points combination to the most realistic combination of systems on your robot. This doesn't mean to go conservative, but to select something that is realistic.

There are plenty of great engineering tools out there. A great source for these tools is form a company called GOAL/QPC. They produce a number of little books for under $10 that are just filled with useful tools. I would recommend the Memory Jogger II as a good place to start getting acquainted with the tools. The Teams Memory Jogger, the Creativity Tools Memory Jogger and the Project Management Memory Jogger ams also be useful depending on what your team needs are. Their website is here. If anyone wants to know what is in these books I have or have read many of them. The books are also available on CD.

Steve

[KenWittlief]

good point. Using numbers to drive your decision is called Data Driven Analysis.

simply, you calculate the results of the different options you have, and then let the numbers determine your best option.

Take last years game again. If the only thing you do is park on top of the ramp, you get 25 points.

if the only thing you do is push half the boxes into your scoring zone, you get (how many boxes were there again?) 26 points?

if you get half the boxes on your side, and maintain a stack of 4, you get 88 points

if you build a bot that stay in the starting box and knocks half the wall over, you get 0 points

let the data show you the most productive tasks your bot can do

same thing for tradeoffs in the design process. If you use the stock transmissions and two drill motors in the kit, your robot will have a certain top speed, a certain amount of pushing force, and you can bolt it all together in one day

if you build a custom transmission, the performance will be different, but it will take you many weeks to design and fabricate.

This is another area that separates engineers from basement inventors. Inventors get an idea that seems cool to them, and they run off and start building it.

Engineers look at the data, and let it tell them where to focus their life-energy to get the most bang for the buck.

In FIRST you only get 6 weeks - its not much time

if life, you only get to be an engineer for 40 to 50 years - its not much time either (when you are trying to change the world :c)

[Aignam]

Group brainstorming sessions. Figure out what works, what'll win the matches. Make things only as complex as they need to be in order to be efficient. Then do it.