I use rotate for 90 degrees, but it isn’t accurate because it sometimes goes a little long and sometimes a little short. Is there a way to make rotating 90 degrees more accurate?
You can switch to using rotateTo() function for the absolute position, then overshoot errors will not accumulate.
Also, please, refrain from creating multiple topics for the related questions.
I would argue that this is a different topic.
Anyways, why will using rotate to not make there be overshoot errors? lets say instead of 90 degrees it goes 90.5 degrees. resetting and then going again from that position will still be the same error filled as doing rotate for 90 degrees.
best way is to write dedicated code specific to your robot and not use our provided generic algorithm that tries to do a reasonable job with everybody’s robot.
@TryhardProgrammer I am basing my assumptions from your code in the other topic where ou use rotateFor() function to move between 90 deg separated positions.
Please note that V5 motor PID does not stop at exact target location but approximately at the target:
If every time you rotate relative with rotateFor() the errors of just 3 encoder counts could slowly add up to many more encoder counts, depending on your good or bad luck. On the other hand, if you use absolute target and call rotateTo() function, then every time you will stop withing 3 counts of each target position.
I hope this explains why your stopping position error may grow over time.
I still don’t see why using rotateTo and an absolute position will help. Let’s say it is reset to 0 at the current position. When going rotate to, lets say it will go 92 b/c of inaccuracy. If you reset at that position, it is 2 degrees off. If you rotate to 90 from that reset position again and it goes 92, won’t it still build up? Or does rotateTo generally mean more accuracy because it tells it to go to an exact position?
You don’t have to reset encoder counter between each command.
When you first power the motor it will remember zero orientation/heading and all following rotateTo() calls will use absolute target position arguments in relation to the original zero position. Every time it moves you could expect it to stop withing 3 counts from the target.
On the other hand, if you reset encoder between calls or use rotateFor() function that takes target argument relative to the current position, then every time it moves it could accumulate additional +/- 3 encoder counts stopping error.
If errors are equally positive and negative it will average out around zero. But if for some reason they are skewed to one side or there is a long run of positive errors before negative run, then it could randomly walk away from the mean zero error for stopping position.
Ok, thanks for the help. So how would I not reset it? If I do rotateTo 90, then I would need to do rotate to 180. How would I do this? With a variable?
In your original code you keep track of the old color slot and the new target color and then have custom rotateFor() distance for each pair.
If you use rotateTo() function without resetting motor position, then everything becomes much simpler. You only need to pass target position to rotateTo() corresponding to the color of the marble container.