several of the methods return a copy of the path class, while others update it and return void.

https://github.com/DanKatzuv/BaseBot/blob/5acc80e9a359845458a33fc7b2d1a113cdf26180/src/main/java/robot/subsystems/drivetrain/pure_pursuit/PurePursue.java#L13

All commands should be in the same folder

examples:

• Change the method generate_smoothing() -> generateSmoothing() to be in line with all other public methods https://github.com/DanKatzuv/BaseBot/blob/b83e1bcfa25d4d0010943d47a3d4c28664b95f3e/src/main/java/robot/subsystems/drivetrain/pure_pursuit/Path.java#L208
• Change variables with ambiguous names to be more straight forward, like for example "lastLeftEncoder" to something like "lastLeftDistance". https://github.com/DanKatzuv/BaseBot/blob/0ef201e7d67c30f7f07a75ca7feb0020bb39a48d/src/main/java/robot/subsystems/drivetrain/pure_pursuit/PurePursue.java#L18-L19
• Rename constant TRACK_WIDTH to ROBOT_WIDTH to be more self explanitory

Pure Pursuit

Max velocity
Velocity K
Max accelration
Lookahed distance

Smoothing
Weight data
Weight smooth
Tolerance

Controller
kV = 1 / Max velocity
kA = 0.002
kP = 0.01

Use VictorSPX

• Add motor ports to Ports
• Add motor controllers

While stopping using pure pursuit is pretty consistent, it isnt a calculated method like last year.
Here is the explanation from the article:

Our controller stops when the closest point to the robot is the last point in the path. Because our points are spaced 6” apart, this means the robot stops about 3” from the end of the path. This stopping behavior has worked well for us because it means the inertia of the robot carries it to our end point, instead of past it. The pure pursuit controller is consistent enough that it’s easy to adjust the path if it’s not stopping in the exact place you want.

Now compare this to the PID method, that ensures it accurately reaches the final setpoint.
Maybe we could even have a hybrid between pure pursuit, and when it reaches the end of the path, to use pid.

Allow the path to be relative by saving the initial angle and the initial position.

Add hyper links to Galaxia and FIRST's websites.

Instead of having to write all five generate methods one after another, we should create a method that does it all for us, in the right order.

After done testing the pure pursuit, we need to see whether the code still works when reversed.

• Move start point coordinates into constants
• Add start point coordinates to parameters list

Currently the angle is 0 degrees when the robot is facing the positive Y direction, even though all calculations work when the robot angle nulls out at facing east.

https://github.com/DanKatzuv/BaseBot/blob/5acc80e9a359845458a33fc7b2d1a113cdf26180/src/main/java/robot/subsystems/drivetrain/pure_pursuit/PathPoint.java#L3

• Setter for left speed
• Setter for right speed
• Getter for left speed
• Getter for right speed

• Add "curvature' field to Waypoint
• Calculate waypoints' curvatures inside the Path class

Move into constants file: lookahead distance, distance between waypoints

https://github.com/DanKatzuv/BaseBot/blob/6403af2809c201f11143fb24afc506edaffc4817/src/main/java/robot/subsystems/drivetrain/pure_pursuit/PurePursue.java#L171

https://github.com/DanKatzuv/BaseBot/blob/6403af2809c201f11143fb24afc506edaffc4817/src/main/java/robot/subsystems/drivetrain/pure_pursuit/PurePursue.java#L153

split each branch into a fix-branch and fix all problems when using getWaypoint() and Vector.add() in the code.

• you could simply do this by removing each respective method, seeing where errors are caused and checking each case where that method is called.