sysID not reporting correct distance values

I’ve been trying to characterize the drivetrain for my team’s robot using sysID, but I can’t get it to report the right distance values after running the tests in the logger. The distance reported by sysid is short by about a factor of 4. I will drive it 4 meters, and sysid will only report 1 meter.

I’m using 3 neo’s on each side with Spark Max controllers, and a CTRE quadeture mag encoder positioned on each of the front wheel shaft plugged into the Rio. The gear ratio is 4.444:1, and we are using 4.2in wheels.


I’m fairly certain that I’ve entered all my parameters in the Generator and Logger correctly. I got the counts per rev, 4096, directly from the CTRE website. I have a 1:1 gearing since the encoder is directly on the wheel. My units per rotation is 0.3348, the wheel circumference * pi in meters. I don’t know what I have wrong that’s causing me to get incorrect distances.

What can I do to fix this?

You’ll still want to account for the gearing from the output shaft to the wheel, so you should put the 4.444 : 1 into the gearing field.

So even though the encoder is directly on the wheel, I still need to use the gearing? I get output shaft confused on whether it means the motor or the wheel

Oh, I misread. Sorry about that. I thought you meant that the encoder was on the output shaft of the motor. If it is on the wheel then what you had should be right. By what factor is the distance wrong?

I wonder if you’re getting caught by the subtle distinction between edges-per-revolution and cycles-per-revolution (see Encoder Resolution). I believe the CTRE mag encoder is 4096 EPR but only 1024 CPR. It doesn’t help that field is labelled counts-per-revolution in the sysid interface.

1 Like

This is along the right track. OP, you have the “Reduce Encoding” box checked which puts the encoder in 1X mode instead of 4X mode. This means that the encoder will measure 1 count per complete cycle instead of 1 count per edge, so you should enter 1024 in the Counts Per Revolution field. It seems like the program should take care of this for you but it doesn’t.

This was incorrect, see posts below.

So you’re saying that the "Counts Per Revolution field means edges-per-revolution when “Reduce Encoding” is unchecked, and cycles-per-revolution when it is checked? If so, the interface could make that a little clearer.

1 Like

Dug deeper and I’m actually incorrect and your original explanation was 100% correct, sorry!! I originally tracked the signal all the way through SysID but not down through WPILib. WPILib accounts for the encoding type in the HAL. Because of this encoder resolution for use with WPILib should be considered in Counts Per Rev which is 1024 for the CTR Mag Encoder.

1 Like

So I should still change the Counts Per Rev paramater to 1024? And then wpilib will automatically scale it up to 4096? Does that mean that right now, I’m actually running the encoder at 4096*4, 16384 EPR?

Yes, you should enter 1024 in SysID and should also use that number if using the encoder in your robot code when you are calculating “Distance Per Pulse” for the SetDistancePerPulse() method of the encoder class.

If the encoder is used with 1X decoding (like when you have the Reduce Encoding box checked in SysID) the FPGA will report 1024 ticks per revolution of the encoder. If you have the encoder set to 4X decoding, there will be 4096 ticks per revolution but WPILib will automatically multiply your distance per pulse by .25 to account for this: https://github.com/wpilibsuite/allwpilib/blob/2e09fa73257aa92c2dad3d52019d96aa04b26129/hal/src/main/native/athena/Encoder.cpp#L163

Yes, the way you have it configured right now would correspond to a 4096 cycles per revolution or 16384 edges per revolution encoder.

Ok so just to make sure, 1024, not 4096 is what I enter for Counts per Rev in sysid, even though it recommends 4096 in the tooltip. I leave units per rotation at the wheel circumference in meters. Within my code, I’m using 4x decoding, so my distance per pulse would be the wheel circumference divided by 1024. Should I leave reduce encoding checked?

The tooltip doesn’t appear to change when you change the encoder setting from “Talon SRX - Built-in” (where 4096 would be the correct setting for a mag encoder) to “roborio quadrature” (where 1024 should be used) so I would assume the authors must have been thinking more about the case of wiring the mag encoder to a Talon SRX.

Yes, units per rotation looks correct for a 4.2" wheel.

Yes, distance per pulse in code should be circumference/1024.

I think you can leave Reduce Encoding checked, but you could also try both ways and compare. Using the encoder in 1X mode (like Reduce Encoding does) reduces noise in the velocity signal at the cost of reduced resolution. With 1024 steps in your wheel revolution, each step is ~.013 in which seems like plenty of resolution. Whichever setting you find works best in SysID, you probably want your robot code to match as well.

2 Likes

That was my take too: 1x vs 4x multiplication…

1 Like

Remember that the project is open-source and you’re free to submit a PR improving the tooltips!

1 Like

@VincentWren looking at you :wink:
Please enshrine this vital knowledge in a better tool tip!