# Encoder value conflict

Hi eveyone!

I’m software programmer in 7682. As a team we are developing a pid package. In robot we are using the basic chassis and the CIMcoders are connected to CIM motors.

Like in the photo

At test time, we saw that the encoder values ​​are not the same as in real life.

Note: In the beginning the robot angle was 144 degree.

For PID code;

``````      Encoder leftEncoder = new Encoder(6, 5, false, EncodingType.k4x);

public static final double K_DRIVE_TICK_2_FEET = 1.0 / 128 * 6 * Math.PI / 12;

public autonomousPeriodic() {
double currentEncoderPosition = leftEncoder.get();

// Calculate the feet of left encoder
currentEncoderPosition *= K_DRIVE_TICK_2_FEET;

// Cast the feet to meter
currentEncoderPosition = Units.feetToMeters(currentEncoderPosition);

differentialDrive.arcadeDrive(rotationalDrive.turnXDegrees(144),

encoderAutoConfigurer.getPIDcontroller().calculate(currentEncoderPosition, 2))}
``````

In this scenario robot should go 2 meter but in the real life robot went 1.20 meter.

Test Results
PID setpoint = 2 meter
CIMcoder value = 2,05 meter
actual measurement = 1.20 meter

We didn’t found the solution for this problem.

Thanks for any help!

Your code doesn’t seem like it will do what you want it to do. The autonomousPeriodic method will be called every 20ms. You also aren’t using the output of the PID controller (at least not in the code snippet you provided). Do you have your code on GitHub? Being able to view all the code will allow others to help you easier.

As mentioned above, it would be easier to help with a complete code example. If this code is on GitHub a reference would help at lot.

The data here is not 100% completely clear. Is the CIMcoder value = 2,05 meaning that the value you compute the robot has traveled is 2.05 meters? If you asked the drivebase to move 2.0 meters, and it thinks it moved 2.05 meters, but in reality is only moved 1.20 meters, this means your computations from ticks to meters is wrong somewhere.

If the robot went 1.2 meters and the computations show it went 1.2 meters, then the PID controller needs to be tuned.

Just my thoughts based on this snippet of code.

Could you talk us through this line of code? Best practice would be to separate out and name the various constants here. I’m guessing that:

• 1.0 is the gear ratio
• 128 is the ticks per revolution of the encoder
• 6 is the diameter of the wheel in inches
• 12 is inches per foot

I can’t confirm from the photo exactly what hardware you’re using, but looking at Bring Up: Talon FX/SRX Sensors / Sensor Resolution, it says that the AndyMark CIMcoder is 80 units per revolution. The ratio between 128 and 80 is approximately the same as that between 2m and 1.2m.

1 Like

Hello,
First of all, I hope you are having a good day. Thank you very much for your answers and help. You can access the TimedRobot version of the code via the link.
Link: Timed Robot code · GitHub

Hello,
First of all, I hope you are having a good day. Thank you very much for your answers and help. I don’t think the problem in the code was caused by the PID controller because it generated the values ​​correctly. You can access the TimedRobot version of the code via the link.
Link: Timed Robot code · GitHub

Hello,
First of all, I hope you are having a good day. Thank you very much for your answers and help. We got the calculation from the 0toAutonomous channel. I’ll get back to you after I get tested on the guess you’ve made.

Watching the video that goes with that example, they use a Grayhill optical encoder which presumably has that particular number of counts per revolution, and which I also think might be attached to the wheel axle instead of the motor like in your case.

1 Like

If it’s attached to the wheel axle, it makes sense for the gear ratio to be one. I can’t see the gearbox clearly in the photo. Do you know your gear ratio?

Hello again,
Our team uses the gearbox in the link I mentioned on the robot. Sorry, I don’t know about gear ratio. We also took tests of the possible solutions you mentioned. You can see the test results below.

LeftEncoder

calculation value : public static final double K_DRIVE_TICK_2_FEET = 1.0 / 80 * 6 * Math.PI / 12;
target setpoint : 2 meter
real life value : 85 centimeter

calculation value : public static final double K_DRIVE_TICK_2_FEET = 1.0 / 160 * 6 * Math.PI / 12;
target setpoint : 2 meter
real life value : 145 centimeter

calculation value : public static final double K_DRIVE_TICK_2_FEET = 1.0 / 128 * 6 * Math.PI / 12;
target setpoint : 2 meter
real life value : 120 centimeter

RightEncoder

calculation value : public static final double K_DRIVE_TICK_2_FEET = 1.0 / 80 * 6 * Math.PI / 12;
target setpoint : 2 meter
real life value : 80 centimeter

calculation value : public static final double K_DRIVE_TICK_2_FEET = 1.0 / 160 * 6 * Math.PI / 12;
target setpoint : 2 meter
real life value : 80 centimeter

calculation value : public static final double K_DRIVE_TICK_2_FEET = 1.0 / 128 * 6 * Math.PI / 12;
target setpoint : 2 meter
real life value : 132 centimeter

Gearbox Link : Toughbox Mini - AndyMark, Inc

The gearbox you link to can apparently be configured with five different gear ratios. You ought to know which one you selected when you assembled it. This is important because the CIMcoder is measuring the rotation of the motor, but you’re interested in the rotation of the drive wheels. The gear ratio is what relates the two. I think the example code you linked to above was assuming a wheel encoder, not a motor encoder.

Also, I’m assuming you’re using six inch wheels here, but you should verify that.

This code doesn’t seem to be complete and it doesn’t match the code snippet you posted above. Is it possible for you to share your githib repo with us?

Stop doing these constant calculations as long, non-self-documenting literals. Define the component terms and build them up piecewise.

2 Likes

The problem is that you have at least 3 unknowns (encoder resolution, gear box ratio, and error from PID driving, and only 1 equation. You could guess and check for quite a while before finding the right combination. I recommend instead simplifying the setup so you can directly measure some of the unknowns. For example, remove the CIM with the CIMCoder from the gearbox and manually spin it 1 revolution and see what distance it reads. Note that because of the way WPILib reports distance, I suspect the correct value is 20, rather then 80, as even with 4x decoding it normalizes the results to 1x values. So there’s 80 steps between 0 and 20.

After you’ve confirmed the correct distance per revolution, you can figure out the gear ratio of the gearbox. You can manually spin the output of the gearbox 1 revolution, and see the encoder value.

Then I’d recommend confirming everything not by PID driving, but by pushing the robot 2 meters, and comparing the encoder value.

Another potential source of error is the diameter of the wheel. It’s unlikely exactly 6 inches.

1 Like

If you don’t know all the appropriate ratios or don’t trust the measurements of wheel diameter you can go with an observed value for distance per click or clicks per distance instead of a calculated one. Open phoenix tuner. Clear the encoder values turn breaking off on your motors. Roll your bot forward a known distance. See how many clicks each encoder has traveled. I find this number close but never identical to calculated values.

In the gearbox we are using this tooth : 48 Tooth 20 DP 0.5 in. Hex Bore Steel Gear - AndyMark, Inc
Also our robot has 6 inch wheels.

Thanks for the good practice.

We will feedback after trying.
Thanks!

Of course. You can access the Repo with this link

I think at this point your best way forward is to follow the advice of @Joe_Ross and @Bmongar above. Push the robot forward a measured distance, and count the encoder ticks.

1 Like