arctos6135 / frc-2023 Goto Github PK

• Limit switches on digital input ports on roboRIO
• For closing and opening, we may be able to remove redundancies in the code and shift all the functionality to a command instead
• Limit switches cannot be installed without proper female dupont crimps (electrical issue)

The elevator should be able to extend to given positions automatically. The elevator subsystem should operate in two modes: position mode and raw input mode.

Raw input mode

• encoder readings have to be accurate and consistent across power cycles
• the elevator motor should run at the given speed
• it should never hyperextend or hypercontract

Position mode

• the elevator motor should use a simple control loop (PID with I,D=0 + a clamp to keep it relatively slow will probably work) to extend to a specific position
• see above about hyperextending

Shuffleboard is very resource-heavy for no good reason. Switching to smartdashboard will make programming a lot less annoying, doing quick fixes at comp faster, and hopefully lead to less stress.

Doing the switch will require going through all the uses of shuffleboard in code and replacing them with smartdashboard.

Specifically for the soft stops

Write code to rotate the arm to a specific angle. The arm subsystem should operate in two modes, PID driven to an angle (should be used all the time), and raw input driven by motor speed (if PID/the encoder breaks for whatever reason).

Raw input mode

• arm keeps sets the motor speed to the given speed

PID mode

• encoder readings need to be accurate and consistent access power cycles, moving the arm while the robot is off, etc
• arm keeps track of target angle
• arm uses PID + maybe gravity feed forward to rotate to the correct angle
• make sure the arm motor has a current limit so it doesn't burn out

Documentation

We should reorganize files and code as well as remove any files that are not required so that there isn't unnecessary clutter. Adding documentation is also quite important for new members so everyone is on the same page (@rynky pls do that for us ;) )

Constants

Many constants have been misplaced in incorrect files and are difficult to find when testing and fine-tuning things. We must clean up and organize all the constants into their appropriate constant files and refactor the import statements.

This is not an urgent issue, we can worry about this if we have extra time. However, fixing this can help speed up debugging and eliminate unnecessary frustration.

To minimize the operator fooling around with the controls, the operator controller should have a number buttons that move the arm to preset positions for scoring and intaking. Since we're only going to be scoring cubes, there's not many positions!

Each command should be run when the operator holds down the appropriate button; if they release it, the command should be canceled.

intaking

There should be commands for double substation and ground intake. Both commands should make sure the elevator is completely retracted (position mode), then rotate to the correct angle (PID mode) and run the intake continuously.

scoring

There should be commands for scoring a cube in mid and low. Both commands should lift the arm to the appropriate angle using PID mode, then (slowly) extend the elevator to the correct position (position mode). The claw shouldn't outtake until a separate button is pressed, as there's a decent chance the driver will need to manoeuvre the robot to get into ideal scoring position.

Our mobility auto (just driving out of the community) is very important. If we are playing with a team who is very good at balancing, it is very possible that our best auto would be to score a game piece and then do mobility. Unfortunately, right now it sucks.

The "balance a cube on the back of the robot and ram it into the grid to score" technique worked surprisingly well at Mac, the main issue was exiting the community. There is a big bump in the field on the outside of the charge station, and hitting it at speed jerks the robot and changes it's angle. At Mac this led to us crashing sideways into the charge station, stopping our teammate from balancing.

The mobility auto needs to be rewritten so the robot doesn't jerk so much while going over the bump. Since we normally have a lot of time left after mobility auto, it might be enough to fix this issue just by driving really slowly.

If driving slowly doesn't work, the robot will need to constantly steer to maintain a consistent gyro heading in order to correct changes in route.

Using the limelight for vision tracking will massively help our performance at Stemly and allow us to get experience working with the limelight at competition: it's definitely a good idea.

We can use the limelight in a couple of different ways: intaking from the ground and intaking from the double substation. Of the two, intaking from the ground will probably require less finicky calibration than from the double substation, and it's still very valuable.

ground intake

• the limelight will need to be calibrated to track purple cubes
• the robot will need to use a PID loop to steer towards the targets
• the code will need to track the distance to the nearest cube so that the robot doesn't try to move toward a cube in its claw
• the robot needs a command to move towards the closest cube and ground intake simultaneously (using #9)