Coaching Tips

We just started a Robotics Club at our school with three VEX teams and I’m wondering if we are on the right track towards creating a successful team (i.e. needing coaching tips).

Each team has a designated Driver, Builder, Programmer, and Designer. We practice twice a week but will ramp it up soon. Every day:

  • the builders work on the robot,
  • the driver works on flying drones and driving other robots (until Moby is built)
  • the programmers work on VEX VR and Replit for C++ training
  • the designers look up strategy, iterative builds, work on 3D CAD modeling, and work on publicity

For context, we had to begin practices in late August because we spent the beginning of the school year recruiting students so we are a bit behind on finishing the build. Also, our order for a field kit is still in the works but should be coming soon.

What more could we do? Or, equally as important, what from the aforementioned activities shouldn’t we be doing? (Our notebook also could use some work, so any tips would be much appreciated.)


The notebook is a critical factor. Many teams use their notebook as a journal to document what they have accomplished but the notebook should be leading the way.

  • Players - who is on the team? What are their roles?
  • Timeline - what is the team’s plan. When will they have certain aspects complete.
  • Game Rules - does your team understand how to play the game? Demonstrate that for the judges.
  • Strategy - Now that they know the rules, how will they play the game? What parts of the game will secure a win? Should they go after the Autonomous Win Point or grab the neutral goals?
  • Design - Based on the declared strategy, how should they build their robot? Should the chassis have four drive motors or two? Do they want traction or omni wheels? Holonomic, H drive, or conventional? How many motors do they need overall? How will they drive - control buttons and sticks, arcade or tank? Document the ideas / options, deliberate which is better, and then document why you chose that option. Draw some sketches. Establish hole positions for motor placement. Determine which sensors you will use, and what ports the motors will be occupying.

Once you have a plan it is easy for everyone to start working. Your primary builder can start on 1/2 of the chassis while the secondary builder builds the complimentary half. Since you have the ports identified on the brain, the programmer can begin programming controls and even some autonomous functions.

If the robot is build with a modular design you can have your builders working on an intake while your driver and programmer work with the chassis. Drive practice, autonomous testing. Does it climb the platform? Can it carry mobile goals?

Many teams dread the notebook but having a plan in place makes the process so much easier and faster. It takes 10-15 minutes at the start of practice. It allows a team to fall back to a previous design if the latest revision has problems. It also helps teams when there is a failure between matches and they cannot remember which device was plugged into what port.

I have done some testing with my teams and the teams with a plan accomplish much more in a shorter period than those with one builder that has the plan in their head. The latter tend to make mistakes and have to redo sections of their robot.

Best of luck on their journey.


Wow! Thank you so much. This is extremely helpful and we’ll be heeding your advice in our next practice.


This post has already provided us with so much since you showed it to us! Thank you

Make sure that there is collaboration - make sure that the driver talks to the programmers and builder/designers about what would make driving easier. Make sure the programmers talk to the builders about any potential limits that would need to be coded. The programmers may want to ask for physical stops or sensors from the builders to make their job easier.


Moreover, all should be ready to step in to drive - life happens. All should understand what the program is intended to do and help with coding - life happens. All should be involved with game strategy, documentation, mechanism design, build, debugging … It is a team effort, and should not be too departmentalized.

just my opinion about world class teams I have observed in and outside of robotics.