@3038922 That's the problem here. fabs（idegTarget - angleChange）<= atTargetAngle
So I don't want GYRO to reset to 0 automatically.
I wrote an odometer, which requires high angular accuracy. So wait a little longer before jumping out. I don't like to use autonomous step by step. I hope to use algorithms to let him automatically judge what to do.Especially now we have vision sensors.
I get that. I wasn't saying you should reset it to 0. You're saying you're overshooting. I'm asking about the PID potentially not going letting the robot rotate slowly enough as you reach the target so that the 0.250 s delay between reaching the target and actually exiting the loop results in erasing the exit. If you weren't using fabs(), but instead had two checks, one <= and one >=, depending on which direction the robot is rotating, this wouldn't show up as a possibility. But with fabs()<= it does show up as a possibility.
Essentially, you're guaranteeing that if you've got some sizable value stuck from the integral part of the PID that there is no way the robot will stop rotating. And you're saying it doesn't cease rotating. So this seems to me to be a good place to look.
Have you tried commenting out the "else atTargetTimer.clearHardMark();" part? I would try that and see where the robot stops. This way, even if it overshoots, it should still stop so long as it has spotted a moment when it was within 0.5 degrees of your goal.
Oh, also, that fabs() bit doesn't behave the same around ±180 degrees as everywhere else. You could throw in an if statement so that if you're targeting around ±180 degrees, it's more like fabs(fabs(idegTarget) - fabs(angleChange)). That's because you want it to read -179.9 degrees as 0.1 degrees away from +180 degrees, while right now you're reading it as 359.9 degrees away.