We have a rotational arm which is working well, but still overshoots its target postion, before correcting and ending up very close to the target.
We are using motion magic on the talon srx.
I’ve noticed this overshoot occurs when the arm is rotating over the top of the robot…in the direction in wish at first the arm is fighting gravity but then gravity is helping get it where it wants to go.
Our D value in the pid is over 10x the P value. I’m not overly well versed in control theory so I’m trying to tune this the right way. Do we continue to tune that value.
When flippjng over to the other side is it possivle our feed forward value isnt strong enough?
Are you using ArmFeedForward, a constant FF value, or something else?
I’d say it’s less likely that your feed forward value isn’t strong enough, and more likely that your feed forward value is the cause. It’s a value added to the output to counter-act gravitational/friction/etc forces. In this case, the act of crossing the vertical plane is changing the direction that gravity is acting on the arm. So a constant FF value would keep it driving and start “helping” gravity instead, thus making the PID (or motion magic) work harder to counter-act it.
Additionally, you likely have some amount of slop in the mechanism (chain/belt/gears aren’t perfect)
A D value that is over 10x the P value doesn’t really mean much, it’s all dependent on your mechanism. Considering that you’re mechanism is flipping over your robot my first question would be whether your feedforward value is static and if so I’d probably account for the variable torque that gravity might have depending on various positions. Either way, it most likely sounds like your PID isn’t perfectly tuned so tweaking that to minimize overshoot would most likely be your best bet.
So I’m using motion magics arbituary feed forward parameter.
But we set it up to be on a cosine function. Right now we calculated the max kf at .2 percent of the motor output
So if thats working correctly, as are arm passes 90 degreess (we have 90 degrees set to be straight up and down), Kf will begin pushing against the arm, especially since itll be -1 when the arm is at 180 degrees. Meaning the kf will be (-1×.2) at 180 degrees, running the motor in reverse whereas on the other side of the robot at the completely horizontal it was (1×.2) running it at 20 percent up!
Hi! I have been using some simple PID control for our mechanisms (arm, Limelight tracking, and auto-balance). We have made our own library for PID (and we’re using it) but simply multiplying the error with a P constant has proven to be a good starting point. I’m not sure what motion magic is (it could be better than what I’m using). For tuning PID, I’ve personally gotten good results following this procedure:
Set P to 0.001 and the rest (I and D) to zero.
Increase P till your arm starts oscillating.
At this point, halve the P value.
Increase I term till offset is corrected.
If needed, increase D term till the arm is fairly fast in reaching the setpoint (but not overshooting).
It goes without saying that too much of P, I, or D will result in a not-so-accurate end point for the arm. If you want to learn more about PID basics, here’s the video that helped understand this. (Part two of PID control is in the same series)
What does the arm do with your 0.2 FF value and all zeroes for other PID constants? If you leave it horizontal, does it maintain position? Drop a bit? Slowly rise? It should be able to maintain position. Increase it until just before it barely starts to move the arm up. Them you can work on P until it starts oscillating. Then work on D.
If FF is tuned right, you PID shouldn’t be doing much work at all.
I think you also need to make sure you understand the difference between kF and AribitraryFeedForward.
In MotionMagic, they are quite different.
kF is supposed to be a calculated approximation of the motor output needed to get to your target. In your case of the Arm, it would be the approximation of the output necessary to meet your MotionMagic velocity constraint.
Your arbitrary feed forward with the arm would be the output of your cosine function (relative gravity to horizontal). So, roughly, MotionMagic output would be something like:
Now, of course there’s also the additional feedback input that will be added, kP and kD will also be added to the total output but for brevity I’m leaving those out.
This is how we typically use MotionMagic, and we have used them for several years now successfully so I hope my understanding is correct.
IMO arbituary feed forwardshould be the solution. I recall the last time i was involved with a motion magic arm we needed to use the cosin of the math.radians(current arm angle). Though this arm did not flip.
I recommend you wright the values your calculating to your dashboard or console if haven’t already to make sure the expected value is equal to actual.
Let’s say you had a target MM velocity of 10000 units per 100ms, and to get your arm spinning that fast you need approximately 50% duty cycle.
You kF calculation would be (.5 * 1023)/10000 = .051
I mean it’s possible your kF could be 1, depends on your mechanism, gear ratios, desired speed, etc. Our kF’s over the years have typically been at least an order of magnitude smaller than 1.
Only thing that is unclear to me is what is the point of being able to set the ‘trapezoid’ style controls as well (peak velocity and peak acceleration)
Basically, the trapezoid profile is just trying to make sure that you have clean acceleration and deceleration as you approach your target.
Smoothing it with s-curve parameters can essentially change the “slope” of the trapezoid edges. By smoothing out the initial acceleration values, you can more properly control the mechanism, which will reduce the amount of feedback compensation you need for your PID. Meaning, you can more or less eliminate the need to have kP or KD if you can get the acceleration and the motion profile in the sweet spot.
