How do you design your robot?

FIRST General Forum
1

For the last few years, 422 has used the same tired method to design our robots, and it doesn’t work that well anymore. Here’s the breakdown:

First, we show the game to everyone and make sure everyone understands what’s going on. We then do some group brainstorming to try and get people thinking about what they want our robot to do. After that, we break up into small teams, each responsible for designing a robot and “general” subsystems (claw here, tank tread drive, etc). We usually then vote on a design, which I now think is a bad idea.

From there the system really seems to break down. Once a design has been voted on, we break up further to teams to attack each individual subsystem, responsible for fully designing it. Last year it was drive train, arm (which had nearly 5 moving assemblies), and control systems.

Anyway, enough of that. It doesn’t work. 20-30 people show up at the first meeting, who design the robot by commitee, but only 10 or so are left to turn concept into design and construction. That just doesn’t work anymore.

How do you all go about designing your robot? Do you have a lego building competition? Do you let your engineers worry about it? Do you have a select few on a “design team” that hands off the concept to the “mechanical team” or some such?

2

Great to Hear from you Gui!
Well, our design meets this year were a wreck, to say the least.
We’re trying new concepts though.
We usually leave the group part for after the design period. Anyone can be on any group. Anyone can submit an idea for anything, and we usually just have long discussions until we usually end up voting or something.
This year I’m trying two new methods (design strategies, if you will):
-Pre-Season Design
-Function Analysis
Pre Season Design:
It’s just as the name states. We’re putting together a “Design Library” of past years designs, and any designs we come up with pre-season. For example, my designs for my Multi-Drive, and MCU were all done over the summer. I’m presenting them to the team at our December meeting. (And a nifty presentation it will be too, in 3D! Everyone grab your interlaced glasses!)
Some things can be decided pre season. I’m not saying you can come up with your exact drive train and controls, but you can agree to things such as “we’ll stick with this drive train unless the game shows that we need something different”. This kind of pre-planning can save ALOT of time. If you come up with an inventory list of parts for your drive train agrees on pre-season, you can have all the parts within the first week to begin building.
Sub-Systems (ie claws, stackers, etc.) can’t be agreed on pre-season, but generic ideas can be submitted that can easily be tweaked for the game. Or, you can look through your previous season’s designs and tweak one of them.
-Function Analysis:
Basically, determining the functions of your robot. Hey, it’s where you begin. My method involves listing all the possible functions, and then I have about 1 page’s worth of things to do to water it down to a final few list of functions, each sorted by importance. I’ve found a rather shocking thing too, (As you know) I’ve been in FIRST since the 02’ season. I went back and viewed the kickoffs from year’s past and performed my little methods, and all the “robots” I came up with had the exact traits as the winning team’s Robots from that year, even at the national level.
Well, we’re going to toy with it. Anyway, If you combine this by getting your functions along with some design libraries and pre-season design, you can’t go too wrong.
But, it is different for each team…
And, since we’re home schoolers, we can spend alot more of our time on design. On our Six week layout that we’ve got for this year, only the first week is allotted for design. We’re really hoping that we’ll have our bot by the night of kickoff though :slight_smile:
It’s been done…
Anyway, I’m kinda cheating, because my multi-drive functions as 4-5 different drives in one. That way we don’t really need to worry about what kind of drive system we need.
As far as controls are concerned, you can come up with some pretty good layout ideas pre-season even without knowing your robot. I designed a generic “Tackle box” of controls that plugs in through two terminal plugs to the robot. Keeps everything organized and clean. Rewiring can be done on the plug level within seconds.
It’s that kind of generic design that can help along the way.
Anyway, hope that helped a little bit…
(PS, Is it true that Dee won’t be working with 422 this year? :frowning: Maybe I’ll see her at FLL on the 22nd…)

3

We first brainstormed as a group, we went around the room and everyone gave an idea. No matter how crazy it was, you had to say something. We then broke down into groups and came up with a rough scetch for each group. Then someone from each group presented their group’s scetch. I dont think we ever had an official vote, we chose the design that everyone seemed to be able to branch more ideas for. (Like where the arm and stacker would go)…yeah, then we would eat(mmmmmm, pizza) and break up to sub-groups the next day. We would assign sub group captains and a mentor to each sub-group. Yeah, we didnt stick with who was assigned to what, it came down to who was there most of the time and they gravitated towards something to work on. Each member was also required to have something non-robotics that they need to work on. Ex. The crate (it looks awesome) we were trying to make a motorized robot cart, something for the robot to be carried around competitions on…LOL, yeah, that didn’t work out. It turned out okay though. I dont think anything turns out as anyone plans it. We never expected to have everyone stay in their groups, and we knew that everyone wasn’t going to consistently show up. We just had a guide line to work from.

4

We tried something new this year when we were thinking about design. We spent a little too long on the design portion because no one was organizing our thoughts and recording what we thought was good and bad. So one of our mentors suggested making a chart type thing where we had an idea, take suction cups for example. So we wrote suction cups down and then we had a list of things to consider such as cost, time, strategy, and so forth (I don’t remember them all). So then we would go across the line and put either a green dot fo good, a yellow dot for so-so, and a red dot for not good. So say for suction cups, we would put a gree dot under strategy, because that would be helpful, and maybe a yellow dot for time and cost if it would take some time and cost a little more than we would like. So we put down all our ideas and filled in the dots for each one. So therefore, the ideas with the most green dots we determined to be good ideas and pursued them and ideas with the most red dots, we scraped and so forth. I really didnt explain that well but if you understand that, that is what we did and it worked out well.

5

like a brick

6

*Originally posted by nuggetsyl *
**like a brick **
like a tank. Those at LA and Phoenix last year know.:wink:

7

The only reason why we build a strong robot is because you might as well paint a target on it same as 47 356 121 16

8

How do you design your robot?

Easy!!!

Lots and lots of cocktail napkins

9

Frankly Gui, we do the same thing. Only instead we focus on three divisions: frame, ‘weapons’, and drive train. EVERYONE contributes to design ideas, but a few refine them, and we also get everyone to agree on two or three things the robot should be this year (short, tall, stacker, pusher, etc.) Those who don’t build or design work with programing or other needed fields.

The idea is to get a general idea for the robot that EVERYONE agrees on, then build from there. Some people had ideas on our team that were outrageous last year, and we shot them down because they didn’t fit what the team wanted.

Another thing is this: the more you have an idea in the air, the longer the person who gave it will stay. So if you shoot it down, they probably won’t stay around, but if you consider it, and work on some ideas, and as for more of theirs, they’ll stay.

10

weapon i think you are in the wrong compition for that

11

wow ! what a great thread.

when you have been an engineer for a while, you learn the big difference between basement inventors and engineers, is the engineering design cycle.

Most people, when presented with a problem, immediately start thinking of solutions - At GE Aerospace we use to call that the GE two-step

the problem with the two step is you are using preconceived notions (thinking inside the box) on how to solve the problem, before you have really given the problem itself much thought.

the problem is where you need to start:

  1. Specify the problem. For FIRST teams the problem is the game - the rules of the game, how to score points - usually the problem can be stated in terms of “these objects and machines start out in these positions, and to score points they need to be in these other positions 120 seconds later”

this is not the time to think about how your robot will get from point A to B, or move the scoring objects from X to Y - at this point only think about WHAT has to be done to get the best score. Using last years game as an example, you could try to move all the boxes into your scoring zone, you could try to stack all of them, you could try to knock down all your opponents stacks, you could try to be on top of the ramp at the end, you could try to prevent your opponent from being there…

It takes a while to go through all the possible combinations - the ‘best’ score is not obvious. In last years game you wanted slightly more than half the boxes in your scoring zone, a reasonably high stack, both robots on top of the ramp at the end

and you wanted the opponet to do the same, but be only a few points behind you

from there you can break it down by each WHAT task, and see which one gives you the most points. That becomes your most important task to perform. That task defines WHAT your robot has to do as its top priority. You can easily spend the first week after the kickoff just detemining WHAT the robot has to do - and it will be the best way to spend that time - because it is impossible to figure out HOW to build your robot, if you have not yet figured out WHAT it needs to do to win.

For last year, our team decided the most important thing was to get more than have the boxes on our side of the field and into the scoring zone, so the primary function of our bot was to get to the wall as fast as the motors and equipement would allow us to, and push at least half the wall onto our side of the field.

  1. the next step is the HOW - brainstorm how a machine can perform that function you decided on in the last step. you should not yet be thinking about how you will build the robot (implementation details) - you should figure out HOW it will do the WHAT - from last year again, How can you get to the wall first? Jump over the railing? reach up with an arm? run the semicircle in auton mode? run a v pattern in auto mode? Pick up a container and fling it at the wall? - again you should be doing some numerical analysis at this point.

How fast can a 130lb robot accelerate from the starting point to the wall? How fast can an arm spring up and hit the wall? how much leverage will it need to have to knock half of it all the way down the ramp? for each possible HOW you should be able to estimate a time to completion, and have an idea of where your machine will be when its done.

  1. once you know HOW your robot is going to do its WHAT - you start breaking the robot down into subsystems - is there a drive train? how fast does it need to be? how many motors will it take to go that fast? is there an arm? how long? how heavy will the chassis need to be to keep from falling over when the arm is extended? do you need sensors to follow the line? to figure out where the robot is on the field? to measure compass heading?

Now guess whats going to happen? you are going to end up with several required subsystems, and each subsystem is going to have a big WHAT - a specification of WHAT it needs to do (sound familar?) Once you are sure of WHAT your subsystem need to do then you can go onto

  1. subsytem design - this is where you finally start figuring out HOW your subsystem will be built - this is where you start thinking about motors and transmissions and pnumatics and gear ratios - weight, center of gravity - amount of power needed from the motors… If you are following the design cycle right then you dont reach this point until the third week!

thats right - you have spent two weeks already and have not built a single thing yet. This is a good thing, because you will have simple, straightforward subsystems, that only need to do one thing each - and it will be much easier to build the subsystems now that you know exactly WHAT it needs to do, HOW you are going to do it, and HOW it all fits back together with the rest of the machine.

  1. fabricate: this is the easy part now - you draw up the parts, make them or have them made, and bolt them together

  2. integrate and test. Test the subsystems as much as you can, then assemble the robot as a whole, and test the robot as an integrated system.

if you have stuck to the design cycle like glue, you will be in the 5th week now, you will be working out minor bugs and revisions, and your drivers will be getting practice time on the real machine.

This is the way to do it. Stick to the design cycle. When you are done with each step you are DONE with it - dont go back and change your mind half way through - if you get a better idea in week 4, its too late (besides, in week 4 you should be focused on that part of the design cycle, not on what you did 3 weeks ago.

The engineering design cycle is what engineers live by - its the only way to get a program done on time, and to have the result function the way you intended it to.

Try it! You’ll like it! :v)

12

Ken, thanks for the huge, detailed thread. Your steps are very rational and helpful, but I don’t agree with your timeline.

My main problem with the schedule is that our team maxes out at around 10 people, and we’re working in a room with a drill press, hack saw, and jigsaw. We can get machined parts, but we either have to send part drawings out and get them back when machinists have the time to do them, or drive to a shop 40 minutes away and do them ourselves. We were still assembling the robot halfway into week 5 last year because we didn’t get the parts in time. Therefore, we have to have a much shorter design cycle in order to get anything moving at all, given the amount of time machining takes.

When you say that you break down into subsystem “How”, and things like that, could you go into a little more detail? The reason I ask is this: we break down into teams, say Drive Train, Chassis, and Subsystem, but the problem is they frequently come up with three separate entities that are expected to click together like Legos. I was thinking of maybe combining all three groups initially, but designing by large committee is never a good idea in my book. Is there an easy way teams have found to do this?

13

*Originally posted by Gui Cavalcanti *
**When you say that you break down into subsystem “How”, and things like that, could you go into a little more detail? The reason I ask is this: we break down into teams, say Drive Train, Chassis, and Subsystem, but the problem is they frequently come up with three separate entities that are expected to click together like Legos. I was thinking of maybe combining all three groups initially, but designing by large committee is never a good idea in my book. Is there an easy way teams have found to do this? **
My team has a “systems team” that is responsible for integration of all the subsystems. Their job is to draw the whole robot in detail (hopefully this time in Inventor), and allow certain space, weight, and money for each subsystem. They also get the subsystems talking with each other to make sure that there will be no conflicts in design or assembly placement.

14

Ohh…Goodie! Small team…
The good thing about a small team is that you can easily spread people over multiple groups. When a person comes up with a design idea, they usually are some of the best ones to build it (if they can) because they have the idea in their head. They also know how it integrates with the rest of the Robot. We usually Split up into 3 groups: Drive/Chassis Sub-Systems and Controls. Sub-Systems are any robot devices that work with game elements. The robot as a whole is discussed by the whole team, but each group is responsible for the construction and integration of their part of the robot.
But if you’re on a 10 person (or so) team, I think you can do alot with the entire team. Design meetings can be held for anyone.
I like some of the methods Ken described, this is what we’ve been doing for a while, and it works pretty good. I think his and my method are pretty much the same thing, just explained differently.
But I agree, the FIRST thing that needs to be done is to identify the problem. In any engineering sense, that assists you in defining your goals. Once you have your goals, you come up with basic ideas to do them, like stacking - putting one box on another, then picking those up, etc. Then, come up with some basic drawings (sketches) of the shape of a device to perform that function. Elaborate on it more, and then define the proper actuation for the task.
But, I’m sure you’ve got that down. It seems you want more suggestions for the group dynamics involved in the design process.
I know what it’s like being a team leader, It’s not easy. These past years we’ve had about the same resources as that of what you mentioned, and we’ve developed some nice bots. When you’re coming up with design, I wouldn’t worry too much about the resources you have. Besides, other teams (like ours, maybe) are probably willing to open their work space for other teams to use. We did this in 2002.

Another idea is to ask the team how they want to handle the design process. You may be surprised that 90% of the team is thinking of the same process in their head. But Pre-Season would be a good time to get this laid out.
Just see what they think. If they don’t have ideas, then give a few different options, and get feedback.

15

If you dont have good access to a machine shop, then you need to lean more towards using off the shelf parts - you are sorta in ‘desert island’ mode - you can only fabricate a limited amount of stuff on your own

for example - the transmissions that FIRST gave us last year werent half bad - and you could alter the final drive gear ratio with the size wheels you used

bolting stuff together out of the kit isnt that bad really - the pnuematic are 100% an off the shelf sort of thing - the only choice you get with them is what cylinders to purchase - so its what you do with what they gave you that makes your machine unique - if you have carefully figured out exactly WHAT you want your machine to do, you will be way ahead of most teams.

Instead of breaking your team up into chassis, drivetrain, manipulators… you might want to break them up by subsystem - the motors and transmission are closely associated with the basic frame, so there is really no reason to have two separate groups working on them

part of breaking the machine up into subsystems is to give each one its allotment of space, weight, motors, pnumatics… and to have some idea of how its all going to bolt together

you have to pick a starting point and work from there with a little flexibility. Take last years game again - say you wanted to build a bot that would get to the wall fast, and have wings that would spread out and push the wall over. You could draw out a basic frame using the extruded beams they gave us, and tell the chassis and drivetrain people “you get the bottom side of the frame” and tell the wing people "you get the top side - and then map out a space where the RC and battery have to go.

16

*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.

17

lol

18

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

19

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.

20

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 :smiley: 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.