frc2399 / 2023-Season

Other
2 stars 2 forks source link

Is the elevator operating in units of pseudometers? #92

Closed wmarshall closed 1 year ago

wmarshall commented 1 year ago

I was working in the lab, late one night When my eyes beheld an eerie sight For my ~monster~ elevator from his slab, began to rise

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

var spark = new CANSparkMax(...);
var enc = spark.getEncoder();

System.out.println(enc.getPosition());

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 cause getPosition to multiply its count of rotations by our factor before returning it.

With the stated units of meters/encoder counts this gives us position = (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 as Units.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?

edf42001 commented 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?

edf42001 commented 1 year ago

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?

alicelin27 commented 1 year ago

yup no changes :) smile