Port Climber code from Java to C++

[jkleiber]

Summary The climber code from 2022 is written in Java. We use C++ now, so it needs to be transferred

Work Required

• Transfer the climber code to C++
• Write unit tests for climber code in C++

Verification

• CI passes
• Work is done

Deferred Work

• Network Tables
• Constants
• Button bindings

[danielbrownmsm]

code from last year https://github.com/Team-OKC-Robotics/FRC-2022/blob/dev/src/main/java/frc/robot/subsystems/ClimberSubsystem.java (dev branch, master has the more complicated version that doesn't work)

[jkleiber]

This is going to be limited to Climber and ClimberIO. Network Tables, constants and button bindings are deferred work

[danielbrownmsm]

The climber code is kind of unique because it written so that the climbers could be hot-swappable (you could quickly remove one and put in another). The issue is that the two different motors had two different CAN IDs. The smart idea would be to just change the CAN ID, but no, we I made it where two separate motors were programmed inside the Climber subsystem, for the two different IDs, and the code checked to see if either were null and then just set the power. This is kind of jank, but it's what we had last season and it (kind of) worked.

[danielbrownmsm]

But we don't have to be like this for this repository. See following spec for phase 1 specification:

Hardware actuators:

• One (1) falcon 500 motor with CAN ID 13

sensors:

• built-in encoder on the falcon 500 motor
• limit switch (plugged directly into motor, does not concern this spec, don't worry about it)

Functions

• a way to set the percentage power of the climber motor [-1, 1]

[danielbrownmsm]

If you want to get advanced, see phase 2 spec:

Hardware actuators:

• One (1) falcon 500 motor with CAN ID 13

sensors:

• built-in encoder on the falcon 500 motor, accessible through the motor
• limit switch plugged directly into motor, accessible through the motor

Functions

• a function that takes an input as a boolean and sets the climber to that state. true is extended, false is retracted
• a function that takes no arguments and returns the state of the climber, using the sensors given
• a function to reset the state of the climber to its initial state (reset encoders, etc)

Periodic Periodically (in the Periodic function of the subsystem), the climber should:

• determine what state it needs to be in
• change the output of the motor, using a PID controller, depending on what state the climber is in
• to decrease inaccuracy, perform sensor fusion. when the limit switch is pressed, the motor encoder should be reset to 0

[danielbrownmsm]

If you really want to get advanced (even beyond what I would/could do), see phase 3 spec: I recommend against this because a) we don't have this functionality, b) we don't have some of the hardware mentioned, c) I wouldn't be able to do this, and d) this is kind of a joke

Hardware actuators:

• One (1) falcon 500 motor with CAN ID 13

sensors:

• built-in encoder on the falcon 500 motor, accessible through the motor
• limit switch plugged directly into motor, accessible through the motor
• IR digital distance sensor to determine if the climber hook is correctly positioned or not, on DIO port 6

Functions

• whatever functions you need/want, provided they can fulfill the Periodic spec

Periodic Periodically (in the Periodic function of the subsystem), the climber should:

• use a state-space controller to maintain the desired state
• if the 'climb' flag is true, the code (parts of this should be implemented using commands, outside the Climber Subsystem file) should completely take over from the driver (there's an override switch, of course) and set the desired state to EXTENDED, and drive the robot so it is lined up with the bar (this would utilize the drivetrain, and it's nonexistent color sensors, obviously), then slowly move forwards until the climber proximity sensors detects that the climber is in proximity of the bar, then the climber should set the desired state to CLIMBED (which is different from RETRACTED in that the controller is more aggressive and appropriately accounts for the mass of the robot) and continue holding that state until otherwise directed, or the match ends, whichever comes first.
• if the state-space controller requires a high power output, request solo-power from the Power Manager interface
• to decrease inaccuracy, perform sensor fusion. when the limit switch is pressed, the motor encoder should be reset to 0
• run CBIT (Continues Built-In Test) to verify correct operation of all hardware. This would include, for instance, checking motor temperature, current draw, status, sensor readings, and so on. If CBIT identifies a problem it should raise the problem to the dashboard. If a component failure that could cause damage to the climber occurs, the climber should disable any parts that would cause damage/be damaged. If the failure would cause certain functions to work, like for instance the auto-climb, then the climber should fall back to manual control, preserving as much functionality as possible.