So I have started building my robotic arm, I am using Potentiometer to work out angle, I am trying to get the motors to move to a place and stop but due to force / momentum etc, they always overshoot.
My motors are set up as tmotorServoContinuousRotation, and have the motor controllers fitted (PWM)
Shouldn’t I be able to make them go to a position and stay? I am thinking of the built in program (Controller / joystick connected) where you can proportionally controller the claw on the clawbot?
I’m sure there are others on here that know much more about this than me - but last year, I noticed the same thing. I overcame it by slowing down once I neared the target. So as I got closer and closer to my target, I slowed down. This significantly reduced overshooting.
Thanks for replying, I was planning to do a feedback loop to slow down the power near to the required place but I am sure adding the motor controller to the motor should allow the motor to stay in a position?
Hence why you can do half open claws etc
This is exactly what the control loops are for. PID loops are one of the more useful ones employed in Vex but they can be a bear to tune until you get a few under your belt. The PID loop detects that you are moving away and they increase the hold power to keep you at your target. However it reacts to the movement so sometimes you get a nice little jerk back into place.
PID will slow it down pretty efficiently as you approach the target. You will probably have a little overshoot. Then as you hold, the integral will back off ever so slightly and then once you are below target you start adding to the integral adding power. If not tuned right, these can lead to big oscillations, not small ones. The new RobotC graphing functions should help a lot with this.
Some of my guys teams have tuned different PID’s for getting into and holding different positions. Buttons work great for telling your robot what position you want to put the arm into.
You can try to add a constant of the expected hold power if you wish and then tune the rest of it or you can figure out the hold power you need in various spots and make that into a function too. But start with a PID function and go from there as you need to tune it with additional hold strengths.
Can you post links to some helpful resources on PID loops? Thanks! We didn’t do a flywheel last year so we didn’t go through the joy of learning PID loops.
So I should be looking at PID examples in RobotC?
There are plenty on the forums here and look back at the online challenges as there are good videos in there too. The oldie but goodies is from Free Range Robotics
http://robotics.org.nz/support/programming-guides/159-an-introduction-and-tutorial-for-pid-controllers
This is reference number 2: PID without a PHD. Pay attention to the graphs in here to see what each part does to controlling what you want to happen. This is what PID is all about - get me where I want without too much overshoot and get me there really efficiently.
Some code examples:
https://vexforum.com/t/a-pid-controller-in-robotc/20105/1
https://vexforum.com/t/qcc2-gyro-and-pid-control-code/29292/1
Step 1 - start with just a P controller and graph it, tune it.
Step 2 - try the PID tuning by finding the critical oscillation. Apply the formulas to get close ( may be able to stop here)
Step 3 - play with the limits of capping integral values and tuning for less oscillation
Some other resources:
https://vexforum.com/t/how-to-make-graphs-to-help-tune-pid/27881/1
I put my own pid in but I am probably missing something, I check the error and reduce speed etc, but you get to a point where there is not enough power / momentum to reach the position
The power to reach the position comes from the I when the error is small (correct me if I’m wrong… I’m not very awake right now). That is the accumulation of error. It can get really large, so capping off or resetting it is key to controlling and using it.
If I were you, I would make a P controller since it is very simple. Having a minimum value will allow it to keep moving even when the error is minuscule. The minimum value is the smallest motor input that can move the arm (so maybe 20 or so). You will need to figure that out.
A very good resource on P is http://www.aura.org.nz/archives/1869
You can do the same thing on your drive and it is easier to learn there as the arm wanting to sag down under its own weight makes it tougher. The principles are the same but the effects are shown slightly differently in each case.
The tuning of the parameters is key like the linked attachments from above show. Too big of a value and you overshoot and start oscillating, too small and get what you have which is undershoot.
The problem with a P control on an arm is it does not have a built in hold strength to keep the arm steady. It inherently goes to 0 at the target. This is why it is easier to learn doing the drive as momentum carries you into the target point.
So how can we make the P controller better? The I and the D help do that. The integral helps with that hold strength but boy it can be a pain. We need to limit the contribution of the I part to not get out of control. The “I” will have some residual holding strength applied to the motor as it creeps down from the target value over time. The longer the undershoot, the more power applied to the motor to get you back to 0. The P takes away power as you approach the target as you found out. The D is the “don’t change up so fast buddy” compensation. So the combination of all three is what makes it great.
So how do we find the right values of P I and D constants? The Ziegler Nichols method generally works - where you can have the robot flailing about without breaking that is. What you need to find is the critical oscillation in the P controller with no I or D values so set them to 0. Starting small with P and increasing you will see you pass your target and the P gives motor power to go the other way. It should get smaller and smaller in its oscillations. This is a damped system. Keep adjusting P constant upward until the graph does not settle down. The first value you get like that is the critical proportional value in Ziegler Nichols.
The other part of the measurement is the period of oscillation. Not sure the Robot C graphs can help you with this accurately but it is the time from peak to peak of the oscillations. Plug these two values into the Ziegler Nichols formula and it gives you a P I and D constant set you can plug in.
You then need to decide the max I contribution and cap it. Arms sometimes need a bit more I but 20% -30% of motor range is typical. If you don’t cap it , the I contribution will get all the way past 127 motor values really quickly and your PID will not work well. Too small from the I and you don’t get the benefit in an arm’s hold strength.
Wow, dude you know your stuff, I implemented my own PID I believe, (work out the error) * 0.5 however limit power range from 100 to 20. and after playing about with the maths, it works pretty well
https://youtu.be/pHcUz6lnNs4 (probably the worse explanation)
One thing just to add. This is proportional control. PID stands for
proportion
integral
derivative
Currently you are using only the first part of PID. A P loop (what you have) is definitely enough for a lot of applications just wanted to make sure everyone knew the correct terms.
One of the forum members wrote a guide to PID that I really like, it can be found here. It is a quick read and gives a good intuitive explanation.
http://georgegillard.com/documents/2-introduction-to-pid-controllers
Thanks again, you’re right I thought the kp bit was the I, I will update my code and maybe do a new video.