I have a very specific question about tuning a PID loop to control the Yaw (angle) of a swerve drive base. A loop such as this allows the user to input a field relative angle, and have the robot autonomously rotate to the desired heading. This was one of the features we implemented in order to accurately align with the vision targets on the field using vision processing. We successfully used this feature in 2019, only instead of using PID, we used hard set values that were proportional to the distance left to rotate. This worked ok, but we are hoping to use a PID loop this season to maintain the heading of the robot more accurately.
My question stems from a behavior specific to swerve drives. When tuning the Yaw control loop (PID or otherwise), when the drive base is in a state of rest, it runs to the desired heading just fine. But once you drive it around the field, the ratio of the input rotation command to the actual speed of rotation of the drive base goes down. This isn’t a problem per say, it’s just a fact of how swerve works. You can think of the X, Y, and Z (rotate) commands as “sharing” the maximum movement capacity of the robot. You maximize your rotation speed by sitting in one spot, but once you start to move, the same rotation input will yield a slower rotation speed. If I didn’t explain that clearly enough, here are some graphical swerve simulations I created that demonstrate this principle quite nicely.
So, my question is, to those who have also implemented a Yaw control loop similar to the one I’ve described (or to anyone who may have an answer), how do you deal with the discrepancy between the behavior of the robot when it is stationary and when it is moving? In our testing, whenever we tuned the Yaw loop properly with the robot in a stationary state, driving the robot around resulted in either oscillating back and forth over the desired heading, or not attaining the desired heading at all (at least until the robot comes to a rest). And due to the face that the ratio of X to Y to Z movement of a swerve drive is infinitely variable, there isn’t a one and done solution that I can think of to account for this discrepancy (i.e. tuning the loop while the robot is moving forward would result in unpredictable behavior when moving diagonally backwards).
As I said before, we were able to deal with this problem last season, but we had to move quite slowly to get accurate results, and we want to find a more robust solution.
Thoughts, comments, and criticism are welcome.