-
Notifications
You must be signed in to change notification settings - Fork 0
Nh command loop #178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Nh command loop #178
Conversation
…eduler loop overrun)
# 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
# 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); |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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()); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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()); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move to if(debug)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
| public synchronized void setPattern(BlinkinPattern pattern) { | ||
| this.pattern = pattern; | ||
| public void setPattern(BlinkinPattern pattern) { | ||
| this.pattern.set(pattern); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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(){ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
armadilloz
left a comment
There was a problem hiding this 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.
# 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
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