Arm Subsystem

[joecaraccio]

The Arm Subsystem is a new experimental subsystem that we are predicating will be a part of the 2022 game. Worse case scenario it stays in our utility library and we utilize it on the future.

The Arm has 2 motors (each controlled by a talon). One part of the arm controls the extension of the arm, the other controls the 'shoulder'. Encoders will be available on extension arm, and encoder will be available on shoulder. Limit switches pending, but I believe will be on each end of the extending arm, to indicate maximum or minimum extension

Here is a basic checklist of what we need to do to get this working:

• Create public facing subsystem functions that will make sense for the rest of the robot to use (extendMax, extendMin, extend(inches), extend(centimeters) ), rotateShoulder(degrees), reset()... It is important these functions are simple to use so when integrating the entire robot it's nothing more than a function call. Other logic should be in private methods to avoid confusion.
• Create Position Based PID loop of Extending Part of Arm. Commanding the talon in Talon.set(Position, PositionValue) should relatively accurately move the arm to the correct position. We did an example of this with the 2019 talon. https://github.com/Team138Entropy/Entropy2020/blob/master/src/main/java/frc/robot/subsystems/Turret.java

Look for; mTurretTalon.set(ControlMode.Position, mPeriodicIO.demand);

if you look at line 151 of link, there is an example of the 'error angle' (amount our turret needs to rotate) to reach. In this case we determined how much error our camera was off from the goal target (usually somewhere within 20 degrees or less) and then calculated how many 'ticks' that is. We will have to quantify how much distance ticks are on the arms motors. For example, on the extending arm...to move 1 centimeter it might take 1000 ticks (guessing)

• Current/gravity based loop for 'shoulder' The shoulder is more complicated as the motor will be harder to drive given the orientation. Driving it by controlling the current will allow us to compensate. I would get the extension arm working first.

[joecaraccio]

Use this class for controlling the Talon via PWM: https://first.wpi.edu/wpilib/allwpilib/docs/release/java/edu/wpi/first/wpilibj/Talon.html

For controlling it via CAN, we can use the typical class we use.

[joecaraccio]

Updated Plan of Attack. I think we are close on the tuning.

@TrueDemoknight

• Command the targeted degrees constantly. This will force us to continually recalculate our Feedforward Velocity (based on the Cosine function). I suspect this will solve issue with the overshoot. Everything else is already very accurate. We might have to continue to tune values.
• Implement basic position PID on arm extension. As of right now we might not have encoder feedback on the test arm, so we will have to put placeholders in.
• Update Feedforward function to account for length of arm

[Team138Entropy]

TODO: Tune new arm and test arm in auto