Suggestion for improvement to level code

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

Suggestion for improvement to level code

Post by shikra »

Intent - Try to get I to control return to perfect level as fast as desired but without overshoot. "Predict" when to slow down to a take into account momentum of frame, speed of rotation etc.

Suggestion - apply angular rate change algorithm to control better. Reduce I sum impact if rotational speed is too high. Reduce faster when approaching neutral attitude faster. Still allow I build up for unstable frames .

Current code - for angle variations, existing I method sums up and does not start to reduce until passing through neutral point. Momentum and the time for I to decay after this causes overshoot. A lot for high I values.
To mitigate we are all reducing I to minimise the impact and hide the issue.
For pure stable hover it is not a big issue, but as soon as start using controlled inputs such as level mode flying / GPS it is not optimal.


I have been running with this for a couple of month, but only recently had time to test fully and post. It's better than I expect. Almost perfectly matching wanted to achieve
Particularly important to have best stable mode setup now we are going with GPS hold and RTH.


Benefits I've noticed from testing:
-More precise feel flying in stable/angle mode.
-Almost eliminate wobble / overshoot situations caused by I
-Can run much higher values of I - stronger/faster reaction to deviations
-No impact to unbalanced frames - actually - is better. Can use stronger I and it sums up faster
-Should be largely frame/sensor independant - as its based upon rate of change
-Very tolerant of bad PI tuning


Negatives:
-Very small amount of memory
-Very small increase in processing time during stable mode
-Reduces speed of rotation. In practice not really seeing the impact.
I think negatives are worth accepting as this is core funtionality

Try it.......!

Put level p=0 and double level I to previously unflyable levels and see how it performs :)

For a quick tryout, replace this line near end of multiwii.pde:
errorAngleI[axis] = constrain(errorAngleI[axis]+errorAngle,-10000,+10000); // WindUp //16 bits is ok here

With this
// DEV - start of test code - use with precaution.
int16_t errorAngleDelta=0;
int16_t Iratecomp=0;
static int16_t olderrorAngle[4];
errorAngleDelta=olderrorAngle[axis]-errorAngle;
olderrorAngle[axis]=errorAngle;
Iratecomp=constrain(errorAngleDelta*50,-2000,+2000); // 50&2000 from empirical testing for an acceptable rate.
errorAngleI[axis] = constrain(errorAngleI[axis]+errorAngle-Iratecomp,-10000,+10000); // WindUp //16 bits is ok here
// DEV - start of test code - use with precaution.

If happy feel free to implement an optimised version!

Finally tested today with GPS Hold and RTH. No issues

Love to hear some testers feedback.



Suggest putting it on a switch so can switch of/on and compare the difference. It helps for
if rcData[AUX1] > 1700 {
int16_t errorAngleDelta=0;
int16_t Iratecomp=0;
static int16_t olderrorAngle[4];
errorAngleDelta=olderrorAngle[axis]-errorAngle;
olderrorAngle[axis]=errorAngle;
Iratecomp=constrain(errorAngleDelta*50,-2000,+2000); // 50&2000 from empirical testing for an acceptable rate.
errorAngleI[axis] = constrain(errorAngleI[axis]+errorAngle-Iratecomp,-10000,+10000); // WindUp //16 bits is ok here
}
else{
errorAngleI[axis] = constrain(errorAngleI[axis]+errorAngle,-10000,+10000); // WindUp //16 bits is ok here
}


.

aidensere07
Posts: 12
Joined: Fri Mar 16, 2012 3:47 pm

Re: Suggestion for improvement to level code

Post by aidensere07 »

Anybody tested this? I'd want to try it when ny flyduino frame turns up. shikra keep up the good work, 8-)

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

Re: Suggestion for improvement to level code

Post by Hamburger »

Hi shikra,
would this modified code also apply to yaw?
I find that when using MWii for a FLBL helicopter, the yaw is by far not as good as with a conventional 10$ HH gyro.
I would be very willing to test that code with one of my TRIs, but I am looking for a solution to the yaw deficiencies of current MWii. Unfortunately, Helicopters are not much fogiving wrt errors, there's so many parts that will break upon each failure.

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

Re: Suggestion for improvement to level code

Post by shikra »

@aidensere07 - I hope someone does try it out. For me at least its working really really well and the best improvement in level since it started to work well back around v1.5/1.6


@Hamburger - no sorry this doesn't work on the yaw. It has potential for baro/gps, but probbaly not acro stuff imho.

To me the acro mode and yaw is just perfect - but I'm not using on a fbl heli!

I've never had any yaw issues at all - and thats with 6 frames and as many controllers. Never used anything other than default PIDS. I set up tx trims to be 1500 and adjust mechanically - sensor aligned perfect + tilt/adjust motors - or servo on a tri.

Only time I have an issue is if leave mag on by mistake!!

What's the fbl yaw doing? Do you see same on a multi?

LuFa
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: Suggestion for improvement to level code

Post by LuFa »

Hi

i will test your change tomorrow :)
But i dont unterstand the following :

Put level p=0 and double level I to previously unflyable levels and see how it performs


with your chance i have to put the P term to 0 ?

Can you explain my what i have todo to use your code ?
I have Change the code and upload it (the method with switch via Aux channel) , what i have to change at the Level Parameter ?

sorry I'm a littlebit confused because i think level will not work without P term .

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

Re: Suggestion for improvement to level code

Post by shikra »

I do recommend using P - but you will probably be surprised at how well it works with p=0 :)

I'm always wary of posting PID's because each craft is different, but this is what I'm running with for stable AP style
P = 4.0
I = 0.020
D = 50
RC rate = .35 ( I did say its for slow smooth flight !!)
EXPO = 0.5

LuFa
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: Suggestion for improvement to level code

Post by LuFa »

ok , cool .
will test it tomorrow ;)

did you think its possible to use it also with Altitude Hold ?

can you tell my what exactly your code do ?
is it a art of dynamic I term ?

signal15
Posts: 37
Joined: Sat Jun 23, 2012 8:44 pm

Re: Suggestion for improvement to level code

Post by signal15 »

Isn't the Derivative term of the PID loop supposed to adjust for predicted future change? I haven't looked at the code, but the D term is supposed to take care of this.

thornton
Posts: 5
Joined: Thu Mar 01, 2012 11:20 pm
Location: Berlin, Germany

Re: Suggestion for improvement to level code

Post by thornton »

Hi shikra,

i tried your code today.
Works really well In windy conditions! Also i had less wobbling in level mode quickly going down (i never could get rid of it playing with PIDs).
I really would like to test it directly against traditional code. Unfortunatly compiling your code ( if rcData[AUX1] > 1700 { ... ) gives me:

MultiWii_dev_20120622.cpp: In function 'void loop()':
MultiWii_dev_20120622:980: error: expected `(' before 'rcData'
MultiWii_dev_20120622:989: error: expected `}' before 'else'
MultiWii_dev_20120622:996: error: 'else' without a previous 'if'
MultiWii_dev_20120622.cpp: At global scope:
MultiWii_dev_20120622:1022: error: expected constructor, destructor, or type conversion before ';' token
MultiWii_dev_20120622:1023: error: expected constructor, destructor, or type conversion before ';' token
MultiWii_dev_20120622:1024: error: expected constructor, destructor, or type conversion before ';' token
MultiWii_dev_20120622:1025: error: expected declaration before '}' token

Can you check this please? Thank you very much.

LuFa
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: Suggestion for improvement to level code

Post by LuFa »

Hi

have test the code today to :)

and it works great !

i fly with the Alexmos code R35 , is it possible to add this also in the Altitude hold mode ?

@thornton : its a small bug , try this one :

Code: Select all

if (rcData[AUX1] > 1700) {
int16_t errorAngleDelta=0;
int16_t Iratecomp=0;
static int16_t olderrorAngle[4];
errorAngleDelta=olderrorAngle[axis]-errorAngle;
olderrorAngle[axis]=errorAngle;
Iratecomp=constrain(errorAngleDelta*50,-2000,+2000); // 50&2000 from empirical testing for an acceptable rate.
errorAngleI[axis] = constrain(errorAngleI[axis]+errorAngle-Iratecomp,-10000,+10000); // WindUp //16 bits is ok here
}
else{
errorAngleI[axis] = constrain(errorAngleI[axis]+errorAngle,-10000,+10000); // WindUp //16 bits is ok here
}


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

Re: Suggestion for improvement to level code

Post by shikra »

@lufa/signal15its is indeed a variation on the D dampening method. Why it works so nice is that it provides more dampening when going faster and closer to level.
I tried numerous and sometimes overcomplex equations to try to produce the effect I wanted, but this simple one worked so well.

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

Re: Suggestion for improvement to level code

Post by shikra »

Thanks Lufa - beat me to it as I was typing. Doh... thats was a bit basic! error...
Good to hear to hear its working well for you. Thats 3 good feedbacks. Lets hope there are a few more!

I don't look at the Alt code at all - it's not really been something I've used or needed. I really don't know if its suitable.

This tweak gives me the stable mode flying I always desired and now GPS is a reality thanks to contributors such as EOSbandi , might have a look. Baro did work pretty good for me, but it would be nice to get it up there to compete with DJI.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Suggestion for improvement to level code

Post by Alexinparis »

Hi,

Note that the ACC code was greatly improved in the dev since the 2.0 code (mainly due to other CMPF factors and a floating point LPF).
So to obtain valid conclusions, it's important to compare things with the level code of the dev version and not the level code of 2.0

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

Re: Suggestion for improvement to level code

Post by shikra »

Agree - test one change at a time to be sure. Actually that's why I suggest to test on a switch to see the improvement clearly.

That said - its very sweet with latest!

signal15
Posts: 37
Joined: Sat Jun 23, 2012 8:44 pm

Re: Suggestion for improvement to level code

Post by signal15 »

Will this be rolled into 2.1? Or is 2.1 frozen?

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

Re: Suggestion for improvement to level code

Post by shikra »

Frozen

also we should see what feedback (both good and bad) there is first before Alex decides if worth including.

nicodh
Posts: 44
Joined: Sun Apr 08, 2012 1:42 pm

Re: Suggestion for improvement to level code

Post by nicodh »

Hi Shikra, I'm going to give a try in my naze32 quad to see if drunken sailor goes home. Keep you posted.

nicodh
Posts: 44
Joined: Sun Apr 08, 2012 1:42 pm

Re: Suggestion for improvement to level code

Post by nicodh »

Tried yesterday. It seems to work, but can't get read of the woobles. It's far more active than the original code. Need to do some more testing.

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

Re: Suggestion for improvement to level code

Post by shikra »

Thanks for feedback. At least its an improvement. I have a Naze32 and I remember having to change level P a lot. I think I had to reduce very low.

nicodh
Posts: 44
Joined: Sun Apr 08, 2012 1:42 pm

Re: Suggestion for improvement to level code

Post by nicodh »

Just coming back from the field. It still having problems to get a real level. Last degrees are fuzzy (sometimes it keeps drifting on hover). I think I have some woobles, but maybe due to my pid in gyro mode. (very stiff for accro).

I should try to slow down the accro mode first and then retest the level mode. But definitily better.

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

Re: Suggestion for improvement to level code

Post by shikra »

Sounds like you have an underlying issue there. I just saw the post in the Naze thread.
Naze wasn't nice for me in level mode either, but I didn't have chance to investigate fully. If no luck perhaps I'll put mine on a frame next week to try.

It's interesting to hear that this has helped regulate that a little. I can see how it might, but the assumption here is that level is reasonably working. Intended to resolve one particular flaw without impacting other areas.

Hope you resolve - let us know how you get one.

nicodh
Posts: 44
Joined: Sun Apr 08, 2012 1:42 pm

Re: Suggestion for improvement to level code

Post by nicodh »

MAybe this afternoon I give a new try. Trying to find better accro pid (less violent). I made some videos this morning, but they are upside down and not very explicit. I will try to upload one to you tube.

Edit: Just saw all the videos, it's crap since the fish eye of the go pro makes everything extremely away. Any of the videos is good.

Post Reply