Preface

Read this if you want to build good robots. Edit this if you feel like this guide isn't complete or isn't doing its job well enough.

High Level Project Management Process: Competitive Robotics

All projects need to be managed at many different levels in order to be a success. This guide is specifically aimed at managing a competitive robotics project at a macro level. Executing this strategy alone isn't enough - the hardware and software management processes must be executed as well.

Every project is different, but these things are needed in some way by all projects

1. Critical Milestones and Targets
2. Weekly Goals
3. Design Reviews
4. Design Documentation

Let's briefly go through each of those

Critical Milestones

Before the project begins (preferably in the summer), all critical systems should be outlined (drivetrain, power control board, navigation software, etc.) and listed somewhere (see documentation) Once the critical systems are listed, each of them will need its own set of milestones along the way to completing that system. Each of these milestones should have 'winning conditions' (what needs to happen for the milestone to be reached) and 'targets' (the deadline).

Weekly Goals

Armed with milestones and targets for all of your critical systems, it is your job as the project manager to use your discretion to figure out how to meet the targets. To make this easier we use clickup, which shows all the tasks that are currently being worked on and the priority each task carries. As the project manager, your job is to look at the tasks underway and recognize when things are running behind schedule with one system and compensate so the milestone is met.

Design Reviews

On a macro level, each critical system should be reviewed to make sure the project is on track. Doing this every 2-3 weeks is recommended. The more thorough you are here, the better. Find all the problems with the current design and find answers regarding how to improve the design. The macro design review should also address the current speed of the project. This should happen in a separate meeting from the regular work meetings.

On a system level, each team needs to review its choices as they go. The best way to do this is through a quick standup held before work is started at a meeting and through design reviews (code reviews, schematic reviews, etc.)

Documentation

To make sense of the projects you'll probably need to make some documentation. For example, if you want to outline how the software architecture works make a block diagram. List your critical systems, targets, and milestones in a document.

Don't make documentation for the sake of making documentation. Optimize your documentation so it is exactly the amount needed to convey all important project information. But don't make bad documentation - that's worse than no documentation.

Lower Level Project Management Process: Competitive Robotics

The below information is designed to help subteam leads and team captains manage the systems they listed in the high level project management process

Design Concepts

All of SCR's robot's are based on these three design concepts:

1. Fast Iteration
2. Modular Design
3. Parallel Design

Here is an overview of each:

Fast Iteration

Every design can be improved. The idea behind fast iteration is to learn as much as possible as fast as possible on the way to solving a problem. The iteration process is as follows:

Design → Create → Test → Evaluate → Iterate

Design Put your idea on paper, in CAD, or on a diagram. For example, if you are designing electronics, make a list of requirements and then a schematic before wiring anything. This can be informal for prototypes, but for more mature designs the documentation should be created in a more accessible way - might as well start early before you get rekt.

Create Build the thing

Test Put your creation to the test. Ideally you should come up with tests in the design phase (see test driven development), but that's not required. Generally test the creation's ability to meet the requirements you made in the design process.

Evaluate This is like grading, but for robotic systems. How did your creation do on your tests? What were the weaknesses? What were the strengths? Identify some next steps.

Iterate Take what you just learned and try to do it better next time.

During prototyping, the iteration cycles should be really quick. These creations are a proof of concept and can be improved later. As the design matures, the iteration will slow down a bit - never stop iterating though!

Modular Design

This is the general principle that things you create should be compartmentalized as much as possible so it is easy to test and integrate multiple systems. For example, the system "chassis" is too general - it consists of a drivetrain, electronics housings, and other parts of the robot.

The reason we do this is because we want each system to manage itself. For example, making a change to the obstacle detection code should not require rearchitecting the localization code for the robot.

Parallel Design

Our goal with the previous two points is to make this one possible. If a robot is modular enough, then different people can work on the different systems at the same time. This makes robot development way faster.

Ideally, there should be a project owner for each system and a group of people who support that system. For example, the drivetrain might have a mechanical engineer as the project owner, and the project is supported by that person, someone from the electrical team, and a programmer who works on firmware. Similarly, navigation code might be owned by a software team member, and the supporting cast is all software members. The PO and supporting cast depends on the nature of the system