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
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