If we are going to debate the relative merits and demerits of PID and "fuzzy" - which is by nature defined in a fuzzy way - let's not forget that PID was invented and used to stabilise ships more than 100 years ago, long before the availability of high speed processors. Even today, makers of temperature controllers proudly state that they use PID which is frankly ridiculous. Temperature control is mostly adequately achieved by simply turning the heater (or cooler) fully on or fully off for a set time depending on the temperature error. The measured temperature lag can be observed on the fly so the turn-off time can be accurately determined to have the temperature come to rest at the exact target temperature whilst pwm of the heater can keep it there with minimal error. No doubt, as manufacturers who have until now boasted about PID will start to boast about AI which of course it isn't either, it's just a relatively simple state machine.

PID mathematics really only works for linear systems. Given the speed of modern processors with speeds far higher than the electromechanical bandwidth of systems they are controlling, the combining of PID principals with fuzzy logic, adjusting variables on the fly makes sense to me. In the case of this project, for high speed movements, the weight being held by the gripper needs to be estimated based on angular acceleration of the limbs with a given drive signal, or you just have to go slower to accommodate this unknown.

I would say that proportional-integral-derivative wasn't invented, it was discovered by observing nature. How does the thrown ball know its path? This robot arm should be a simple linear system, as easily controlled by PID as the millions of current other devices using PID. Fuzzy here is a unneeded band-aid to IMO bad physical design.

 

Fuzzy here is a unneeded band-aid to IMO bad physical design.

So PID is not working because IYO bad physical design makes it not amenable to PID control?

 

So PID is not working because IYO bad physical design makes it not amenable to PID control?

It makes it unstable (it moves from non-linear to chaotic where small changes in inputs can have large changes in output almost at random) with any type of control. The first SpaceX Starship rocket RUD is a good example. The control system battled the mechanical faults but it lost.

After several physical design changes, this is flight 3.
https://www.youtube.com/live/isth05TZC2g?feature=shared&t=1092

I'm sure there were small tweaks to the control parameters but SpaceX knows what it takes to control rockets so it's unlikely they changed anything basic in the software platform.

 

Yes, PID can be untunable, IF the elements involved are NOT sized correctly! Been there, done that, got my ass kicked trying. I never worked with motor systems. All of my PID work was with 4-20mA pneumatic controller valve systems and heat/flow control. Valve sizing and/or pipe flow orifice flow limiting was essential before even starting PID controls. 5 element PID control or 5 PID controllers? Hmmmm... Well I'm old and new things come along all the time...

 

Yes, PID can be untunable, IF the elements involved are NOT sized correctly! Been there, done that, got my ass kicked trying. I never worked with motor systems. All of my PID work was with 4-20mA pneumatic controller valve systems and heat/flow control. Valve sizing and/or pipe flow orifice flow limiting was essential before even starting PID controls. 5 element PID control or 5 PID controllers? Hmmmm... Well I'm old and new things come along all the time...

Exactly.
This is what you would normally expect with a detuned PID motor control loop. Easily fixed with PID constants adjustments.

https://github.com/arduinoNube/digital-pid-classroom-demo

The logical alternative to PID is not FL, it's MPC control for things like robot arms they have dynamic movements.
https://en.wikipedia.org/wiki/Model_predictive_control

 

Dear all,

Big thank you for your all suggestions, I truly appreciate!!

From tommorow I will try to apply code ideas as suggested by Jerry and then study how to apply fuzzy logic hinted by Nsaspook, afterwards I will revert to you what I did and the outcomes.

TY
Saviour

 

Dear Jerry and Nsaspook,

Thank you very much your kind help which was very fruitful.

As I promised, I went through to the suggestions of the PID code by Jerry, After I did PID integral windup which I cater for both negative and postive error, then included some deadband and finally I tuned the PI control parameters on the second joint. The result of the error was within boundaries as I was seeking. The outcome can be seen from the demo link and code snippet can be seen below.


https://drive.google.com/file/d/1Qan8OKEFXznlufbMkdTgoc-yn-htLRQY/view?usp=sharing


Monitor_current_value_2=analog_channel_2;

if((Monitor_current_value_2 > prev_ramping_current_w_2))
{ T_difference_2 = (Monitor_current_value_2 - prev_ramping_current_w_2);
T_difference_2 = (T_difference_2 / filter_constant);
W_Iave_2 = (prev_ramping_current_w_2 + T_difference_2);
}
else
{ T_difference_2 = (prev_ramping_current_w_2 - Monitor_current_value_2);
T_difference_2 = (T_difference_2 / filter_constant);
W_Iave_2 = (prev_ramping_current_w_2 - T_difference_2);
}

prev_ramping_current_w_2 = W_Iave_2;
//PID for joint 2
error2=W_Iave_2-Servo_ADC_2;//joint two pid
//error2=analog_channel_2-Servo_ADC_2;
if((error2<-80)||(error2>80))
{
integral2=integral2+error2;//integral windup
}
derivative2=error2-errorBefore2;
errorBefore2=error2;
GAIN2=1000+ Kp2*error2+Kd2*derivative2+Ki2*integral2;//added deadband
GAIN2=abs(GAIN2);
if (GAIN2>4000)GAIN2=4000;




if((error2)>10)
{
if (GAIN2>4000){GAIN2=4000;}
analogWrite(11,0);
analogWrite(12,GAIN2);


}
else if((error2)<-10)
{
if (GAIN2>1700||GAIN2<4000){GAIN2=1700;}

analogWrite(12,0);
analogWrite(11,GAIN2);

}
else if((error2>-10)||(error2<10))
{
analogWrite(11,0);
analogWrite(12,0);
integral2=0;
//GAIN2=0;

}

With the code I added wellford filter, which doesn't work as I want for joint 2, If I increase "filter_constant" the robotic arm move slower but the steady state increase, on the other side when the welford filter is removed the steady state is reduced drastically with swift movement. I am wondering If I remove the welford and increase gruadually the angle with a counter until set point is reached. What do you think?


Saviour

 

Wow, getting there! Looking at the video clip, is the arm jogging up and down just because it's not very rigid? Your links are quite long and whilst your clip shows them extended with a far reach I wonder how the control will respond to having the limbs 'drawn in'? The quickest way to make a movement of the gripper to a new location far away may be best achieved by pulling in the limbs to reduce angular momentum.

How about maximising the gain of the proportional term when the error signal is large and reducing it when the error signal is small?

 

Wow, getting there! Looking at the video clip, is the arm jogging up and down just because it's not very rigid? Your links are quite long and whilst your clip shows them extended with a far reach I wonder how the control will respond to having the limbs 'drawn in'? The quickest way to make a movement of the gripper to a new location far away may be best achieved by pulling in the limbs to reduce angular momentum.

How about maximising the gain of the proportional term when the error signal is large and reducing it when the error signal is small?

I did a quick look at the end-effector movement vs one elbow joint. The entire arm from base to end-effector is unstable.
The video point of view moves so much (IF YOU MAKE MOTION VIDEOS, DON"T MOVE the CAMERA) I can't tell if the table mount is flexing or/and the servo pivots are.