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
Shogun
Posts: 13
Joined: Thu Sep 06, 2012 9:14 am

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

Post by Shogun »

For any reason the trunk version behaves different to original AlexK. I already tried some weeks ago, angle mode was like acro. Now as I read this I gave it one more try on my Flydumini, I raised pid to 10.0 0.060 20 and still feels like acro. I will revert again to the original where all is fine with 3.6 0.017 20.

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 »

what a helpful statement. Works well - at least care to mention what coptertyps which modes what pids you referring to?
Repeating your bashing of mwii s/w and h/w is rather boring. Do you have anything useful to offer here or just dumping some emotional garbage? Please stick to your preferred future oriented section and do not waste your time here.

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 »

gektor wrote:After Activating GPS I hat an immediate Crash


I had 2 of those tricopter crashes after activating GPS with normal (not alexk) soft. Never had it with a quad. Is there a glitch with tricopters and gps?

Anyone else?

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

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

Post by copterrichie »

Plüschi wrote:
gektor wrote:After Activating GPS I hat an immediate Crash


I had 2 of those tricopter crashes after activating GPS with normal (not alexk) soft. Never had it with a quad. Is there a glitch with tricopters and gps?

Anyone else?


I have not tried it myself however I do recall reading Angle Mode is required. Not sure why when activating GPS mode, Angle Mode is not engaged automatically. Maybe it is now.

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

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

Post by brm »

Hamburger wrote:what a helpful statement. Works well - at least care to mention what coptertyps which modes what pids you referring to?
Repeating your bashing of mwii s/w and h/w is rather boring. Do you have anything useful to offer here or just dumping some emotional garbage? Please stick to your preferred future oriented section and do not waste your time here.


a Picture ... works for me.
maybe you create a wiki page for different copters.
i agree - boring work.
Attachments
Settings which should work
Settings which should work

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

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

Post by Shogun »

Hamburger wrote:what a helpful statement. Works well - at least care to mention what coptertyps which modes what pids you referring to?
Repeating your bashing of mwii s/w and h/w is rather boring. Do you have anything useful to offer here or just dumping some emotional garbage? Please stick to your preferred future oriented section and do not waste your time here.

I do not remember to ever bashed mwii. If so you can surely proof, post links!
Your reaction indicates this is definitely no place where I want to be, be assured I will no longer waste my time here.

User avatar
mbrak
Posts: 136
Joined: Sat Dec 03, 2011 8:08 pm
Location: Germany, Lemgo

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

Post by mbrak »

Hi
I am using the alexk PID with my naze32 and Harakiri sg2.4!
For me it is working very well. I normaly use only the horizon Mode. The only Parameter i have modified is the Level I Term which is Used as p-Term when horizon is activated. I raised the value to the Double as Default to get the Same behavior as in multiwii.

Only if you fly a bit faster the Copter is leveling Not so fast as expacted:) but no Problem if you Know it :)

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 »

Shogun wrote:
Hamburger wrote:what a helpful statement. Works well - at least care to mention what coptertyps which modes what pids you referring to?
Repeating your bashing of mwii s/w and h/w is rather boring. Do you have anything useful to offer here or just dumping some emotional garbage? Please stick to your preferred future oriented section and do not waste your time here.

I do not remember to ever bashed mwii. If so you can surely proof, post links!
Your reaction indicates this is definitely no place where I want to be, be assured I will no longer waste my time here.

Sorry for the confusion. I was referring to the preceding post from user brm. I did not oversee the possible conflict while posting from my mobile.

basti
Posts: 4
Joined: Tue Mar 12, 2013 10:03 am

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

Post by basti »

Is anyone on here arming using one of the aux channels? When I enable boxarm on, for example, aux3 'H' the serial output into the GUI from the board stops when I flip the switch on channel 7 (i.e. the channel linked to aux3) and the board does not arm. It arms/disarms fine using yaw...

I have the board flying, stock P values on roll and pitch were to small for my copter (homebuilt 400 size), I'm at P=4.1 at the moment but still have to increase it when I get round to tuning. All other settings are stock.

Angle mode is also not working on my copter - it is different to acro - just feels like a more sensitive version of acro.

Otherwise I'm happy with it, a big thanks to you Alex K for all the work you've put into this!

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

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

Post by Shogun »

Hamburger wrote:
Shogun wrote:
Hamburger wrote:what a helpful statement. Works well - at least care to mention what coptertyps which modes what pids you referring to?
Repeating your bashing of mwii s/w and h/w is rather boring. Do you have anything useful to offer here or just dumping some emotional garbage? Please stick to your preferred future oriented section and do not waste your time here.

I do not remember to ever bashed mwii. If so you can surely proof, post links!
Your reaction indicates this is definitely no place where I want to be, be assured I will no longer waste my time here.

Sorry for the confusion. I was referring to the preceding post from user brm. I did not oversee the possible conflict while posting from my mobile.

Oh, now I understand. All fine then, thanks for clarification.

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

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

Post by Shogun »

I took a look at the source codes, for PID_CONTROLLER == 2 the errorAngle calculation is

Code: Select all

errorAngle = constrain((rcCommand[axis]<<1) + GPS_angle[axis],-500,+500) - angle[axis] + conf.angleTrim[axis]; //16 bits is ok here

what should be

Code: Select all

errorAngle = constrain((rcCommand[axis]<<1) + GPS_angle[axis],-500,+500) - att.angle[axis] + conf.angleTrim[axis]; //16 bits is ok here

could only test it with a short jump in the living room and had a stable angle.

edit: Come back from outdoor tests 12 hours after posted the code modification.
It was quite gusty winds, I flew two batteries in angle mode with a Flydumini 20cm quad. No pid tuning, just set roll/pitch to 5.0 0.040 20. Angle mode works and behaviour is exactly AlexK.

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

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

Post by -ralf- »

Shogun,

thanks for the patch; angle is working now on my hexa :mrgreen:

Due to a complete rebuild of the copter I have to retune the pids these days.
I'll post a screenshot when I'm ready.

basti
Posts: 4
Joined: Tue Mar 12, 2013 10:03 am

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

Post by basti »

Thanks for the fix, everything works nice now (except boxarm which I've just stopped using). Attached are my PIDs - I have only tuned the Roll, Pitch and Yaw gains, rates and TPA. Everything else, including level, is unchanged from stock.
Image
My copter is a homebuilt (sorry, I realise it means the PID's are not that meaningfull) 400 size frame, weight about 1kg inc batteries. It has Rctimer 750kv motors with 10x4.5 plastic props. I have tuned this for 4cell but it runs fine on 3, just not nearly as snappy.

The althold feels like the P isn't quite high enough, and when in GPS pos hold, the copter twiches a bit, but again, those settings are stock so really I'm very happy with it.
Attachments
Untitled.png
(5.76 KiB) Not downloaded yet

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

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

Post by BarneyG »

Can someone outline their PID tuning process for this algorithm ... I'm finding that changes I'm making don't seem to be having much effect ... don't get me wrong I'm actually loving the way it is flying but I think it could be better ... especially yaw ... it was getting twisted about quite badly by the wind the other day ... good 30 degree swings.

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

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

Post by Shogun »

Here is PIDs for my 320 size Warthox frame, 8x4.5 props on A2208/17 1100kv, 3S 2200, AUW: 600gr
Image
Tuning was as usual, in order P I D, raised each until oscillating then reduced to about 3/4. Did not do any tuning to yaw. Later during the flights I got oscillations, reduced I from 0.025 to 0.020 to cure that. I also added little rate to yaw.

No PIDs yet for my Flydumini, I made some flights but did not carry equipment to alter the pids. Here I also had oscillations during flight, will try with reduced I next time.
Attachments
130814_MultiWii_2_2_r1551_AlexK_config__.jpg
(11.86 KiB) Not downloaded yet

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

Post by BarneyG »

Did you start at defaults for I and D or did you reduce them to 0 first ?

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

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

Post by Shogun »

I started with defaults. But if then already are oscillations I would first check that props are balanced before I would cut roll, pitch and yaw pid to 1/2 for the next attempt. Do not reduce to 0, you would not have any stabilization at all.

gektor
Posts: 10
Joined: Thu Jul 18, 2013 5:20 pm

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

Post by gektor »

Angle is now working, but when turning on Mag and Baro in Angle Mode, my Tri will not take off at all. Any Ideas?

By the way: Where do I setup die Angle PID when using AlexK? I've read somewhere, that the Level PIDs are not takein into Account?

krtek2k
Posts: 25
Joined: Mon Jul 15, 2013 10:57 am
Location: Decin , Czech Republic

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

Post by krtek2k »

Angle still using LEVEL PIDs , or am i wrong?

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

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

Post by -ralf- »

Angle is Level_P
Horizon is Level_I
Level_D is unused

The Copter will not arm when BARO is active. This is new since r1550 and by design ...... :D

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 »

-ralf- wrote:The Copter will not arm when BARO is active. This is new since r1550 and by design ...... :D

when you say baro, what you really mean is alt.hold, right? BARO is hardware support for a sensor, that gets configured in config.h to be compiled into the MWii hex. Altitude hold is one of the features which can be toggled on/off during flight. The sensor is used for other stuff besides altitude hold - and more to come.

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

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

Post by -ralf- »

Hamburger wrote:
-ralf- wrote:The Copter will not arm when BARO is active. This is new since r1550 and by design ...... :D

when you say baro, what you really mean is alt.hold, right? BARO is hardware support for a sensor, that gets configured in config.h to be compiled into the MWii hex. Altitude hold is one of the features which can be toggled on/off during flight. The sensor is used for other stuff besides altitude hold - and more to come.


Right .... I mean the switchable alt.hold .... when it is activated, disarmed copter can't get armed.

skytor
Posts: 48
Joined: Tue May 29, 2012 5:14 pm

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

Post by skytor »

Hi at ALL

Horizont mode ""broken"" ?

I used the 2.3 relase Kandiat (r1604)...
Mega Flyduino Megaboard (ATmega 2560) with Freeimu 0.43 on HEX6 config
with #define PID_CONTROLLER 2

no I2C error nothings all PID setting standart nothings changed
Angel Mode works ""normaly"" but the horizont mode do excatly the same ! no ""auto leveling"" back to horizont level after
stick motion in any direktion .... broken ? oder new ""feature"" ?

with #define PID_CONTROLLER 1 als works fine in horizont mode ...

best regards Thorsten

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 »

Hi Thorsten
Pid.controller 2 feels really different from #1. Do you compare to earlier versions of #2?
It seems it is new but Lready not supported anymore by the original author.
What coptertype do you run?
Maybe other #2 users can verify your observation.

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

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

Post by -ralf- »

With defaults HORIZON feels like ACRO. You need to increase
LEVEL_I, this controls the HORIZON-MODE ......

The pure LEVEL ist only controled by LEVEL_P and the Gyro-PID's,
LEVEL_I is HORIZON,
LEVEL_D is unused .....

skytor
Posts: 48
Joined: Tue May 29, 2012 5:14 pm

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

Post by skytor »

Hi @All

@Hamburger ... I used the 2.3 relase Kandiat (r1604)...
Mega Flyduino Megaboard (ATmega 2560) with Freeimu 0.43 on HEX6 config ;-)

@-ralf- test start today evening .. thanks !! results come tomorrow :-)

read you all tomorrow bye

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 didn't want to do another thread so I spam here... Well after the idea kicked off by BRM here: viewtopic.php?f=23&t=2624&start=10 I implemented a cascaded pt1 element for the D part (hoping that it is a pt2 element). The flighttest was really great. The D part will iron out instabilities / wobbles due to too high "P" VERY well. With a sufficient "D" value (I use "30" but may be different in mwii/setups etc) you can easily increase "P" (Roll/Pitch/Level) without wobbles of death or instabilities and have a better flying copter. So it increases the P range, before instabilities occur.
I did a quick patch for mwii Dev1639 just altering the "normal" controller (that's why this post is somehow OT) - but the same can be done with the alex.khoroshko controller as well. Since I have no flying mwii hardware anymore I can not test it. There are only some float point calculations that shouldn't increase the cycletime significantly.
The Variable "MwiiTimescale" is just something I use to keep the pids related to a cycletime of 3000 (and in the known range).
If you want to test out the sketch, please do an inhand test before, since I can not test it on mwii.
The Zip contains a "diff", only MultiWii.cpp is altered but all files supplied.

EDIT: It would be interesting to know, if that backport works so good on mwii as well.

Cheers
Rob
Attachments
MultiWiiVersionDev1639.zip
Added pt2 element for normal pid controller
(155.58 KiB) Downloaded 97 times

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

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

Post by brm »

i would not use it as it is not stable.
to much delay for the d-term is deadly.
also 180 degree phase response versa phase 90 is is deadly.
fun to test ;-)

Hasi
Posts: 10
Joined: Fri May 17, 2013 9:11 am

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

Post by Hasi »

I also tried out PID controller 2 and I'm looking forward to try FPV flying with it. The tuning was somehow easier than the original (or maybe I have changed). I made the mistake, that I enabled angle mode with the original LEVEL P and I value and it immediately started oscillating, which got out of control and crashed. I had to lower the LEVEL P to like 1/5th of the original value to get rid of the oscillations. I have attached my PID settings on a 350mm homebuilt H-Quad. The values are quite different, than with the original PID controller.
Attachments
pid.jpg
my pids
(32.43 KiB) Not downloaded yet

User avatar
Benik3
Posts: 25
Joined: Mon Aug 26, 2013 1:06 pm
Contact:

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

Post by Benik3 »

So this PIDs are not more developed by Alex?
I tried my first fly with quad yesterday. I used this PIDs and Angle mode. Sometimes it was strange.
What I found: Sometimes when I make big change of direction, the quad make "jump" like if it doesn't know, where it is/where to fly. Also Yaw change easily.
When I make change of direction to opposite (e.g. roll from right to left), the copter resist to change until it's levelled.
Sometimes it doesn't level itself very well and I must help it...

I want to try the Horizon mode + compare to PIDs v1..

nebbian
Posts: 67
Joined: Mon Jul 21, 2014 6:54 am

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

Post by nebbian »

I just tried this out, and it's way better than the original PID implementation. As others have said, you need to lower your Angle P value a lot otherwise it's very unstable. However once this is done the angle system seems a lot easier to tune, I had it snapping back to level quite nicely (unlike the original PID method). I'm a lot happier with this than the old PID system.

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 »

Benik3 wrote:Sometimes when I make big change of direction, the quad make "jump"


there seems to be a nice little overflow in alexk 2.3 D-term calculation.
replace
DTerm = (deltaSum*conf.pid[axis].D8)>>8;
with
DTerm = mul(deltaSum,conf.pid[axis].D8)>>8;
or with
DTerm = ((int32_t)deltaSum*conf.pid[axis].D8)>>8;

User avatar
Benik3
Posts: 25
Joined: Mon Aug 26, 2013 1:06 pm
Contact:

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

Post by Benik3 »

Thx for reply, I will test it in August :)

Post Reply