PID Trainer, issue on setup

[drbitboy]

Approximation of the transfer function based on the #18 data:
...

Sweet.

To the naysayers I reply "Living is easy with eyes closed, misunderstanding all you see...." Strawberry Fields Forever, John Lennon

k = 0.53 / 37.1 = 0.014 (in my opinion, quite close to 0.018 calculated in # 68)

Heh; that feels good.

 

[drbitboy]

Tweaked the plot a bit to be more visually similar to, and match the tuning of, @Peter's updated PDF.

There is still a whisker of overshoot; I suspect it is caused by aliasing in the discrete analytical model calculations.

 

[Peter Nachtwey]

The title angle graph had its labels switched around. That is corrected now. I changed the time length of the plot. They should look closer to the same. Look at page 6/6 of my pdf. This shows the response that one would get if the transfer function is converted to the time domain. The over shoot looks worse.

 

[MaxK]

After all, to whom should I sell my soul in exchange for secret knowledge of how the PID block calculates (how to convert the PID block coefficients into kp and kd per second)?

 

[drbitboy]

After all, to whom should I sell my soul in exchange for secret knowledge of how the PID block calculates (how to convert the PID block coefficients into kp and kd per second)?

I don't understand the question. To me it sound like you are asking what calculations a PID instruction makes during each loop update based on CV and PV inputs, along with any tuning and configuration parameters, but that is well-known and available in almost any manual.

Unless you are asking about what Micro800/CCW PID instructions do, which is a bit more complex.

 

[Peter Nachtwey]

After all, to whom should I sell my soul in exchange for secret knowledge of how the PID block calculates (how to convert the PID block coefficients into kp and kd per second)?

I have my Peter Ponders PID YouTube channel.
It is pretty advanced. Most people stop watching after 3 minutes because they don't understand the math but I think you can handle it.
https://www.youtube.com/channel/UCW-m6-nwUfJrnZ0ftoaTU_w
I show all the work. Most if not all is done using the metric system when I use numbers. I derive the formulas for the controller gains symbolically so you can see how each term in the transfer function affects the gains. This provides for better understanding. I never liked using matrices or functions like are in Matlab or Octave because all you get are numbers that don't mean as much as a symbolic solution. Matlab and Octave are great if all you want are the answers but they provide no true understanding. I think it is a crime that Matlab is used to teach in universities.

 

[ndzied1]

I've been watching mostly in popcorn mode (because I don't have time to participate further... which I'd love to do).

But I found these videos interesting...

https://youtu.be/GP7L7wrLOOQ

https://www.reddit.com/r/raspberry_.../?utm_source=share&utm_medium=web2x&context=3

https://youtu.be/wvAPdFuQjow

I almost didn't watch this one past the first few seconds. You should watch this one until the end (at least to 6:00)

https://youtu.be/-h1OtBgMqcE

 

[drbitboy]

I have a few thoughts for @geniusintraining.

Caveat/disclaimer: these are random thoughts and inferences I came up with from looking at the problem, I could be completely off base; it would not be the first time.

• I don't think tuning is the problem, I think system limitations inherent to the design choices are the problem. To wit
• We already mentioned backlash
• That servo looks like an RC analog servo. If so, then it takes a 20Hz (50ms) or 50Hz (20ms) PWM pulse frequency (period).
• Which should be fine, but the PID loop update time is 10ms, so only one of every five, or every other, loop update is going to actually effect a change (although the effect could be cumulative)
• On top of that, an RC analog servo typically works with a duty cycle (ON duration) of between 1% and 2%, or maybe up to 2.5%, of the PWM period.
• The 1400 PWMX.DC (Duty Cycle; cf. here) setting has a range of 0 (0% Duty Cycle i.e. always off) to 1000 (100% Duty Cycle i.e. always on).
• So that 1-2% range will mean the CV output to the PWM.DC control parameter will have a usable range of 10-20 out of 1000, or only 11 discrete values.

Maybe this has already been taken into account, and that is not an RC servo, or there is a 555 timer circuit or Arduino in between the 1400 and the servo to enhance the CV resolution.

Anyway, intuitively these issues make it seem like a fairly unworkable system, at least to me; I think it would be an interesting project or thought experiment to teach people about order-of-magnitude thinking in the design of mechanical and control systems, but I am not so sure it is going to teach anyone about PIDs.

For example, in the Circuit Cellar video that @ndzied1 posted, that ball has low rotational inertia compared to its translational inertia (i.e. mass), and they were moving the surface up to 36 degrees, so not only is anything close to a linear control characteristic a vain hope*, but with that largish range of angles and angle step they also left out a possibly significant centrifugal acceleration term from their model.

Sorry to be so negative, and again, I could be way off base. That said, on a more positive note, the control you have achieved is pretty impressive.

* although that could be handled if there was at least adequate servo resolution and linkage geometry, which there was not

 

[MaxK]

I don't understand the question. To me it sound like...

Unless you are asking about what Micro800/CCW PID instructions do, which is a bit more complex.

Please excuse me. I wasn't specific enough. Of course, I was asking about Micro800/CCW PID instructions.

For the last few days I have been trying to link video #1 (scaled error, control output, Kc Ti), curves #18 and calculations #68. It have no sense.

 

[drbitboy]

For the last few days I have been trying to link video #1 (scaled error, control output, Kc Ti), curves #18 and calculations #68. It have no sense.

We cannot do anything useful with dynamic data from the video, because there is a sampling problem: RSLogix 500 does not update that value at 100Hz (i.e. the PID loop update time), so there is no meaningful correlation between the instantaneously-displayed values.

And there is summat seriously wrong with post #68: it makes no sense at all, those numbers are way out there; I suspect I divided when I should have multiplied, or vice versa.

Maybe if @geniusintraining gives us a PDF of the program and provides some information on the input and output scaling, servo model number and parameters (arm length), etc.

I think what you did in Post #101 is the best we have.

 

[Peter Nachtwey]

I've been watching mostly in popcorn mode (because I don't have time to participate further... which I'd love to do).

But I found these videos interesting...

https://youtu.be/GP7L7wrLOOQ

https://www.reddit.com/r/raspberry_.../?utm_source=share&utm_medium=web2x&context=3

https://youtu.be/wvAPdFuQjow

I almost didn't watch this one past the first few seconds. You should watch this one until the end (at least to 6:00)

https://youtu.be/-h1OtBgMqcE

The real problem is the resolution of the feed back and how consistent the sampling interval is. The ability for the motor to position can be a problem too.
So far we have assumed the motor responds instantly to the tilt error.

In the last video you can see that the motor control was jerky because of the poor resolution which results in noisy speed estimations. This makes the derivative term look "noisy". Also, the ping pong ball has rolling friction.

We have ignored that. Friction makes the ball easier to control. There needs to be a damping term in the closed loop transfer function. So far friction has been ignored so all the damping has been done using the derivative gain but in reality the damping is done by both the mechanical friction and derivative gain. The problem is which damping works best. If the feed back is noisy then mechanical friction is better if the mechanical friction is somewhat linear. That is the friction is proportional to the speed of the rolling ball.

Since we haven't stopped long ago, why not add friction and the response of the motor. Adding in the motor would make this a cascaded loop problem. I can deal with it.

Anyway, I am camping so there is little to do at night. I have some internet so I made a new Mathcad worksheet showing the calculations for using a PID controller and using state space. I show all the work and how the gains are derived but again, I am assuming the motor response is instant and there is no friction.

https://deltamotion.com/peter/Mathcad/Mathcad - RollingTTBall PID.pdf

BTW, yes I am lazy. I don't like having to scroll through pages of posts to find out what was done before. My Mathcad pdfs are self contained. Everything needed is in that one pdf. I don't like transfer functions with a lot of numbers. The numbers do show how the transfer function was derived. Symbolic transfer functions show what terms make up the damping function. In the PD example it is clear that K*Kd*s term provides the damping.

 

[MaxK]

I have a few thoughts for @geniusintraining.

Caveat/disclaimer: ...

I have attached a chart shows disturbance (velocity (Dirac delta) 0.1 m/s ) response with the following parameters:

k (plant) = 4.2 * 0.00086 * 250 / 0.2 = 4.515
kp = 0.14
kd = 0.5

PID Loop Update=0.01s;
servo pulse frequency=20 Hz;
encoder resolution=10^-5 m (2^12 / 0.4);
actuator speed limit=0.005 m/s;
rod play=5*10^-4 m

To make the task more difficult, I eliminated friction

You are right, such a system is very difficult to configure.
There are 2 main restrictions:
1. The limited speed of the actuator is critical in the active phase of the transient, it does not allow aggressive tuning of the PID controller.
2. Backlash in the angle of inclination mechanism. This makes the system (in the absence of friction) unstable in near-zero point. Backlash does not allow to tune the PID-controller "slowly" (small values of kp and cd => small CV => no possibility to overcome the backlash at the near-zero point).

PID Loop Update and servo pulse frequency in the case of a slow actuator do not have a negative effect (the fact that the "old" CV values are received at the input of the 50 ms actuator does not matter, because the actuator has not yet reached the "old" CV values)

 

[drbitboy]

BTW, yes I am lazy. I don't like having to scroll through pages of posts to find out what was done before.

Likewise i.e. I am not interested in what you have to say either .

 

[drbitboy]

You are right, such a system is very difficult to configure.

Actually, @Peter Nachtwey was the first to say this, not me.

 

[drbitboy]

Anyway, I am camping so there is little to do at night. I have some internet so I made a new Mathcad worksheet ...

https://deltamotion.com/peter/Mathcad/Mathcad - RollingTTBall PID.pdf

While you fry your eggs over the fire, minor corrections for page 2:

​

etc. But that changes neither the approach nor the general result.