2014 help for third year team

[faust1706]

and about committed students, by the end of build season, there was 6 students remaining, and after build season on friday nights and saturdays working with out practice robot. We start out with 30+ students every year, but after the 3rd or so week of build season, most of them are gone. We've tried to fix this by encouraging them to keep engineering notebooks and similar things, but they all seems to disappear, then of course reappear around competition. How have other teams fixed this issue?

[Alan Anderson]

Originally Posted by faust1706

and about committed students, by the end of build season, there was 6 students remaining, and after build season on friday nights and saturdays working with out practice robot. We start out with 30+ students every year, but after the 3rd or so week of build season, most of them are gone. We've tried to fix this by encouraging them to keep engineering notebooks and similar things, but they all seems to disappear, then of course reappear around competition. How have other teams fixed this issue?

The TechnoKats have participation requirements in order for a student to be eligible to travel with the team. This year it was 50% of the days there were work sessions during the build and following week. I think that worked out to at least 21 days that each student had to be present (and productive).

[dcarr]

Originally Posted by Alan Anderson

The TechnoKats have participation requirements in order for a student to be eligible to travel with the team. This year it was 50% of the days there were work sessions during the build and following week. I think that worked out to at least 21 days that each student had to be present (and productive).

Echo the 50%.

Any student who is interested is welcome to attend the competition on Saturday, but to be excused from school from team travel, our students must meet baseline requirements including attendance.

[Moriarty]

Originally Posted by dcarr

Echo the 50%.

Any student who is interested is welcome to attend the competition on Saturday, but to be excused from school from team travel, our students must meet baseline requirements including attendance.

This solves one aspect of the issue: preventing students that aren't really dedicated from wanting an opportunity to skip school.

However, it does not solve the other attendance issue: Students that are initially very interested in robotics, but due to distractions lose interest mid-build season.

From what I've seen, for the most part if a student isn't coming to 50% of the meetings, they don't really care enough to want to attend the competition.

The real interest for me lies in how to keep more of those students that initially show interest but lose interest for whatever reason. Many of these students probably couldn't make the time commitment -- thinking it was "Robotics Club" or something. But there are also some students that have the potential to become dedicated, but lose interest due to timidness or some other factor. I would love to hear key points to avoid losing such members.

Ideas that come to mind: Focusing on giving them tasks, making them feel part of the group, etc

[Siri]

Originally Posted by Moriarty

The real interest for me lies in how to keep more of those students that initially show interest but lose interest for whatever reason. Many of these students probably couldn't make the time commitment -- thinking it was "Robotics Club" or something. But there are also some students that have the potential to become dedicated, but lose interest due to timidness or some other factor. I would love to hear key points to avoid losing such members.

This has been a problem for us as well. The biggest pointer I can give you is talk to them. Catch them when they do come in, or even call them or have any friends on the team reach out. You might learn more about them, and you'll definitely learn a lot more about your team.

Do they feel like they're not doing anything? Like they don't know enough to contribute? That they're always behind because they can't make it every day? That they're under-appreciated? Did something happen that you don't know about? It's a lot easier to fix a problem once you know what it is.

It's also good to do this preemptively. We try to do one-on-one feedback sessions with all our students, either with an approachable mentor (can vary by student) or an approachable and responsible student veteran. See what they want out of the program, what they feel they're getting out of it, what they want to change, basically anything they want to say. It's invaluable feedback and you might be able to catch a loss of motivation before it happens.

As for how to actually solve the problems once you find them, I've done a variety of things based on student responses. You might do some/most of these things already, but just in case:
- We try to assign rookies their own veteran guide (sometimes we make exceptions for VEX alumni or children of mentors, or if they find one themselves which is rather common). It's great experience for the veterans, and it can really help rookies get acclimated and gain confidence. One challenge is if the rookie often shows up and the vet doesn't come, though. This can send a bad message as well as losing the experience.
- Talk to them often--even non-rookies. Make sure everyone knows the importance of what they're doing for the robot/team. It helps a lot!
- Recognize excellence/dedication/etc and give credit where it's due. We've started an "MVP of the week/competition" program for this.
- Start new training opportunities or help students switch/add fields of expertise within the team. Also try for some non-build bonding activities. Like say, if there's interest in doing something: a last build weekend party, a volunteering trip, whatever, at least make the effort to find out and engage people to make it happen (if possible, of course, but often it's the show of effort and interest in their input that counts).


We went through a 5-member team phase several years ago, and I think the biggest thing I learned from it is to remember to step back and refocus. Focus on the students that come for the robot, rather than the robot the students want to build.

[jimwick]

We are a team from rural Vermont drawing from 10 different high schools, so we have our own set of problems. Nevertheless, we had a very competitive bot at the Granite State Regional this year without having much access to sophisticated technologies.

Here are some suggestions.

1. It is not necessary to use CAD. We mostly do prototyping in cardboard and plywood, and it works fine. Making full-size paper drawing of the entire bot is a HUGE help. It is possible to make pretty good drawings of the whole bot and all systems on big paper. Avoid tiny sketches that conceal the problems.

Paper and plywood have a big advantage in that they make the problem very real for the kids, which is half the battle sometimes if you're not already an expert. We have had excellent luck by making operating prototypes of subsystems (shooter, conveyor, picker-upper) out of plywood and odds and ends. When they basically work we build the final versions in a proper way. When making prototypes it is not necessary that they conform to all the rules; you just want to test the principle that makes them work.

2. We have been using the kit-bot chassis or something close to it in recent years. This has solved an enormous number of problems for us, although sometimes some kinds of solutions are foreclosed. Still, a strong positive. You can get a chassis together after a week and build on that. You can drive it around and test control.

3. We have been willing to start out with "C+" solutions and gradually improve them. We have found out that a modest design that works will be far more successful that a complicated design that doesn't. And historically these C+ bot can be gradually improved to work quite well.

4. Even if it means limiting what you do, it is very important to get the complete bot together several days before the bag date. Use the time for testing and practice. Trying to get it to work the first time at the event is a sure way to lose.

5. We have had good luck by insisting that each major subassembly exist as a separate module that can be added or removed from the bot independently. That way the devices can be developed independently without everybody getting in each other's way. We often keep a couple of alternatives "alive" right down to the last week.

6. Be patient. It gets easier every year. It really does.

Hope this helps some.

[1683cadder]

Hold off on CAD until you're ready for more complex designs. For right now, I suggest using what I call the black box method, which is designing a bot with a whole bunch of imaginary boxes. Then after the layout has been made, you design the components to fit within the allowed space. This method would help you in the future when CAD is ready.
I meant asking local teams. They are always willing to help.
Also maybe your team should not be focused on winning, but instead focused on teaching English and teamwork through robotics. .02$

[faust1706]

We did that for the travel trip. Only twenty students are allowed to come. The thing is, at the local regional, it isn't much of a hassle to include the students who weren't really committed, so they are allowed to go. I don't know, my freshman year I sat back and learned, didn't do much, I just watched people do things and learn programming, but the people who don't participate just sit in the classroom and talk 3-8 everyday. It got under the skin of the people who did things. We tried to do a journal type thing. Write down in detail what you did that day, but the grader, the teacher sponsor, just gave everyone perfect scores regardless of what they did. It's at the point where only us 6 students can describe the technical aspects of the robot. Has anyone else had success with reversing this trend? And how common of a trend is this?

[Moriarty]

In response to retaining members... I found this extremely old thread on the subject that had some good insight:
http://www.chiefdelphi.com/forums/sh...ad.php?t=16465

[pmangels17]

CAD Design is a tricky thing. What types of machines do you have in your shop? We use both Inventor and Solidworks on 271, both are free for FRC teams, but Solidworks requires an application process, though it isn't rigorous. CAD Design is a great thing to use during the off-season. It teaches students about mechanical design, and allows them to estimate weights without actually building, so everybody can learn how to lighten parts, if you have a weight problem consistently.

Remember that robots do not have to be done in CAD. If you have the funds, designing and building a base via CAD over the summer is a great way to train students on machines while also teaching concepts that are key to FRC. Then gauge how difficult it was to build a base in a reasonable amount of time. From their, you can judge the practicality of CAD for your team during build season. This will also help your team become better trained before build season, since you have a high student turnover rate. Remember, you don't have to do a base if you don't have the money. Anything you can design and build will teach everybody about design. CAD doesn't take a long time to figure out initially, but it takes months to become proficient enough to design in a reasonable time frame, with practical design techniques. These techniques can b applied outside of CAD as well.

At FIRST Team 271, we CAD as much as we possibly can, and then machine with incredibly tight tolerances. All of our machining is done in house, and we do not have a full CNC machine, though our mill has some CNC capability (Z-Axis is manual, still operates mainly as a manual mill).

Hope his helps, good luck to you and your team.

[eedoga]

I started writing this this morning and had to leave for work in the middle, so I'm sorry if the topic has drifted or if someone else has already pointed this out.

First off, I want to applaud you and your team for making things work in an atypical environment/with an atypical student population.

That said, given the high transiency rate for your team, perhaps you should change your goals a bit. Why not make your focus for 2014 to build a great team with sustained support. Try and work out a way to maintain your mentorship from year to year, and focus less on the kids. Have your kids start a "book of ideas" or mental toolbox that they can pass on to kids in coming years. In the least try to get all of the information on how your team runs in one place that you can sustain from year to year.

As for "drop ins" We have them too. I think everyone does. I oscillate back and forth between thinking we should act like one of our sports teams where missing a practice means you miss the game and thinking we should be open and accept everyone. Some of our best students have started out as fringe drop ins...who found something they love and decided to stick with it...Others show up every day and seam to get little to nothing done. Given your population you may want to work out something that works with your kids. Maybe have your core kids serve as group or sub assembly leaders. Give them something to take charge of and be proud of, and then they can take drop ins under their wings and make building the robot into a learning experience.

Once you have a really great foundation you will probably be a bit more comfortable.

Another thing that I would recommend is that you keep this years robot in one piece for as long as you can. Take it everywhere. Go to makerfares. Take it to the park and shoot frisbees for people's dogs. Try to get your robot into a parade, and contact all of the kids who have been involved with your club and get them to walk along side it. Go to store openings. Have your kids present to the business where you work that is giving your team money. Basically make the robot something you guys are known for.

I honestly wish you the best of luck. If you would like any more help from me feel free to PM me for my information.

Edoga

[prismiko]

Our team is currently at a middle stage - not rookie but still far from the established older teams. We are happy to grow a little bit every year. I am a second year mentor and actually got some good tips from other mentors at the mentor training back in the fall.

This year, for example, we've tried to formalize/emphasize a little more:
- define roles and responsibilities - regardless of who does it, there are certain tasks which need to be done. If you have a small team, people will have to wear multiple hats. If you have small tasks, it would be easier to assign to kids that are there that day.
- project planning - we asked student team leads to break down to task level and track them on Trello. Note that it worked very well for our programming team but not the others (but only because they didn't do the exercise and not all the mentors were able to follow up).
- project management - we tried to have catch up/ stand up meetings for the first few minutes of each session so that everybody knows what they're doing. The kids may need to be reminded to do this until it becomes routine.
- communication - someone from each team sends out an email summarizing progress for the day and where they left off/tomorrow's work
- design - we tried discussing design ideas during sessions and over emails - we don't have CAD yet (that's for next year).
- We planned to finish our robot a few days before bagging and have our drive team tryouts/practice. We were able to hold tryouts an hour before bagging and found our best driver. Our programming team had prepared a cheat sheet which showed the commands/buttons for the robot that anybody who wanted to try out can look at. This was an improvement over last year considering our first practice was at regionals.
- programming - we got GitHub integrated; we developed code using pair programming so that each of our 2 programmers served as the backup for the other. We converted to the Command-based model in Java - it was easier to move forward once the template was established.
- we changed the meeting hours slightly to accommodate the mentors - we had support from our teachers who have to be there to supervise in the school building.

If your students only have a 2 year span, you'll need to get some mentors that will commit to more than 2 years. Once you find a process that works, you'll need the mentors to enforce and teach the students that process.

There were a good several weeks where we lost momentum - students on our team are involved with many other activities at school, they had finals, we had the snowstorms, sometimes we couldn't get the hours needed at school to finish building, etc. We're still struggling with that and how to keep the team engaged during the off season. I send them emails with interesting stuff from CD, FIRST updates, robotics related articles, etc. since I know most of them were not regularly reading these sites.

There are definitely many other areas we need to develop but we found that too much change is difficult to make stick. Besides, from what I've read on other threads, it's taken years for the older teams to get to where they are now. You should discuss with your fellow mentors on the team and agree on a list of goals for 2014.

Hope this helps!