themilkenknights / milkenknights-powerup Goto Github PK

Update Talon Feedforward based on desired velocity AND desired acceleration. Waiting on CTRE Phoenix update to implement.

Ensure code does not crash and required subsystems switch to open loop mode.

The Trajectory Following code that gets the desired segment is broken. Both the interpolation code and the timing logic are broken. Needs to be revised/fixed

Button to spin one intake motor in and the other motor out, in order to spin a cube that is in at 45º.

The Light Path Generator cannot accept angles greater than 90 from point to point and has incorrect/inconsistent angles.

MkTalon.getPosition and MkTalon.getSpeed slow down code cycles from a solid 5ms to an inconsistent 4-12ms. Tried changing the can frame update period but that only seemed to slow down everything and cause stale can frames.

On startup/disable: solid purple
disabled/connected: white
if robot is enabled on blue allaince: pulse blue
if robot is enabled on red allaince: pulse red
if robot is enabled and allaince is unknown (or not in a match:) pulse purple
if arm is in manual mode: pulse red
if arm is calibrated (I know that we dont zero anymore, but drew should have a button to get the absolute value of the encoder. ): solid orange for 3 seconds
if intake has a cube: pulse yellow for 5 seconds

Yoel's Joystick:
button two: solid green [signals to human player to drop a cube from portal] (toggle on/off)
button three: turn off all lights (toggle on/off)

Once intake rollers reach current limit, run at default slow speed

CSV logging only working for Superstructure

Tune Path Follower kP, kA, and kAng to ensure accuracy and precision. Desired accuracy is +-0.5in and +-0.5deg

Both TrajectoryLib and Pathfinder do not seem to allow for backwards movement. Need to find a solution for going backwards while generating (hopefully more than just add a negative to the generated paths when needed).

Test Open Loop Switch Auto from center with a p angle follower

Ensure that an open loop straight drive switch auto is fully working as a backup

Currently Arm Subsystem needs a checkSystem method to be implemented (and Drive's one needs to be fixed). Likely a drive forward and back in velocity setpoint mode, ensuring that the wheels reach a certain velocity and the motor current is above a certain level. The arm will hopefully enter it's zeroing routine then move to each of the preset setpoints.

Add rotate in place using path following (with different PID constants) or motion magic. Assign 4 buttons to 0,90,180,and 270 degree angles.

Run intake rollers until current limit is reached then change arm setpoint.

Difficult to replicate bug that causes robot to go full speed, far past the desired path. Occurs every ~10-30 runs. Possibly a result of a race condition