FRC Characterization Output - Driven Results

Technical Programming
#1

After running the frc-characterization tool, we took the gains it generated and got a path running. The outputted P value (14.0) was way to high, and we could see this as our robot was taking large steps and over-correcting. We put the P value to a tenth of the characterized output (1.40) and the path was much smoother. We were curious if anyone has experienced a similar issue, or if anyone has any insight as to what might be causing this issue with our values.

This is the output of the characterization we ran the other day:

results
results2716Ɨ898 712 KB

1 Like
#2

Can you post the diagnostic plots?

#3

This could be happening because the Max Controller output defaults to 12. If you are using the scaled -1 to 1 mode, rather than passing voltage values, you should change this value to 1.

1 Like
#4

Here are edursoā€™s plots:

All_Combined_3D_Vel-Accel_Plane_Plot All_Combined_Voltage-Domain_Plots All_Combined_Time-Domain_Plots

#5

LQR gains tend to be on the aggressive side (the LQR algorithm does not account for sensor noise and backlash), and also you may be consuming the gains on a scale of [-1, 1] rather than in volts.

Your diagnostic plots look very clean. What motor controllers are you using?

#6

We are using the spark max motor controllers. We will check how we are taking inputs.
Thanks for your help.

#7

The test drive train has 6 neos and is quite light (just a drivetrain, thin rail, etc) and geared quite low (actually a shifter, but we are doing all of this testing in low gear). The code is using the SparkMax setVoltage api, which we believe is scaled properly from -12 to 12; however, it is a little different than the WPILIB interface:

Sets the voltage output of the SpeedController. This is equivillant to
a call to SetReference(output, rev::ControlType::kVoltage). The behavior
of this call differs slightly from the WPILib documetation for this call
since the device internally sets the desired voltage (not a compensation value).
That means that this can be a ā€˜set-and-forgetā€™ call.
@param outputVolts The voltage to output.

Wondering if the issue could be a ā€œdouble controlā€ loop interaction and we might be better off just setting power and scaling by 12? Wonā€™t be able to test until Monday evening. Has anyone else successfully used this controller with SmartMax and setVoltage api?

#8

We tried running the characterization again, this time using the Talon motor controller setting to calculate our gains. With this, we were able to set our encoder counts to 42 (count of integrated neo encoder) and our gear ratio (after motor output). The gains generated from this worked very well.

#9

This is almost certainly by chance, but Iā€™m glad it worked.

Iā€™ve done some testing and verified that the Spark PID gains are scaled correctly; it seems that the LQR we run tends to output gains that are about an order of magnitude too high for most robots. I am unsure of the cause - Iā€™ve scrutinized our code for a missing factor of 10, with no luck.

#10

To clarify, when you run the SPARK MAX in voltage mode there is no control loop, it is still running open loop. The voltage you set is the voltage that the controller will output. The advantage over the native WPILib method is

  1. The voltage calculation happens on the controller every cycle (20kHz)
  2. The voltage measured by the controller will be different than the voltage measured by the RIO
1 Like
#11

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.