Intake command activates Intake and Transport
Intake IR changes LED to indicate Note Intaking
Transport middle IR sees note, slows Intake and Transport motors for repeatable stopping
Transport flywheel IR sees note, stops Intake and Transport motors

Transport has note method returns true whenever Transport middle IR || Transport flywheel IR are true.

Eject, score amp, shoot all run until transport has note is false (no timer) or interrupted.

Align isFinished() methods to use transport.hasNote() where appropriate.

Remove the brake mode from shooter motors.

Create a "keep it warm" mode for shooter when in range (default command on Shooter subsystem).

• If we can get backCam operational and reliable
• See what happens if we put all three cameras on one Orange Pi

• Use Pathplanner to move to the amp
• Combine all logic for amp score into 1 command

Configure the Elastic Dashboard for competition.

• Add Game time widget
• Driver cameras
• Debug View (Have Swerve Modules, Pivot cancoder, addition subsystem info needed for debugging)
• Push configuration to Repo
• Download elastic on all laptops. (All comp laptops at least)

• Run Sysid
• Add constants to code
• Push changes

[WPILib:] (https://docs.wpilib.org/en/stable/docs/software/wpilib-tools/robot-simulation/physics-sim.html)
[CTRE:] (https://v6.docs.ctr-electronics.com/en/stable/docs/api-reference/simulation/simulation-intro.html)

WPI is easy to follow but some things are different when using falcon motors. For that you will need to use the CTRE example to figure out the logic.

• Elevator Simulation
• Decide if you need to change the logic to simulate a staged elevator since we have one on the robot.
• Shooter Pivot Sim
• Combine the pivot sim to the elevator to mimic what we have physically. (called Ligaments in code)

We updated the wheel diameter on 3/16, but did not retest Path Planner. There may still be odometry issues or Path Planner PID that needs tuning.

Manual Amp Score fires upon cancel (end). Add check to only fire if elevator in Amp Score position (less than that means lower without shooting).

• Wait for new sensors and mechanical changes
• add logics to intake transport and shooter for new sensors.
• shooter is finished should be triggered by the last ir sensor

See Here: https://github.com/Mechanical-Advantage/RobotCode2024/blob/main/src/main/java/org/littletonrobotics/frc2024/commands/WheelRadiusCharacterization.java

• Compute DriveBase Radius
• Access Gyro Rotations
• Get Wheel Rotation Average
• Spin Robot
• Solve For Radius
• Test on Robot

• Test that it works
• make sure it spins the right way
• add command for auto use

• Update CAN ids
• Update Driver Controls
• Update Operator Controls
• Update LED Patterns (More may be added later)
• Add PDP Channels
• Add Sensors

See here for IDs, channels, and more: https://docs.google.com/spreadsheets/d/11TQMXD3nzPmcKLsk1cHGZZUNVzGtR144qfmQZADasTA/edit?usp=sharing

• 2 Piece Center
• 2 Piece on either side
• 4 Piece (clearing wing)
• 3 Piece (clearing from center)
• Push limits with 5? maybe 6? piece

• Test on bot
• Verify if reliable
• Implement in code

• Make Pivot Faster

It would be helpful is the LEDs could change color when a note is in view and the intake is empty. This method in NoteFinder and the corresponding method in Transport will help.

• See this Spreadsheet: https://group.me/3A8XLlZvM5HtGI

• Make a new copy with each stick/axis on a separate tab. Sweet spot (exponent) is identified in cell G2

• Don't forget to divide the joystick input by its maximum input. Ex. Max of joystick is 0.6 and current value is 0.6. 0.6/0.6 is 1 which when given to code will give us maximum output

• Make sure joystick values are positive and negative when they should be

"Basically, when it goes all the way down, if bottom sensor triggered, entire system makes a loud noise and jerks up before settling down" - Akshay

I'm not sure exactly what this means so maybe talk to Akshay about this one

• See how many and where we want cameras
• check with mentors about more info on this topic

• Run during auton
• Use sensors to trigger indicators during auton
• Flash green when intaking a note (normally should be brief)
• Validate endgame lights
• Test more thoroughly

The ranging logic is an ideal candidate for a JUnit. Refactor the method / command to support automated unit testing.

May want to create an inner class to hold the pivot and speed values as a return type. Or, might make those fields on the object that a JUnit could access via getters. Lots of ways to do it, but most importantly, test with different odometry values (pass odometry as input). Ensure zero, out of range, equal to single row in table, between row 1 and 2, between row last - 1 and last, are covered.

Make all constants work off of a voltage instead

• Establish new LED patterns and sequences
• when shooter is aligned change color
• when note in intaked change color
• when auto driving during tele op
• make important leds flash color to grab attention
• update README

Slow drivetrain down while a button is held so driver can make fine adjustments.

• Drive Speed slowdown
• Angular Speed Slowdown
• Bind to Controller

Related to #73, need to add MathUtils.applyDeadband() to the cubic input enhancement.

Centered joysticks do not necessarily return a precise zero on both axes. WPILib supplies a method on MathUtils that will force a zero value when the input is within specified range around zero. It automatically scales the remaining number space between zero and 1.

See https://github.wpilib.org/allwpilib/docs/release/java/edu/wpi/first/math/MathUtil.html#applyDeadband(double,double).

We will need constants for each axis.

Additionally, the joystick maximums on the flight controllers do not necessary reach 1.0. We need to divide the axis by its maximum (more constants). See https://github.com/hackbots-3414/2023-Energize/blob/main/2023-Energize/src/main/java/frc/robot/RobotContainer.java#L91 for examples. 2023's 0.7 and 0.9 are probably still good but should be verified. Potentiometer-based joysticks are prone to wear.

• FIX PLEASE

• Drive to Amp
• Align for score

Simulation does not run Robot.java's robotPeriodic(), but rather simulationPeriodic(). Therefore, to schedule commands, we need to copy the CommandScheduler call in robotPeriodic() into simulationPeriodic().

This will alleviate the headaches from 2/3.

• Convert flywheel to use motion magic velocity instead of PID

See Elevator.java and ShooterPivot.java for examples of motion magic position

See here for documentation on Motion Magic Velocity:

https://v6.docs.ctr-electronics.com/en/stable/docs/api-reference/device-specific/talonfx/motion-magic.html#motion-magic-velocity

keep in mind that some of the constants don't do what they typically mean. The documentation covers this.

Add a expo scale to the driver joysticks and apply dead bands to joysticks to help avoid drift.

• Add expo Scale
• Apply dead bands

Add current limits to drivetrain and all other motors. Drivetrain might already have code to do so.

• Note detection using photon vision.
• make drive to note command
• check if pose is in the field
• test
• bind to button on driver controller

• Remake Lookup table
• Speed Up pivot speed
• test for optimal Intake & transport speed combo. (typically want intake as fast as possible)

• See if needed
• make elevator faster

Actual sensor is on the Transport to detect presence / absence of note

• Add choosers to elastic dashboard
• Filter off number of pieces
• starting position (Amp-side, middle, Source-side, other)

Some files that include this is IntakeCommand.java. Talk to Chris for more info.

Intake does not have a limit switch.

Add individual motor control for motors related for transport to elastic. Mostly intake motors and transport motor.

• add auto shoot from afar command
• build paths around new commands
• ensure that it works in various paths

Configure drivetrain such that AprilTags can be turned off, turned on, and turned on just for shooting.

AprilTag updates to odometry field-wide are coming online late in testing, limiting the opportunity to identify problems. Configuring the drivetrain such that AprilTag enable / disable / shoot-only is visible on the dashboard and can be set by commands on the dashboard may be an important tool to mitigate risk.

One state is the quiet, on-the-fly update from anywhere AprilTags are visible. This is the desired target state.

Second is a total disable of AprilTag processing.

Third is normally disabled processing, with the shoot commands enabling AprilTag updates from just the Red or Blue alliance tag immediately under the speaker. As there are two tags there, processing is further restricted to read only one of them to permit accurate ranging. Once shooting completes, AprilTag updates turn completely off.

Commands on the dashboard can be used to toggle between states should Drive Team need to make adjustments on-the-fly.

• setPivot in ShooterPivot
• isAtSetpoing in ShooterPivot