Go Down

Topic: PID rules can be changed! (Read 8090 times) previous topic - next topic

adelphysi

Oct 07, 2017, 08:10 pm Last Edit: Oct 11, 2017, 05:29 pm by adelphysi
hi,

there is some thing exciting i want to share with you .
i have been working on my cuad and i have always wondering why   error = gyrovalue-setpoint

why to add an necessary  term to the PID equation , what i did simply is that i removed all the setpoint values from pid equations  and  i added them to the esc final signal drop calculations ,  the wonder result that i have achieved more stable cuad  and when i searched about my  way of PID i found that all  scientific  referances about this subject i found that (error = gyrovalue-setpoint) is a main truth in designing

, so how my conclusions are correct!?

is what i did  a method of  PID i dont know?

if so why isnt it used in common cuadqopters or balanced systems?

can i have a coversation in this result





jremington

Sorry, but  your post makes no sense. Try using a program to translate from  your native language (or post on a native language forum), and post the well documented code, using code tags.

hammy

#2
Oct 09, 2017, 12:50 pm Last Edit: Oct 09, 2017, 01:07 pm by hammy
I'm not sure what you are saying either , but if I'm right moving the "error" to the position you suggest makes no difference to the PID algorithm - which is a feedback loop.

There is no advantage to moving it as far as I can see. It is the error term that drives the algorithm and having it  where it conventionally is helps with tuning  - error multiplied by "P" can be readily different from the multiplier for say "I" and is more logical.


Background : http://www.ni.com/white-paper/3782/en/

adelphysi

may be i didn't make my self so clear ......

i have been studying cuadqopter issue for a while , motors ESCs  gyro  accelometer and PID.....

i made my first cuadcopter based on Joop Brooking code :

http://www.brokking.net/ymfc-al_main.html


and i have watched many codes of arduino for  building a cuadcopter

and all of them follow the same principles of  PID:

https://en.wikipedia.org/wiki/PID_controller



and that was always:


error = (balance sensor value (gyro ,degree or degree/sec ) - set point ( celebrated RC remote control signal value))


so :

P_controller = p_gain multiplied by error .

and

I_controller  += I_gain * error


and

D_controller = D_gain * (error - previous error)


so i thought that why error =  gyro value- setpoint value ??


this will make things  not accurate when there is a fault
in the control signal  , in addition that this fault will e multiplied by  each gain!


when i removed all set point values from PID equations, and added them to another part of the code

i got  a good result  with a gyro , meanwhile the same result needs to have an accelometer to get the same stabilization and take off !

i hope i made my self clear this time

here is  a  a part of my modified code :

Code: [Select]





 
 
 


  







void pid_cal(){
  //roll cal
 X=(gyro_roll_input)+6.37;//+6.37
 Xp=1*X;//0.8 propotional   roll
 Xi+=X;
 
 if(Xi>400)Xi=200;
 if(Xi<-400)Xi=-200;
 
 Xd=4*(X-Xl); //3derivative roll
  roll_cal =Xp+(0.02*Xi)+Xd;//0.007
 if(roll_cal>200)roll_cal=200;
 if(roll_cal<-200)roll_cal=-200;
  Xl=X ;

  //pitch cal
X=(((gyro_pitch_input)*-1)+0.23)*-1;
 Yp=1*X;  //0.01 propotional   pitch
 Yi+=X  ;  
 if(Yi>200)Yi=200;
 if(Yi<-200)Yi=-200;    
 Yd=4*(X-Yl); //3*derivative pitch

  pitch_cal =Yp+(0.02*Yi)+Yd;//0.007
  
 if(pitch_cal>200)pitch_cal=200;
 if(pitch_cal<-200)pitch_cal=-200;
 Yl=X ;

  
// yaw cal
Z=(gyro_yaw_input*-1)-7.7;//-7.7
Zi+=Z;
Zp=1.5*Z;//1.5 propotional   pitch

 
 yaw_cal =Zp+(0.006*Zi);//0.006
  if(yaw_cal>400)yaw_cal=400;
 if(yaw_cal<-400)yaw_cal=-400;

  
  }


final result in this video :
https://www.facebook.com/electronicsofpalestine/videos/1857989604216498/


bms001

It is not entirely clear in the video, but are you actually controlling the roll/pitch movement of the quadcopter or just the throttle?

I don't know exactly how you have incorporated the setpoint elsewhere, but the PID controller that you have implemented (i.e. without any setpoint) is basically equivalent to setting the setpoint to zero. So it will try and resist changes to the rate of rotation i.e. if it is at 0 degrees roll it will try and stay at 0 degrees roll. If it is at 30 degrees pitch it will try and stay at 30 degrees pitch.

Where have you added the setpoint back in?
I would not expect removing it from the PID calculation would have improved performance unless by luck. I suspect that this will cause you problems later on.

I would suggest posting your whole code. Otherwise it's unlikely anyone can make a particularly informed comment.

adelphysi

in short.....
i dont know what is the problems that will happen later on

just consider the change made by setpoint is achange made by a touch of human hand !

it will turn in  a specific   direction and PID will make it balance again after the setpoint value termenates

to determine where i have add set point value you can look this part off the code

(the forum forbids me to put full code because of max allowed characters 900)

in addition that i dont prefer   to share all the code to public ^_^)





esc_1 =throttle-pitch_control-roll_control +roll_cal+pitch_cal -yaw_cal;  //  throttle+ roll_cal-  pith_cal
esc_2 =throttle+pitch_control-roll_control +roll_cal-pitch_cal+yaw_cal;    //throttle+ roll_cal+  pith_cal
esc_3 =throttle+pitch_control+roll_control -roll_cal-pitch_cal -yaw_cal;    //throttle- roll_cal+  pith_cal
esc_4 =throttle-pitch_control+roll_control -roll_cal+pitch_cal+yaw_cal;    //throttle- roll_cal-  pith_cal
/////////////////////////////////////////////////


roll_control =0;
  if (roll > 1510)roll_control=(roll-1510)/4;
  else if (roll < 1490)roll_control=(roll-1490)/4;
  
pitch_control =0;
   if ( pitch> 1510) pitch_control=( pitch-1510)/5;
  else if ( pitch < 1490) pitch_control=( pitch-1490)/4;
  
yaw_control=0;
if ( yaw> 1512)yaw_control=( yaw-1512)/6;
  else if ( yaw < 1488) yaw_control=(yaw-1488)/6;

;

   myservo1.write(esc_1);
   myservo2.write(esc_2);
   myservo3.write(esc_3);
   myservo4.write(esc_4);

 


and here is another video of the drone:
https://www.youtube.com/watch?v=sfdaV9hYH6s

bms001

it will turn in  a specific   direction and PID will make it balance again after the setpoint value termenates
Based on the partial code you have show so far I can't imagine this (balancing) is the case. You appear to be using gyro readings which measure angular velocity i.e. the rate at which it is turning about an axis, rather than an absolute position (attitude). So the PID will not make it balance - it will make it achieve a particular rate of rotation (this could of course be 0).

As I mentioned previously your PID is basically acting as if the setpoint is zero. And it looks like your control input is acting like a shock to the system, which the PID controller will then try and counteract.

Are you sure that moving the control input to where it is now is really what improved your quadcopter? Could it have been an error in your previous implementation, or un-tuned parameters instead?

I'm sure that you don't want to take a step back after getting it to fly, but if you want better performance  in the future I think it will be a lot easier if you follow a more standard approach.


One general point - if you come onto a forum relating to open source technology, and say you have written your code based on someone else's work that they made available, and then you don't want to share it... well some people might have an issue with that.
Probably the worst thing that will happen is that your code gets criticised which means you learn something and get to improve it.

adelphysi

#7
Oct 11, 2017, 03:50 pm Last Edit: Oct 11, 2017, 04:03 pm by adelphysi
shock.....mmmm

shock means bad result ,right? ok lets say it is a shock , but what is appearing that is a kind of acceptable control .isnt it?

i will not be absolute in my answer , but i have been working on this project for a very long time

and i have made all the guy's models, the one with just a gyro (like mine) cant take off from ground with this stability!

i have tried  and  as the owner of the main code declares  that his is not  an (auto -level )

so he made an other one to achieve  better results which almost like the one i have improved . but he uses accelometer in addition , so i have made all modules and the one with accelometer was the best and what i have improved looked like it, i think all i have done is that i reduced the  the effect  of control random errors by not adding them to PID which depend on gain factor for each orientaion which may rise this kind of control fault value if they were written in PID equations.


lets consider   that i have achieved  the same result with the orginal one with just gyro ,
dont we have to ask   a big quastion about PID standers.

how do you explain the result you see in the previous video?


the guy that wrote the original code  dont show all his work to public , as he says.


and science standers tells us by default that he somehow improved some ones else work

so me or him  didnt invent  Drone !

all of us improve , but i am ready to share to public but arduino forum dosnt allow much characters

i will see where i will put it on the web and after  i will share the link

however i wanted to be sure about my result that they are right before sharing a non-meaningful code (if i am wrong)



bms001

shock means bad result ,right?
No, shock is just some external force upon the system.


ok lets say it is a shock , but what is appearing that is a kind of acceptable control .isnt it?
That really depends what you think is acceptable.

but i have been working on this project for a very long time
Please don't take my comments the wrong way, I am not trying to discourage you!

and i have made all the guy's models, the one with just a gyro (like mine) cant take off from ground with this stability!
It should be able to. The fact that it can't suggests there is some problem elsewhere (e.g. PID parameters). Note that using gyro only is often described as 'rate' or 'acro' (acrobatic) mode, and it will not autolevel or maintain a particular angle (attitude), instead it can maintain a particular rate of rotation. Google it.

i think all i have done is that i reduced the  the effect  of control random errors by not adding them to PID
Can you explain what you mean by a control random error?

lets consider that i have achieved  the same result with the orginal one with just gyro ,
dont we have to ask   a big quastion about PID standers.
how do you explain the result you see in the previous video?
As I mentioned previously your PID is basically acting as if the setpoint is zero. And it looks like your control input is acting like a shock to the system, which the PID controller will then try and counteract.
I have already offered a possible explanation twice (but again, without seeing the full code it is a guess). By removing the setpoint you have implicitly made it zero, so your QC wants the rate of rotation to be zero. Your control input affects the motor speed directly - in many ways it's similar to someone hitting the QC on one side as it will cause some rotation. Because the PID setpoint is zero, the QC will try to resist this rotation to bring the actual rotation back to zero. Again, this is a guess and I'm happy to be proven wrong but without any additional information this is what I suspect is happening, and is not a good control method.

but i am ready to share to public but arduino forum dosnt allow much characters
You can attach it to your post if it's too long to include in the main body.

adelphysi

#9
Oct 11, 2017, 05:24 pm Last Edit: Oct 11, 2017, 05:30 pm by adelphysi
Please don't take my comments the wrong way, I am not trying to discourage you!



i understand that ,but i was trying to answer your question about being sure in all my trials


i consider it acceptable because it stays (stable) in flight that is not a view point


random faults means the bad signal caused by noise and electrical disfunctionality  or human bad interference

and these things happen why to be added to critical PID  as parameters?!


(I have already offered a possible explanation twice (but again, without seeing the full code it is a guess). By removing the setpoint you have implicitly made it zero, so your QC wants the rate of rotation to be zero. Your control input affects the motor speed directly - in many ways it's similar to someone hitting the QC on one side as it will cause some rotation. Because the PID setpoint is zero, the QC will try to resist this rotation to bring the actual rotation back to zero. Again, this is a guess and I'm happy to be proven wrong but without any additional information this is what I suspect is happening, and is not a good control method.)

your conclusion is right about how it works, but i dont know why (it is not a good control method)!


if it is flys well  and stable and works as the one  of (standard PID ), where is the problem?

why to consider  a non-happening problem as it happens !?

and i am going to attach  the code to see it



bms001

i consider it acceptable because it stays (stable) in flight that is not a view point
...
if it is flys well  and stable and works as the one  of (standard PID ), where is the problem?
why to consider  a non-happening problem as it happens !?
If you want to stop there that's up to you and it's great what you've made. But if you want to improve it (and I think you should be able to achieve significant improvement based on the video you showed) then you would almost certainly need to change this approach.
Don't forget that you asked for a discussion!


random faults means the bad signal caused by noise and electrical disfunctionality  or human bad interference
On the subject of non-happening problems...have you observed that any of these are actual problems? It would be simple to put some checks on your radio input to make sure it makes sense, and apply some limits if necessary. You should probably be doing this anyway.
I don't know what human bad interference could possibly be! (Someone steals your transmitter?)

adelphysi

#11
Oct 11, 2017, 06:09 pm Last Edit: Oct 11, 2017, 06:21 pm by adelphysi
hhhh


dont understand my words in a wrong way i meant that it is observable results not expected result ...

so i said ( its not a view point)

it is a nice conversation :)

humman interference it not about stealing loool

it is about tiny bad stick moves   static charges that affect the cheap common transmitters i have watched my transmitter signal  on the oscilloscope  , and there is always noise when touching it  .

.....

`

Southpark

#12
Oct 19, 2017, 08:38 pm Last Edit: Oct 19, 2017, 08:52 pm by Southpark
shock.....mmmm

shock means bad result ,right? ok lets say it is a shock , but what is appearing that is a kind of acceptable
control .isnt it?
PID is one method that allows you to alter the behaviour of an existing closed loop negative feedback system, as we would expect for any controller. If the system without the controller can be characterised (where parameters of the original system can be measured or determined so that a mathematical model of it is able to model the original system's behaviour), then it might be possible to alter the original system's behaviour in a predictable (using a mathematical model) way by adding a PID controller having a given set of P and I and D amplification factors.

But..... for cases where we haven't yet characterised a particular system, people can still add a PID controller to alter the system behaviour......and this particular PID approach will be a trial and error (blind) approach, where we keep blindly tinkering with the P and I  and D amplification factors until we come up with a combination that makes the system behave in the way we want..... more or less.

At the moment, the questions you are asking don't make sense because you're not clearly explaining your ideas with control system diagrams. So show your ideas with control system block diagrams and/or control systems formula, to make your ideas clear and understandable to all.

You mentioned 'more stable' with your particular control 'technique'. Does that mean 'more stable' only because you didn't manage to understand your system well enough to achieve a stable set of PID parameter values?

When presenting and comparing results..... it's necessary to show diagrams, formula used, etc. At the moment, the details you provided are somewhat vague.

Your opening post..... you mentioned  "error = gyrovalue-setpoint". You do understand that the error signal is the output of the 'differencing' (subtracting) device of the closed loop control system right? And the controller...... such as a PID controller .... can be made to operate on the 'error signal'. It is one method of changing the system behaviour.

Southpark

#13
Oct 19, 2017, 09:04 pm Last Edit: Oct 21, 2017, 01:10 am by Southpark
so i thought that why error =  gyro value- setpoint value ??
Because, for a closed loop negative feedback system, the signal at the output of the differencer is called an 'error' signal of some sort. And that 'error' signal is the difference between set point and feedback value.

The software code is attempting to get "approximations" of the derivative of the error signal values and the integral of the error signal values. PID control involves these sorts of terms.

Also, your comment about "error = gyro value - setpoint value" is incorrect when it comes to discussions about conventional feedback system theory.

It's really the other way around.... ie.   error = setpoint minus feedback value.
So..... error = setpoint - gyro value is what you should have written. Not gyro minus setpoint.

I_controller  += I_gain * error
The above could be wrong as well. The integral would be something like: existing accumulated error value PLUS (Kd times an approximate area under the error curve for some relatively small duration of time). So, a crude approximation could be something like:
new accumulated error = current  accumulated error + Kd*(current error * T), with 'T' being a duration of time, such as sampling period.

is what i did  a method of  PID i dont know?
It's probably a case of needing to basically understand what "PID" involves (to begin with), and understand basics of closed loop negative feedback systems and controllers.

adelphysi

 i have seen a lot of talk....

you need to study my code to understand what my questions are about.....

i am not specialized in PID systems ,,,,, and i am not talking about theoretical approach  .... and i am not discussing  ( correct phrases )


i am talking about some thing i change in PID (and it not related to PID standerd systems)

i will call it APC  (AdelPhysi Control )^_^

you are right  i have to go in a scientific research to approve that it is a more balance system or not.....

 
 i will give the control system formula and block diagrams  as soon as possible....

but at the moment the code i published shows the major idea about what i am saying 



 

Go Up