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
User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

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

Post by Plüschi »

Hamburger wrote:Plain wrong. I do it all the time.


Why does mine not flip in horizon, but does in angle with acrotrainer enabled ?

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re:

Post by scrat »

BarneyG wrote:I've got a v2 ... The reason I asked is that it is the line you bolded has been changed to 100000 in Alex's code :)


I know. I have both commented out because in file def.h there is already defined. This apply for v2 too.

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

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

Post by crashlander »

Plüschi wrote:
Hamburger wrote:Plain wrong. I do it all the time.


Why does mine not flip in horizon, but does in angle with acrotrainer enabled ?


What are your PID's, pitch roll RATE and RC RATE? I found it difficult to flip it even in ACRO mode until I upped both RATE's (I'm flying wii-esc flashed ESC and gyro PID's P around 8)!

Regards
Andrej

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

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

Post by shikra »

Cool developments in places.

Crashlander -
Low D helps with fast flips as well as rates. In standard implementation

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

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

Post by brm »

alex.khoroshko wrote:Thanks for such a good response!
Here's a sketch of the implementation. I've also attached the PDF version (it's hard to read from image). I would try to increase the readablitity (increase font size or something).
pid alex.k11.png

but in that case you have to hold the value of the integrator cause it would wind up

There's no integrator for horizon mode - regulator just requests the angle rate proportionally to angle difference (I used "I" value because it was free. it should be renamed into "horizon P"). The system integrates by itself, because angle is integral from angle rate. As for horizon strength - coefficient of 16 corresponds to the same leveling strength, as 1 for "level" mode (they have equal implementation, only the scaling is different).
For the next version, I've made out the fix for that as well - I just squared the coefficient, so the more you increase GUI value, the faster real coefficient is increased. Should give very weak leveling at 1 (the way I like it) and really locked-in leveling at 4 (like in angle mode - the way you seem to want it to be). Would test myself and then post here (together with scaling fix (all modes) and extreme sticks mix-up for horizon).

looking at the code is always problematik.
in essence you are cascading two control loops.
instead of naming it 'tmp' name it desiredRate. this rate is scaled according to mode you are flying.
separating the two loops could lead to code which is more understandable.

on the d-term it is not so simple.
i don't like averaging buffers.
a pt1 element is more predictable.
doing not so the changes on the dterm can saturate your esc.
also the d-term can be calculated on the state or the error.
both have different flightbehaviours.
in general i like the cascaded approach and the error on the d-term.

to prove what you said you need a vicon-system to verify your point of view.
also looking only at the loop/cycletime is wrong - you need the whole feedback loop.
your command has to come through.

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

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

Post by Mis »

Did you know if you have Crius AIOP v1, V1.1 or v2 you can have I2C speed commented out. I have it like that and don't have I2C errors anymore.

Do you know, that "#define I2C_SPEED" definition have no effect in most cases because "sensors.ino" have own I2C speed definitions for every sensors ?
BTW this is waste flash, CPU time ect, and cause that I2C work in most cases with 400kHz, even if you declarate "#define I2C_SPEED 100000".
The "#define I2C_SPEED" definition is only usable with old WMP and nunchuk sensors.

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

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

Post by copterrichie »

Mis wrote:Do you know, that "#define I2C_SPEED" definition have no effect in most cases because "sensors.ino" have own I2C speed definitions for every sensors ?
BTW this is waste flash, CPU time ect, and cause that I2C work in most cases with 400kHz, even if you declarate "#define I2C_SPEED 100000".
The "#define I2C_SPEED" definition is only usable with old WMP and nunchuk sensors.


there is ALLOT of optimizing that can be done. Seriously.

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

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

Post by scrat »

Mis wrote:
Did you know if you have Crius AIOP v1, V1.1 or v2 you can have I2C speed commented out. I have it like that and don't have I2C errors anymore.

Do you know, that "#define I2C_SPEED" definition have no effect in most cases because "sensors.ino" have own I2C speed definitions for every sensors ?
BTW this is waste flash, CPU time ect, and cause that I2C work in most cases with 400kHz, even if you declarate "#define I2C_SPEED 100000".
The "#define I2C_SPEED" definition is only usable with old WMP and nunchuk sensors.


No I didn't know that. Thanks for info Mis.

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 »

Just took this process loop implementation on baseflight/stm32 for a test flight, very nice! Great work alex.k!!! The values posted here by Phil.S are great, though I added a little more RC Expo.. I'll maiden it on one of my Crius AIO Pros on the weekend...

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 »

Alex.k... I hear you like documentation... please ask Hamburger or Alexinparis for a wiki ID and do your worst... :D

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 »

Hi i just tested the new Pid controller and it does great but i think the levelP should be prescaled (division by 3?) otherwise people will crash when not turning down their "known" level P. Just an safety - idea.

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 »

alex.khoroshko wrote:
pid alex.k11.png

Image


This is realy, realy helpful to understand and afterwards tune the PID's!
Many thanks for that!

Is this the current multiwii2.2 or an adapted version, which SVN release?

Manu

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 »

@alex.khoroshko: First of all a big thank you for actually rethinking and improving core parts of the flightcontrol !!!
While fiddeling around with your new controller i was wondering if the frequency cut of the D term used in the arducopter2.7.X/multi GPS code could also help your main pid controller (http://code.google.com/p/multiwii/sourc ... GPS.ino#39)? Currently i am implementing it and was wondering what frequency cut off might be useful. I will start with 20Hz, but do you have any suggestion concerning that cutoff frequency?
An indoor Hand-test suggests a cut off frequency below 10Hz, 5Hz seems fine. Constant rain here, cant wait to test it.
Cheers Rob

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 »

Is there already a SVN release with the new controller implementation ?

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 »

No, and I guess there wouldn't - some changes were introduced by someone, but the implementation is still in the mazy form. I have a version, which fits my needs better than original, nobody of the developers seem to care - the fun part here is complete.
So now I decided to quit and go build my own flight control software with blackjack and hookers, and here's why. I have 2-3 students per year, who need to write their graduate thesis (I'm a teacher in Siberian Aerospace university). It was always such a pain to make out the topic related to control systems and aircrafts (this year the topic was the control system for cooling equipment needed to perform the degradation tests of lithium-ion batteries for satellites - imagine, how far that is, lol). Now the problem is solved. I first thought to do that within the multiwii project, but then I realized that separate development better fits the constraints of the graduate thesis.

So, good luck to everyone!

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

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

Post by brm »

alex.khoroshko wrote:No, and I guess there wouldn't - some changes were introduced by someone, but the implementation is still in the mazy form. I have a version, which fits my needs better than original, nobody of the developers seem to care - the fun part here is complete.
So now I decided to quit and go build my own flight control software with blackjack and hookers, and here's why. I have 2-3 students per year, who need to write their graduate thesis (I'm a teacher in Siberian Aerospace university). It was always such a pain to make out the topic related to control systems and aircrafts (this year the topic was the control system for cooling equipment needed to perform the degradation tests of lithium-ion batteries for satellites - imagine, how far that is, lol). Now the problem is solved. I first thought to do that within the multiwii project, but then I realized that separate development better fits the constraints of the graduate thesis.

So, good luck to everyone!


ahh,
welcome in the club!
you are facing the behaviour of the developper core.
way to slow for quite a few people.

i would invite you to use timecops baseflight hw and sw.
would be interesting to develop new things.
i hope your development is not too isolated.

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

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

Post by brm »

Let’s focus first in the ACRO mode for understanding.
The scheme is mainly correct.

in essence nothing wrong ... in theory.
the d-term needs to more controlled - use a pt1 element to dampen the changes comming from the d-term.
the result is more predictable.
a 08-15 pid controller must have a pt1 element.

the pid calculation as a whole sucks.
the implementation is too sensitive with regards to vibrations.
you get int16_t overruns...
also the dyn pid also has a problem with heavy vibrations.
here i need more time for investigations.

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 »

alex.khoroshko wrote:...nobody of the developers seem to care - the fun part here is complete....
So, good luck to everyone!


Come on, the "non-developers/comiters" do also want to have fun ;)
You could at least ask a separate branch as casquad got for the code reorganisation! , "commiters", can you make this happen?
Thanks,
manu
PS: IMO a proper "simple/standard (without too many special tricks)" PID control loop is mandatory, the right PID values will make the difference!

BarneyG
Posts: 39
Joined: Tue May 07, 2013 4:42 pm

Post by BarneyG »

Indeed ... At least post your latest version for those of us who are seeing the benefits of your efforts :)

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 »

@brm: "the d-term needs to more controlled - use a pt1 element to dampen the changes comming from the d-term."
Yes, absolutely! - Came to the same conclusion while fiddeling with that altered Pid controller. The gps "D" part didn't do it :( . (It is basically the same but missing the averaging part)
I put everything on "floats" in the pidcontroller and can not complain, works nice. The flightfeeling is different compared to the convetional mwii controller but i like both now. I think mwii should somehow implement that altered Pid controller as an option to choose from. On the other hand who really cares? The soft is opensource. It's just a matter of days, till someone comes up with a more polished version of that. Maybe mahowik?
Cheers
Rob
Last edited by Crashpilot1000 on Sat Jun 22, 2013 12:52 pm, edited 1 time in total.

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 »

Crashpilot1000 wrote:...I think mwii should somehow implement that altered Pid controller as an option to choose from. On the other hand who really cares? The soft is opensource. It's just a matter of days, till someone comes up with a more polished version of that. Maybe mahowik?
Cheers
Rob


Or make it more "pluggable", everybody should be abe to "plug" its PID controller into mwiii ! :roll:
manu

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:No, and I guess there wouldn't - some changes were introduced by someone, but the implementation is still in the mazy form. I have a version, which fits my needs better than original, nobody of the developers seem to care - the fun part here is complete.
So now I decided to quit and go build my own flight control software with blackjack and hookers, and here's why. I have 2-3 students per year, who need to write their graduate thesis (I'm a teacher in Siberian Aerospace university). It was always such a pain to make out the topic related to control systems and aircrafts (this year the topic was the control system for cooling equipment needed to perform the degradation tests of lithium-ion batteries for satellites - imagine, how far that is, lol). Now the problem is solved. I first thought to do that within the multiwii project, but then I realized that separate development better fits the constraints of the graduate thesis.

So, good luck to everyone!


SAD but understandable. I hope you will reconsider.

disq
Posts: 29
Joined: Tue May 21, 2013 2:11 am
Location: Northern Cyprus

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

Post by disq »

felixrising wrote:Just took this process loop implementation on baseflight/stm32 for a test flight, very nice! Great work alex.k!!! The values posted here by Phil.S are great, though I added a little more RC Expo.. I'll maiden it on one of my Crius AIO Pros on the weekend...


Also in baseflight i_level is limited to 0.20 ("200") and multiwiiconf limits it to 0.25. So Level_I=0.30 posted by Phil is not possible at the moment (and probably not tested/not set, I didn't check but probably not in multiwii as well since the values are 8-bit ints)

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

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

Post by -ralf- »

disq wrote:
felixrising wrote:Just took this process loop implementation on baseflight/stm32 for a test flight, very nice! Great work alex.k!!! The values posted here by Phil.S are great, though I added a little more RC Expo.. I'll maiden it on one of my Crius AIO Pros on the weekend...


Also in baseflight i_level is limited to 0.20 ("200") and multiwiiconf limits it to 0.25. So Level_I=0.30 posted by Phil is not possible at the moment (and probably not tested/not set, I didn't check but probably not in multiwii as well since the values are 8-bit ints)

When using WinGUI like Phil the limitation on Level_I is 2.54 .....

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

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

Post by timecop »

So sounds like WinGUI I is 0.030 then and not 0.3

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

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

Post by -ralf- »

timecop wrote:So sounds like WinGUI I is 0.030 then and not 0.3


Just tried it - you are right. Setting the Level-I in WinGUI to 0.3 will be
read as 0.03 in MultiWiiConf .....

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 »

0.3 / 0.03 what units. I already said these PID values do not mean much if the implementation details are not know or wel documented. IMO all mwii PID values should be shown in the GUI's like 0..100%. Really, on the field i am NOT interested in the real values/units of measure, just "more" or "less".
I would really appreciate it could be done, and should solve at the same time these kind of confusion(s) in the GUI's.
manu
Last edited by alll on Sat Jun 22, 2013 6:55 pm, edited 1 time in total.

-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:0.3 / 0.03 what units. I already said these PID values do not mean much if the implementation details are not know or wel documented. IMO all mwii PID values should be shown in the GUI's like 0..100%. Really, on the field i am interested in the real values/units of measure, just "more" or "less".
I would really appreciate it could be done, and should solve at the same time these kind of confusion(s) in the GUI's.
manu

+1 I agree .... make the values readable ....

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. »

alex.khoroshko wrote:So, good luck to everyone!

I am really sorry that you leave as fast as you came. But I understand your motives! To me, MultiWii is definitely part of history if the devs do not understand that people like you could prevent the whole project from sinking further into insignificance. In terms of autonomous functions, ArduCopter & Co. are way ahead and acro flying is quite poor without your mod, resp. a lot more fun with KK & Co. So what´s the sense in using MultiWii?

Alex, many thanks for your inputs and good luck too you! Best regards, Philipp

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

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

Post by copterrichie »

To the best of my recall, MultiWii started with the focus on meeting the needs of the hobbyist community with an easy to build, low cost Flight Controller. It has since grown to rival many of commercial packages costing much more performance wise when configured correctly. Agreed, this is not an easy task for a totally new comer however, there are many using the firmware to accomplish some amazing tasks. With this understanding, there are some fundamental questions introduced as to where is this project headed?

I don't believe I have ever read anywhere of anyone objecting to the usage of MultiWii Code in full or in part for any other project and in fact, I believe it is encouraged. There is nothing stopping folk developments from the main code as long as credit is given to the source. Considering the number of board manufactures and existing boards already available, it comes as no surprise the reluctance to incorporate radical changes to quickly. Especially considering the history of people coming and going on this project. Expanding the community was suggested in the past however that suggestion was met with resistance and for obvious good reasons at the that time. this is not a commercial venture with many developers having full time jobs and families. The development as well as flying is a pastime and enjoyment. With any growth or expansion to any project, there come new problems related to personality clashes and differences of opinion. Believe it or not, this is a very positive sign because any venture of this magnitude is subject to GroupThink (Yes people) that will just flow with the program regardless. The disagreements and clashing is a way of weeding out the bugs in the system.

Without going into great detail, the hobbyist has come under allot of scrutiny and some criticism too with many States in the US attempting to create laws to govern the usage of these aerial vehicles. As long as the project remains in the hobby realm, there is little harm with the exception of a few NUT Cases that exist in project of this nature.
Last edited by copterrichie on Sat Jun 22, 2013 9:29 pm, 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. »

copterrichie wrote:... when configured correctly. Agreed, this is not an easy task for a totally new comer however, ...

It seems to me that it is not an easy task for at least some of the devs to fly a copter to its aerodynamical limits hence not beeing able to learn where the limits of their codes are.

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 »

@casquad
i tried to make a new "svn" project from eclipse, point to the right CPPMigration directory, and the "Check out as a project using the New Project Wizard", but this is grayed out because you left a the svn ".project" file in the repository. (maybe you did it by perpose?)

I try from within Eclipse to checkout, then invoke new avr project...

manu
Attachments
eclipse-checkout.PNG

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:@alex.khoroshko: First of all a big thank you for actually rethinking and improving core parts of the flightcontrol !!!
While fiddeling around with your new controller i was wondering if the frequency cut of the D term used in the arducopter2.7.X/multi GPS code could also help your main pid controller (http://code.google.com/p/multiwii/sourc ... GPS.ino#39)? Currently i am implementing it and was wondering what frequency cut off might be useful. I will start with 20Hz, but do you have any suggestion concerning that cutoff frequency?
An indoor Hand-test suggests a cut off frequency below 10Hz, 5Hz seems fine. Constant rain here, cant wait to test it.
Cheers Rob

you can copy it from baseflight.

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

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

Post by -ralf- »

Is there any chance to get the alex.khoroshko-PID-mod implemented in current
dev-release? Maybe as a selectable "#define ALEX_K_PID" option?

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

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

Post by -ralf- »

Thanks, Hamburger, for doing this in r1501 ...
You are my hero ;)

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 »

Yes, thats GREAT !!! :-) Thanks to Hamburger AND Alex. This is what MultiWii is all about ! Now the fun part is to all of us :D :D :D :D :D

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 »

@ Hamburger:

the rev1501 won't arm when compiled with AlexK PID (2)

I changed this part in Multiwii.ino to:

Code: Select all

 
if ( f.HORIZON_MODE ) prop = min(max(abs(rcCommand[PITCH]),abs(rcCommand[ROLL])),512);
 
  //----------PID controller----------
  for(axis=0;axis<2;axis++) {


from the original code:

Code: Select all


 prop = min(max(abs(rcCommand[PITCH]),abs(rcCommand[ROLL])),500); // range [0;500]

  //----------PID controller----------
  for(axis=0;axis<3;axis++) {


now it arms. Was the "3" in the for(axis=3..... wrong ?

Could you please make a new Rev with the bugfix in SVN ?

Thanks a lot,

Chris



Correction: no, that was not the solution. It does arm, but with the above changes I lost YAW control :oops:

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 »

Mmmm,

I saw Revision r1501, I really hope we could move to the new reorganized cpp/h structure. As i see it going, to get the cpp-branch in sync, we will have to do it manually? :cry:

manu

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

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

Post by nhadrian »

Hi all,

does anybody succeed with this new code? How safe it is?
I'm especially interrested in tri-copter...

OFF

you know guys, when I made my first changes in baro code and nav code, I got hard comments on why posting BUGGY codes, although it was not in any repository but only in attached ZIP files, and I wrote out with capital that TRY IT ON YOUR OWN RISK...
And now, since 1474, there are many broken/untested/not working/dangerous things around PID in shared. (Tricopters are unflyable with 1474, not only for me but for other users in Hungary....)
I just can't understand what changed around Multiwii community... :(

ON

BR
Adrian

PS.: good luck on new PID calc!!!!!!!!!!

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 »

@Hamburger,

The PID_CONTROLLER define should cover the PID defaults listed in EEPROM too

Code: Select all

diff -u MultiWii/EEPROM.ino MultiWii-new/EEPROM.ino
--- MultiWii/EEPROM.ino   2013-03-11 15:08:47.000000000 +0900
+++ MultiWii-new/EEPROM.ino   2013-06-14 21:49:58.000000000 +0900
@@ -101,8 +101,8 @@
 }
 
 void LoadDefaults() {
-  conf.P8[ROLL]     = 33;  conf.I8[ROLL]    = 30; conf.D8[ROLL]     = 23;
-  conf.P8[PITCH]    = 33; conf.I8[PITCH]    = 30; conf.D8[PITCH]    = 23;
+  conf.P8[ROLL]     = 28;  conf.I8[ROLL]    = 10; conf.D8[ROLL]     = 7;
+  conf.P8[PITCH]    = 28; conf.I8[PITCH]    = 10; conf.D8[PITCH]    = 7;
   conf.P8[YAW]      = 68;  conf.I8[YAW]     = 45;  conf.D8[YAW]     = 0;
   conf.P8[PIDALT]   = 64; conf.I8[PIDALT]   = 25; conf.D8[PIDALT]   = 24;
   
@@ -110,7 +110,7 @@
   conf.P8[PIDPOSR] = POSHOLD_RATE_P * 10; conf.I8[PIDPOSR]   = POSHOLD_RATE_I * 100;  conf.D8[PIDPOSR]   = POSHOLD_RATE_D * 1000;
   conf.P8[PIDNAVR] = NAV_P * 10;          conf.I8[PIDNAVR]   = NAV_I * 100;           conf.D8[PIDNAVR]   = NAV_D * 1000;
 
-  conf.P8[PIDLEVEL] = 90; conf.I8[PIDLEVEL] = 10; conf.D8[PIDLEVEL] = 100;
+  conf.P8[PIDLEVEL] = 30; conf.I8[PIDLEVEL] = 32; conf.D8[PIDLEVEL] = 0;
   conf.P8[PIDMAG]   = 40;
   
   conf.P8[PIDVEL] = 0;      conf.I8[PIDVEL] = 0;    conf.D8[PIDVEL] = 0;


Worth noting that many have found these values to work well so perhaps an update is needed to the above defaults for the new PID controller: download/file.php?id=2261&mode=view


EDIT: correct me if I'm wrong, but there are three errorGyroI axis in PID_CONTROLLER == 2..?? static int32_t errorGyroI[2] = {0,0}; won't work... and errorAngleI doesn't get used in new PID controller either...?

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 »

@ felixrising: Yes, you are right. There are missing some defs for the AlexK PID and also the changes in the EEPROM.ino would help.

I tried to minimize the patch file from AlexK to the definition parts:
AlexK: can you please doublecheck your changes to the definition-part ? I Think we are on a good way to make it fly :)

Code: Select all

diff -u MultiWii/EEPROM.ino MultiWii-new/EEPROM.ino
--- MultiWii/EEPROM.ino   2013-03-11 15:08:47.000000000 +0900
+++ MultiWii-new/EEPROM.ino   2013-06-14 21:49:58.000000000 +0900
@@ -101,8 +101,8 @@
 }
 
 void LoadDefaults() {
-  conf.P8[ROLL]     = 33;  conf.I8[ROLL]    = 30; conf.D8[ROLL]     = 23;
-  conf.P8[PITCH]    = 33; conf.I8[PITCH]    = 30; conf.D8[PITCH]    = 23;
+  conf.P8[ROLL]     = 28;  conf.I8[ROLL]    = 10; conf.D8[ROLL]     = 7;
+  conf.P8[PITCH]    = 28; conf.I8[PITCH]    = 10; conf.D8[PITCH]    = 7;
   conf.P8[YAW]      = 68;  conf.I8[YAW]     = 45;  conf.D8[YAW]     = 0;
   conf.P8[PIDALT]   = 64; conf.I8[PIDALT]   = 25; conf.D8[PIDALT]   = 24;
   
@@ -110,7 +110,7 @@
   conf.P8[PIDPOSR] = POSHOLD_RATE_P * 10; conf.I8[PIDPOSR]   = POSHOLD_RATE_I * 100;  conf.D8[PIDPOSR]   = POSHOLD_RATE_D * 1000;
   conf.P8[PIDNAVR] = NAV_P * 10;          conf.I8[PIDNAVR]   = NAV_I * 100;           conf.D8[PIDNAVR]   = NAV_D * 1000;
 
-  conf.P8[PIDLEVEL] = 90; conf.I8[PIDLEVEL] = 10; conf.D8[PIDLEVEL] = 100;
+  conf.P8[PIDLEVEL] = 30; conf.I8[PIDLEVEL] = 32; conf.D8[PIDLEVEL] = 0;
   conf.P8[PIDMAG]   = 40;
   
   conf.P8[PIDVEL] = 0;      conf.I8[PIDVEL] = 0;    conf.D8[PIDVEL] = 0;


diff -u MultiWii/MultiWii.ino MultiWii-new/MultiWii.ino
--- MultiWii/MultiWii.ino   2013-03-11 15:08:47.000000000 +0900
+++ MultiWii-new/MultiWii.ino   2013-06-14 21:49:58.000000000 +0900
@@ -362,7 +362,7 @@
 // ************************
 // EEPROM Layout definition
 // ************************
-static uint8_t dynP8[3], dynD8[3];
+static uint8_t dynP8[3], dynD8[3], dynI8[3];
 
 static struct {
   uint8_t currentSet;
@@ -536,6 +536,8 @@
     }
     dynP8[axis] = (uint16_t)conf.P8[axis]*prop1/100;
     dynD8[axis] = (uint16_t)conf.D8[axis]*prop1/100;
+    dynI8[axis] = (uint16_t)conf.D8[axis]*prop1/100;
+   
     if (rcData[axis]<MIDRC) rcCommand[axis] = -rcCommand[axis];
   }
   tmp = constrain(rcData[THROTTLE],MINCHECK,2000);
@@ -867,14 +869,14 @@

-  int16_t error,errorAngle;
+  int16_t errorAngle;
   int16_t delta,deltaSum;
   int16_t PTerm,ITerm,DTerm;
-  int16_t PTermACC = 0 , ITermACC = 0 , PTermGYRO = 0 , ITermGYRO = 0;
-  static int16_t lastGyro[3] = {0,0,0};
+  uint16_t CycleTime[3] = {0,0,0};
+  static int16_t lastError[3] = {0,0,0};
   static int16_t delta1[3],delta2[3];
-  static int16_t errorGyroI[3] = {0,0,0};
-  static int16_t errorAngleI[2] = {0,0};
+  static int32_t errorGyroI[3] = {0,0,0};
+  static int32_t errorAngleI[2] = {0,0};
   static uint32_t rcTime  = 0;
   static int16_t initialThrottleHold;
   static uint32_t timestamp_fixated = 0;
@@ -1308,54 +1310,75 @@
 

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

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

Post by shikra »

+1
I for one think this is very interesting and exciting development. It is a shame Alex K has decided to leave before I have even had opportunity to test it... :(

I do think we should have some more comprehensive tests carried out before adopting it in core code. Confirm improvements across core copter types and flying styles - fast sharp movements for ACRO or slow AP with no wobble. This is fundamental change to how MultiWii feels to fly.


Adrian - how you do it is perfect BTW...



nhadrian wrote:Hi all,

does anybody succeed with this new code? How safe it is?
I'm especially interrested in tri-copter...

OFF

you know guys, when I made my first changes in baro code and nav code, I got hard comments on why posting BUGGY codes, although it was not in any repository but only in attached ZIP files, and I wrote out with capital that TRY IT ON YOUR OWN RISK...
And now, since 1474, there are many broken/untested/not working/dangerous things around PID in shared. (Tricopters are unflyable with 1474, not only for me but for other users in Hungary....)
I just can't understand what changed around Multiwii community... :(

ON

BR
Adrian

PS.: good luck on new PID calc!!!!!!!!!!

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

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

Post by Hamburger »

guilty as charged, on all accounts.
I will push an update after I have flown it myself.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

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

Post by shikra »

hey - not having a go... we like beefburgers here...

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

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

Post by Hamburger »

r1502 test flown PID_CONTROLLER = 2 on a 25cm TRI with both the original alexK pids and the new philS pids.
Horribly sensitive for my taste, even with 45%expo & rcrate at 70% and pr-rate=yaw-rate=0. Ymmv.

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 »

I also just spent 30 minutes maidening in the lounge room (my wife is extremely understanding of my obses^H^H^H^H^H hobby). I came up with these values on a AIO Pro v1.1, HT Flip FPV with 4s/f20a/MT2216-11 1100kv w/ 8045 gemfans:

Initial PID values with very brief lounge-tuning w/ 42Hz LPF
Initial PID values with very brief lounge-tuning w/ 42Hz LPF


There is plenty of room for improvement with extended tuning. values vary a lot from those previously posted but then it's a totally different quad.

NB: this is my own merge of code into NHAdrian's r23 codebase. - basically the same as what Hamburger (our favourite burger) did in _shared r1502.

I think its worth remembering that _shared is a DEV branch.. basically all commits are pre-test.. What I believe would really help is a validation process, either via incident reports or double checking by another developer before it's fully accepted.. Now, lets get these changes into the CppMigration branch too. <- that is an important step fowards.

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. »

Hamburger wrote:... with both the original alexK pids and the new philS pids.
Horribly sensitive for my taste, ...

Like Fisherman`s Friend? It is fast. Are you?

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

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

Post by copterrichie »

I sincerely hope AlexK will resume work on this contribution. I also give it a try on one of my bicopter with very unfavorable results. I figured my experience was due to my exotic servo/motor mixing so I decided to withhold my test results in hopes of others with more traditional builds give it a test.

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

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

Post by nhadrian »

Hi all again,

my major problem is that before r1474 we had a rock solid, well tested PID and IMU implementation, without any known bugs in ALL FLYING SITUATIONS thanks to the high number of users/testers/flights.
I can't understand why we need to modify this core part and start testing from scratch?!?!?!
What was the main problem of the previous PID implementation??? Can anybody tell me?

Unfortunatelly such a major change in PID implementation can't be tested with some "hovering" copters, because there can be still bugs when extreme flight situations occure (ie. calculation overflow?! extreme banking because of wind ghust in GPS hold?! fast forward flying?! etc.....)

I think there are still some weak/outdated functions (compared to other flight control systems in the market) in Multiwii code what should be better improved a lot, for example:

- improve the current EXTREME SIMPLE Baro mode with vario and the possibility of automatically moving to defined altitudes
- finish the half-finished nav code
- more functional MSP (wich can handle the weakness of any half-duplex telemetry system, because Bluetooth is WAY NOT ENOUGH for telemetry but current MSP have many data-loss when for example 3DR module is used)
- maybe HOTT telemetry integration
- maybe implementation of mavlink protocol for REAL telemetry on REAL ground station softwares...
- real failsafe with controlled descending, maybe with RTH

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 have information that EOSBandi is cuntinously working on a brand new nav code in his spare time, but he has limited time of course. :( I wish him good luck on his job!!!!!)

BR
Adrian

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 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.

Post Reply