We recently added a Rev Through-Bore encoder to our turret. From the documentation this should be returning data at 8192 ticks per revolution. However, it seems we’re not seeing this.
We have the encoder plugged into the encoder port 0 on our main hub. This happens to be the encoder port for one of our drivetrain motors, which is a goBilda 435. If I multiply the “getPosition()” value from the through-bore encoder by 383.6 then we DO get tick-values which appear good.
Can / does the motor plugged in affect .. something?
The actual motor plugged in doesn’t technically affect the encoders, but definitely how the motor port is configured in the Robot Config and the mode that the motor is set to in software can make a huge difference, depending on the methods you’re trying to interface with.
The FTC SDK cannot split “motors” from “encoders” on the motor ports, so when you select the “motor type” in the Robot Configuration it sets several properties for the motor and encoder, including ticksPerRevolution, maxRPM, default rotation direction, and others. However, when reading raw tick count, most of the values don’t matter - they’re more for knowing things about how fast the motor is rotating or trying to move to a specific position.
What it sounds like it maybe you’re not using the RUN_USING_ENCODERS motor mode. In general, it’s a good idea to always set your motor to RUN_USING_ENCODERS mode whenever you’re wanting the robot to do anything with the encoders - if you then don’t want motors affected by the encoder values, just use setPower() and don’t use setVelocity() or any other mode.
After some more looking, a somewhat embarrassing conclusion (as sometimes happens with debugging!): it turns out that we had computed the “revolutions” of the actual turret, not the degrees. Since “383.6” is actually somewhat close to 360, some rough numbers for the turret looked plausible. More investigation ensued revealing the error.
revealing the error.