What constants in our pid should we retune so that the robot doesn’t turn slightly at the end of a straight path.
This is urgent. Please help!!!
1 Like
It’s hard to help without a sample of your code- you should post that if you want specific advice. In general, here are a few pointers:
Tuning: there are various ways to tune a PID control loop for varying levels of accuracy. The easiest method I am aware of is setting all three constants to zero, and then setting P to some arbitrary value. From there, double P until you see oscillation, and then halve it. That would be your P. Using that determined value, tune I and D in the same manner, one at a time.
That being said, this doesn’t really sound like a tuning issue to me, so much as a code/mechanical issue. Without more information about your code or sensors, it’s somewhat hard to tell what your particular issue is, but I have two pointers:
-
Make sure your chassis sides are being assigned the same power values. Independent assignment of power based on separate encoders can work, but it relies on very little drift and a well built drive base. Try calculating error based on the average of every encoder and assigning every motor the same value. If this is what you are doing, it also may be worth trying the opposite.
-
Apply a correction factor. This is definitely more of a workaround than a real fix, Essentially, take the difference between the travel distance of your two sides (Left-Right) and assign a new P constant to it. For convenience, we’ll call this number C. If you add C to the right side and subtract it from the left side, this could solve the problem, but the constant you multiply the difference between encoders by will also need to be tuned.
With all that said, we really need code to diagnose the issue.
10 Likes
This is our code. We’re only using the motors encoders. Please take a look and tell me if there is anything wrong with it.
1 Like
Looking at your driving code, I don’t see anything obvious that would cause a turn at the end. My guess is that one side of your drive base is higher friction than the other. You could try to fix this mechanically, by making sure your wheel assemblies are well aligned and using lube.
FYI, you can test how much power is used to turn the wheel at full speed by turning your robot on its side, navigating to the devices menu on the brain screen, selecting each motor, and pressing the arrow until it reports that it is spinning at max speed. It will also tell you how many watts it takes to maintain speed. This number would ideally be the same for every wheel assembly, and I’m guessing it’s not.
My second suggestion would be to calculate motor power individually. Essentially, calculate 2 lateralMotion values, one for the left error and one for the right error. This would ensure that each side independently reaches the desired distance, but can also result in drift to one side if one side accelerates faster at the beginning.
Finally, I’m just going to re-emphasize this as a possible solution, my PID code incorporates this:
But again, my guess is that your problem is mechanical, so you should start there.
4 Likes
I’m noticing also that you’re using motor.move(). If I’m not mistaken, that’s voltage control. I would actually suggest changing to velocity control (move_velocity?), this will make your base less sensitive to small differences in weight of the robot and different friction between assemblies.
2 Likes
Generally when using PID you use voltage control, because otherwise if you use velocity control then you are effectively putting the output of your PID loop into another PID loop, which can cause strange behavior.
7 Likes
if it turns at the end, implement drift correction
what is velocity control?
As @dashwsd said in the post above mine, move_velocity is a function that uses velocity control. Velocity control uses a built in PID loop on the motor itself to control the motor voltage.
3 Likes
I know velocity is PID controlled as well, but if you take the time to tune it I’ve found that it is actually faster than PID based on voltage. I think this is because the motors can actually brake as they approach the target instead of just slowing down.
3 Likes
There’s a chance it could be a mechanical issue so rule that out first.
I would reccomend writing a program to print out the encoder values for the right and left sides then comparing them after moving in a straight line (with the unwanted turn)
If the values are the same after a straight line + slight turn, it means the encoders aren't picking up the turn
It’s most likely a combination of backlash between the wheel and the internal encoder and the wheels slipping. If the encoders picked up the chassis turning after a straight line, the control loop should straighten out the robot.
My team switched to external encoders because we’ve always found the internal encoders inaccurate and prone to wheel slip.
If the values are different after a straight line + slight turn, it means the control loop isn't straightening the robot.
As dashwsd pointed out, the Ziegler-Nicholas method is relatively simple method to tune a PID. Bear in mind that each system/envoirment is different, even moving to a different field could require slight re-tuning
2 Likes
I believe they are actually pretty decent…
Linaertica, for this slew control is the most useful thing I know of.
1 Like