Robot Characterization - Invalid Quasistatic Data

[BlueberryPi]

I’ve been using the new characterization tool, and up to this point it’s worked to a tee. However, I recently had to re-characterize our test bot because the competition drive was fitted to it, and the gear ratio changed to 4-to-1. Now when I run the routine, the encoders are returning much lower values and (more importantly) the data analysis tells me that the quasistatic data isn’t reaching the motion threshold. We are using CANEncoders and brushless motors , and working in Java.

An image of the error the data analyzer gives me

The data the analyzer tool gives me at a motion threshold of 0.005, the highest it goes before giving me an error

The project being used for characterization
Robot.java (7.1 KB)

[Oblarg]

Please post your diagnostic plots and your data json.

It looks like you’ve done something a bit strange; the SparkMax Brushless project generally does not have an encoder EPR specification.

[BlueberryPi]

imSoTired20200202-1137.json (882.3 KB)

[Oblarg]

Yeah, so I’m pretty sure that the issue is the encoder epr spec you’ve put in your robot code; the brushless project template is not set up to use external encoders (it’s not necessary for characterization purposes).

Try running the project again with the ordinary brushless template, and be sure that “gearing” reflects the gearing between the motor and the wheel shaft.

[BlueberryPi]

I did as advised and removed the EncoderEPR specification so the encoder was formatted as default. I got the following results:

This is certainly better, but the kP value seems far too high; could there be something else I’m doing wrong?

[Oblarg]

It still looks to me like your units are off; your top speed is something like 10 units/second - no FRC robot is going to go 10 meters per second. You have probably specified your gearing incorrectly.

As for the P gains, the LQR gains are very aggressive and have been reported to be about a factor of 10 too large in most cases - we’re still investigating the cause. Also note that the SparkMax gains assume that you have set the SparkMax to operate in your units of analysis with the library’s scaling functionality.

[BlueberryPi]

When I put these values into my trajectory following program , the robot turns rather dramatically considering it’s supposed to be following a straight path. Would the incorrect units be the primary cause of this, or could it be something else?
(Relevant code below)
RobotContainer.java (4.5 KB)
DriveSubsystem.java (6.9 KB)
Constants.java (4.1 KB)

[Oblarg]

There could be many causes of that; units are one possible cause, but more likely it’s that your initial robot pose doesn’t match your trajectory start state (gyro inversion is a common issue here).

I’ll be able to help you more if you can put your code on github rather than sending the files.

[BlueberryPi]

Andrew-Kohler/TroubleshootingRepo

Apologies if it’s a little sloppy; made this on the fly since our team repo is private.

[Oblarg]

So, there are a number of things here that could cause issues. I’d start by logging your odometry, motor setpoints, and motor speeds throughout a following command.

In particular, this looks likely wrong:

    leftEncoder = leftLeadMotor.getEncoder(EncoderType.kHallSensor, 4096);
    rightEncoder = rightLeadMotor.getEncoder(EncoderType.kHallSensor, 4096);

If you’re using the internal hall sensor, you shouldn’t need to specify an encoder resolution.

[BlueberryPi]

Ok, I’ll give it a shot- what else might be the issue, for the sake of being thorough?

[Oblarg]

Encoder inversion’s a big one, as is starting pose. Hard for me to debug those remotely (especially since you’re using pathweaver paths).

[BlueberryPi]

Alright, I’ll check both of them and see. Thank you so much for your help.