Go Down

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

Southpark

#15
Oct 23, 2017, 11:10 am Last Edit: Oct 24, 2017, 02:03 am by Southpark
My current "guess" at what you did was ----- you set the 'set point' to zero, while somewhere else in your software code, you added your own input value to the 'error' signal (ie. summed your input value with the error signal)..... which would basically be the SAME thing as changing your setpoint. In other words, your system is still a basic PID system. You're still applying a 'set point', or the total equivalent of a set point.


adelphysi

you are fairly right .....


i didnt add the set point to the PID equations  (so set point dosn't exist and equals 0 ,already as you said)

so PIDs are just the mathematical on error which in my case ( gyro signal values only)

and as you mentioned i added the setpoint away from PIDs  somewhere in the code


now how come is this still   the basic  standard PID sys?

standerd PID  takes the difference between the gyro or balance sensor  and the set point AND MULTIPLY IT BY
THE GAIN!  in my case gain involves just with the gyro values . because i saw that there is no need to MULTIPLY
THE GAIN WITH THE SETPOINT ( set point is already  in error value which is the difference between the gyro   and the set point )



summary :

standerd PID  error =the difference between the gyro   and the set point

so   P = GAIN* error
      I =GAIN*   integral of ( error)
      D  = GAIN * deferential of (error)


my PID   error = the gyro values

so   P = GAIN* error
      I =GAIN*   integral of ( error)
      D  = GAIN * deferential of (error)


there is no need to calculate the difference which will be multiplied with gains!

i wish i am understood now!


Southpark

#17
Oct 25, 2017, 09:30 pm Last Edit: Oct 26, 2017, 04:33 am by Southpark
there is no need to calculate the difference which will be multiplied with gains!
It's all about equivalent systems. Your system still involves PID control. It is not new.

See the signal "S" in the two diagrams ..... those signals will be exactly the same (for both diagrams). That signal "S" will be the input to the PID controller. This means..... it looks like the system you ended up is just the usual PID system.

Adding the signal (input) in the way you did is absolutely the same as setting a setpoint. The same.




bms001

Adding the signal (input) in the way you did is absolutely the same as setting a setpoint. The same.
I don't think it is the same.

there is no need to MULTIPLY THE GAIN WITH THE SETPOINT ( set point is already  in error value which is the difference between the gyro and the set point )
This is only true when your setpoint (as determined by your control input) is zero.

Normal PID:
output = Pgain *(actual - setpoint) + Igain*(sum of errors) + Dgain*(change in error)

Your controller:
output = Pgain *(actual)  - setpoint + Igain*(sum of actual) + Dgain*(change in actual)
(here 'actual' will be your gyro reading)

(I believe normally it would be written as setpoint-actual but it doesn't matter too much)

Ignore I and D for now, and consider the following scenarios:
A) Pgain = 2, actual = 10, setpoint = 0
normal PID output = 2 * (10 - 0) = 20
your controller output = (2 * 10) - 0 = 20

Now the setpoint is not zero
B) Pgain = 2, actual = 0, setpoint = 30
normal PID output = 2 * (0 - 30) = -60
your controller output = (2 * 0) - 30 = -30

C) Pgain = 2, actual = 0, setpoint = 50
normal PID output = 2 * (0 - 50) = -100
your controller output = (2 * 0) - 30 = -30

I hope you can see that your controller is unaffected by the Pgain and therefore the response is not proportional to the error (difference between setpoint and actual) which is the point of a P controller.

Now see this scenario:
D) Pgain = 2, actual = 20, setpoint = 20
normal PID output = 2 * (20 - 20) = 0
your controller output = (2 * 20) - 20 = 20

In this case you are exactly where you want to be, so there should be no output, but your controller is still trying to correct the motors!
(If Pgain = 1 then you won't see this)


Now consider the I term:
E) actual = 20, setpoint = 20
normal PID error to add to I term: 0
your controller error to add to I term: 20

The error will be zero, but your Iterm will keep growing and affecting the output when you don't want it to.


What you are doing does not make sense. The issues with it are somewhat masked (I assume) by having a Pgain of 1, and mostly wanting a setpoint of zero.

adelphysi

I don't think it is the same.
This is only true when your setpoint (as determined by your control input) is zero.

Normal PID:
output = Pgain *(actual - setpoint) + Igain*(sum of errors) + Dgain*(change in error)

Your controller:
output = Pgain *(actual)  - setpoint + Igain*(sum of actual) + Dgain*(change in actual)
(here 'actual' will be your gyro reading)

(I believe normally it would be written as setpoint-actual but it doesn't matter too much)

Ignore I and D for now, and consider the following scenarios:
A) Pgain = 2, actual = 10, setpoint = 0
normal PID output = 2 * (10 - 0) = 20
your controller output = (2 * 10) - 0 = 20

Now the setpoint is not zero
B) Pgain = 2, actual = 0, setpoint = 30
normal PID output = 2 * (0 - 30) = -60
your controller output = (2 * 0) - 30 = -30

C) Pgain = 2, actual = 0, setpoint = 50
normal PID output = 2 * (0 - 50) = -100
your controller output = (2 * 0) - 30 = -30

I hope you can see that your controller is unaffected by the Pgain and therefore the response is not proportional to the error (difference between setpoint and actual) which is the point of a P controller.

Now see this scenario:
D) Pgain = 2, actual = 20, setpoint = 20
normal PID output = 2 * (20 - 20) = 0
your controller output = (2 * 20) - 20 = 20

In this case you are exactly where you want to be, so there should be no output, but your controller is still trying to correct the motors!
(If Pgain = 1 then you won't see this)


Now consider the I term:
E) actual = 20, setpoint = 20
normal PID error to add to I term: 0
your controller error to add to I term: 20

The error will be zero, but your Iterm will keep growing and affecting the output when you don't want it to.


What you are doing does not make sense. The issues with it are somewhat masked (I assume) by having a Pgain of 1, and mostly wanting a setpoint of zero.

a big mistake to consider  P gain of mine equals the same gain of standerd PID sys ! you cant just  erase the setpoint  from the standerd  PID and multiply it with the same gain! and wait to see results  !

that makes no sense ,

have you learned the code i have published ?

the minus values may not be always as you mention , reading the code deeply will help

comparing it to controller  code on this site will be easier to understand

http://www.brokking.net/ymfc-3d_v2_downloads.html


bms001

a big mistake to consider  P gain of mine equals the same gain of standerd PID sys ! you cant just  erase the setpoint  from the standerd  PID and multiply it with the same gain! and wait to see results  !
I am not saying that it is the same - I am trying to describe to you how it will behave.
I am specifically pointing out that it acts differently, and in a way that is far from desirable (unless you have very odd ideas about what kind of control you want).
[/quote]

have you learned the code i have published ?
What code? The only 'complete' code I've seen is from your other post and contains errors that would prevent the QC from ever getting into the air like sending two of the motors a zero microsecond pulse. So it is clearly not your current code.

the minus values may not be always as you mention , reading the code deeply will help
Ok, can you explain what they will be and not just make a vague statement? I think you need to understand your code. So far it seems you are just making guesses and assumptions, unless you are not telling us everything here.

comparing it to controller  code on this site will be easier to understand
http://www.brokking.net/ymfc-3d_v2_downloads.html
No, this is a standard PID controller. It is NOT what you are doing.

adelphysi

#21
Oct 27, 2017, 02:23 pm Last Edit: Oct 27, 2017, 02:28 pm by adelphysi
i mean the code i have attached ! :smiley-confuse:

haven't you seen yet! :o


i understand my code my friend but i am having trubble to let some people understand what i have  done

but unfortunately  it seems there are some people who don't  bother  to  focus

and they keep guessing

i have explained much !

and i have attached the code so now its easy to be understood

i have so far taken a veiw point that what i have done is the same standerd PID sys

some one is talking about that  ,it means  that he has understood it


all i have to say is that you have to study my code and joop brooking code to understand what i have done

that will reduce arguments






bms001

Well there is always the possibility that I am wrong. But I think that I have explained why I think the way that I do in detail and with examples.
So I would have thought that you could take those examples and explain where and why they are incorrect. But so far, I do not understand your explanations and I would suggest are not very clear.

Anyway, good luck with your project.

adelphysi

over all it still flighs :)


thanks

Southpark

#24
Oct 27, 2017, 11:37 pm Last Edit: Oct 28, 2017, 01:20 am by Southpark
i have been working on my cuad and i have always wondering why   error = gyrovalue-setpoint
It is good that your quadcopter flies. Although, keep in mind that when you ask this particular question "why is error = gyrovalue-setpoint?", it immediately shows that you haven't properly studied enough automatic control text books. In unity gain negative feedback systems, the 'error' is difference between 'setpoint' and 'output', which means error = setpoint MINUS output. So, for a start, you should have written 'setpoint - gyrovalue'. Let's assume what you mean by 'gyrovalue'. I will assume it means a reading from the gyroscope that is measuring a CHANGE in angle over some given duration of time.

So....what you need to do is to show some kind of basic system diagram to convey to everybody here --- where you introduced your control signal? Show exactly where in the system diagram the input control signal is being fed (inserted). Don't get people to decipher your software code.....that's just time wasting. What you need to do is to show your method by means of some basic control system block diagram - which allows everyone to see where you apply your control input. And the diagram should show what signals are operated on (by your P and I and D components). Or, if the PID block operates on one particular (error) signal only....then just show it. The point is ..... show your method clearly ---- and clearly does not mean someone needs to decipher or reverse-engineer or read through your computer code. Your block diagram should also show what measurement devices are used (eg. gyro only, or gyro and accelerometer, etc.). An alternative to system diagram is to explain very concisely your processing method --- eg. setting the set point to zero, subtracting this zero setpoint with the output (eg. an angle for pitch, or roll etc), and adding a control input at (where-ever you add it), and proceed to explain where (and TO what) you apply your P plus I plus D. Right now, having incomplete code and unclear/incomplete pieces of information means unable to have some kind of logical discussion.

Happy and safe flying. All the best with your project.

adelphysi

#25
Oct 29, 2017, 07:52 pm Last Edit: Oct 29, 2017, 09:01 pm by adelphysi
in my code   error = gyrovalue-setpoint  , may be you are right but  i thought i will meet specialized people who can get the point just like to look at the CODES


however  , my friend in the code there is no difference  
eg.
3-2 = 1

2-3 = -1 just multiply it by -1 and you will get the desired  value

i dont get  to be restricted with  what people consider  as principles ( or correct phrases )  and all the issue of this post  is about (change ) as i got satisfying results at the end......



again  i thought just looking at the code for any expert than me will help , yes gyrovalue is the change of angle and  that is a basic work of gyro  does it give any thing else , i mean the gyro ??  it gives basically degrees/sec


i just mentioned gyro signals this means no accelometer or any  else sensor was used .....

here is the block diagram





i don't know if i make it clear , i hope

the picture may help

Southpark

#26
Oct 30, 2017, 06:52 am Last Edit: Oct 30, 2017, 09:14 am by Southpark
Your diagram is unclear and does not convey your system properly. You have a node that is labelled 'cal' and you have 'setpoint' connected to it. You may need to brush up on block diagram drawing first. Also....your gyro-only system won't self-stabilise. That's what happens when you use gyro alone.

If you draw an incomplete diagram like the one shown (which is your diagram that I have loaded for you here), that shows unconventional symbolism that nobody can interpret (except maybe yourself), then it's impossible for anybody to have a proper conversation on this topic.



Step #1 is to draw an adequately detailed closed loop system diagram (of your system).]

Try to convey your method clearly. Avoid presenting something vague - that people cannot interpret properly.

again i thought just looking at the code for any expert than me will help , yes gyrovalue is the change of angle and  that is a basic work of gyro  does it give any thing else , i mean the gyro ??  it gives basically degrees/sec
It's not the job of experts here to decipher your code for you. If you have something to new to share, then convey it in a normal way ..... not in a code that somebody needs to reverse engineer for you. Also, when you mean 'will help'.....does that mean to help you? Also note that our UAVs are very stable with PID controllers. Mine (just like a lot of UAVs being used these days) employ accelerometers and gyros ...... to get best of both worlds.

adelphysi

#27
Oct 30, 2017, 02:01 pm Last Edit: Oct 30, 2017, 02:07 pm by adelphysi
my friend  USING only gyro WILL stabilize the drone , that's my experience with this project!......

unfortunately  that's the best i can do to show my work ......


thank you for your  kind participation ......

Southpark

#28
Oct 30, 2017, 09:18 pm Last Edit: Oct 30, 2017, 10:31 pm by Southpark
my friend  USING only gyro WILL stabilize the drone , that's my experience with this project!......

unfortunately  that's the best i can do to show my work ......


thank you for your  kind participation ......
You will need to learn about the limitations of gyros. Using gyro-only will NOT allow a system to be developed that will self-stabilise your UAV (ie. keep level). A gyro used for angle measurements does not have any fixed angle reference to work with. That's the reason for including accelerometers or some kind of device to get a fixed angle reference - so that the system can automatically level itself (indefinitely) when you take your hands away from the joystick.




adelphysi

that's right using accelometer will make it auto level .......


but  i found that its stabilized while flying ..... so for that i said gyro stabilizes the drone.....

Go Up