Sub Teams
 

After a disasterous season last year, my team is basically trying to turn over a new leaf this year. As one of the only senior members on the team I really want to get the team organized and try to be more productive then last year. I have noticed that many teams break down in to sub teams to specialize in each of the different areas of the robot. I was wondering what areas your team breaks down into and the number of people in each area if possible. Anything would be greatly appriceated.

Re: Sub Teams
 

It would probably be beneficial for you to look at this thread. Also, you can see what worked well for my team last year in my post in that thread.

As for what the specific subgroups are, my team decided this and the number of students in each in what they call the team "constitution" However, it has been a while since I've seen it and I don't have a copy.

I believe last year it was something like this:

Drivetrain/Chassis - 3 people
Arms - 3 people
Suckers - 3 people
Stacker (backup subsystem) - 3 people
Systems Integration - 2 people

And then there like 2 people who didn't show up so often and kind of floated around.

The job of the systems integration team was to allow weight and space for each of the subsystems. Also, they had to check to make sure everyone was on schedule and made sure subsystems didn't interfere with each other.

Last year we had a Veteran's Council that consisted of 6 people where two of the six shared a vote. They did all the decision making. It worked in a way, but often took too much time and left the rookies with nothing to do.

As for team structure, I'm in favor of not having one. For us last year, our team council meeting sat around arguing while we could have actually been doing something. We often argued for an hour without deciding anything. Several times, I couldn't take it anymore because no one was getting anywhere. We would have stupid debates over things like chassis member lenght and wheel size; things that had already been decided but then someone wanted to change it. I got so anoyed I would give council meetings x number of minutes of my time. If nothing was decided in that time, I didn't care and left the meeting to get back to work.

We're in this to have fun, not to argue. I think team structure "inhales audibly." If you have a good group of kids who get along well and a couple of easy-going mentors, you don't need no stinking structure. If you don't have those things, you'd better get them because no structure can fix an inoperable team.

There are times when there does need to be some sort of structure to prevent chaos. I've found what works well instead of forming little groups and subteams, is the concept of individual responsibility. The more people that are involved in something, the harder it is to get done and the more things that could go wrong and the more people you can defer the blame to if something does go wrong. Last year, I was the person responsible for building the chassis and I was the only person who built the chassis. In one hour, we had a chassis no problem. Individual tasks work. Like Bill makes pillow blocks. Jim makes the chassis. Shanon mounts the motors. If something is not right, you don't get the run around, you know why because there was only one person responsible.

Now, there is a con to this. What happens if this one person disappears of the face of the Earth? We ran into this only once last year. (they didn't really disappear, they were just sick) In this senario, it is good to make sure that everyone on the team knows how to do everything. Our team, except for that one time, has always been this way.

Even though the idea of something big depending on one person seems scary, it's a whole lot better than having something rest on the shoulders of an entire group. If you have one person responsible for the chassis, and it isn't done, you only need to ask that one person why and then you will know.

My .02 ... + 45.86

Re: Sub Teams
 

Our biggest problem last year was too many people doing the same thing. At one point 5 people were building the frame, and it took 2 weeks, which is a rediclious amount of time for such a simple task.

As for the actual design of the robot, everyone gets their imput, and we all decide on what we want to build. I just want to have groups of people working on each different sub assembly instead of everyone working on one thing at a time.

Basically this is what I have come up with so far, please suggest and changes or additions-

• Frame
• Drive Train
• Game Device depending on what we need to do
• Electrical
• Programming
• General Help- floaters who can do a number of tasks

The general help people would be the more advanced people in the team. Hopefully they will know the inner workings of each of the sub systems well, so that they can do repairs in the pits with a minimun number of people.

Re: Sub Teams
 

Hi, I'm the "lead engineer" on team 1317 this year. Although it is a rookie team, I have been on many other FIRST teams over the past six years. From that experience, I have drafted a "Team 1317 Standard Operating Procedures" document. It includes our team organization, as well as bunch of other useful stuff. You might want to take a look at it:

http://www.osufirst.org/twiki/pub/OS...dureManual.doc

Two points that I want to highlight: about the comment about not having any team structure, that's a bad idea. You need team structure, the key is to sure that is an effective structure, not an ineffective structure. A committee of six people rarely gets anything accomplished. Democracy sounds great in principle, but it is very inefficient. A dictatorship or oligarchy approach is usually best for FIRST as it is more efficient. Put one or two people in charge and let them have final say over everything. Then, have a nice hierarchy under them.

Second point: although this depends upon the style of frame (or "chassis") and drivetrain that your team uses, I have found that making separate frame and drivetrain groups is usually not the best idea. Combining them into one group works much better for us.

Re: Sub Teams
 

That is a really nice document. Once the white papers are back up that is where it belongs. I do agree with you that democracy on a robotics team does not work. A dictatorship is probably a better choice. Also, the chassis and drivetrain are indeed related and it is wise to combine them.

In your document, I don't think all that procedure is really needed but I do think it is very good procedure. Do you actually plan on following all of it? Also, I strongly admire the building practices you listed in there.

I wrote this to my team once:

Re: Sub Teams
 

116 tends to break into subsystems that present themselves from the game. Last year there was Control, Mobility, Swing Arm, Stacker, and Integration. There are also other non-build groups, Chairmans, Animation, and other 'Ancillary' tasks that appear. (Finances, travel plans, organizing lunch)

The tasks that seem to repeat themselves year after year are these:

• Mobility
• Control
• Lift
• End effector
• Animation
• Integration

Mobility is simply responsible for making the robot locomote.
Control is the physical wiring of the robot- layout of speed controllers and relays- as well as the code writing.
Almost always some sort of lift system will be used in some aspect of the game, stacking in 2003, soccer balls in 2002, floppies in 1999.
The end effector is sometimes integrated directly with the lift system, but ultimately there is some scoring object with which we must interact.
Animation isn't part of building the robot, but is still a major subgroup. This year our animation team is teaching the basics of Inventor to many students so that at lest one student on each subgroup knows it so that the whole robot will be done in Inventor before we actually build anything. (Hopefully)
Integration is usually the Team Captain and an engineer, and makes sure the groups are interacting and that things that need to shift can shift, or that an appropriate solution is found. They also make sure to kick people when, I mean before they fall behind schedule.

Overall, the number of students in each group is determined by the total number of students. There is a limit to how many people can work on a part at a given time, but if you CAD everything out beforehand (if you have the resources), then it is easy to have many people manufacture parts, until you start assembly, then space becomes limited. And for repairs in the pit, we have a 'pit crew'. They are the only team members who are there all 3 days, the rest of the team is only there Friday and Saturday. They are the 5 people, usually one from each subgroup who put in the most time and best know the system. Other things come into play when selecting them as well, but that varies from year to year.


Determine what tasks need to be done, and then divide up your manpower among them. Define goals for each group (the mobility base needs to be done by week 5 day 2) and make sure they stay on track. Have fun at competition when your robot performs flawlessly and never breaks. :D


Wetzel

Re: Sub Teams
 

Here's 350's sub teams that we have operational during build season:


-Mechanical Sub Team (with the following sub-groups)
::: Drive Train (chasis)
::: Sub-Assembly 1 (sub assemblies are things like grippers or arms)
::: Sub-Assembly 2
-Electrical Sub Team (with the following sub-groups)
::: Power Distribution wiring
::: Control System wiring
::: Programming

The captain and assistant captain usually have good knowledge of both mechanical and electrical, so they float around, helping where they are needed most.

we dont do the animation competition, so theres no team for that.

Competition sub teams (in case you want these too), Primary Drive Team, Secondary Drive Team, Scouting/ Strategy Team, and Pit Crew (the elite members of the 2 build teams whose main job on pit crew is to repair the robot at competitions).

Hope that helps.

Re: Sub Teams
 

Thanks for the compliment. Once I go back through and revise it, I will certainly consider submitting it to Chief Delphi's white paper section.

What procedures specifically do you think are unnecessary? I intend to follow pretty much everything in there (unless my team members strongly object). Almost everything that I wrote is in there because one year or another, something turned out badly and having this or that procedure in place would have prevented a lot of trouble.


This is good practice to follow... However, I would contend that a better, more concise way to state it would be "use the right tool for the right job". There are times in FIRST where a hack saw is the best way to go. And there are times when a band saw is best. And there are times when a mill is required. The key is to recognize when the extra effort of a mill is needed, and when it isn't. Unfortunately, the only way to learn this is by experience.