We have been using the characterization tool trying to characterize our drivetrain. Over the past several tests, our track width is said to be about 30 units (which we set to meters). This doesn’t sound quite right. We have tried verifying our gear ratio and encoder values.
Additionally, after running just the quasistatic forward test, the characterization logger said we traveled roughly 180 units (I’m assuming this means meters?) which is not correct as we ran the robot on about five meters of carpet. This value was not quite right for all the other tests when ran as well.
Can somebody explain to us what these tests are and what unit numbers they are printing, and if there are other important configuration settings we need to set in order to get this right?
You also type in the track width value, right? So you entered 30 “units”? If so, you really need to make sure your units are consistent. If you’re using meters for everything else, then you need to use meters here. If your track width is 20", then you need to enter 20*2.544/100 or ~0.5 (I didn’t run it through a calculator to get the exact value, but you should)
I am next to edurso right now. We did not have the old config file, and the project had been edited so we just re-did it all. Our config is now:
{
# Ports for the left-side motors
"leftMotorPorts": [1, 2, 3],
# Ports for the right-side motors
"rightMotorPorts": [4, 5, 6],
# NOTE: Inversions of the slaves (i.e. any motor *after* the first on
# each side of the drive) are *with respect to their master*. This is
# different from the other poject types!
# Inversions for the left-side motors
"leftMotorsInverted": [False, True, False],
# Inversions for the right side motors
"rightMotorsInverted": [False, True, False],
# The total gear reduction between the motor and the wheels, expressed as
# a fraction [motor turns]/[wheel turns]
"gearing": 13.55,
# Wheel diameter (in units of your choice - will dictate units of analysis)
"wheelDiameter": 0.15,
# Your gyro type (one of "NavX", "Pigeon", "ADXRS450", "AnalogGyro", or "None")
"gyroType": "NavX",
# Whatever you put into the constructor of your gyro
# Could be:
# "SPI.Port.kMXP" (MXP SPI port for NavX or ADXRS450),
# "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": "I2C.Port.kMXP",
}
Our results now seem much closer; however our track width is now very narrow (less than a centimeter if we understand the units).
Checked the generated project and the navx stuff looks right:
// Note that the angle from the NavX and all implementors of wpilib Gyro
// must be negated because getAngle returns a clockwise positive angle
AHRS navx = new AHRS(I2C.Port.kMXP);
gyroAngleRadians = () -> -1 * Math.toRadians(navx.getAngle());
Try inverting the motors on one side of your drive and re-running (this may require some silly fiddling to get it to turn instead of drive straight). I suspect the encoder inversion when using NEOs is causing problems, and we’ll have to throw an abs() into the calculation.
