Issues:
 Therefore, the revised list of remaining handoff and connecting logic issues is:

   1. `hwMap.java ` - LED/Flicker Servo Port Conflict: LEDA, LEDB, and LEDC are mapped to the same hardware servo names as flickA, flickB, and flickC. This creates an alias, meaning controlling one set of servos will inadvertently control the other, leading to unintended behavior and potential conflicts.
   DONE (diff thing but i did what was needed) - 2. `hwMap.java` - Incomplete `getAprilTagPose()` Implementation: The getAprilTagPose() method returns an empty double[0], rendering getDistanceFromAprilTag() (which relies on getAprilTagPose()) ineffective, always returning -1. This impacts the accuracy of turret aiming calculations.
   DONE - 3. `hwMap.java` - `isTurretReady()` Placeholder: The isTurretReady(double turretPower) method always returns true. This is a placeholder and does not reflect actual turret readiness, potentially causing finalTeleOp to proceed with scoring prematurely.
   DONE -  i just removed the if alliance = 0 4. `subsystems/Turret.java` - `motif` Update Restriction: The motif (AprilTag pattern) in Turret.java is only updated via hardware.getMotif() when alliance == 0 within the update() method. If alliance is set to a non-zero value (e.g., 1 or 2 by finalTeleOp), the motif will not be updated from new Limelight detections in
      teleop, potentially using an outdated pattern for TransferSys.
   5. `subsystems/Turret.java` - `updateAuton()` Limelight Pipeline Management: The updateAuton method (used in autonomous) calls hardware.setPipeline(allianceTarget). If allianceTarget (which is 1 from pedroRedNet.java) does not correspond to the correct Limelight pipeline index for AprilTags, the Limelight may switch to
      an incorrect pipeline, hindering accurate AprilTag tracking.
   6. `subsystems/Turret.java` - Unused `apriltags` array: The apriltags array is declared in Turret.java but is never used, indicating potentially vestigial or incomplete logic.
   7. `subsystems/TransferSys.java` - Incorrect `flickTimer` Logic in `processFlickSequence()`: The flickTimer is reset when liftCurrentItem() is called, and then FLICK_RESET_MS is measured from that same flickTimer to determine when to dropCurrentItem(). This means the FLICK_RESET_MS duration is not correctly measured from
      the moment the item is flicked up, but from the moment it started moving up, leading to potentially incorrect timing for the drop sequence.
   8. `subsystems/TransferSys.java` - Redundant `indexAllArtifacts()` Calls: indexAllArtifacts() is called when setTransferState(TransferState.INDEXING) and at the beginning of startFlickSequence(). While not a critical error, it could be redundant if the artifacts have already been indexed.
   9. `subsystems/TransferSys.java` - Simplistic `updateMotif` Logic: The updateMotif method creates a motif where only one slot can be color 2 (Green), and the rest are 1 (Purple), based on a single pattern input. This might be too simplistic or inflexible if more complex motif patterns are needed.
   10. `teleOp/StateMachine.java` - Direct `TurretState.LAUNCH` in `handleGameStateEntry(GameState.SCORING)`: The handleGameStateEntry for SCORING directly sets m_turret.setTurretState(Turret.TurretState.LAUNCH). This immediately commands the turret to launch without checking if it has acquired a target or is otherwise
       ready, potentially leading to inaccurate shots.
   11. `teleOp/StateMachine.java` - `isMotifEdited` Flag Never Resets: The isMotifEdited flag in StateMachine.java (which mirrors the one in TransferSys.java) is set to true when m_transfer.isMotifEdited() is true but is never reset. This means that once a motif is detected and updated once, isMotifEdited() will always
       return true, making the alliance detection logic in finalTeleOp.java trigger only once.
   12. `teleOp/StateMachine.java` - Unused `handleStatePeriodic()`: The handleStatePeriodic() method is defined but never called, indicating incomplete or unused functionality.
   13. `teleOp/finalTeleOp.java` - `alliance` and `isMotifEdited()` Fragility: The initial detection and setting of alliance = 1 based on stateMachine.isMotifEdited() is fragile due to the isMotifEdited flag never being reset. This can lead to alliance being stuck at 0 or 1 incorrectly if motif detection doesn't happen as
       expected or if the flag is not reset.
   14. `teleOp/finalTeleOp.java` - Conflicting `hoodServo` Control: finalTeleOp.java directly initializes hoodServo and controls its position via hoodPosition. However, the Turret subsystem also has a hoodservo and a setHoodPos() method. This creates a potential conflict where finalTeleOp might be directly controlling the
       servo while the Turret subsystem also tries to manage it, or the Turret's setHoodPos is being bypassed for manual control. Control should be consolidated through the Turret subsystem.
   15. `teleOp/finalTeleOp.java` - Redundant `stateMachine.getTransfer().indexAllArtifacts()`: indexAllArtifacts() is called at the very end of the while (opModeIsActive()) loop. This re-indexes artifacts on every loop iteration, which might be inefficient if indexing is a resource-intensive operation and not always needed.
   16. `teleOp/finalTeleOp.java` - Coupled `manualSAM` and `manualFlicker`: manualSAM = manualFlicker; directly couples manual flicker control with manual Shot Adjustment Module control. This might not always be the desired behavior and could limit flexibility.
   17. `teleOp/finalTeleOp.java` - Blocking `sleep()` Calls in `manualFlicker`: The use of sleep() calls within the manualFlicker block in the main while (opModeIsActive()) loop will block the entire robot's operation, preventing other subsystems from updating or responding to input for the duration of the sleep. Servo
       operations should ideally be managed with non-blocking timers within a state machine.

