V2.2 - ACRO PID implementation is wrong, right?

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by nhadrian »

copterrichie wrote:I think the main issue with the current MWC is the YAW does not hold as liked by many however, for me, it is working fairly well when the YAW PID are set correctly for the given build. I have never, repeat, never been able to use the Default settings especially the YAW. FYI, In my opinion, PID Settings are as unique as each person and build.


Yes, I didn't talk about PID settings itself. I'm talking about the risk of having serious BUGs in the modified calculation method itself.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »

I know and understood that, just stating my perspective.

Phil S.
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Phil S. »

nhadrian wrote:What was the main problem of the previous PID implementation??? Can anybody tell me?

From a pilot´s point of view basic control was poor easily outclassed by simple 15.- $ FCs. IMO yaw rates were ridiculous and reducing PID Gains a questionable way to increase agility while sacrificing stabilitiy when it is particularly needed.

I am no programmer at all but I cannot imagine how cascaded loops should be able to control e.g. altitude or position properly when a skilled pilot isn´t able to fly without constantly being scared to loose control, expecting the FC to do do something unexpected.

Ardupilot is miles away in terms of autonomous functions so why not concentrate on basic things, make them rock solid to build upon?

chris_kmn
Posts: 31
Joined: Sun Jun 09, 2013 11:11 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by chris_kmn »

Sorry to say that, but I feel that the current state of MWI would need other improovements better than changing PID or IMU, the "base"!!!!!


I am very glad that people commit their improvements to this community. What is wrong in evolving something ? The response in this thread shows, that it seems to make sense to work on PID implementation. I personally see a great improvement in flight performance. And I'm not talking about hovering. I did a lot of flips and loop and all that in gusty winds. AND there is still the choice of using the oldshool implementation. This is what MultiWii is all about. Having the choice to adopt it to your personal needs and hardware.

If you want other improvements, feel free to commit them and listen to the feedback as Hamburger did in this case. I see it as an success how fast this idea came to a working solution. That is a great job !!!

Phil S.
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Phil S. »

nhadrian wrote:I'm talking about the risk of having serious BUGs in the modified calculation method itself.

You always have to take risks trying something new but in this particular case it is very worth doing it!

After the upgrade I made some pretty cautious first attempts but confidence grew quickly and after a few minutes I banged sticks to the limitis like I did never before with my poor Gaui! Full throttle to the limits of visibility, kinds of funnels, huge loops to flips on the spot, Immelmann, Split S, Cuban Eight, not everything clean because rolls always tend to be barrels but recognisable, even something like Rainbows but ending with flips instead of proceeding inverted, it is still fixed pitch! There is no tendency to pitch up at high speed and in fast vertical descends into its own downwash the copter remains perfectly controllable. Briefly said, how could it be better?

So I am quite confident that as long as x configured quads in the size of a Gaui 500X are concerned (did not try anything else) no GPS and/or Baro controlled manoeuvre should be harsh enough to reveal unexpected reactions of the central PID loops of this MW modification. As Chris just said Alex obviously did a really good job!

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »

A video would be very helpful.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »



Example: mwc hexa - flyduspider aerobatics

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Hamburger »

anyone willing to do further maintenance / improvement of current alexK pid controller?
At the least, post a screenshot of your pid settings, so what works in most cases as good starting point could be found. For as many copters as possible it would need to suffice conditions
- already flyable for almost all copters (small, large, #motors etc.)
- performance is reasonably well (already shows typical characteristics in flight behaviour),
- individual improvement in getting closer to optimum (?) is straight forward from starting point

Phil S.
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Phil S. »

copterrichie wrote:A video would be very helpful.

Thank you for yours! That´s the typical climb-flip-hover acro style not beeing afflicted with speed induced pitch up or imprecise yaw stop or blending out PIDs. Try to maintain speed after a loop or through a roll or in Speedcircles or fly kind of Walls or sharp turns from high speed to hover then you know what I´m talking about.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »

Let your video speak for itself please.

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Mis »

Hamburger:
Checking for "defined SERVO" for exclude yaw constrain is bad idea. The SERVO is defined on any copter with gimbal or CamTrig enabled.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by timecop »

nhadrian wrote:Yes, I didn't talk about PID settings itself. I'm talking about the risk of having serious BUGs in the modified calculation method itself.


move to a 32bit system and do all PID calculation in floats or int32, problem solved.
this bullshit of counting cycles and bitshifts making code unreadable just to fit into tarduino328 is getting tiring.
worst example of this is in current pid where it does if (someshit < 640) { do int16 } else { do int32 }. Horrible waste.

Phil S.
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Phil S. »

copterrichie wrote:Let your video speak for itself please.

I will try to find a camera, a camera man and someone spending hours on cutting and uploading to convince you that I´m not talking trash.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by timecop »

Phil S. wrote:
copterrichie wrote:Let your video speak for itself please.

I will try to find a camera, a camera man and someone spending hours on cutting and uploading to convince you that I´m not talking trash.


I prefer just talking trash, its so much easier.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »

Phil S. wrote:
copterrichie wrote:Let your video speak for itself please.

I will try to find a camera, a camera man and someone spending hours on cutting and uploading to convince you that I´m not talking trash.


It is not that I do not believe it, just that I enjoy analyzing video. there is sooooo much information in a video and not just the imaginary but the sound as well.

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by felixrising »

Well, apart from this correct PID control loop implementation by alex.khoroshko, it's worth pointing out that this isn't the first time a reworked PID Control loop has been implemented in MultiWii: https://code.google.com/p/multiwii/sour ... i_gke_Lite

Anyway, let the testing continue. As Hamburger requested: post your flying brick specifications and PID values so some normalised defaults can be adopted.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »

felixrising wrote:Well, apart from this correct PID control loop implementation by alex.khoroshko, it's worth pointing out that this isn't the first time a reworked PID Control loop has been implemented in MultiWii: https://code.google.com/p/multiwii/sour ... i_gke_Lite


It is SAD things like this gets buried because Gke knows his stuff.

chris_kmn
Posts: 31
Joined: Sun Jun 09, 2013 11:11 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by chris_kmn »

one question:

Oldschool:

Code: Select all

 axisPID[axis] =  PTerm + ITerm - DTerm;


AlexK:

Code: Select all

    axisPID[axis] =  PTerm + ITerm + DTerm;


Mistake ?

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Hamburger »

chris_kmn wrote:one question:...Mistake ?

Interesting. That is going to show us if any of the followers will step up and maintain that code.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Crashpilot1000 »

chris_kmn wrote:one question:

Oldschool:

Code: Select all

 axisPID[axis] =  PTerm + ITerm - DTerm;


AlexK:

Code: Select all

    axisPID[axis] =  PTerm + ITerm + DTerm;


Mistake ?


No, it is OK this way

The D of the original Controller is based on this:
delta = gyroData[axis] - lastGyro[axis];

The D of the other Controller boils down to this:
delta = - gyroData[axis] - lastGyro[axis];

But there is always one way to find out: Change the sign and test it :)


@copterrichie: How is the flightexperience of the GKE approach compared to the original or the altered one we are discussing here? (I just ask because i have no flight ready mwii anymore at play to check it out quickly)

Another note to the alex.khoroshko controller (if i get it right):
Angle mode takes (besides the acro controller) just the level P into account.
Horizon mode takes (besides the acro controller) just the level I into account.
Shouldn't we re-introduce the Level D as constrain, like in the "original" controller? As i remember right it was introduced to dampen the "wobble of death".

Cheers
Rob

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »

Crashpilot1000 wrote:
@copterrichie: How is the flightexperience of the GKE approach compared to the original or the altered one we are discussing here? (I just ask because i have no flight ready mwii anymore at play to check it out quickly)


My understanding is, GKE authored the UAVX firmware and is a professor at a school in Australia

Here is his thread on RCG: http://www.rcgroups.com/forums/showthread.php?t=1093510

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Crashpilot1000 »

copterrichie wrote:
Crashpilot1000 wrote:
@copterrichie: How is the flightexperience of the GKE approach compared to the original or the altered one we are discussing here? (I just ask because i have no flight ready mwii anymore at play to check it out quickly)


My understanding is, GKE authored the UAVX firmware and is a professor at a school in Australia

Here is his thread on RCG: http://www.rcgroups.com/forums/showthread.php?t=1093510


Thank you very much for the link! I can't find the original ARM F4 sourcecode on his site: http://code.google.com/p/uavp-mods/ just compiled hex files. Perhaps he fears someone bitching about his codingstyle :) :) .

Shogun
Posts: 13
Joined: Thu Sep 06, 2012 9:14 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Shogun »

Crashpilot1000 wrote:...
The D of the original Controller is based on this:
delta = gyroData[axis] - lastGyro[axis];

The D of the other Controller boils down to this:
delta = - gyroData[axis] - lastGyro[axis];
...

Just a typo here in the text? I did not check the coding.
Unary- has higher precedence than arithmetics, correct should be:
delta = -(gyroData[axis] - lastGyro[axis]);
or
delta = - gyroData[axis] + lastGyro[axis];

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Crashpilot1000 »

Yes, actually it wasn't meant as real C code respecting "unary". So not a typo but not thought through.
Well, look at the code and shuffle around the signs yourself as well and you will see that "+D" in the final equation is correct.

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by felixrising »

Crashpilot1000 wrote:
copterrichie wrote:
Crashpilot1000 wrote:
@copterrichie: How is the flightexperience of the GKE approach compared to the original or the altered one we are discussing here? (I just ask because i have no flight ready mwii anymore at play to check it out quickly)


My understanding is, GKE authored the UAVX firmware and is a professor at a school in Australia

Here is his thread on RCG: http://www.rcgroups.com/forums/showthread.php?t=1093510


Thank you very much for the link! I can't find the original ARM F4 sourcecode on his site: http://code.google.com/p/uavp-mods/ just compiled hex files. Perhaps he fears someone bitching about his codingstyle :) :) .


;) I don't think he's that secretive about it.. https://code.google.com/p/multiwii/sour ... i_gke_Lite

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Crashpilot1000 »

Well, actually i am not really interested in that 8Bit stuff. I am interested in his GPS / INS fusion part. And that seems undisclosed. There are some "opensource" projects online that are suddenly obscured when you get to the interesting part. Or they try to hide it by digging it deep into some "tree".

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »

Crashpilot1000 wrote:Well, actually i am not really interested in that 8Bit stuff. I am interested in his GPS / INS fusion part. And that seems undisclosed. There are some "opensource" projects online that are suddenly obscured when you get to the interesting part. Or they try to hide it by digging it deep into some "tree".


Seems to me, the logical thing to do is to talk directly with him, we never know what can happen by being direct and open. ;)

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by -ralf- »

Another note to the alex.khoroshko controller (if i get it right):
Angle mode takes (besides the acro controller) just the level P into account.
Horizon mode takes (besides the acro controller) just the level I into account.
Shouldn't we re-introduce the Level D as constrain, like in the "original" controller? As i remember right it was introduced to dampen the "wobble of death".

Cheers
Rob


No, AlexK only used P for Level and Horizon, and Level_I in the GUI is really Horizon_P.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Crashpilot1000 »

Yes, that is exactly what i actually meant. The Level P value for Angle and the Level I value for Horizon (I should have written: interpreted as "P").
That is something like the KK2.0 boards do when level - i think.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by brm »

Crashpilot1000 wrote:Well, actually i am not really interested in that 8Bit stuff. I am interested in his GPS / INS fusion part. And that seems undisclosed. There are some "opensource" projects online that are suddenly obscured when you get to the interesting part. Or they try to hide it by digging it deep into some "tree".


the implementation would remain the same.
the f4 source is kept as a secret.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »

brm wrote:
Crashpilot1000 wrote:Well, actually i am not really interested in that 8Bit stuff. I am interested in his GPS / INS fusion part. And that seems undisclosed. There are some "opensource" projects online that are suddenly obscured when you get to the interesting part. Or they try to hide it by digging it deep into some "tree".


the implementation would remain the same.
the f4 source is kept as a secret.


here is a thread started by Gke on the topic: viewtopic.php?f=23&t=2831

alex.khoroshko
Posts: 27
Joined: Sun Jun 09, 2013 9:17 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by alex.khoroshko »

Hello, I've just received the PM telling that my offer on PID is included into the code. Now I feel bad, that I left so early - sorry to all! I would look though the code, test, and then we can continue on fine tuning it. Are there current unsolved issues with it?

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »

alex.khoroshko wrote:Hello, I've just received the PM telling that my offer on PID is included into the code. Now I feel bad, that I left so early - sorry to all! I would look though the code, test, and then we can continue on fine tuning it. Are there current unsolved issues with it?


Yea, around here, one has to have balls of steal and the temperament of a Goat. LOL

Welcome back. ;)

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Hamburger »

alex.khoroshko wrote:Hello, I've just received the PM telling that my offer on PID is included into the code. Now I feel bad, that I left so early - sorry to all! I would look though the code, test, and then we can continue on fine tuning it. Are there current unsolved issues with it?

Yes.
We /YOU / someone has to provide good dwfault values which
* are good starting point for indiv8dual tuning
* work for almost all coptertypes in different sizes

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by alll »

IMO it would be better to have "safe" default values (that will never overshoot on any machine). As no copter is the same, and people pretending they use default values are lucky if it works or are not aware it could be 100x better with the right values for a given copter.
manu
PS:could we have the "more/less" (0-100%) PID values implemented, this will so much clearer. :|

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by -ralf- »

alll wrote:PS:could we have the "more/less" (0-100%) PID values implemented, this will so much clearer. :|

+1

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Crashpilot1000 »

@copterrichie: Thanks for the link, that was an interesting link. Esp. the person that warned gke about the rude manners and aggression here. Yes this forum has quiet frequently narrow minded "bad karma" at play but on the other hand there are nice and helpful persons as well.

@alex.khoroshko: I am very glad to hear that you made up your mind and rejoined the discussion. Your input as a "person in the know" is always very appreciated. Finding correct "average joe copter" values may not be easy but i wouldn't bother about that too much as long as the "dimensions" are right and not off by x1000 :) .

The 0-100% Pid is basically a good idea but since both pid controllers have different behaviour and interprete some values differently it will be not an easy task.
I also thought that stockpids of all zero could be also an idea - that would force people to read and understand the PID controls. That idea is probably very unpopular.

Cheers Rob

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Hamburger »

alll wrote:PS:could we have the "more/less" (0-100%) PID values implemented, this will so much clearer. :|

no difference at all. Both ranges [0;100] and [0;255] (or [0;0.255]) are of the same category - numbers with no resemblance to real world. One is not in any way better than the other - in both cases users have to learn the impact of changing that particular variable.Only drawback of the 0-100% range is it has less granularity when mapped to the true integer representation. I agree we could drop the decimal representation in the gui but then again pleny of people are accustomed to that already.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »

I think part of the problem is, many do not understand what the PID process is or not to tune it. This Explanation should be incorporated into the Wiki.
http://www.rcgroups.com/forums/showthread.php?t=1890703

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by alll »

Hamburger wrote:
alll wrote:PS:could we have the "more/less" (0-100%) PID values implemented, this will so much clearer. :|

no difference at all. Both ranges [0;100] and [0;255] (or [0;0.255]) are of the same category - numbers with no resemblance to real world. One is not in any way better than the other - in both cases users have to learn the impact of changing that particular variable.Only drawback of the 0-100% range is it has less granularity when mapped to the true integer representation. I agree we could drop the decimal representation in the gui but then again pleny of people are accustomed to that already.


So, lets make all parameter granularity to be at least 0..255 (byte), let the code do the math to lower/increase the scaling factor, and show in the gui only values for all pid-parameters to be from 0..255.

manu

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by alll »

copterrichie wrote:I think part of the problem is, many do not understand what the PID process is or not to tune it. This Explanation should be incorporated into the Wiki.
http://www.rcgroups.com/forums/showthread.php?t=1890703

He also only talks about "increasing", "back off", "speed", ... ;)
manu

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »

alll wrote:
copterrichie wrote:I think part of the problem is, many do not understand what the PID process is or not to tune it. This Explanation should be incorporated into the Wiki.
http://www.rcgroups.com/forums/showthread.php?t=1890703

He also only talks about "increasing", "back off", "speed", ... ;)
manu


Which is why I made this statement:

This is very good, excellent in fact! The only misgiving I can see is, if the P value is too low from the start, it will oscillate also but somewhat more radical, maybe totally uncontrollable. This can be mistaken as be too much P value.


but yet, it is the BEST I have seen as of today. :)

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by alll »

copterrichie wrote:
but yet, it is the BEST I have seen as of today. :)

Yes i like these kind of "simple" explanations, you see he "knows" by experience.

copterrichie wrote:This is very good, excellent in fact! The only misgiving I can see is, if the P value is too low from the start, it will oscillate also but somewhat more radical, maybe totally uncontrollable. This can be mistaken as be too much P value.

But then your copter is IMO unstable by design, on one of my quads, i can fly with p almost to zero ;)

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by copterrichie »

alll wrote:But then your copter is IMO unstable by design, on one of my quads, i can fly with p almost to zero ;)


LOL, I am not about to get into stability debate because ALL Multi-rotor copters are inherently unstable. Because you are using a very low P factor simply means, you have a very high power to weight ratio. ;)

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by felixrising »

Welcome back alex!

I think the discussion on obfuscating PID values with "user friendly" 0-100 scale is off topic. Related perhaps, but start another thread if it's so important.

So far I've seen only two sets of working PIDs posted here, please post your PIDs!.

My experiments with the Ziegler-Nichols Pot tuning code over here in conjunction with the new PID Controller left me surprised by the range of values that do work with the Z-N ballpark stuff, I'm talking Kp of 2.5 to ~10! However Level Kp effect changes a lot with different Roll/Pitch Kp values - from not maintaining level flight to strong oscillations.
Last edited by felixrising on Fri Jun 28, 2013 9:47 am, edited 2 times in total.

Phil S.
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by Phil S. »

First of all, welcome back Alex! Ithink this is good news for MW community.

I have written this before, to me PID setup got a lot easier with the new implementation. My quad was controllable over a wide PID range, e.g. P for roll and pitch started working not far over 2.0 and was still not bad at 5.0, impossible with the old PID loops.

I spent a lot of hours flying different kind of stuff over the last couple of years and observed the development of flybarless helicopter systems let´s say during the last three years. Simply said In the beginning there was a lot to adjust but they worked poor now they are plug and play more or less and work well with defaults from 250 heli size to 700 plus.

In the middle of 2012 Futabas CGY750 was V1.2, one had to fiddle with PIDs a lot sometimes even mixers were needed but especially in smaller sized helis control was frequently far from ideal. This changed totally with V1.3, just enter heli size and one of five flight modes from beginner to champion, adjust gain for yaw a little bit, that´s it. Gains on roll and pitch usually work with defaults, rising or lowering the values does not change a lot but a perfectly running system doesn´t need to be changed!

It was pretty similar with other FBLs and installing Alex´modification IMO resembles this development pretty much, its easier to adjust AND works a lot better!

So from a pilot´s point of view: Keep it up! Keep it simple! Only a few parameters to adjust with as few steps as possible (really 255 required?).

Microbeast FBL system e.g. has a single potentiometer for roll and pitch gain (called "Cyclic Gain", P and D together?) and a six step cyclic I gain (called "Pitching Uo Behaviour"). There are two more potentiometers for direct feed on cyclic and yaw. P gain for yaw as the most important value for single rotors is set via radio, yaw I gain is called "Heading Lock Gain", again six steps. That´s all with stabilization, a few more settings are kind of expo and D/R.
With all these values on defaults almost every single rotor flies pretty well. The manual describes shortly but precisely how parameters work, what they do when raised or reduced and how the heli reacts when they are set too high or too low. Not a single word about proportional or integral all the PID loop stuff simply not needed. All you have to do is attaching the little box into your heli and plugging in the servos. Without being Einstein It takes just a few lipos to finish setup and get a perfectly controlled single rotor.

It´s even more simple with KK5.5 board. Two important pots, the third works on 50% in most cases. Start with 25% Roll (P roll + pitch, D fixed?) 0% Pitch (I roll + pitch). Increase Roll until oscillation starts and reduce a bit. Increase Pitch until speed pitch up disappears. Period.

All these systems described above are perefctly controllable by direct pilot input. Is there such a big difference whith input coming from baro sensor or GPS unit?

alex.khoroshko
Posts: 27
Joined: Sun Jun 09, 2013 9:17 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by alex.khoroshko »

Oh, that's a good idea! All the coefficients (P, I and D) are scaled by the trust to weight ratio. So, we can make the common parameter, which would adjust them all at the same time (not change their values, but is a scale factor, which implicitly multiplied by them all). It would work as good, as possible for people, who can not/do not want to understand the difference between all the gains. It can be done very efficiently -by scaling of error value - single multiplication is only needed.
This should look like this:
Gain [0:255], P[-100%:+100%], I[-100%:+100%], D[-100%:+100%].
Or, PIDs gains correction can be done in our favorite [-127:127]. It needs testing - quite possible that the range of about 10% would work for all. The only potential drawback here is D - it may make aircraft twitchy if the vibrations are bad, so there should be a way to make it zero (-100% correction should be accessible).

Also, I still remember about redoing the horizon mode to make it tunable from minor leveling (like I did initially) to the same behaviour, as horizon is in the initial version of PID. Would do that ASAP.

Also, why changing with a pot? Let's make any PID value assignable to any channel via GUI? You fly and tune - the best way possible, IMO. The only problem here is how to save the settings. Saving every second seem nice, but it needs asynchronous EEPROM write routine. I have one, if that would be needed.

And I thought about self-tuning PIDs. Ziegler-Nichols method won't work well, because different multirotors (not only different types, but also different frames) have different amplitude-phase characteristic - some ESC may introduce dynamic influence early, some - may not etc. For example (I said it earlier) my bad quad needs very low P and most of the control is done through the I gain (without it the quad is barely flyable). So just setting the gains proportionally is not the solution for all the problems, it's a good idea to start tuning, though (as I've written above)

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by alll »

felixrising wrote:Welcome back alex!

I think the discussion on obfuscating PID values with "user friendly" 0-100 scale is simply off topic. Related perhaps, but start another thread if it's so important.

So far I've seen only two sets of working PIDs posted here, please post your PIDs!.

My experiments with the Ziegler-Nichols Pot tuning code over here in conjunction with the new PID Controller left me surprised by the range of values that do work with the Z-N ballpark stuff, I'm talking Kp of 2.5 to ~10! However Level Kp effect changes a lot with different Roll/Pitch Kp values - from not maintaining level flight to strong oscillations.


So, if you think it is off topic, give us examples of PID's and tell us how to interprete them. I really don't see what you will do with those PID's without knowing the mechanics of the multicopter!
So if it is so important those PID values, start another thread that gives us the relation between PID and multicopter physical setup. ;)
manu

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by alll »

Most important for us to be able to tune the different PID values (0..255 ;) is to explain (the developer of the PID loop) how and what the ERROR is and how it is calculated, this for each PID.
And the PID formula in speudo code : eg:

Code: Select all

previous_error = 0
integral = 0
start:
  error = setpoint - measured_value
  integral = integral + error*dt
  derivative = (error - previous_error)/dt
  output = Kp*error + Ki*integral + Kd*derivative
  previous_error = error
  wait(dt)
  goto start


The PID implementation drawing Alex.k posted is also very, very useful, a necessity!

angular velocity PID error for roll/pitch/yaw : Rx[axis]-Gyro[axis] (knowing that gyro is angular velocity)
level PID : ...
...

Thanks,
manu
A drawing is wort 1000 words ;)

sorg
Posts: 34
Joined: Mon Apr 08, 2013 2:49 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Post by sorg »

felixrising wrote:Welcome back alex!

I think the discussion on obfuscating PID values with "user friendly" 0-100 scale is off topic. Related perhaps, but start another thread if it's so important.

So far I've seen only two sets of working PIDs posted here, please post your PIDs!.

My experiments with the Ziegler-Nichols Pot tuning code over here in conjunction with the new PID Controller left me surprised by the range of values that do work with the Z-N ballpark stuff, I'm talking Kp of 2.5 to ~10! However Level Kp effect changes a lot with different Roll/Pitch Kp values - from not maintaining level flight to strong oscillations.

I had the same results with the "oldschool" PID algorithm and Z-N pot tuning: In gyro mode the range of usable value is quite large... It makes very easy to find an acceptable tuning point. My guess is that the Z-N formula make I and D sweetly compensate the P allowing quite a large range of acceptable value for P.

In Level (angle) mode, it is more difficult though.

Post Reply