2025 stage 3 edits

Docs/2_Architecture/2.3_CommandBased.md

@@ -4,10 +4,12 @@
 
 Command based programming revolves around three concepts: **Subsystems**, **Commands**, and **Triggers**.
 
+### Subsystems
 A Subsystem represents a system on our robot, like the drivetrain, elevator, arm, or intake, that will always operate as a unit.
 Each subsystem contains some associated hardware (motors, pistons, sensors, etc).
 They are the "nouns" of our robot, or things that it is.
 
+### Commands
 Commands are the "verbs" of the robot, or what our robot does.
 Each Subsystem can be used by one Command at the same time, but Commands may use many Subsystems.
 Commands can be composed together, so the `LineUp`, `Extend`, and `Outtake` Commands might be put together to make a `Score` Command.
@@ -20,6 +22,7 @@ Therefore, it might not be stored in a Subsystem.
 On the other hand, a roller that is driven by a motor can only go at one speed at a time.
 Therefore, we would wrap it in a Subsystem so that only one Command can use it at once.
 
+### Triggers
 A Trigger is something which can start a Command.
 The classic form of this is a button on the driver's controller.
 Another common type is one which checks if the robot is enabled.

Docs/3_Specifics/3.1_ControlsIntro.md

@@ -16,21 +16,21 @@ Choosing a control strategy is an important takeaway from these articles.
 Generally we have a pretty direct tradeoff between time/effort spent on controls and precision in our output (as well as how fast the mechanism gets to that precise output!)
 Loosely speaking, there are 3 'levels' of control that we tend to use for our mechanisms.
 
-1. Is simple feedforward control.
+### 1. Simple feedforward control.
    Really, this is only feedforward in the loosest sense, where we set a DutyCycle or Voltage to the motor.
    This sort of control doesn't set the exact speed of the output, and is really only useful on mechanisms that just need some rotation to work, but not anything precise.
    You'll usually see this on intakes or routing wheels where we just want to pull a game piece into or through the robot.
-   The [Intake Subsystem](https://github.com/HighlanderRobotics/Charged-Up/blob/main/src/main/java/frc/robot/subsystems/IntakeSubsystem.java) from 2023 is an example of this.
+   The [Roller Subsystem](https://github.com/HighlanderRobotics/Reefscape/blob/83a11f1bb1dfd20c04c3dc6a0e548773f11dfc58/src/main/java/frc/robot/subsystems/roller/RollerSubsystem.java#L45) and [RollerIOReal class](https://github.com/HighlanderRobotics/Reefscape/blob/83a11f1bb1dfd20c04c3dc6a0e548773f11dfc58/src/main/java/frc/robot/subsystems/roller/RollerIOReal.java#L99) from 2025 is an example of this.
 
-2. Is simple feedback control.
+### 2. Simple feedback control.
    We tend to use this on mechanisms that we might want to use sensible units for (like rotations per minute, or degrees) instead of an arbitrary output but don't need huge amounts of precision or are so overpowered compared to the forces on them that we can ignore outside forces.
    Often we use this by calling a TalonFX's Position or Velocity control modes.
-   [The angle motor on a swerve module](https://github.com/HighlanderRobotics/Charged-Up/blob/main/src/main/java/frc/robot/SwerveModule.java) is an example of this sort of control, and works because the Falcon 500 powering the module angle is so much stronger than the friction of the wheel with the ground.
+   [The angle motor on a swerve module](https://github.com/HighlanderRobotics/Reefscape/blob/83a11f1bb1dfd20c04c3dc6a0e548773f11dfc58/src/main/java/frc/robot/subsystems/swerve/ModuleIOReal.java#L203) is an example of this sort of control, and works because the Kraken X60 powering the module angle is so much stronger than the friction of the wheel with the ground.
 
-3. Is combined feedforward and feedback control.
+### 3. Combined feedforward and feedback control.
    This is ideal for most situations where we desire precise control of a mechanism, and should be used on all primary mechanisms of a robot.
    It tends to require more effort to tune and model than the previous levels, but is the correct way to control mechanisms.
-   The [Elevator Subsystem](https://github.com/HighlanderRobotics/Charged-Up/blob/main/src/main/java/frc/robot/subsystems/ElevatorSubsystem.java) from 2023 is an example of this, specifically the `updatePID()` method which adds the results of a PID controller calculation with a feedforward controller calculation.
+   The [Elevator Subsystem](https://github.com/HighlanderRobotics/Charged-Up/blob/4475dfc7e07efa000e87597dddaac1e75c28a29c/src/main/java/frc/robot/subsystems/Elevator/ElevatorSubsystem.java#L49) from 2023 is an example of this, specifically the `updatePID()` method which adds the results of a PID controller calculation with a feedforward controller calculation.
    Notice the use of a WPILib feedforward class here.
    WPILib provides several classes that model common mechanisms.
    [This article](https://docs.wpilib.org/en/stable/docs/software/advanced-controls/controllers/feedforward.html#feedforward-control-in-wpilib) goes over the classes in more detail.

Docs/3_Specifics/3.2_MotionProfiling.md

@@ -2,16 +2,17 @@
 
 ## Motion Profiles are a way to smoothly control a mechanism by combining PID and FF control
 
-As the [feedforward](Feedforward.md) article covered, it is often beneficial to combine feedforward and feedback (for our use, usually PID) control.
-One problem with this is that a feedforward for a dc motor (such as a falcon 500) controls _velocity_ while a mechanism might require _position_ control.
+As the [Controls](3.1_ControlsIntro.md) article covered, it is often beneficial to combine feedforward and feedback (for our use, usually PID) control.
+When we want to control the _position_ of a mechanism, however, we're limited by the fact that feedforward for a DC motor (such as a Kraken X60) controls _velocity_.
+
 A motion profile smoothly interpolates, or transitions between, between a starting position and a setpoint position.
-There are a variety of types of motion profiles, but the one we use most often is called a _trapezoidal motion profile_.
-When using a trapezoidal motion profile, a mechanism will attempt to accelerate at a constant rate to some cruising speed, then deaccelerate to a standstill at the setpoint position.
+There are various types of motion profiles, but the one we use most often is called a _trapezoidal motion profile_.
+
 ![An illustration of a trapezoidal motion profile](../../Assets/MotionProfileExample.webp)
 
 This graph shows a motion profile over time, although the specific values aren't important.
 The blue line is the position of the controller, the black line is the velocity of the controller and the red line is acceleration.
-You can see the 3 phases of the profile, with an accelerating phase at the start, a cruising phase through most of the profile, and a deaccelerating phase at the end.
+You can see the 3 phases of the profile, with an accelerating phase at the start (the first leg of the trapezoid), a cruising phase through most of the profile (the top base), and a deaccelerating phase at the end(the second leg).
 The position line smoothly starts and stops, resulting in clean movement of the mechanism which minimizes wasted effort.
 The real advantage of this is that now we have both a position and velocity setpoint at any given time, which means that the PID controller can adjust for disturbances in position while the feedforward controller can provide the majority of the control effort to get to the setpoint.
 
@@ -33,4 +34,4 @@ The real advantage of this is that now we have both a position and velocity setp
 
 - Motion profiling is primarily used for position-controlled mechanisms like elevators and arms.
   It can also be used on velocity controlled mechanisms, although it provides less of a benefit.
-- The `motion magic` control mode for a talon fx is really just running motion profiling on the motor controller.
+- The `MotionMagic` control mode for a TalonFX is really just running motion profiling on the motor controller.

Docs/3_Specifics/3.4_Choreo.md

@@ -84,7 +84,7 @@ They'll generally look like this:
   }
 ```
 Choreolib relies heavily on `Triggers`, which will not be discussed here.
-Refer to the [WPILib docs](https://docs.wpilib.org/en/stable/docs/software/commandbased/binding-commands-to-triggers.html) for more *or potentially another article here?*
+Refer to the [WPILib docs](https://docs.wpilib.org/en/stable/docs/software/commandbased/binding-commands-to-triggers.html) for more or the [Command Based article](../2_Architecture/2.3_CommandBased.md#Triggers)
 
 You'll notice one of the parameters above is the `choreoDriveController()` method.
 This is in `SwerveSubsystem`.

Docs/3_Specifics/3.5_Vision.md

@@ -128,4 +128,4 @@ Some test data of other frequently used cameras is linked below in the Resources
 ### Examples
 
 - [Photonlib examples](https://github.com/PhotonVision/photonvision/tree/master/photonlib-java-examples)
-- [8033 2024 implementation](https://github.com/HighlanderRobotics/Crescendo/tree/main/src/main/java/frc/robot/subsystems/vision)
+- [8033 2025 offseason refactor](https://github.com/HighlanderRobotics/Reefscape/tree/14928b3bf749ae28fc13cbb02c7e44a223574c80/src/main/java/frc/robot/subsystems/camera)