It sounds like to me that you need to increase team buy-in (if you look up team buy-in on Google you’ll get a bunch of relevant results). You probably have a lot of students who are half-committed. The first step to getting people committed in my experience is to give people ownership over team results. So I would have a team meeting and ask people where they want the team to end up next year. Come up with some SMART goals (look up the acronym SMART), then decide as a team a plan to reach those goals. Make sure you write the goals and the plan down. It’s important to let the people who’s participation you want to encourage lead this process. One way to do this is to specifically ask specific people during the meeting what they think. It’s also important that people understand why goals and planning are important. If you give team members ownership over the offseseason plans, they are more likely to follow through.
I’ve considered talking to them as a team or individually, but I’m afraid that doing so will discourage them even more.
I do plan to let them write this year’s robot code this summer. The reason they did not write much of the code was the non-stop mechanical work that left little time for programmers to test the robot and its unprecedented features. But with our outreach events and personal projects in the way, there might not be enough time to rebuild the whole software from scratch.
I’ll try writing documents - that seems like a good idea.
That approach might be more workable with fewer members on the team, but we currently have about ~30 new members this year and having them decide on the team’s vision doesn’t sound practical. And because their lack of motivation led to lack of involvement, they might not have the best judgement of what is best and what is realistic for the team.
Then have a smaller, but still sizeable subgroup with involved members make those decisions. The point is, the team will have to set priorities in some way, and one of the best ways to get people involved is getting them to have some stake in the priorities.
Cutting people out from the decision making process is one of the best ways to demotivate them, in my experience.
It might help if you share a little bit about how your team organized. Do you have any strong mentors, how big is the team (both in total numbers and also people who actually showed up to most things) and what is the student leadership like?
The fundamental question you need to answer is “What’s in it for programming sub-team members to stick around?”
Do they want to enjoy themselves?
What do they want to learn?
What do they want to program?
What do they want to achieve?
The only ones that can answer reliably are the sub-programming team members themselves.
I would suggest you hold a lessons learned session at the end of the 2019 Destination: Deep Space season and be straightforward about your concerns.
We have no mentors. We are still the only team from our country, and we still can’t find anyone with expertise and a good understanding of FIRST. Our best bet would be the first generation of alumni. Most of our knowledge is researched and passed on from generation to generation, that is why I was worry about this generation lacking in commitment.
There are ~40 active members, lead by a core team of captain, vice captains and subteam leaders. The captains would be the primary ones to decide on the team’s vision and plans, with heavy input from subteam leads who train and manage new members. That has been the way it works for 3 years.
As far as communication goes, I didn’t realize you folks were in Taiwan. I’m only really experienced in working with US teams and businesses, and I know communication expectations can be different overseas. I know around the folks I work with there is definitely a desire for clarity of purpose, even if it involves slightly hurt feelings. There’s a distinct tact to saying “this isn’t your fault so you shouldn’t feel bad. However, we need to improve still.” It will take time to digest in general, but it’s better than keeping people in the dark as to why they are being asked to do certain things .
The other thing to consider is a priority discussion with the team. If keeping the programming team trained is a priority, other responsibilities may have to be outsourced or negotiated to ensure you have the time you need. Ultimately your team needs to do what’s best for your team, which involves discussion with everyone, and possibly reallocating time spend.
Try github and partner with a US team that is known to program well. i find it hard to believe students in Taiwan cant code well and “are not motivated” break the problem down to simple parts…start with existing resources then find motivated students. Coding is global no excuses.
Actually we’re from Vietnam, not Taiwan. And as far as getting a robot up and running, yeah they can do that, but they lack the will to learn new things on their own and just take in what I’ve trained them, so they don’t know much about what works well and what doesn’t, and what has room to improve on.
Please try team building and build their confidence. Sometimes students (for that matter everyone) feels overwhelming to step into others shoes, especially if the expectations are high. Get programming team and work through projects and of course with constructive feed back and positive reinforcement. I may be asking too much from outgoing team but see what’s best for your team.
I have a feeling the other programmers will become more motivated as they get more experience. You don’t need a robot to continue teaching, and, honestly, you don’t need the entire subteam to be as motivated as you. Find a handful of (or at least 2) underclassmen with potential and work with them to build up their motivation to learn and do. You can’t force motivation, but you can cultivate it in those who already have some motivation and, ideally, expertise.
The mission of FIRST® is to inspire young people to be science and technology leaders and innovators, by engaging them in exciting mentor-based programs that build science, engineering, and technology skills, that inspire innovation, and that foster well-rounded life capabilities including self-confidence, communication, and leadership.
You should think less about judging the performance of the new programmers and more about how you, since your team doesn’t have mentors, how you can inspire them to continue on. What can you do so that you don’t lose half the recruits after one year?
SInce you don’t have mentors you and your programming co-lead should sit down and think about how you are going to pass along all you know to future students.
You might want to think of how the code is written/organized so that there is a consistency and is easily handed off to another programmer.
You need to come up with an off season projects for the team to work on.
You need to come up with training exercises for the team.
Usually having them program previous year’s robots is a good start.
You need to think about the build season and what is expected of the programming team. What should the program team be working on each week of the season.
Since bag day is gone next year, maybe not each week, but think of the milestones during build season and how programming is involved in the process.
Other people have already given a lot of good advice.
Your team seems to go to the Southern Cross Regional every year. It would be worthwhile to build relationships with teams that also go to that Regional every year.
It would also be a good idea to study the successful robots at the events you go to. Ask questions about what the team is doing, why they are doing it and how.
Since you are operating without mentors or any students with previous experience, it would also probably be a good idea to build simpler robots with fewer features such as the 118 Everybot 2019, 2018. The “Strategic Design” videos from Mike Corsetto of 1678 and Karthik of 1114 will help guide you to robot designs based on the constraints you face.
Lastly, it may be a good idea to use your old robots as programming platform. You may have to purchase a second set of control system parts. This allows your programmers to start testing basic functions independently of the mechanical assembly work. Since this programing platform is not what you will bring to a competition, the rules about when the parts were manufactured do not apply. You may also be able to use it for driver practice up until you have to leave for the airport to go to your event.
We do use old robots to practice coding. However, as I said, this year the team went with an ambitious design that presents unprecedented features. Our old robots are quite simple when it comes to code since they only have motors and cylinders (and a gyro, perhaps). I think that next year they would have this year’s bot as a more complete practice robot.
What some teams do is they remove the upper structure and use the chassis as a programming platform and/or practice chassis.
You do not neet to totally reproduce your competition bot to use an old chassis for programming. You only need to add motor controllers motors of the same type so you know the motors are turning on and off at the correct times and that they are turning in the correct direction. It will not be a complete test but it does not tie up your competition bot to find out a motor is turning the wrong way.
We took full use of the old chassis and even got pathfinding running on one of them, but the main feature of this year’s robot was the elevator which we never built and program before. And since we didn’t have enough components to build an identical prototype, most of the code was written by the co-lead who had to stay overnight in the last week.
You have discovered why many people recommend learning to design and develop new mechanisms in the off-season. You have also run into a constraint that you need to take into account in future years, the availability of parts. Being the only team in a country adds a lot of constraints that the teams you may be emulating do not have to face.
I think others have already given really good advice, but I just want to get word in here:
I think one thing you should definitely do is give them something to work towards. For example, since we (7700) are a new team, we are going to be working towards the goal of making a drive systems repository (maybe some other stuff like pneumatics, or arms/etc. too), so that next year when we need to code things, we can utilize this. Something that makes the team work together, but also lets them contribute to the team in the coming years would be best, as it gives a sense of involvement.
Next, you want to try and establish a sense of community within the programmers. This can be done through things like inside jokes (that come naturally), or just getting to know each other, and become friends. One of the main things that can kill teamwork, is people not liking each other. (Don’t do icebreakers. This will just be awkward.)
Lastly, I’d try to find one or two people, that you want to directly train to be co leaders/leaders next year. But, make sure to not spend all your time on them, just give them a more in depth understanding of the code, etc. (Also, you can tell everyone that you will be selecting 2 people to be co heads for next year, to spark a bit of friendly competition.)