Project Mangement

A few monthes ago earlier this year, Vex was something far out of reach for me, something which I also had no information about. Back then I was the project manger for my team(38474 Polaris) there were tasks which were assigned around the team. It made it easier to keep track of tasks which had to be done in a team. Now after months, I’m now in Vex, and also thinking of being not only a team member but also a project manger. But since the structure of Vex is so much more complex it creates more aspects to mange. I was interested in knowing, how other teams have been doing their job in manging tasks, and distrubuting jobs. Furthurmore what aspects/elements they have incorporated into their task lists. Hopefully someone has an solution for manging a team.

2 Likes

Hi,

For jobs that are used every meeting , I suggest having at least the following:

  • About 2-3 builders
  • A programmer
  • Someone in charge of the engineering notebook

There are also jobs that may not happen every meeting:

  • Driving (at every match including practice)
  • Design (early in the year plus redesigns) - I suggest everyone participates in robot design
  • Scouting (mainly at competitions)
  • Research (early in the year plus redesigns)

All these jobs depend on the team, as they may want more/fewer jobs, and people depending on their needs and goals. Jobs can be assigned based on skill, or the team members can choose what they want to do. This year everyone is learning a different job to be able to assist others, in addition to jobs kept from last year.

For our tasks list, we make goals each day based on what we need to do (like continuing base prototyping or gear down the catapult), but keep an overall priority list in mind for the robot: such as listing robot components in order of need, and knowing that we need to brainstorm first. We follow the recommended VEX EDP: (https://curriculum.vexrobotics.com/curriculum/intro-to-engineering/what-is-the-engineering-design-process.html)
I am also curious about how other teams manage jobs and tasks : )
I hope this answered your questions!

3 Likes

For my team we have builders, programmers (cheer), and dual programmers/builders (who usually are more of the leaders). Everybody scouts except for the main programmer and driver at every tournament. And the main programmer and driver scout most of the time. Driver is a secondary job. The driver can be better when they have an understanding of the robot and its coding. We don’t usually have a specific set of goals for each meeting. Early season we try to finalize design and build it. As we keep moving forward, we focus more on autonomous and how we can refine our design. We follow the design process as we constantly look for improvements.

2 Likes

For my the team that I am on, we have a head builder, a secondary builder/notebook person, a programmer, a skills driver/secondary programmer, and a match driver. We all scout and try to set deadlines for when our robot should be completed (well, our mentor does, and we usually surpass them…). After our robot is completed, we spend some of our days driving the robot, and some programming it.

2 Likes

How much time do you give, between the completion of the robot to the first tournament?

Really 1-2 months is good, but of course that won’t always happen.

But isn’t that for veteran teams? What is recommendation for newer teams, who don’t have pre made designs, or experience from building robots. Isn’t the period going to be shorter. Or do you recommend using less time to build the robot, to give more time to practice for driving?

A lot of times in project managem,ent IRL we do 2 passes… in the first we work forward, laying out tasks and how long they will likely take and see where everything is projected to be done. Usually that date is not acceptable, so then we use that first plan as a guide to plan backwards from due date (say 1st Competition) to now. That 2nd pass often involved hgaving to make commitments to work faster, figure out how to parallel path more items, identify and resolve likely risks and sometimes reduce the scope.

Whether you spend more time developing a more complicated or robust robot and have less time to practice driving, or you design a simpler robot that gets more practice time, is a strategy decision that should be evaluated and recorded in the design notebook at the front end

2 Likes

It’s my belief that driving practice is a lot more important than quality of the robot. This is why you see teams with the same robot, but one does much better because they have more practice driving. So I’d recommend building pretty quickly (you should be done building in about 2-3 weeks if not faster), programming driver/auton, and using whatever time you have left to practice. Just my 2 cents. :smiley:

4 Likes

Yeah, I agree that your belief that driving practice is a lot more important because at worlds, we competed against you for our last match and we were more worried about you guys, a cap bot, than your shooter alliance just because of how you would score caps really fast and how other teams would just ignore it. Thats why we told our alliance to just play defense on you the entire match. (we were 6364A btw, the team with the red and black robot)

But most mostly importantly does driving practice have to be done with one specific robot? Does experience usually move on from one robot to the other?

Sometimes… depends largely on how similar the robots are to each other

Our team usually does it with our sister team. If you do not have a sister team, you can build a small “bully bot” that can play defense and do some stuff ( 4 this year, look at some of the MCC designs). We did this last year, and it helped a lot. You should also try to have scrimmages with other teams. This can get your drivers used to plating with other types of robots.

2 Likes

What’s the principle of a bully bot, just a really powerful drivetrain. With destruction principles?

Not destruction, but more about pestering the drivers while they are trying to practice strategies. We would also put a simply fast acting arm to move objects away which does not hurt anything just another item of distraction for the drivers. Really helps younger teams learn pressure and driving skills. I am going to be building a 10 motor drive bot with pnuematics this year for a bully bot.

3 Likes

So a bully bot is really just for practice?

Yeah pretty much, or in a pinch (If it is legal) an additional team to have fun at tournaments with…

For us it’s is to let other team mates to get some driving practice. It also allows us to have 2 v 2 matches with our sister team. It does not have to be complicated; ours from last year had a cap flipper/ de-scorer, and could get on the platforms. A 4-bar/6-bar with a 2-3 cube capacity claw should be good for this year. It should also have a strong drivetrain to be able to play heavy defense on your team’s main robot.

3 Likes

Is it something, which is not used for competition

For my team, we have 2 members.
One (Jacob) does building/cadding/driving/journals, and the other (me) does programming/build assist/website/partner driver.
We meet twice a week for 3-4 hours, and a bit more before a competition.
We cad, journal and program at home, to maximize our meet times. Sometimes we build directly from a cad model of a robot.
We have 3 full journals, with todo lists for each meet, complete project summary, and all strategies and prototypes documented.
While it would be nice to have more members, our team is an example of a manageable 2-person team with limited time.

3 Likes