Robot Characterization & Trajectory Tracking Help

Vinay_Pan · February 23, 2021, 9:03pm

Hey everyone!

I’ve been trying to get the basic trajectory tracking to work on our robot, but it has not been going well. Below is the video of what the robot does after following the instructions as described at this WPILib Page.

I might be completely wrong, but here are the issues that I think might be contributing to the problem:

When characterizing the robot with the FRC-Characterization Suite, the distances that it reports are consistent, but inaccurate. I’ve put the “Units per Rotation” value at 0.47877872 meters, which is the circumference of the wheels (6 inch diameter --> meters). The “gearing” value is set to 11.5. However, after running the data logger, the reported values are much higher than they should be.
The dynamic velocity vs. time graph has a section of it cut off. This might be due to setting the motors/encoders inverted value to the wrong value in the config file, but the robot moves in the right direction when enabled, so I’m not sure.

All of our code can be found at our Github. I’m really at a loss as to what I’m doing wrong, so any help would be appreciated!

– Vinay

jdaming · February 23, 2021, 9:07pm

What motors / encoders are you using on the drivetrain? Can you post the characterization config as a text file here?

Vinay_Pan · February 23, 2021, 9:10pm

We’re using 4 Falcon 500 motors, and their respective integrated controllers, geared at 11.5:1. The text file is below.

{
# Ports for motors
# If doing drive test, treat this as the left side of the drivetrain
“motorPorts”: [11,21],
# Only if you are doing drive (leave empty “[]” if not)
“rightMotorPorts”: [12,22],
# Class names of motor controllers used.
# ‘WPI_TalonSRX’
# ‘WPI_VictorSPX’
# ‘WPI_TalonFX’
# If doing drive test, treat this as the left side of the drivetrain
“controllerTypes”: [‘WPI_TalonFX’,‘WPI_TalonFX’],
# Only if you are doing drive (leave empty “[]” if not)
“rightControllerTypes”: [‘WPI_TalonFX’,‘WPI_TalonFX’],
# 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 CTRE Mag Encoder, use 16384 (4 * 4096 = 16384)
“encoderEPR”: 2048,
# Gearing accounts for the gearing between the encoder and the output shaft
“gearing”: 11.5,
# Encoder ports (leave empty “[]” if not needed)
# Specifying encoder ports indicates you want to use Rio-side encoders
# If doing drive test, treat this as the left side of the drivetrain
“encoderPorts”: [],
# Only if you are doing drive (leave empty “[]” if not)
“rightEncoderPorts”: [],
# 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”: False,
# ** 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”: “NavX”,
# 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”,
}

jdaming · February 23, 2021, 9:14pm

You need to use 8192 for “encoderEPR”. I know the Falcon is only 2048 . This is due to a bug in FRC char that divides everything by 4.

Alternatively if you don’t want to regen the project it is easy enough to go in and remove the /4 on the line that looks like this in Robot.java:
static private double ENCODER_EDGES_PER_REV = 2048 / 4.;

Vinay_Pan · February 23, 2021, 9:31pm

I changed 2048 to 8196 in the config file, and it did help. The data logger was capturing more accurate numbers, but the robot still isn’t following the path at all. It goes really fast backwards as its first step, which definitely isn’t right.

jdaming · February 23, 2021, 9:36pm

Have you gone through this troubleshooting?

D.Allred · February 24, 2021, 3:40pm

Hey Vinay,
We just got our trajectory code running with 4 Falcon’s and 6 inch wheels. What Kv, Ka, Ks constants are you running for the feedforward components?

By the way, we did the steps in troubleshooting before doing our first trajectory with feedback control. It’s a very systematic way to ensure each piece is working correctly.

David

Mr.R_2 · February 25, 2021, 2:46am

This may be irrelavant, but are you running a holonomic drivetrain? If so (especially if it is mecanum) is there a conflict with the sensors (I am wondering if wheel slip on the linoleum is an issue)?

Vinay_Pan · February 25, 2021, 10:25pm

Hey David,

Our constants are as follows:

ksVolts = 0.012;
kvVoltSecondsPerMeter = 0.43;
kaVoltSecondsSquaredPerMeter = 0.154;

Since we are on a linoleum floor, the kS should be much lower, but did you get similar values for kV and kA?

We’re actually currently in the process of going through each of those steps right now, so hopefully it provides some insight.

–
Vinay

Vinay_Pan · February 25, 2021, 10:34pm

We’re running a standard west-coast tank drive. Wheel slip might be an issue, but I turned down the step voltage in the characterization suite for quasistatic and dynamic voltage to compensate, so it should be factoring in wheel slip, I think.

–
Vinay

D.Allred · February 26, 2021, 2:56am

Hmmm. Our pneumatic wheels are about 5.6 inches plus we are running on carpet. But your robot on a competition field should have a top speed of 3.5 meters/sec – similar to ours.

Your constants are way off. So say you want to use feed forward to cruise at 2 m/s.

Feedforward Volts = Ks + 2 m/s * Kv. With your constants that would be less than 1 volt.

Our Ks = .7 and Kv = 2.5. I would expect your Kv to be in the 2.5 to 3 range.

Also, the feedfoward and feedback are in volts, not percent output. Are you sending that value to the Falcon without voltage conversion? We used this method to convert from ramsette controller voltage to percent output the Falcon controller accepts.

kFalconLeftFront.set(ControlMode.PercentOutput, leftVolts / RobotController.getBatteryVoltage());

Bottom line. Go through troubleshooting steps beginning with verifying odometry. When you eventually generate trajectories, you will have to have a super low acceleration rate … maybe something like 0.5 m/s^2. That floor looks slick…

David

Zekrim · February 27, 2021, 11:13pm

Hey all!
So I’m working on characterizing a west coast drive train, and it gives me a “List index out of range” error whenever I set the “encoderPorts” or “leftEncoderPorts” dictionary entry to an empty list.

I saw that plenty of example code using that, but whenever I try it, it doesn’t work, do you have any ideas as to why that is or what I’m missing, or anything else?
If this information helps you, we’re using a Spark robot controller and neo motors

Thank You!

Edit : Nevermind, the issue was I had it set to “Simple” and not “Spark MAX” mode