Frc-Characterization returning bad data

[Egreen42]

My team has been trying to get characterization to work for the at home autonomous challenges. the problem is out robot characterization is not returning good data. All of the values seem smaller than they should , with not much change from run to run/ Our configuration code is below and the results it returns after the tests are run are also below. The encoder rotations seem correct and are consistent from run to run. Our team if running the standard am1u4 chassis with the toughbox mini and cim motors on Victor SP controllers. Our encoders are the rev through bore encoder and our gyro is the ADXRS450

# Ports for motors
# If doing drive test, treat this as the left side of the drivetrain
"motorPorts": [0,1],
# Only if you are doing drive (leave empty "[]" if not)
"rightMotorPorts": [2,3],
# Class names of motor controllers used.
# Options:
# 'Spark'
# 'Victor'
# 'VictorSP'
# 'PWMTalonSRX'
# 'PWMVictorSPX'
# If doing drive test, treat this as the left side of the drivetrain
"controllerTypes": ['VictorSP', 'VictorSP'],
# Only if you are doing drive (leave empty "[]" if not)
"rightControllerTypes": ['VictorSP', 'VictorSP'],
# Set motors to inverted or not
# If doing drive test, treat this as the left side of the drivetrain
"motorsInverted": [False, False],
# Only if you are doing drive (leave empty "[]" if not)
"rightMotorsInverted": [False, False],
# Encoder edges-per-revolution (*NOT* cycles per revolution!)
# For the AMT 103-V, use 8192 (2048 * 4)
"encoderEPR": 8192,
# Gearing accounts for the gearing between the encoder and the output shaft
"gearing": 1,
# Encoder ports
# If doing drive test, treat this as the left side of the drivetrain
"encoderPorts": [0, 1],
# Only if you are doing drive (leave empty "[]" if not)
"rightEncoderPorts": [2, 3],
# Set to True if encoders need to be inverted
# If doing drive test, treat this as the left side of the drivetrain
"encoderInverted": False,
# Only if you are doing drive (set to False if not needed)
"rightEncoderInverted": True,
# ** The following is only if you are using a gyro for the DriveTrain test**
# Gyro type (one of "NavX", "Pigeon", "ADXRS450", "AnalogGyro", or "None")
"gyroType": "ADXRS450",
# Whatever you put into the constructor of your gyro
# Could be:
# "SPI.Port.kMXP" (MXP SPI port for NavX or ADXRS450),
# "SerialPort.Port.kMXP" (MXP Serial port for NavX),
# "I2C.Port.kOnboard" (Onboard I2C port for NavX),
# "0" (Pigeon CAN ID or AnalogGyro channel),
# "new WPI_TalonSRX(3)" (Pigeon on a Talon SRX),
# "" (NavX using default SPI, ADXRS450 using onboard CS0, or no gyro)
"gyroPort": "SPI.Port.kMXP",

}

[Egreen42]

[Egreen42]

[Gabriela1772]

Your Motion Threshold is probably too high.
You can change the value and then hit the button Analyze Data again.

Viewing Diagnostics

[Oblarg]

PSA: High-resolution encoder noise w/ WPILib Encoder class

After some more poring through characterization data and liaising w/ teams, it’s become apparent that some teams are getting swamped by noise on high-resolution encoders when used with the WPILib Encoder class. It is important to note that the WPILib Encoder class measures rate by time per period, rather than pulses per time. Thus, an extremely high-resolution encoder (such as the REV through-bore encoder, which comes in at a whopping 2048 periods per revolution) will tend to have extremely no…

I need to add a mention of this to frc-docs.

It’s also important to note that this problem is not frc-characterization specific - if that’s what your encoder measurements look like to frc-characterization, then that’s probably what they’ll look like to your robot code, as well.