As of the commits that put the drivebase into closed loop velocity mode, it is undrivable. Lots of oscillations when coming to a stop.

A turnaround is likely to be caused by the robot turning. But it will likely keep turning for the duration of the turnaround, so the turnaround target will be out of date by the time it gets there.

The last call to stopMotor is outside the if statement. Given the logic in this block, I presume this isn't the intention…

I totally forgot that CTRE's motor controllers actually allow configuring the behaviour of the velocity measurement filter: https://robotpy.readthedocs.io/projects/ctre/en/stable/ctre/BaseMotorController.html#ctre.BaseMotorController.configVelocityMeasurementPeriod

We should be able to practically turn off the filter by setting the period to 1 ms and the sliding window to 1. This should improve the shooter PID loop performance significantly.

Very sensitive controls atm.

I know we're only using PWM motor controllers for testing, but I'm sure someone will stare at the robot for a solid hour and be confused as to why something isn't moving if we don't fix this now.

This behaviour has been observed when the turret starts anti-clockwise of the left index. This position violates the rules around starting configuration and is extremely unlikely to occur during games (We are 180 degrees from our intended start). The same situation could conceivably happen if scan direction is reversed from a more conventional starting position.

Because this is unlikely to occur, a fix to this bug should be considered low priority, as long as scans start anti-clockwise first

The current autonomous system while function is messy. The series of lists should be combined into a single data type (maybe a namedtuple) and path input should be considered. These changes are low-priority since the current version works and is not expected to be used.