Challenges of small teams with fewer than 10 students

[chi-town-biker]

Now that everyone has bagged their robots, I thought I’d ask what approaches other small teams use to manage their season. Robotic Colonels is three years old and has eight students who attend a high school with about 350 students. Our students vary in skills/abilities that I think is typical for an FRC team. We compete in FTC in the fall and the Midwest FRC regional in the winter.

One of the obvious differences between a small team and a large team is the total number of student hours available during the build season. Every team commits a fixed number of hours building a basic drive system, field elements, bumpers, programs and a practice bot. For a small team, these fixed hours are a larger portion of the total available student hours than a large team.

I’d like to share what we’ve learned and hope that other small teams will share their wisdom. For example, this year we decided before kickoff that we were going to build the kitbot on steroids. We knew upfront that it wouldn’t be the ideal drive system but that it would be a better than average drive regardless of the game and save us time. It’s worked well and I think we’ll do it again next year.

Right after kickoff we take a different approach to analyzing the game because we are a small team. It’s not practical for us to design and build the perfect robot. Instead, we focus on what we can build that would make an ideal second or third alliance pick. This year we built a feeder/defensive bot. But primarily we focused on three bot balancing. Our robot’s COG is purposefully set far to the right and has a set of wheels that ride on top of the 2x2 bridge rail. This lets us hang 60% of the robot off the side of the bridge leaving enough room for two long robots to balance with us.

I’m not complaining or suggesting FIRST change any rules. We’re interested in the experiences of other small teams and any tips or advice they can pass on. When you reply, please mention how many students are on your team.

[bf2416]

Team 4058 from Union County is also a small team with about ten members. Our school has about 450 students on a good day. We are in a small farming community, so mechanical solutions were not a large problem. Our biggest obstacles were funding (hard to get sponsors in a small town) and programming. Those two obstacles, coupled with the fact we are a rookie team, led to a slightly stressful, and at times hostile build season. We had a good time, however, and grew closer as a group.

I am the head programmer and I work with maybe one other person, depending on the day. I know I had to teach myself the basics of labview very quickly, and be able to explain what I was doing to the other part-time programmer. That was difficult, but thankfully we caught on quickly.

Other than the programming department, everyone on the team did a little of everything, such as design, rough CAD, field building, robot build, and various business operations. I personally like being on a smaller team because I get the chance to learn about many other aspects of robotics, not just programming.

I personally am glad I got the chance to participate in FIRST and I am also looking forward to next year. I have already looked at other drive systems (we are using a simple tank drive this year). Looking forward to the Boilermaker Regional in a couple of weeks.

That's my take on being on a small team for any that cares.

[SenorZ]

Team 3677 is a second year team in a school of around 2800. Our team has about 10 active members. I attempted to recruit more at the beginning of the school year, but not having an FTC team or other "cool" things for the recruits to do, they slowly vanished.

Our approach is simple: everyone show up as much as you possibly can! This works for some students, who will be in my classroom after school almost everyday and Saturday's too. But others have sports practice, other clubs, even college classes that keep them out of the build room. When those students come by their 1 day out of the week, they are lost and have to catch up on a lot. This is VERY stressful for me.

I like your idea of knowing your limits, and going for the best niche robot you can build with the personnel available. If we had done that we would have been done by week 3, but instead our (my) lofty ambitions caused multiple delays and rebuilds of some robot parts.

One last recommendation: CAD! NONE of my students know how to CAD because I don't. We have one former student who stopped by occasionally and did some CAD work for us, but otherwise we had a poorly organized plan of what the robot would look like when it was done.

[pfreivald]

1551 has always been a small-ish team from the middle of nowhere, though we've expanded by recruiting students and mentors from nearby schools. Small schools face the issue of having students that do FIRST, but also swimming, basketball, Academic All Stars, Jazz Band, etc, etc, etc -- so at any given time we may only have four to eight students working, and projects must be passed off as students leave and arrive. Centralized information database (or engineering notebook(s)) are essential when projects are being worked upon by different groups at different times. Shared network space and smart boards help a lot with this. A consistent schedule where kids sign up when they will be there and for how long is something we keep intending to implement, and keep not doing it -- though that's going to change for next year.

Fundraising is a constant struggle because we are limited by the school in what we are *allowed* to do (so that we don't take too much money from other clubs/groups) -- though since we were adopted into the Bausch + Lomb family things have been insanely better on that front! Their support is invaluable and essential for the continuation of our team, but we have to put in a lot of effort to bring in more money.

Mentorship has improved greatly for us, but for the first few years it was very hard. (We had no engineers for three years, and no programming engineers for four!) I very, very highly suggest demoing your robot anywhere you can -- our FLR Woodie Flowers Award Finalist electrical engineer was recruited in the grocery store, and one of our new programming mentors is the dad of a kid we recruited from a school next door.

Continuity can be hard, because fluctuations in interest from grade to grade can result in 20-50% membership number drop or increase. (The one kid who can program moves or graduates or whatever. Eek!) Peer and mentor training throughout the year is critical to long-term success.

Those are my thoughts for the moment, abridged because I have students coming in to learn some electrostatics!

[lcoreyl]

This is my 4th year with a team that averages 7-8 "full time" members.
Build Season
Design
I'm guessing that small team = poor team = poor resources in most cases, so I definitely agree with the idea above of avoiding the best robot design so that you can end up with a robot that actually works. I guess the struggle is making sure that the kids who are making final design decisions fully understand how many teams each year can't achieve the design they come up with. If you haven't ever built something in your plans, get onto chiefdelphi and ask around if it's a bad idea to try it for the first time in build season.
CAD
We've never used it and every year I get tired of hearing myself harp on to the kids that they need to learn it (and offer to learn it with them). I told the non-seniors that if at least 1 of them doesn't complete an offseason Inventor project I won't be helping anymore (which likely means no team). I see CAD as addressing a few problems:
1) no/few mentors and kids who aren't mechanically savvy: now instead of "figure this out and build it", you can say "build this"
2) Kids who've missed a few days and don't know what's going on: they can more easily look and see what needs to get done. This year I've had kids who had no idea what our plan for shooting was 2 weeks after we'd basically decided.
3) Shooting too high with design: the realities of what needs to happen are easier to see if you've CADed things out detailed enough
Communication
If you can't spare the kids and mentors to be the project manager, you need to have something in place so a kid/mentor can see where you are, and what the current plan is. This year I created a forum online and made categories for strategy and all subsystems, then within them had our current design and any further questions that still needed to be researched/prototyped/etc. Admittedly it didn't work because I didn't have buy in from the kids (they rarely ever even looked there), but I think it has the potential to work. I might force its use...
Newbs
Unless you are in a really serious time crunch, try to make sure the newbs are the ones actually doing--the programmer at the keyboard, the person drilling, etc. Otherwise your experienced people all graduate, and now you have serious problems.
Off Season
-get kids to work on some project to increase their knowledge on one topic. Programming, pneumatics, CAD. An advanced kid(s) could also look at other robots they've seen at competitions or on chiefdelphi and try building parts of them--drivetrain, arms, lifts, etc. New programmers really should go through a lot of work with the cRIO before build season as well.
-Do as much as you can in the community to get some press, make sure any PR material always says that you are looking for mentors and/or financial support.
If you actually get some money
-8020 T-slot aluminum. Even our mechanically challenged ("what are vice grips?") can prototype with this stuff. We also have built our frames from it the last 2 years. Also, its reusable, so long term it's cost effective.
-Arduino sparkfun kits. These have been great because they introduce programming in a way that relates to what they will do on the robot, and to the motivated student needs little to no help from anyone else. I've even used these during build season to give a student something to do where otherwise they might leave because they don't feel like they can do anything on the robot.

[AdamHeard]

We had 11 students during our 2011 season, but really only about 4 on average that worked on the robots directly.

Worked out well for us.

Don't convince yourself that a smaller team must set lower goals.

[PayneTrain]

Wait until I tell my teammates West-GRR (I come from 340 GRR territory) won a championship with a team a third the size of ours! Sometime we look at teams with 70-90 on the active roster and it can drag us down. Now I just see it as a challenge.

I think that to do well, all you need is determination, education, and good fortune. IIRC, GRR has been very aggressive with raising its standards over the last four years, and that's how they got to the top of competition's Everest.

It's hard to gather up the blood, sweat and tears a team of seven dozen puts into their team if you only have a roster of seven, but it can be done. I've seen it.

[chi-town-biker]

So what's your secret? If four students build the robot, what do the others do? Or, how do you manage the work to meet high goals?

It appears CAD is a challenge for most small teams. How do you train your students in CAD and find the time? How many students work on CAD? Are they finished by the end of week 2?

[Dan 1038]

Hi! Here is my take, from a guy leading 2 small rookie teams this year... niether of my teams had other experienced mentors helping, nor did we have much in the way oc resources. My recommendation to both teams was determine what we could reasonably accomplish and do well; both teams chose kitbots with 4 CIMs, 6 wheel drive and arms to grab the bridges - the focus was excel at defense and balancing. Based on 4306's performance in practice today, this approach rocked! We proved able to do everything we set out to do! The next few days will be fun knowing we are great at what we set out to do... keep the team focussed on achievable goals with maximum results!

[MAldridge]

I have the unique perspective of having just moved from a small team (~7 people) in one state, to a large team (~35 people) in another state. In the small team, everyone did everything, but we usually had to rely on only about 3 people with the specialized skills such as programming and electrical engineering.

On the larger team, I find that as a programmer, I can be far more specialized and get more done. I can easily just say that I need something added or adjusted on the robot and it gets done. It's easy to concentrate more on what I need to get done, and since I really like programming, I prefer this arrangement.

[metainf]

My team (3205) has from 5-10 kids on any given day, even though our high school is pretty big (Concord Carlisle).

The truth is, we have one SUPER dedicated member, who does a lot of the mental heavy lifting for us. This isn't a great way to run a big team, but it works for us. However, that kid is leaving this year...so next year is going to be tough.
(I'm formatting this the same as lcoreyl)
Build Season

CAD/Building
-although we are a very small team, we are lucky to have access to a very well equipped machine shop, and we do get quite a bit of funding from the school.
-The aforementioned super member does most of the CAD work, but I'm starting to take over that job.
-Because our team is small, we have to get a design ready by the end of the first week, if not just the drive train and other things.
Mentors
-Again, we got lucky, and we found someone who moved into the area last year, and he was a former FRC mentor, and he has helped us out a lot (shout out to Mr.Peeke if anyone else knows him).
-Another two mentors are the science heads, and they are the ones that keep us in line, and help us with planning our schedule/meetings.
New members
-last year I was the only new freshman out of two new members, and I got a lot of help from the older members.
-This year we got around 5-7 new members (they come and go), and its been hard to help all of them, but we're getting there.
-The new members really have to be quick on the uptake in our team, and they have to learn on the job.
-And most of the people who know anything are leaving next year, except for me and two others, so we need to get the new members ready.

That's about all for our small team. We are really screwed for next year unless the new members step it up.

[dbeckwith]

Originally Posted by MAldridge

I have the unique perspective of having just moved from a small team (~7 people) in one state, to a large team (~35 people) in another state. In the small team, everyone did everything, but we usually had to rely on only about 3 people with the specialized skills such as programming and electrical engineering.

On the larger team, I find that as a programmer, I can be far more specialized and get more done. I can easily just say that I need something added or adjusted on the robot and it gets done. It's easy to concentrate more on what I need to get done, and since I really like programming, I prefer this arrangement.

On our small team (~10) it's a little different. As metainf said, we (team 3205) have about 4 or 5 people who know everything and organize everything, and all the new members just kind of tag along and try to learn stuff but don't help very much. As a result our progress is usually slow but honestly I think I would prefer this to a larger team because everyone at least gets a chance to contribute and everyone gets to work on every part of the robot. I feel like on our team we get a more hands-on experience and a more meaningful attachment to our robot. Larger teams may be more efficient, but I think you lose that personal connection with the robot that everyone gets on a small team.

[Chris is me]

Originally Posted by chi-town-biker

I’d like to share what we’ve learned and hope that other small teams will share their wisdom. For example, this year we decided before kickoff that we were going to build the kitbot on steroids. We knew upfront that it wouldn’t be the ideal drive system but that it would be a better than average drive regardless of the game and save us time. It’s worked well and I think we’ll do it again next year.

I'll have to stop you right here. A well executed Kitbot on Steroids is better than 50% of drive systems you will see this year. That's the beauty of it!

Right after kickoff we take a different approach to analyzing the game because we are a small team. It’s not practical for us to design and build the perfect robot. Instead, we focus on what we can build that would make an ideal second or third alliance pick. This year we built a feeder/defensive bot. But primarily we focused on three bot balancing. Our robot’s COG is purposefully set far to the right and has a set of wheels that ride on top of the 2x2 bridge rail. This lets us hang 60% of the robot off the side of the bridge leaving enough room for two long robots to balance with us.

Few teams have the wisdom to recognize their own limitations and build a robot that meets them. It sounds like you guys did just that, which is remarkable for a team of any size and experience set.

I’m not complaining or suggesting FIRST change any rules. We’re interested in the experiences of other small teams and any tips or advice they can pass on. When you reply, please mention how many students are on your team.

2791 is not as small as your team, but we have similar constraints. We have found that playing smart goes a long way to make up for lack of manpower. It is much easier to build a simple robot that plays a single part of the game very well than it is to build a complex multitasker. A minimalist and simple robot has many, many advantages in terms of time - less to test, somewhat easy to make weight (we have not been overweight since our rookie year, with no formal weight budgeting or planning whatsoever!), easier to find a niche...

The key is to analyze the game, pick a part of the game that is both strategically valuable and something achievable for your team, and then go for it. It sounds like this year, you picked the bridge as your primary task and ball movement as your secondary task. In my opinion, you're right on the money. If you're good enough at that, at many regionals I wouldn't expect you guys to be available in the second round.

[PayneTrain]

Watching the regionals today, it's the same two keys to the game you will have in most years.

1. Please be able to pass inspection/move.
2. Accomplish endgame. At least half of the time you and a partner can win a qualification match if you both balance on the bridge.

Any team with the kit can do this. Isn't that fantastic?

[sand500]

Our team is very small with around 6-10 members, personally I like it this way because everyone gets to be involved with everything, so you dont have the CAD guy, the electrical guy, the programming guy, for us, everyone does everything.