Captains and Team Leads

Preface

The goal of this page is to be a brief but useful set of tips and guides for leading teams in SCR. This is the cumulative experience of many teams and their successes and failures.

Being a Team Lead

General

Tips

• Try to develop tasks that would take 2-3 people about 4-6 weeks to complete. This lets your members take ownership of bigger projects which are more exciting than small tasks. Additionally, members usually enjoy working together but letting members work alone if that makes them more comfortable is also important but make sure you scale the scope of tasks accordingly.

Electrical

Job of the Electrical Team

Electrical is the bridge between your robot's software and the hardware. Tasks include

• Working with Software to research the sensor suite, microcontrollers, and main computer.
• Working with Hardware to research motors, servos, and other electromechanical components.
• Developing a high-level block diagram for all electrical components.
• Calculating and estimating current, voltage, and power requirements for all components
• Developing firmware for the sensors and other components.
• Developing low-level hardware logic for time-critical or safety-critical components
• Developing PCBs for any hardware logic or freestanding components. [1]

[1] Why are PCBs so important? Developing PCBs help focus your team on making a more robust and complete design than breadboarding. PCBs also provide much more consistency and reduce sudden electrical issues. One of the most common causes of failure at a competition is electrical issues due to weak connections or similar.

Software

The software requirements for your team will vary wildly depending on the complexity of your competition, but every team is still susceptible to the same errors.

Develop a high-level software block diagram that shows the flow of logic and data.

This is critical to making sure everyone on your software team has a complete understanding of how your software components interact with itself. If you are using ROS (you should be), this will help you decide your node and topic structure.

Simulate as often as possible. Don't let software stall.

Depending on the complexity of your robot and the speed of your other subteams, your software may already start requiring sensors or components that are not yet available in your robot. Having some form of simulation can help you test your code on a basic level to find large errors in logic. If a simulation is not possible, mark the code as needing to be tested (a WIP pull request is an easy way to do this) and let work start on other code. Be careful of dependencies. If A still needs to be tested and B depends on A, test A before you test B.

Mechanical

Being a Captain

• Read all the above for team leads