Software Framework and Guidelines - TAMSFormers5212/TAMSformers-Database GitHub Wiki

WIP

Robot Code Framework

Command Based Framework

The robot has tons of moving parts and requires thousands of lines of code, and that's why we need to break the robot down into parts that can be controlled one at a time. These are Subsystems: an arm, elevator, intake, drivetrain, or any other system of parts which operates together. They are controlled using Commands which tell the Subsystems what to do and allow for more advanced logic, particularly when using multiple subsystems. This is how they are designed to work, but oftentimes we find that just composing commands on the fly and doing most of the logic within a superstructure class is easier and more efficient than making entire commands for simple one line functions.

State Machines

Most robots are defined using a set of states. You'll learn about these in CSCE 2100, and the concept here is same. Each state defines where everything should be and what needs to be known, and there are conditions that need to be fufilled to move to another state.

A basic example (and what we normally end up with) is a system where the subsystem will do one thing continuously based on which button was pressed. Our arm in 2024 operated on this logic. It would just go to a position defined in code based on which button was pressed.

More advanced logic would include analyzing sensor information like beam breaks to tell where a game piece is to automatically move to another state without human input. You can also run multiple things in one state. We had a button that run the arm, shooter, and drivetrain to aim at the speaker in 2024. The limelight data was used to calculate a rotational drive, arm angle, and shooter rpm.

Coding Guidelines and Best Practices

What is good code?

Github

Committing, Pushing, Syncing

⚠️ **GitHub.com Fallback** ⚠️