-
Notifications
You must be signed in to change notification settings - Fork 0
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
Calibrate Intake #153
Merged
Merged
Calibrate Intake #153
Changes from all commits
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
fac4f76
Update ports
Emma03L 518fb18
Calibrate constants
Emma03L fccb83f
Change neutral mode to break
Emma03L be13b1f
Calibrate PID
Emma03L 392d589
Fix tuning position
Emma03L f45a98f
Calibrate softlimits & pid
rakrakon 18cf248
Switch to use `PositionVoltage`
rakrakon a77a2ef
Increase INTAKE_VOLTAGE
rakrakon 6c7503e
Remove redundant print
rakrakon 7f7b2e5
Merge branch 'dev' into calibration/intake
rakrakon 1cde9ed
Merge branch 'dev' into calibration/intake
rakrakon b64e3ea
Fix merge conflicts
rakrakon File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 changes: 1 addition & 1 deletion
2
src/main/kotlin/frc/robot/subsystems/intake/extender/ExtenderPorts.kt
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,3 @@ | ||
package frc.robot.subsystems.intake.extender | ||
|
||
const val MOTOR_ID = 0 | ||
const val MOTOR_ID = 11 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 changes: 1 addition & 1 deletion
2
src/main/kotlin/frc/robot/subsystems/intake/roller/RollerPorts.kt
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,3 @@ | ||
package frc.robot.subsystems.intake.roller | ||
|
||
const val MOTOR_ID = 0 | ||
const val MOTOR_ID = 12 |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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?
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.
Soft limits takes rotations and we calibrated this with Phoenix tuner x.
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.
Sure, but you can still use centimeters here and convert the measured to rotations.
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.
If i use centimeters here i'll have to measure again. Since we measured in rotations via Tuner X i don't see why that is necessary
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.
Maybe. But in this case you know the gear ratio and everything and you can calculate it. Or, you can take a tape and measure it. Or, you can check the position input in AdvantageScope which is in meters (which is another reason the min/max positions should be in meters). and take the value from there.
All of these solutions will take you less than a minute to implement, probably less time than it takes to discuss the matter.
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.
Yes, we can calculate it but there is no reason. We calibrated it through tuner x so the value will be in rotations. There is no need to convert it to a distance in the constants file and then right back to rotations
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 reason to do so is to make it easier to change in the future, and to retain the same dimensions -- again, if position is measured as a distance (as it should), it doesn't make sense to write its min/max values in another dimension.
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.
We are measuring the MAX & MIN Position via Phoenix x which measure in rotations.
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.
You both said that multiple times and I don't see how this is relevant. I don't want this to block the merge, but you shouldn't make decisions based on the specific measurement tool you used.
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.
So, by your logic, if we can only measure in inches for some reason and our code already works with inches, we should first measure in inches, convert to centimeters, put that in the code, and then convert back to inches in the code. How is that logical?
Just for clarification in situation above your code takes Inches and you can't change that, just like our situation.