Motion Profiling 2020 Issue

[Phlogiston]

I think the problem is that you don’t need to convert from ticks to meters. When you run the characterization tool, it generates values based on the wheel size relative to the number of ticks per rotation. Just use whatever unit you used for wheel size in the characterization tool.

[Joe_Sims_2534]

This is correct. I’ll edit my previous posts to be accurate.

[Joe_Sims_2534]

@Phlogiston

I think the problem is that you don’t need to convert from ticks to meters. When you run the characterization tool, it generates values based on the wheel size relative to the number of ticks per rotation. Just use whatever unit you used for wheel size in the characterization tool.

This code is automatically generated by the WPILIB Characterization tool:

double encoderConstant = (1 / ENCODER_EDGES_PER_REV) * WHEEL_DIAMETER * Math.PI;
leftEncoderPosition = ()
→ leftMaster.getSelectedSensorPosition(PIDIDX) * encoderConstant;
leftEncoderRate = ()
→ leftMaster.getSelectedSensorVelocity(PIDIDX) * encoderConstant *
10;

This is the same conversion we used in our code to get the velocity and position. I think we do need it for motion profiling. Removing it makes to robot move forward/backward rapidly. It probably thinks it moved about 200 meters in a fraction of a second.

@s-neff

I suspect that the distance between diagonal wheels is a better physical proxy on a mecanum robot.

When we measure diagonally (from the center of one wheel to the center of the diagonal wheel), We get 0.5842 meters, still a great difference to the 1.244222932233876 meter number from the tool. Could this number issue be why it doesn’t work?

I am currently looking through the troubleshooting guide. I will get back with results!

[s-neff]

@Joe_Sims_2534

When we measure diagonally (from the center of one wheel to the center of the diagonal wheel), We get 0.5842 meters, still a great difference to the 1.244222932233876 meter number from the tool. Could this number issue be why it doesn’t work?

Whoops, less dramatic than I thought.

My point is that what the tool calls “track width” is a value that has to do with “how hard it is to turn”, and happens to be related to tank drive track width with standard traction wheels. I’d trust the characterizer and keep the large value.

[Joe_Sims_2534]

@s-neff

what the tool calls “track width” is a value that has to do with “how hard it is to turn”, and happens to be related to tank drive track width with standard traction wheels

Hah! That’s wierd!

@s-neff

I’d trust the characterizer and keep the large value.

Yeah. Looking at the troubleshooting guide, it seems like this is the right option.

[Oblarg]

The 1.2 meters figure seems suspicious to me, as well; if it is wrong, it won’t have any effect on a straight trajectory, but it would result in possibly-severe over-steering on a curved path (which the ramsete controller will then attempt to fix).