A large team

[keehun]

Hello Chief Delphi,

I'm from Team 2502 and this year we've had about 20 students on our team. I've seen pictures where the whole team is like 50 students and I've noticed that at least for our team, the "functional" team is less than 10 members. How do you maximize learning for the members who don't seem to be "part of the picture" when it comes to the "functional" team?

For instance:
Programming can be handled by 1 person with 1 mentor.
Electrical can be handled by 1 person with 1 mentor.
Building can use as many people as possible but so far it seems to be down to like 4~5 members in the "functional" group.

Can anyone give me advice on how the "other" part of the team can be more involved, learn more, and feel like they've done something on the robot?

We are a 2nd year group (3rd year next year) and we don't have enough mentors/resources for the second group to be building another practice bot, and we are squeezed for time so we can't quite teach everything to everyone during build season.

A few of our members kept on poking "can I try this? can I try that? let me do this!" and that definitely seems to be a good way for them to get involved and get to learn but also severely impede the progress of the robot's development. How should the team leaders handle such situations? Let them have control of the joysticks for a bit? Explain that it's only testing and they should calm down?

Big Thanks from a sophomore having ran a second year team,
Keehun
Captain, Team 2502

[laurenlacy]

In my experience the ways you can add more students is simply by expanding those programs you mentioned... our rookie year we had about one person doing programming, I know there is now a whole programming team that works on a bunch of different coding projects and toys around with different ideas. By breaking the building down into functional subgroups with a subgroup leader, and having the subgroup leaders work together to make sure the robot can integrate well you can also allow more students to feel "functional" in building the robot. This also means you have a larger group of students who know one part of the robot really well, which is good for troubleshooting.

As a team captain, you will need to work with your team to decide how to work with students who "just want to try one more thing". That is a great question to ask a mentor... situations will continue to come up in your life where someone will "just want to try one more thing" and your mentors probably have lots of great ideas for how to handle the situation.

Another way to work things is to have a "non robot construction" group for students who just really want to get their hands dirty. From building a crate to a mock up field (if you have the budget for this sort of thing), non robot construction can also be a blast.

I would also add that it seems you are missing an important "functional" group and that is the non technical side of things. While perhaps your intent was to draw attention to adding more students to the robot construction, FIRST is so much of the Inspiration and Recognition components, which in my experience don't always come from the robot. Another great way to add students to your team is to pursue avenues beyond building the robot, be it adding an animation team, pursuing the website award, and getting kids more involved with your corporate sponsors. Many large teams have half of the team or more dedicated to non-robot aspects of being a great team... finding innovative ways to reach their communities, working with FLL and TECH, working with corporate partners and finding new corporate partners.

Hope this helps.

[EricH]

CAD. CA submission. WFFA submission. Animation. Website.

What do I mean by that?

Your CAD team can do a lot of work to help the robot builders. They can design custom parts, help show where things can go, and otherwise be very helpful in the building. Don't forget, there's an award for Inventor use!

Animation can, used right, also help the designers. You can roughly design some things and visualize some unexpected things. But, they'll probably be too busy doing something to win the animation award.

Website designers can be doing a lot of PR stuff, plus there's another award for that.

And finally, the essay writers. The Woodie Flowers Award is one of the best ways to thank one of your mentors. The Chairman's Award tells what your team is doing to reach out to your community.

You could also get a few more onto electrical and programming. It's a little more complicated, but you can do more.

Option 2: Full-team prototype BEFORE the season. Take it easy and let everyone participate. Prototype anything your heart desires, like a crab drive or a mecanum drive, or different arm types. This isn't critical, so it doesn't matter who does/doesn't help.

[OScubed]

Team 1511 is a very large team (http://www.penfieldrobotics.com) (http://rollingthunder.smugmug.com) There are several ways to get other members involved.

For programming for instance, we had 2 subteams:
1) worked on the drive train control software - starting, stopping, traction control, etc. There was always at least an experienced student and a new student and a mentor working on this subteam
2) worked on the "upper mechanism" control - running the belts and pulleys, monitoring sensors, PID loops for control, - again 2 students, one experienced, one new.
3) Our build team was also split between top and drive mechanism, so that they didn't get in each others way when building.
4) We used a WIKI and team integration meetings to be sure that it all would go together (and work together) in the end.
5) Some team members worked on non-build items, chairman's award initiatives, Public Relations, website, animation, community service, fundraising, sponsor drive, rookie meet and greet, team awards at the eventss, etc.
6) Since we run a rally the last day before ship day, we had a team building a field, making over 90 orbit balls by hand, and running field logistics
7) We design our whole robot in inventor prior to building anything. Different students worked on different parts of the eventual full 3d model.
8) We're well known for our scouting program, and someone has to build it, design it and run it both before and during events.
9) The drive team works on strategy and tactics, and is not part of the pit crew.
10) we had a safety captain to run our safety program.
11) The team is a year-round team (we even meet in the summer) and we train our new members in subteam sessions prior to build season on key topics (they must select a main and minor subteam to participate in).

In short - there is plenty to do, it's a matter of having a motivated mentor or parent to guide the students, and recruiting students who want to work on those other things in addition to, or in some cases instead of actually building the bot.

To recruit such a large team you need a few ingredients:
Significant recruiting effort at the FLL/Middle school level so kids entering high school already know about and want to join the program
A mentoring system that makes sure that the new students are not left behind the experienced ones.
Respect and recognition of the school teacher and student body for your achievements and hard work. This means good PR and relations with the board, PTA, teachers and the janitorial staff.
Recognition of the team and it's achievements by parents of prospective kids. The best way to do this is through parent involvement and outreach. Parents talk to each other. Give them the tools to succeed.
Excellent sponsor and fundraising capability. Make sure there is a fundraising and sponsorship requirement that each student must achieve.

We put paying for trips on a slideing scale. Achieve all our required achievements and your trips are either completely or mostly paid for. The less effort you put in - the more you pay if we travel.

[nlknauss]

We started a rookie team this year that saw up to 45 people start out the year and were really worried about how to keep everyone involved. It actually turned out to be relatively simple by really subdivided each area of robot building down into subteams.

After we identified our initial design strategy we divided the robot into mechanical, electrical, and software and then further divided those sections based on the subsystems of the robot which include Chassis, elevator, and shooter. So we had 9 teams of students Chassis electrical, mechanical, software, elevator electrical, mechanical, and software, and so on. Each also had 3 or 4 students to handle the workload and figure out how to integrate between the different subsystems. On top of that we had the students who were developing a marketing plan, some video, some website, and documenting the process. It turned out to be a really nice system, but of course the major factor that need to be considered with this module is robot integration. Stay organized and make sure someone is overseeing the system and ensuring that goals are met.

Good luck!

[sgreco]

There are lot of ways to get people involved.


There is a great possibility that when your team gets to be over 20 people that you won't get everone to do something significant with the robot. The best way to get a lot of people involved in in the mechanical aspect is to do a lot of prototyping. You can have at least 3 different prototypes happening at once and at least 2 maybe as many as 4 or 5 people on one prototype. This way you can get 15 people all working and learning things. Not only do lots of prototypes get people involved, but it really helps tou learn what the best way to achieve whatever task you want to achieve. On top of this you can hve people working on the things Eric mentioned as well. You can always work on fundraising and thanking sponsors because there are always ways that you can use money.

I don't do the programming on my team, but I recall that we had at least 4 students and 2-3 menotrs working on code at one time (I'm not sure how that worked but it is possible).

[whitetiger0990]

I can only speak about expanding programming, but it's simple.

1) Keep open communication and documentation
2) Divide and conquer

This year it was kind of hard to divide up work if using LabVIEW Basic framework. Using C++ or Advanced framework, just develop the system into subsystems which communicate to eachother. We used the advanced framework and our robot main basically consisted of a series of subVIs which called the code for the Shooter, Conveyor, Drive, Lights (LEDs), etc.

Each subsystem had a cluster that was part of the Robotdata cluster. Each subsystem usually stayed within its own cluster.. so they guy working on Conveyor code developed it completely independently from the shooter code. Then it was later integrated and merged (which wasn't too hard since the only shared code was the robotdata control which just needed to have the new typedefs added, and then tho robot main vi which just needed to call the new code).

Revision control is also good. Everyone works in their own branch until it's merged with the master branch.

Keeping all this in mind, it's easy to expand the programming team.

Similar with the Electronics. Electrical wiring (specifically the PWMs) information is shared with programming, so make sure that's well documented too.

You can have someone work on parts placements and wire routing (might be good to have multiple people do that so there's less mistakes). This also requires talking to the Build team so a speed controller isn't placed on the opposite side of the bot than the motor. One person can also work on labels (labels are always good). Should be short, and useful (tells the name of what it does and where it plugs in).

The actual wiring can also take more than one person.. one to cut, one to crimp, one to place. Etc. With more people, it can go even faster than normal (but not too many..)

Yeah.

We have a Controls team which is responsible for a much more holistic understanding of the bot. While you have some people on build which may have spent their entire time on one subsystem. Because Controls works more intimately with all of the bot, they get to have a much more deeper understanding of it (if they choose to, but that's the fun part!).

[Justin Stiltner]

Don't forget your other sub groups,
1. Fund Raising (you still need more... dont know of a team that doesn't, plan for the future)

2. Public Relations ( see if you can get free spots in your local paper, prepare press releases, work with local tv radio, etc. Get demos lined up at public functions, make your imagery and name work for you, let people know you are there. Some of the best sponsors, and resources you will get, are the ones that could not be looked up in the yellow pages, or found on the internet)

3. Logistics team ( prepare the crate, practice field, find game pieces, organize food for the meetings, clean up afterward etc.)

you get the picture here, FIRST is not only building a robot, but inspiring students, something they will realize when they see the different groups working, is that it takes more than just engineers to run a team, or business. It takes all these groups, and that one person on your team that may realize they dont like engineering (gasp) may just love PR or logistics!!!

My team always spent a good amount of time trying to "figure the game out" what that meant was really sit down and think about how to play it, what is important and what isnt, and other ways to accomplish the goal, that may be a bit out of the norm, Ive always wanted to dedicate a few people to this task, for at least a week, and see what they come up with.

[Steven Sigley]

Another small area depending on your budget is a CNC team. You can get students to learn about Mastercam, and mill out special parts for your bot. On 701 we mill out a few custom hooks, and other small pieces and do awards for other teams on our CNC. Even if this isn't an option now, if you acquire one down the road it's a good thing to have kids do.

[FIRSTgirl675]

Team 675 is a large team of about 50 students, and we tend to have the same issue as you. We have a core, or functional group of about 20 people, and the other 30 aren't as into it or are not active.

The thing that I have noticed is that the difference between the functional group and the rest is that the functional group is very into the program (and spends every waking moment at school) and the others aren't as into it (and are not there that often). This may be your team's issue, and I'm sure there are many teams that have this issue. If this is the issue that you have, then it is going to be hard for you to get people that are not into the program to be at school to work on the robot.

One thing that 675 does is before the season starts we have weekly 1 or 2 hour training sessions beginning in September in almost every aspect of our team (some parts of the team have this 2 times a week to make sure that all material is covered in time). Not only does this have everyone ready for the season, but it will also tell you who is going to be in your functional group and who isn't. Doing this can also get rid of people that are dead weight and are not going to be a worthy member of the team.

Some ways you can try to get people to be more active in your team is to require a certain number of hours at school during the build season to be part of the team and to have the opportunity to go to competition. Also, having community outreach events and fundraisers throughout the year to try to get more people doing things on the team.

Hope this helps. Good luck!