PID controllers can reach steady state not at the setpoint. You might get some information from an article such as this (there are thousands on the Internet). I’m glad you found the problem; your solution was my next suggestion after you convinced yourself it wasn’t a troublesome slew rate limiter. And now you know it isn’t strange - it’s not unusual to see this happen.
Thanks, l feel that this problem is straneg because several months ago, l used the same PID value in my falcon and tried to control it via falcon’s velocity controlled loop and it works very well. But now, with the same PID values, the swerve just drives at a slow speed. l think it is strange.
Besides, l remember that someone has told me that the PID value in the integreted sensor is the same with the PID values in the PIDController. Is that the case?
I think the most important reason that l use slewratelimiter is that it can help me control the swerve drive motor’s acceleration. In that way, it seems that the swerve can drive smoothly.
l am not very sure about this. But the slewratelimiter’s effect can be easily seen from the drive motor.
I assume by Integrated Sensor you mean the TalonFX or SparkMax or whatever motor controller you are using as opposed to the various WPILib PID controllers.
The PID constants are essentially units conversion devices and especially the I and D have a time basis that they integrate or differentiate respectively. If you change the time base then you have to change the I and D appropriately.
Typically the WPILIb controllers are run at your robot iteration speed (0.02 seconds). Or you optionally can speed it up using a faster IterativeRobot or (better yet) use the Scheduled Periodic Task feature in IterativeRobot to say 0.01 seconds or a little faster. The TalonFX runs at 0.001 seconds per iteration so you have to change the time-based units for I and D. I don’t know the SparkMax period.
The 3 joystick axes had slew rate limiters - X, Y, rotation.
For steering, trapezoidal control works very well (with only a P – I and D can be zero). You might want to look at something like Motion Magic (the specifics vary depending on which motor controller you are using – again, if the code was up somewhere these answers would be at hand).
You can do a similar thing with the drive motors. You use velocity control instead of position control though. Then, you simply limit the maximum acceleration. This is what you most likely want to limit, if anything.
Just for reference, our 2022 swerve robot did most of the fancy stuff in autonomous, and the steering was always just trapezoidal position control. But in teleop, we didn’t do anything fancy with drive, and the robot was very controllable. We did have a slow mode for ease of fine positioning and did modify the commanded drive power if the steering motors were out of position, but no slew rate limiting. I have seen others assert this was found to be beneficial for them though.
At the end of the day, it sounds as though you have a software bug. Without access to the robot, it’s tough enough to help out in this type of scenario. Without the robot and without access to the code, it’s really hard.
1 Like
Thanks, we have already used the MotionMagic on our steering motor ( l remember l had ask some questions about it in the last year😂).
And with the drive motor, l try to combine the feedforward and feedback( with only P value) together.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.