Hell everyone! My school started an FRC team earlier this year and we have decided to dive into feedforward command and path planner. We are using Rev SparkMax relative encoders. We have found there is no first party Rev tool like Sysid for these encoders. So we are stuck with Sysid. We have been able to get results out of Sysid but the values they produce seem to be a bit high. Mainly the Ks and Kv. We tested the values by making an auto in path planner that would go 1 meter exactly. With the values from Sysid we have found it overshoots a little bit going 1.2 meters. By adjusting the values manually to be a bit lower, we did get it to go exactly 1 meter. However my question is. Is it normal for Sysid to be a little off? Is it just a starting point for further tuning or is it very accurate to where it doesn’t require any further tuning?If you are willing to share I would like to hear your thoughts as to what the issue could be. Below I have linked the code I used to find the numbers on Sysid. Maybe something is wrong but I’m not sure. Any insight would be very much appreciated! Thank you.
Code: https://github.com/FRC-9438/Sysid/tree/main/src/main/java/frc/robot
Are you using any feedback, or only feedforward?
When you say the robot overshoots, do you mean by measuring it, or by looking at odometry, or both? It could be that your odometry is off, it could be something like your wheel circumference.
We checked our odometry by manually driving it forward with the controller to a meter. Our Odometry says we have gone to the correct distance. It just seems to happen in autonomous with Pathplanner. When it overshoots, it goes past a meter in distance and this shows in odometry, which is where my confusion is happening.
We are using feedback with our feedforward, that being our PID controller to read our encoder ticks. We referenced the autoDrive method from the official wpilib documentation example code to achieve this. Below is our version of that which we have implemented.
public void autoDrive (ChassisSpeeds chassisSpeeds) {
DifferentialDriveWheelSpeeds speeds = DriveConstants.kDriveKinematics.toWheelSpeeds(chassisSpeeds);
m_wheelspeeds = speeds;
final double leftFeedforward = m_feedforward.calculate(-speeds.leftMetersPerSecond);
final double rightFeedforward = m_feedforward.calculate(-speeds.rightMetersPerSecond);
final double leftOutput =
m_leftPIPidController.calculate(getLeftEncoderPosition(), -speeds.leftMetersPerSecond);
final double rightOutput =
m_rightPIPidController.calculate(getRightEncoderPosition(), -speeds.rightMetersPerSecond);
m_FLM.setVoltage(leftOutput + leftFeedforward);
m_FRM.setVoltage(rightOutput + rightFeedforward);
m_drive.feed();
}
I hope this awnsered your question. If it didn’t please let me know.
Also I have linked our team code in case there was something else you wanted to look at.
Thank You.
You are passing in a position as your PID measurement, but a velocity as your PID setpoint.
Well, what are your feedback gains?
Can you share your SysId parameters and diagnostics?
We are only running a kP coefficient, kI and kD are set to 0, and we received a 0.11785 value for P when we ran SysID the last time.
How does performance differ with kP set to zero, versus kP set to the current value?
It doesn’t make a ton of difference where P was set. If it was set higher, then it ran about .2 meters over where if it was set lower it ran about .12 meters over. What I believe is happening, is that based on this reply, our PID controller is not working as intended, and path planner stops the robot based on a timeout. I will have some time for the students to test this today and can report back after.
We made the modification to our PID controller today, when P was set to 0.1785, it ran to about 1.17 meters, when P was set to 0 it ran to 1.14 meters. Here is a copy of our code.
Here is a video showing our PID and feed forward values as the bot drives
Any help is appreciated.
You may be using a wheel diameter in your odometry calculation that does not accurately represent the effective rolling diameter of the wheels.
We updated that value and the behavior seems to be the same. The changes aren’t reflected in our github at this time. Further testing also shows that when we tell it to turn 180 degrees we are only getting about half of that.
We are still working on this issue. We just tried using the differential drive example out of the advantage kit github. We wanted to implement advantage kit anyways, so this made sense to us. We set our constants, and ran the test. The numbers look close to what I was expecting except we are registering a negative Ks. It seems I am unable to upload the log file, but I can provide that as well if need be. I appreciate any help as we are a new team, and this issue with getting correct values out of SysID has been an issue since the beginning of the season.
IDLogs.zip (1.3 MB)
edit: I was able to add logs using a zip file