Go Down

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

#### Southpark

#15
##### Oct 23, 2017, 11:10 amLast 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.

#16
##### Oct 25, 2017, 05:35 pm
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 pmLast 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

#18
##### Oct 26, 2017, 11:18 am
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)

output = Pgain *(actual)  - setpoint + Igain*(sum of actual) + Dgain*(change in actual)

(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

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.

#19
##### Oct 27, 2017, 10:13 am
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)

output = Pgain *(actual)  - setpoint + Igain*(sum of actual) + Dgain*(change in actual)

(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

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

#### bms001

#20
##### Oct 27, 2017, 10:56 am
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
No, this is a standard PID controller. It is NOT what you are doing.

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

haven't you seen yet!

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

#22
##### Oct 27, 2017, 03:33 pm
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.

#23
##### Oct 27, 2017, 03:41 pm
over all it still flighs

thanks

#### Southpark

#24
##### Oct 27, 2017, 11:37 pmLast 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.

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

#25
##### Oct 29, 2017, 07:52 pmLast 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 amLast 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.

#27
##### Oct 30, 2017, 02:01 pmLast 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 pmLast 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.