Page 6 of 6

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

Posted: Thu Aug 08, 2013 6:23 pm
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.

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

Posted: Thu Aug 08, 2013 7:37 pm
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.

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

Posted: Thu Aug 08, 2013 7:58 pm
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?

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

Posted: Thu Aug 08, 2013 8:02 pm
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.

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

Posted: Thu Aug 08, 2013 8:32 pm
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.

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

Posted: Thu Aug 08, 2013 9:06 pm
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.

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

Posted: Fri Aug 09, 2013 12:18 pm
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 :)

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

Posted: Fri Aug 09, 2013 10:35 pm
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.

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

Posted: Sat Aug 10, 2013 8:03 am
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!

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

Posted: Sat Aug 10, 2013 3:21 pm
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.

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

Posted: Sat Aug 10, 2013 11:08 pm
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.

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

Posted: Sun Aug 11, 2013 5:01 pm
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.

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

Posted: Tue Aug 13, 2013 9:20 am
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.

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

Posted: Wed Aug 14, 2013 2:50 am
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.

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

Posted: Wed Aug 14, 2013 10:32 am
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.

Posted: Wed Aug 14, 2013 11:55 am
by BarneyG
Did you start at defaults for I and D or did you reduce them to 0 first ?

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

Posted: Wed Aug 14, 2013 1:23 pm
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.

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

Posted: Thu Aug 15, 2013 11:17 am
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?

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

Posted: Thu Aug 15, 2013 11:36 am
by krtek2k
Angle still using LEVEL PIDs , or am i wrong?

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

Posted: Thu Aug 15, 2013 11:46 am
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

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

Posted: Thu Aug 15, 2013 5:46 pm
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.

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

Posted: Thu Aug 15, 2013 5:56 pm
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.

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

Posted: Tue Nov 05, 2013 8:26 pm
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

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

Posted: Wed Nov 06, 2013 7:51 am
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.

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

Posted: Wed Nov 06, 2013 3:47 pm
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 .....

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

Posted: Thu Nov 07, 2013 10:43 am
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

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

Posted: Fri Dec 13, 2013 2:36 am
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

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

Posted: Mon Dec 16, 2013 4:53 pm
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 ;-)

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

Posted: Sat Jan 11, 2014 4:11 pm
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.

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

Posted: Fri Feb 21, 2014 3:04 pm
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..

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

Posted: Tue Jul 22, 2014 3:50 pm
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.

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

Posted: Tue Jul 22, 2014 4:11 pm
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;

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

Posted: Tue Jul 22, 2014 7:57 pm
by Benik3
Thx for reply, I will test it in August :)