Closed wmarshall closed 1 year ago
I do love a good debugging challenge. In our sim elevator code, we have the gear ratio as 9. If you convert your 0.275
with that in mind, 0.275 * 20 / 9 = 0.611
, a lot closer to 0.642
. Do you think that could be it?
But now that I think about it, isn't that for the first stage carriage? So the final elevator height is twice that?
So we discovered the source of the discrepancy, we're operating in first-stage units, so everything is halved. Does that mean we should close this issue? Since we are unlikely to change it?
yup no changes :) smile
While doing a traipse through the code last night, I kept coming back to the METERS_PER_REVOLUTION constant and trying to understand where it was coming from.
[REV documentation](https://codedocs.revrobotics.com/java/com/revrobotics/relativeencoder#getPosition()) tells us that out of the box
should print a double representing the total rotations of the integrated hall effect encoder (1:1 with the motor shaft) since boot.
Calling
setPositionConversionFactor
like we do here will causegetPosition
to multiply its count of rotations by our factor before returning it.With the stated units of
meters/encoder counts
this gives usposition = (meters/encoder counts) * revolutions
- where encoder counts and revolutions don't cancel.I'm also not quite sure fractional encoder counts so close to the 42 CPR that the builtin hall effect encoder is specified at make sense - maybe this was generated empirically but the shaft wasn't rotated all the way?.
I'd have expected the constant to be calculated as
Units.inchesToMeters(lift travel per sprocket rotation / gear reduction from motor to output shaft)
. For our 22-tooth #25 sprockets and 20:1 reduction, that comes out asUnits.inchesToMeters(22*0.25/20) = Units.inchesToMeters(5.5/20) = Units.inchesToMeters(0.275)
By comparison
Units.inchesToMeters(27/41.951946) = Units.inchesToMeters(0.642)
, which is weird , but is the right order of magnitude so it didn't jump out to anyone as obviously wrong.Ultimately this doesn't mean that our lift doesn't work (we've got the footage to show it working), but that it's hard to reason about any of the values involved in lift behavior because they don't correspond to any physical unit.
Is there something I'm missing here that explains this constant?