My school started a robotics club for VEX V5, and I am helping to run it. Currently the system is use hero bot/internet/brain as inspiration for robot, build it the best we can (we have a good amount of metals/resources) then attempt fix problems and code and practice.
However, only 2 or 3 people can physically work on the put together robot at a time, and the rest of the team (we have 8 people, max size) waste away. What roles should the rest of the team carry out while some people attempt to fix the robot? Should the rest of the team go home?
There is generally poor communication in what to do and how to do it and who will do it. Should leaders just decide what to do and who to do it and tell them so?
When the robot is done, the fixing issues gets in the way of the autonomous coding gets in the way of the practicing.
For next yearâs competition, this is the plan:
First design: teams come up with idea for drive train and all components, modular
- Specific, including all sizes of all materials (is this a good idea for designing?) OR Specific sizes for key components
- E.g. base drive chain size off of intake size
Justification for cutting required before cutting
Approval by leadership
Make timeline
Build prototypes
Fix issues & adjust
Assemble prototypes into final robot
Code half, practice half
What can we do to make sure we can make a good robot, work better as a team, improve club organization?
Thank you all.
Many schools, including my own, will have multiple teams at once. If you have 8 people, I would recommend 2-3 teams, each building their own robot. This does require additional resources, but itâs better for the students, as they get more time to work on their robots. As a bonus, it makes it easier to organize and work together.
When you say âleadersâ, I assume you mean a student who is in charge. At my school, these roles get filled sort of accidentally. Usually, we pick a goal as a group, divide it into parts, and then each person will do part of it. Sometimes the jobs are assigned, sometimes we volunteer for them.
Coding and practicing isnât usually an even split. I would have the teams pick days for each thing ahead of time, so that they donât have to fight over it.
Iâd just like to add in my current team demographics.
I would not go larger than a team of 4
- Driver
- Coder
- Designer/builder
- Engineering notebook
(all roles can help with building)
While it may seem cruel to have one person do the engineering notebook, it is important to have a dedicated person because you can get a lot of judged awards that can take you to states and worlds.
Also I would force the designer to make a CAD so they spend less time building: leaving more time for coding+driving
If you really have 8 people, I would say you need to distribute people into teams first. You cannot have 8 people working on a robot practically.
My team is just two people, me and my friend and the job distribution is basically:
- Modifier/notebooker
- Coder/driver
Everyone should contribute design ideas and build the base robot.
Still though, it really depends on how dedicated your people are and how good of a teacher/coach you have as well as what resources you have. Figure out team distributions first according to that(bigger teams for less resources/less available time) then work it out from there.
I would recommend that instead of just having 1 person do notebook, have multiple people help and the entire team at least know whatâs happening. Burnout on engineering notebooks is very real, and having even just 1 person to consistently help out is extremely beneficial (Iâve experienced this firsthand).
Yes I agree, even with one person, we still have the Coder, and the designer document.
This way it keeps the formatting consistent compared to having people just take turns.
Like others have mentioned itâs usually better if you can split off into more teams of 3-5 people, but if youâre stuck in a team of 8 then here are some potential options you have on top of the other suggestions above (from someone who has been in a 10-person V5RC team before):
- Some sort of âshiftâ system, where members come in based on their availability so that throughout the week thereâs always some 2-3 people working on the robot (this will only work as well if your team members donât all âcome at onceâ which you seem to have implied)
- Form smaller sub-teams that work on prototyping for individual components, allowing you to speed up the ideation and prototyping portions of the EDP (but not necessarily making the final robot)
- Team members not actively working on the robot could work on some other tasks such as parts/tools organization, documentation for the Engineering Notebook, programming, running tests on already-made prototypes, brainstorm more ideas, etc.
Just to pile on, iâ'll say that 2-3 teams would be better, much each team has itâs own registration fee(from what I know), and we donât know what opâs budget is, so they might not be able to have multiple teams.