I’m in charge of a new Vex team and trying to get it to compete in at least state or nationals. I secured funding and kind of have knowledge on competitions. I have a few questions:
How do you organize builders/coders/inventory to save time on your team?
If the limit per team is 4 people per competition, how is it decided who goes?
I’d really appreciate any tips or just feedback because i’m eager to get the robotics team off the ground. Thanks!
1 Like
Is this set by your organization? Or did you see a rule in the game manual that makes you think there is a specific team size?
3 Likes
No, its just that as I scroll throup upcoming events they have specific team capacity. Maybe I’m reading events incorrectly?
Team capacity is referring to the number of teams from a single organization that can register for an enent, as many organizations have multiple teams.
11 Likes
Thank you for your help!
My suggestion would be to build two drive bases if you have the parts, one for coding and one to build the robot on. This way, the builders can still build and the coders can still work on their code with a physical robot. If you’re unable to do this, I’ve found modeling my algorithms in a simulation is a good way to visualize how they work, and where I may need to debug it.
5 Likes
9 Likes
Using some sort of CAD software such as Autodesk Inventor to plan out your robot beforehand can be very beneficial. This can save hours of trying to improvise and allows you to cut less parts because you know exactly what you need. Let me know if you need help securing a license if needed.
If this isnt an option because of parts or any other reason, you could also have your coders work on a secton of code. Then when they finish they could take the robot for a day and test code and such for that day and then the builders can get back to it.
Having a schedule layout such as a Gantt Chart can be beneficial because it can show teammates what they can/should be doing at any moment.
5 Likes
If you’re lucky, you’ll have someone who wants to be driver and a builder, two people who want to be a builder, and someone who wants to be a programmer. Two programmers on a team may be problematic, but one of our sister teams has THREE so it probably wouldn’t cause any big issues, as long as they have the same vision. The most mature, dedicated, and open minded person should be the team leader, not the most skilled one (at least in my experience). Our team has a kind of hierarchy:
Team leader: everything major gets run by him before we implement it, and he needs to approve. So even if 3/4 of the team loves an idea, he can still technically veto it (though he probably wouldn’t usually)
Second in command: never been defined, but one of our builders is basically second in command. He basically just helps the rest of us formulate ideas in our head before we show them to the team leader.
Everyone else: we only have two other people but that rank it’s relatively independent. I’m the programmer of my team, and as long as I get what the team leader needs done, I can go off coding whatever I feel like (which I certainly do). That lets me learn a lot of things that I can then use for what he needs done (like auton), or things I come up with that I think are necessary for the robot.
I think this is the best way to organize a team. It’s very subjective, so anyone can just strike it down as they wish. However, you NEED to make sure two things if you go with this idea:
A) Everyone on the team has a motivation and dedication to robotics
B) You let the kids decide the team leader, even if they end up making the wrong decision.
Reason for A: If you pick just off of skill, you will absolutely never reach worlds. I don’t think there’s one robotics team that isn’t trying extremely hard to get to worlds that actually DOES get there. I was unskilled when I went into my robotics program, however I was motivated and wanted to do something. Considering how great we’re doing at the moment (at least with the code, our mentor decided to take a month vacation and before that I got covid so we’ve had much less time to work until a couple of days ago), it is certainly worth it. Without even being able to test anything out on the robot I have about 1200 lines of code, and I’m not even 1/2 done with my code, MINUS making it actually work. That is what motivation can do for a team.
Reason for B: hating their team leader will cause many, many, many problems down the line. Don’t let them hate each other, and don’t let them pick on one another.
That’s my essay, now I’m gonna go do some programming. I know it was really long sorry for the read BUT structure in teams is very important so I just said all this.
5 Likes
Thanks for the advice on structuring the team. Appreciate the time you took to reply.
Thank you for the guide, I find it to be very helpful!
I wouldn’t recommend a team leader. If you really want, you can have a team captain that can be in charge of stuff like communications, but he shouldn’t have total power over stuff like design decisions. That’s just a recipe for disaster.
13 Likes
I see your point, but I will note that a leader who guides, motivates, and exerts an influence over the team is a game changer. Skill is the primary key to success but can be rendered entirely useless if the team doesnt mesh together well, communicate, and understand each others strengths and weaknesses and use it to their advantage. There is a difference between a “leader” and a “boss”, the latter being the one described by UvuvweOnyetenye.
4 Likes
I vehemently disagree with at least half of this. Glaringly this idea that a “team leader” is something of a necessity. Naturally there will always be that one team member who will often take the most responsibility and provide more direction, however to suggest that this person gets a title and near dictatorial vetoing control on how your team and the robot operates is absurd. Having a second-in-command is even more ridiculous, and the idea that you, “formulate ideas before we show them to the team leader,” is really a nonsensical, entirely synthetic disparity of individual team member influence in your robot’s design trajectory/ team operation.
Your team should be one thing above all else: collaborative, equitably. Never in my time did one of my teammates have more say or command over the other. We worked together and communicated ideas clearly every day, through every step of the design process, experimented, implemented, and worked much in tandem. No one was artificially more important or held more say over the other (not even in seniority.) We all came to decisions rationally with mutual understanding of what outcomes and avenues would best benefit the team competitively. I will agree with you in what you said in “A)”, in that, everyone should have motivation and dedication, and it was that shared motivation and dedication that all of my teammates had that got us as far as we did for so long, but I can say with certainty that if we had started the season with some asinine “hierarchy” we would’ve been extremely unproductive and likely would’ve blown cheeks. All of the truly great teams I’ve been able to compete with largely followed this same philosophy, and, in my experience, clearly was a winning one.
To answer the post’s question, with four members who want to be competitive you’ll ideally want (imo)
-Driver/builder (also helps if they at least have a decent understanding of coding so they can collaborate with the programmer to tune the drive-train and systems that they’ll end up operating, as well as helping to map out controls)
-Another dedicated builder/designer
-programmer
-Dedicated journal writer (A truly great and award winning journal can really get you far, but it takes a lot of time and dedication)
All of the builders should try to get familiar with CAD software because its an amazing tool and an amazing skill to develop (especially if they intend to do engineering professionally later on), and all members should at least have the ability to help build. Team roles should be taken as semi-loosely defined areas of interest or expertise rather than set-in-stone occupations. Just please don’t assign a “team leader”, encourage your team to work together and enjoy the experience.
5 Likes
We can agree to disagree. I don’t make it sound nearly as ok as it actually is, since we’re all on the same page usually. I mean, I just came up with the design for our intake, and my team leader immediately liked it and we’re gonna use it now. I believe moderation is needed in a team, because otherwise things may just never get done. Overall, he can’t just say “we’re doing this”, it’s just that when we all say “we’re doing this”, he has to also agree. So it’s still a democracy, just one with vetoing power.
I do absolutely agree with your distribution of jobs AND the cading software thing. 3 of us on our team know how to cad and it makes things much more efficient. Microsoft 3D builder is a good start if someone wants to get the basics, Blender is for much more advanced projects, but it is quite nice I will say.
I did state my opinion is subjective and many could disagree with me. I’m just speaking from personal experience the thing that worked best for us. It could just be how we are as people, and that makes us work better in a hierarchy, like how I’m a programmer who codes basically anything that comes to mind, and if it’s affecting the driver/leaders user control he needs to put his stamp of approval on it. Other than that, I can just go off and do all the crazy stuff I can think of.
I think proof that it’s not a dictatorship is in what we’re doing with our design. I wanted from the beginning to do a turret, however the rest of my team members thought it would be to complicated for too little reward. However I compiled a list of pros and cons, searched the forums like a madman, and got a strategy we could use for the turret and gave it to my team. In one sweeping move, I convinced everybody and we started working on it. Intake, I came up with a design for it and now we’re doing it just cuz I called him and told him about it. Clearly, if he’s able to just listen to what we’re doing, I think he’s much more of a “boss” type than a dictator type. You definitely need a mature person to take the job though. It’s better to work on soemthing than work on nothing, and the wrong person will make it so nothing happens.
1 Like
The best way to make your teammates all listen to you is to listen to them and respect each other.
I am my team’s captain this year. Last year, I was suffering from an uncomfortable team vibe. Like everyone hates each other, I think the reason is that they didn’t put in the same amount of effort. So, if u want your team to improve “together”, you must find people with a passion for vex.
From my experience(although not much), a captain must be nice to people, and also understand a lot of stuff. But they don’t need to be the best. He/ She needs to organize the team, helping with conversations between different positions.
The coolest thing about my team is that we have 5 people: two people are full-time programmers, one is a full-time note-taker, and one is a full-time builder. And I am the only person left, which means I have to fully support them. I do coding and constructing and driving, so I am very important for making two sides balance and as a driver, I can also code driver programs myself. It will allow the other two programmers to focus on optimizing their macros and algorithms.
Yeh, these are some of my opinions. Good luck!!
5 Likes