Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StateBased Coding Style #41

Open
LuisFerArredondo opened this issue Jan 30, 2024 · 0 comments
Open

StateBased Coding Style #41

LuisFerArredondo opened this issue Jan 30, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request mechanism Mechanism related task

Comments

@LuisFerArredondo
Copy link
Contributor

This is The ticket to explain what the "State Based" Coding style is.

-In the Robot project there are two main folders; "Mechanisms" & "Superstructures":

Inside the "Mechanisms" folder there will be a file per each mechanism. To put an example of what each folder will contain:

Imagine that in the robot, somewhere there are two gearboxes, one of them has a pneumatic break and the other one has two motors. A mechanism will be each gearbox as a hole, so in the folder there will be two files(one per mechanism aka. gearbox): Lets name the first file as "GearBox1" we will have the most basic hardware control of the two motors that are allocated in the gearbox, by basic hardware control is literally having a method defined to control the voltage of each one, the PID values of each one and other basic stuff. Now lets name the other file "GearBox2", in this one we will define the most basic control of the motor(the same way as mentioned before) and also the most basic control for the pneumatic system(move piston forward or reverse, if its a double solenoid). Each file will extend from the "SubsystemBase" abstract class.

now these two mechanism are meant to integrate an Arm mechanism, so lets jump now to the superstructure folder, in here we will define the Arm mechanism, so we'll create a file and name it "ArmSuperstructure", in this file we will have a higher level software control, such as using and Inverse Kinematics algorithm. On the constructor method we will require to pass in the mechanism files that we defined before

Now, to integrate the Commands we can set a command to make this arm go up, so inside the Superstructures folder we'll create another folder named "Commands", in this folder lets create a "Command file" named "ArmS_Up" just for simplicity, inside this file well bring in the superstructure file and the mechanisms, and now the logic will be done by the superstructure file.

In other words, this coding style is meant to have the software(high level algorithms) and hardware control(low level algorithms) of each mechanism in separate files, so then all of the mechanisms can get merged into superstructures, making more straight forward the automation.

The main advantage of this code style is that for logging and the simulator are too easy to be implement. And also will be much easier to implement more high level algorithms, such as using state machines. Which is the why setting this standard code is mainly meant to be, though it is not a requirement, nor will bring disadvantages. If you want to see more about state machine integration, jump to the "StateBased Programming" ticket

@LuisFerArredondo LuisFerArredondo self-assigned this Jan 30, 2024
@LuisFerArredondo LuisFerArredondo added enhancement New feature or request mechanism Mechanism related task labels Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request mechanism Mechanism related task
Projects
None yet
Development

No branches or pull requests

1 participant