Skip to content

Conversation

@noahheller
Copy link
Contributor

contains a couple of optimizations that might increase performance. If we dont like any of them they are separated by commits, so we can cherrypick

# Conflicts:
#	src/main/java/frc/robot/subsystems/Deployer.java
#	src/main/java/frc/robot/subsystems/Feeder.java
#	src/main/java/frc/robot/subsystems/Ramp.java
@noahheller noahheller self-assigned this Mar 22, 2024
# Conflicts:
#	src/main/java/frc/robot/subsystems/Ramp.java
#	src/main/java/frc/robot/utils/BlinkinPattern.java
.withSize(2, 2);
*/

Logger.logBoolean(baseLogName + "FWD LMT", isDeployerForwardLimitSwitchClosed(), Constants.ENABLE_LOGGING);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move to the if (debug)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like the benefit of leaving it (what if the switch gets bent and the robot is not hitting the switch?) is greater than the performance gain.

Copy link
Contributor

@armadilloz armadilloz Mar 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think anyone is looking at these values during the competition (we have diags for that), and even if they are important, they can be placed behind another LOGGING constant that can default to TRUE, so we can control it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

SmartShuffleboard.put("Ramp", "Desired pos", rampPos);
SmartShuffleboard.put("Ramp", "Reverse Switch Tripped", getReversedSwitchState());
SmartShuffleboard.put("Ramp", "Forward Switch Tripped", getForwardSwitchState());
// double pidP = SmartShuffleboard.getDouble("Ramp", "PID P", neoPidMotor.getPidController().getP());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code above (setting thePID_FF) can probably be be part of a command rather then run every time in periodic

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the ramp is a PID and the MoveRamp command finishes instantly, what do you recommend? Reading the document it does say to use the method "Infrequently" because it takes time. I could store the last PID Value and compare against it before setting it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a functional reason that the command be done immediately? I would think that it would make sense for a command to terminate once the ramp it at the position.
So you can have a sequential group of two commands: One to get the ramp "close enough" with FF and another to get the ramp closer (without the FF), and the second one to end once the ramp error is within range.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked and I don't think it will break anything if I make the ramp move not end immediately. I added the logic to the ramp commands

// if (pidI != neoPidMotor.getPidController().getI()) neoPidMotor.getPidController().setI(pidI);
// if (pidD != neoPidMotor.getPidController().getD()) neoPidMotor.getPidController().setD(pidD);
// if (pidFF != neoPidMotor.getPidController().getFF()) neoPidMotor.getPidController().setFF(pidFF);
SmartShuffleboard.put("Ramp", "Forward Switch Tripped", getForwardSwitchState());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why deleting the debug shuffleboard values?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete selection was to big when removing pid stuff

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

.withSize(1, 1);
}

Logger.logDouble(baseLogName + "EncoderValue", getRampPos(), Constants.ENABLE_LOGGING);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move to if(debug)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still some logs left outside the condition

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@noahheller noahheller requested a review from armadilloz March 24, 2024 23:38
public synchronized void setPattern(BlinkinPattern pattern) {
this.pattern = pattern;
public void setPattern(BlinkinPattern pattern) {
this.pattern.set(pattern);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like there is no real need to protect the pattern and the running since they are primitives (boolean and a reference), though using an atomic reference here does not hurt. The one thing that does require protecting as it is modified from both threads is the map, which is currently vulnerable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed to concurrent hashmap

public double getPieceOffestAngleY() {
return ty.getDouble(0);
}
public double getTv(){
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A better name would be isPieceSeen. This one sounds like it porvides you with an appliance.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@Override
public void periodic() {
gyroValue = getGyro();
frontLeftDriveCurrent = ((CANSparkMax)frontLeft.getSwerveMotor().getDriveMotor()).getOutputCurrent();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the Current stuff can be placed inside if(CURRENT_DEBUG). It can be set to true is we want it in the competition, but this way we at least have some control over it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Contributor

@armadilloz armadilloz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly fixed, a few more comments.
Plus, I don't see anything dangerous here that should be kept away, with the potential exception of the Limelight piece command that seems to have functional changes.

@noahheller noahheller marked this pull request as ready for review March 25, 2024 03:33
@noahheller noahheller requested a review from armadilloz March 25, 2024 03:33
# Conflicts:
#	src/main/java/frc/robot/commands/MoveToGamepiece.java
#	src/main/java/frc/robot/commands/ramp/RampFollow.java
#	src/main/java/frc/robot/constants/GameConstants.java
#	src/main/java/frc/robot/subsystems/Ramp.java
#	src/main/java/frc/robot/subsystems/SwerveDrivetrain.java
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants