So the program is already written however when it performs a turn it goes over the value that it was given by about a few degrees. How would i make it turn exactly to a 90 degree angle?
Thank you!
I am assuming your code turns until it reaches the target angle and then shuts the motors off. You are overshooting because the robot has momentum and continues to spin after the motors stop receiving power. To make it turn to an exact angle, you need a PID controller, which slow the robot down as it reaches its target angle. They can get fairly complex to tune optimally, but the concept isn’t that hard to understand. Here are a few resources to get you started:
http://m.eet.com/media/1112634/f-wescot.pdf
http://wpilib.screenstepslive.com/s/4485/m/13810/l/241879-operating-the-robot-with-feedback-from-sensors-pid-control
Have any teams created a very accurate rotate to angle algorithm?
We have gotten gradually better as a team over the past 3 years, but have not really reached the level we felt should be attainable. Perhaps with the new roboRIO we can finally realize something better, but I’m unsure.
I can share our experience.
Rebound Rumble-- we wanted to capture the backboard location, calculate an angle to turn, and then rotate to that angle. Drive train was chain driven 6 wheel drop center. Slop in chains would mean that when we sensed correct angle and stopped motors that robot could drive a half a degree or more further, causing the pid to come on again and try to correct. This lead to oscillations. We could add very small I so that the P portion could get us close and then after ~1s the I would build up and it would creep to the correct angle, but this was not a fast rotate. Our hope was to say rotate to 10 degrees and be there in a matter of 1-2s. Our best attempt took 5-8s to achieve the target angle +/- 0.5 degrees iirc.
Ultimate Ascent-- we did not need rotate to angle, but we tried it anyway. This year we had belt driven 4 wheel drive with omnis on front. With no slop in the chain we were able to do much better. However, optimal PID values for rotating 10 degrees were different than optimal PID values for rotating 30 degrees. We though of writing code that would check distance and use PID based on current error, but still became problematic because PID required to move 30 degrees from stopped position was still different than if we saw we were < 30 degrees after starting 90 degrees away and passing within 30. Since we did not need it, we did not pursue it.
However, that we had good success using a PID loop to drive along a gyro vector. So we could request to drive straight along 90 degrees. In this case we had tank drive and we would reset gyro (zero our straight ahead position) and then tell the pid to drive forward at some speed along 90 degrees. So if we wanted to drive at 0.4 speed at 90 degrees and we were 90 degrees off, we would do something like set both right and left of tank drive to 0.4 and then based on output value from PID, adjust left up by output and right down by output. So we would end up rotating mostly in place until we had rotated close to 90 degrees. Then we would keep both wheels going at 0.4 and delta them right/left based on error from 90 degree reading. This let us drive forward for 12s and then drive to -90 for 4s and it would do a fairly good job of doing what we wanted without the need for a 90 degree turn. It was not incredibly precise, but we could drive a box around the pyramid at a reasonable velocity and not hit it.
We also incorporated vision that year as we were a low-goal dumping robot. We used our ability to drive to a gyro heading coupled with camera data that kept adjusting the gyro setpoint we were aiming for. So we could set the robot at any angle as long as low goal could be seen by camera. It would automatically adjust and drive toward it. If the goal moved right on the camera, we’d calculate the new center and new required gyro heading and adjust the setpoint to drive along so that the target would come back to center on the camera. It worked quite well.
Last year we put encoders on the drive train and used rate PID to control speed. This is powerful because if you are 3 degrees away from where you wanted to be, and your PID said the output should be 0.1, we could send 0.1 (10% full speed rotation). Sending 0.1 %dbus to a motor can’t even overcome friction-- so you need to apply at least 0.5 perhaps to get any motion in %dbus, but then you get going so fast so quick that you can’t stop quickly enough before you’re past your 3 degree rotation goal. But on rate pid, you can specify 10% full speed rotation and it will apply full power to motors until encoders say it’s beginning to move and as soon as it detects too fast it will slow motors down thus being able to actually move at 10% full speed even though motors are constantly adjusting up and down to keep it at that rate.
With this added level of control we were able to do rotate to angle with good precision much faster than we had in prior years. However, it was still not ultra fast. But we had no cause for rotate-to-angle last year either so we did not try much harder than a couple hours to see what might be possible with the encoder based drivetrain. But one PID setting was able to turn larger distances and smaller distances alike. It just could not do so too fast or it would still overshoot from momentum of 120 lbs rotating. We had to go slow enough to control the stop, but we could reliably arrive at the mark anywhere from 90 degrees to 10 degrees in only 1-5s (I’m going of memory and may be overstating it). Effectively you are running 2 PIDS on the same drivetrain-- one to control how fast the wheels turn and another to control how fast the motors go in order to achieve that requested rotation speed. It worked reasonably well and we were able to use a distance pid to drive forward reasonably fast and then stop when we had traveled 130 inches +/ 6". I think we would have had to drive much slower to get within 6" with simple %dbus control.
Have any teams achieved outstanding success with rotate to angle concept?
That is high precision and do it fast? If so what techniques are important?
In theory a human driver can often twitch the joystick just enough to come remarkably close, so in theory a roboRIO ought to be able to do the same with higher precision. We floated the idea that perhaps what one needs to do is capture the acceleration and breaking curves that are required to ‘stop on a dime’ from various speeds over various distances. Then run an algorithm that says-- I need to stop in 8 degrees, so I should be going xxx angles per second at this moment to accomplish that according to our stopping curves. Next iteration it says I need to stop in 7.85 degrees so I should be going xxx angles per second. Then constantly change the rate PID set point to request the calculated angle per second required. Effectively causing the robot to follow the ideal stopping profile for the current rate and the distance to target. We never tried to code it up though.
At first, I was thinking about compensating for the error of the angle ; however it doesn’t work out so well because it can fluctuate or have a consistent angle each time. I would attempt to use PID however I’m not familiar with it, is there a quick way to get a fast understanding of it since we only have so little time left for build season.
If you take a little time to read about the math and concepts behind it, it isn’t that difficult to understand.
These resources might help:
http://www.csimn.com/CSI_pages/PIDforDummies.html
https://en.wikipedia.org/wiki/PID_controller (it’s Wikipedia, so its a little wordy, but it has some good information)
http://wpilib.screenstepslive.com/s/4485/m/13810/l/241879-operating-the-robot-with-feedback-from-sensors-pid-control
Ok Thanks, I would look into it!