Page 1 of 2

A different approach to levelling ? - drift killer?

Posted: Thu Nov 17, 2011 9:04 pm
by shikra
I'd like to suggest a different method for autolevel.. I call it LEVEL_LOCK

If you just want to try, change this in multiwii.pde near end....

PTerm = (int32_t)errorAngle*P8[PIDLEVEL]/100;
to:
PTerm =constrain((int32_t)errorAngle,-P8[PIDLEVEL],+P8[PIDLEVEL]);

Essential: Recalibrate acc to remove previous acc trim
Try a starting Level P of 4.0 and level I of 0.050


*************************************************************************************************************************************************************************************
Full detail:

If you are experiencing drift issues in level mode - this will help
If you are having to add quite a bit of acc trim even when calibrated as level, this will help

Principle:
- Fixed speed rotation to level - speed adjustable according to the flyers preference
- A very narrow adjustable band in which level position is known to be achieved ** later **
- Within this small band, proportional force is maintained to return to level ** defined as 1 degree at present **

I practice, what I was aiming to achieve is a nice controlled return to level, then lock it hard into position. I think this comes close to achieving that.

Benefits over current method:
- Should reduce previously raised odd drift issues to a minimum
- With suitable settings, prevents excessive force at extremes of tilt and overshoots creating wobble of death at take off / wild changes when in level mode.
- Maintains a more consistent / predictable force to return to level until it is achieved. Givel flyer more "feel"
- Maintains better level during full throttle punchouts
- Guaranteed to return to level within a reasonable time -
- Holds better in the wind
- Perfect for AV work - consistent level panning
- Acc calibration is much more effective. Trim may not be needed.
- When flying in angle mode (i.e. with level on permanently) should help maintain a better angle / stick position

Disadvantages:
- slightly increased code time. Quite small.
- increase in lock hold strength is at expense of more level twitching. Reduce until best compromise reached.
- may need more tuning than current setup

Initial code:

Change this in multiwii.pde

PTerm = (int32_t)errorAngle*P8[PIDLEVEL]/100;
to:
PTerm =constrain((int32_t)errorAngle,-P8[PIDLEVEL],+P8[PIDLEVEL]);

Essential: Recalibrate acc to remove previous acc trim
Try a starting Level P of 4.0 and level I of 0.050
Reduce / increase P until you get a steady return to level. Better not to have a very fast "snap" back to level with this method

(caveat - this is dev stuff. Do at your peril. test carefully - it's not fully optimised)
(Autolevel P becomes speed of rotation; 4.0 worked well for me; higher = faster return to level).
(NOTE~: recalibrate acc before using first time to remove any acc trim - otherwise will get false results)

Test results:
- Starting point - a calibrated (but not acc trimmed) Tricopter that experienced very bad drift ( alarming drift to left at large angle > 10 degrees)
- With proposed code change only, perfect level achieved quickly and was maintained.
- Attempts to create wobble of death failed
- Flying in gusty wind was noticeably different. Really "locked" into level so much more than drifty experiences before
- Angle mode flying (with level permanently on) seemed so much more precise
- Astonishingly easy to fly...


Why this is needed - the cause:

The current method is based upon a PI loop and is theoretically perfect to achieve a level mode.
The further away from level, the greater the force applied. This is reduced gradually as level is reached until theoretic position of perfect level is reached

In real world environment there are external factors which can create unequal forces on a multi-copter .
- ESC's, motors, props are never perfectly matched to each other.
- ESC's may not be perfectly calibrated
- Wind on one side providing a lifting effect under the prop
- CoG out of balance - battery positions etc.
- Differential in motor spacing

And the real issue and cause of "drift" ... and understanding the problem
First understand that the proportional effect of the current method provides a very weak force at low angles away from level.
Forces created by the external factors tip the copter over until the angle is large enough that feedback force created by the level equals that of the external factors. Hence the drifts....

That's all - so simple really. But It took me two evenings of serious effort reviewing the code...
Explains why there are varying feedback
Also note the acc trim is masking the issue for many. Also fixing for many.


Other improvements for consideration......


Lots can be done to provide different flying styles.
Remove angle constraints - so can loop, roll, then let go and watch it stabilise...
Reduce levelling for for larger stick moments - quasi acro/level mode. Good for staged learning to fly acro
Level mode switch - 3 positions - varying degrees of level lock strength / different modes

How about using something similar for baroalt? Maybe a variable constraint as approach hover?


Alex: over to you sir!! Hopefully this will help
You have better skills than me to optimise and integrate...... Also I have a new copter to finish

Re: A different approach to levelling ?

Posted: Thu Nov 17, 2011 9:09 pm
by shikra
Would love to hear some feedback if anyone dares to try it out... !!

Re: A different approach to levelling ?

Posted: Thu Nov 17, 2011 11:43 pm
by mr.rc-cam
I'm not the best person to test your code since my Quad doesn't have any issues with Level mode (it works very well as-is). But to offer some preliminary feedback, I tried your patch. One thing to note is that the code you want replaced lies within the LEVEL_PDF section. I have not used LEVEL_PDF before so I don't know how your patch would differ from unmodified code.

So I added your patch and defined LEVE_PDF. Then I went out for a test flight (hovering and slow forward flight). Here are my observations:

1) I noticed that when I enabled Level Mode there were random "level" attitudes. What I mean is that when I flipped the Level Switch on my Tx, sometimes the Quad would remain level and other times it would have a pitch or roll offset of a few degrees. It was random.

2) With my existing PID's, Level mode worked much differently than what I am accustomed to. For hovering in a fixed place it is very "snappy"; Quick stick jabs would quickly return to level -- A very interesting effect.

3) I did not feel comfortable with the feature in slow forward flight because it sort of got in my way of being the pilot. Perhaps more time with it would change things for me. Or maybe different PID values.

If Alex adds it then I would request that it be an option that was enabled via a define (or GUI) rather than be an out of box default for the Level mode. For sure, it will be interesting to hear from others that try it. I suspect some will love it and some might like the old way. The software can accommodate both. :)

- Thomas

Re: A different approach to levelling ?

Posted: Fri Nov 18, 2011 12:11 am
by shikra
Thanks for the feedback and test. Am glad it din't crash! was my worst fear.


mr.rc-cam wrote:1) I noticed that when I enabled Level Mode there were random "level" attitudes. What I mean is that when I flipped the Level Switch on my Tx, sometimes the Quad would remain level and other times it would have a pitch or roll offset of a few degrees. It was random.

So the question there is that as a result of fluctuations in the sensor results or maybe the PI being a bit off.
I would go with lowering P as below first
Decrease I singnificantly down to half - it will not harm.

mr.rc-cam wrote:
2) With my existing PID's, Level mode worked much differently than what I am accustomed to. For hovering in a fixed place it is very "snappy"; Quick stick jabs would quickly return to level -- A very interesting effect.

3) I did not feel comfortable with the feature in slow forward flight because it sort of got in my way of being the pilot. Perhaps more time with it would change things for me. Or maybe different PID values.


Definately decrease P. A lot - try half. Until rotation speed is how you like. Mine is very slow - maybe a complete rotation in 2 seconds . It becomes so easy to fly like that my wife could fly!

If its fast return like you say - that would be horrible to fly!! Usefull for hover only.

Would love to hear your feedback with tuned PI


This is raw code - not really intended to match current PI settings so expect tuning until new defaults for it are set!

Re: A different approach to levelling ?

Posted: Fri Nov 18, 2011 12:14 am
by shikra
I had cut/paste error in the first post - well spotted by mr rc-cam!!

It is updated, but note what it should read!

Change this in multiwii.pde

PTerm = (int32_t)errorAngle*P8[PIDLEVEL]/100;
to:
PTerm =constrain((int32_t)errorAngle*I8[PIDLEVEL]/100,-P8[PIDLEVEL],+P8[PIDLEVEL]);

Re: A different approach to levelling ?

Posted: Fri Nov 18, 2011 12:18 am
by mr.rc-cam
Am glad it din't crash! was my worst fear.

That was the main intent of my test. I wanted to offer some assurance that the code was safe so that others would be encouraged to try it. So let the games begin!

Change this in multiwii.pde
PTerm = (int32_t)errorAngle*P8[PIDLEVEL]/100;
to:
PTerm =constrain((int32_t)errorAngle*I8[PIDLEVEL]/100,-P8[PIDLEVEL],+P8[PIDLEVEL]);

When the dust settles I will patch the patch and try it again. If time allows I will play with the PID's too.

Re: A different approach to levelling ?

Posted: Fri Nov 18, 2011 12:45 am
by shikra
I though about your twitches - updated the disadvantages. It wil highlight issues with varying level angles
The good news is I can be reduced right back to give identical "twitch levels" to current levels! If you have too.

Edit - I changed code so please try the latest on the first post.
It should be much more consistent across different platforms

Re: A different approach to levelling ? - drift killer?

Posted: Fri Nov 18, 2011 2:08 pm
by shikra
Just to remind - this is dev code.

Please see latest update on post #1

the following should be ignored - for ref only

I just remembered I made another tweak I forgot about... I fixed my Level I value so I could use GUI to change angle
this line will be wrong too.

ITerm = ((int32_t)errorAngleI[axis]*I8[PIDLEVEL])>>12; //32 bits is needed for calculation:10000*I8 could exceed 32768 16 bits is ok for result

Maybe a different approach... keep the I. It is still relvant
and define the csize of the catch angle .

I'll try that approach and re-post
If using default I it should be OK anyway... but is not good

Re: A different approach to levelling ? - drift killer?

Posted: Fri Nov 18, 2011 2:35 pm
by shikra
OK, that works better as avery simple approac...

Replace:
PTerm = (int32_t)errorAngle*P8[PIDLEVEL]/100;
with:
PTerm =constrain((int32_t)errorAngle,-P8[PIDLEVEL],+P8[PIDLEVEL]);

Is much more consistent with current code. I was being too clever with the configurable angle - that can be done via define if needed. Otherwise int32 can be frome as well.

This aims to get level very close....

P is still autolevel speed/strength
I is as per original

Edit: what I do like about this approach too is that for higher values of P, the constrain provides a wider angle before starting to reduce the levelling force withing the "lock" area.

It tests well in the garden. Am looking forward to trying this in some real flying..

Re: A different approach to levelling ? - drift killer?

Posted: Fri Nov 18, 2011 4:00 pm
by Hamburger
Hi shikra,
sure sounds interesting but is a bit difficult to follow with all the changes and comments etc.
May I suggest you contact Alex and let him register you as a developer for the google rep.
That way you can
- supply your own branch of code for other people to download
- integrate it into the _shared section (this is meant as the base for Alex to integrate in main branch)

It does not really require extra work and has its advantages.

Re: A different approach to levelling ? - drift killer?

Posted: Fri Nov 18, 2011 4:31 pm
by shikra
Yes understand - and agree. This is a bit of a dev thread. I wasn't going to release until complete, but had nagging PM.....

Just look at first 10 lines of first post - it is probably good enough now to suit everyone.

So simple, but very effective

Re: A different approach to levelling ? - drift killer?

Posted: Fri Nov 18, 2011 9:01 pm
by UndCon
If my drifting issues are not gone with the latest 1.9 releases I will sure try this as I feel this would sort my stable issues.
I have to fabricate new alloy arms and assemble my Quad before I can test.

During this rebuild I added more features into the design like LED-strips now MultiWii controlled instead of manually by separate channel.
//UndCon

Re: A different approach to levelling ? - drift killer?

Posted: Sat Nov 19, 2011 11:42 am
by Alexinparis
Hi,

With the current code mod suggestion I understand:
- basically, it's still a PI loop
- P is little increased (no more P/100 for error coef), but very limited (limited by P, ie errorAngle limited by 4 degrees for a P = 4) => I understand the flip of the death protection here. I think the counterpart is a decrease speed to reach the target level.
- ITerm is the same as before

I'll give a try to test.
The Horizon mode I have in mind is different because the main control will be closer to acro mode (rate driven and not angle driven)

One thing however: I don't believe it could solve the drift problem we try to solve in 1.9, because it was mainly due to the angle calculation, and not to the control loop.

Re: A different approach to levelling ? - drift killer?

Posted: Sat Nov 19, 2011 1:27 pm
by shikra
Thanks Alex!

yes - I think you understand.

To counteract the causes of the drift (mentioned in first post), a non proportional force is needed. I was trying to simply produce an inverse exponential. This is an approximation of that. It is probably best shown on a diagram.
Yes, it will not return to level as quick, maybe 1 second per 90 deg. Could be faster with an if statement... , but I figure this is for level, stable mode so not really needed.

1st TEST FLIGHT: !!

If I had any doubts, they were completely dismissed this morning. Had first test flight and it is pretty impressive to fly in level mode compared to before.
If you don't experience drift now then might not notice, but my Tri I tested it with this morning suffers quite badly with it.

So with previous versions I would calibrate acc, but if tried to fly it would drift in one direction, gradaully getting more and more until crazy angle and speed.
If I applied acc trim I could get it to fly level, but when flying around I would find sometimes the stick would be hard over and it struggled to tilt in one direction. Not nice

So I went out this morning to give it a real world test.
Calibrated on level
No acc trim
Tri with all blades rotating same way.
Test tri - motors/props not particulalry well balanced.
The frame purposely unblalnced with battery too far forward.
I only changed P so the return speed felt right (4.0), I didnt change I or the angle
Entire flight was flown with autolevel on and it exceeded my expectations.
Very bad drift on this Tri was completely eliminated....

See what you think? Shot in narrow angle mode so it show up everything... I Needed to see the impact.
You can't tell from this, but the angle hold is just incredible. It really matches the sticks so well.
http://www.youtube.com/watch?v=tli_YfQIlaw

Without acc trim it does move a little bit to the one side. It was so minor I didn't even bother to trim...
Feels very much like more flying a RC plane. Holds the angle incredibly well.
Climb out under power much more level....
Wobbled less on descent. (this was particularly bad on teh test tri)
I am not the best RC flier, but I have never felt more comfortable flying it at a distance and low...
I would not have done that before - felt completely at ease
I think this will be very nice for FPV or AP....

The downside...
Only one - I see a very small and slow wobble as it tries to keep in the locked angle. It's less than I expected, but can be seen if loock hard.
But considering what it was like before it is a huge improvement

The real benefit wil only be felt by those with level/drift issue. And many of teh fixes are really related to the frame.
In my case, even though ESC's are calibrated, the power outputs are uneven. I proved by swapping motor and ESC to other side - drift changed sides... !

Re: A different approach to levelling ? - drift killer?

Posted: Sat Nov 19, 2011 5:33 pm
by shufflez
Hi Skikra,

I've just tested your latest LEVEL_LOCK code, and whilst it levels perfectly, i still experience drift in direction of last user input.
Having flown an entire battery with LVL switched on (only with ACC calibrated, not trimmed), I find that even on stick jabs it'll level quite nicely and respond properly a bit smoother than the original code!
Except for when i release the stick, although it'll level out mostly, it still goes the way I've last directed it, so maybe not actual drifting :)

Something to do with my stock PID values? Or hardware? Or software configuration?

BTW this test flight was indoors.
PID's are on 4, LEVEL PID is 4 too, should that be increased?

EDIT:
Settings when testing LEVEL_LOCK
Settings when testing LEVEL_LOCK


EDIT 2: Found other strange issues: when trimming ACC it flies well, as soon as i turn off LVL and turn it back on, it'll start drifting again. And with LEVEL PID on 5.5 it did a flick of 'death' again... :( Luckily no damage. I can now reproduce the issue too; whenever i give more than 30% stick input in any direction and release it, it goes crazy.
When I'm up high enough it'll sometimes recover just before impact. Otherwise, when I'm hovering low and increase throttle quickly, it jabs into one direction, i'll correct it, and then it goes crazy again :).
Lift off with LEVEL causes it to go in any direction too.

Hurray for the disarm switch! :)

Re: A different approach to levelling ? - drift killer?

Posted: Sat Nov 19, 2011 5:55 pm
by Duguy
Hi Skikra,
I've just made a rapid test with your mod and really appreciated enhancement.
My quadri had very bad drifts in level mode that I couldn't explain. (Acc calibrated and almost trimmed) in different directions... I was loosing the latin I never had on it.

After your mod here is my observations:
- First take off is almost good, still a very small drift rear with acc calibrated, nothing to see with initial behaviour.
- With P:4 I:0.05 Still a drift in the last direction for few seconds that seems to correct it self solwly if I don't touch sticks (but few seconds may represent a huge distance)
- Still a recurrent small rear drift when autoleveled, but at least, this is coherent compared to original approach and not sure of perfect Level for initial calibration.

Played a little bit with increasing P until 4,8 but still globally same behaviour.

Thanks for this drift discussion, I think it could lead to something very interesting...

Re: A different approach to levelling ? - drift killer?

Posted: Sat Nov 19, 2011 10:06 pm
by shikra
Shufflez - so sounds liek you are saying the level is better?
I'll take a look at the other comments - see if I can replicate them. I haven't seen anything like that at all. I will have a look at how it works in conjunction with the other elements of code in the PID axis section.

Duguy
I do you mean sliding effect . I don't think anythink can correct for that except maybe more sensors/gps !

slight tilt in some direction will be evident is something is up as per the causes in the first post, but can be removed further by putting a multiplier in front of errorangle. e.g. *120/100 will decrease hold angle (tighter lock). *80/100 will increase the angle. small angler angle may increase woblle or bounce inside. Its a compromise.

Re: A different approach to levelling ? - drift killer?

Posted: Sat Nov 19, 2011 10:11 pm
by shikra
OK - more results in ...

Maiden FPV flight.
Same settings as first flight. Absoloutely no acc calibration.....

See what you think!
(BTW - this is test flight/fogged up lens/purely to see how it flies. Not going to see award winning stuff. Might see a couple snogging in the woods though. Bet that was a shock!

http://www.youtube.com/watch?v=XPf_DwzgAVQ

Re: A different approach to levelling ? - drift killer?

Posted: Sun Nov 20, 2011 12:20 am
by shufflez
Level is a lot better! But still the annoying flicks... What are your PID settings? Will LEVEL_LOCK work on 1.8p2 BTW? :)
Last flick caused me to burn out an ESC (or so it seems, motor spins up, but stops under load).

Your video looks amazing!! Great stuff Shikra!

Re: A different approach to levelling ? - drift killer?

Posted: Sun Nov 20, 2011 1:13 am
by UndCon
video looks very stable with a bit of side to side wobble.

Much better IMO - I must repair my Quad tomorrow and see wow it goes

My Quads are medium sized with 30cm long arms running KDA 20-22L and 10" props.

Suitable testbed?
I don't mind taking off in level mode or flying most of the time like that as FPV/aerial photo is my intentions.


//UndCon

Re: A different approach to levelling ? - drift killer?

Posted: Sun Nov 20, 2011 7:00 am
by mahowik
Hi Shikra,

Thanks for your idea!
As I understand the main goal here to control the reaction speed to achieve necessary inclination.

I'm sure you know but just FYI, as I have experienced, you can achieve almost the same by set big "D" (it's related not only for acro but also for stable mode) value.
Try to use 40-50 for "D" for ROLL and PITCH...

P.s. "D" parameter is not classic in MultiWii in terms of PID regulator knowledge...

Re: A different approach to levelling ? - drift killer?

Posted: Sun Nov 20, 2011 4:45 pm
by PatrikE
I tested this mod to day.
Managed to fly a full acc in stable mode for the first time ever.

I will set up and test the difference and make it possible to switch between the modes in flight.

Code: Select all

      #ifdef LEVEL_PDF
      if(AUX2>1700){
      PTerm      = -(int32_t)angle[axis]*P8[PIDLEVEL]/100 ;}    // The orignal way
        else{
      PTerm =constrain((int32_t)errorAngle,-P8[PIDLEVEL],+P8[PIDLEVEL]); } // The Shikra Way
      #else
 


/Patrik

Re: A different approach to levelling ? - drift killer?

Posted: Sun Nov 20, 2011 5:37 pm
by KeesvR
I've tried this drift killer, but I've got much more drift.

First i had to lower level P to 1.5 to get rid of the wobble I have with P 4.
The level I lowered to 2.
I needed a lot of trim to the left to get rid of the drift, but at take of i need to correct this.

Alex version i fly with level P at 4 and I at 0.
Need some trim to left front.

This version was not an improvement for me.

Re: A different approach to levelling ? - drift killer?

Posted: Sun Nov 20, 2011 7:53 pm
by copterrichie
KeesvR, which Acc are you using please?

Thanks

Re: A different approach to levelling ? - drift killer?

Posted: Sun Nov 20, 2011 8:47 pm
by shikra
mahowik
- yes all about controlling the amount of force to return to level.
The constrain keeps the same rotational speed until returns back to approx level - this is the "lock" angle. The effect I am after is to allows a higher P value near to level, but the constarin prevents over controlling outside
Once inside this, the P reduces proportionaly to zero at dead level.

At the moment, the size of the angle is related directly to P. Really it is best if this is tunable. Different copters will work better with different angles.
So the code here is really not quite how I intended - but enough for people to try out. Kept it simple, whereas really now I wish I had put it out properly - if guys are tweaking already, then a little more shouldn't be a problem.

In my original post I used Autolevel I on the gui to change the angle. And fixed the real I value to what I used. 0.010 worked best on my particular setup. But forgot I fixed the original I !! So put out an alternative.

D interests me on this one for autolevel. Having time to test is the issue for me...

Re: A different approach to levelling ? - drift killer?

Posted: Sun Nov 20, 2011 8:53 pm
by shikra
PatrikE - that sounds good. How much better is it?

Nice idea on the tx - actually I have similar setup. midrange = using error angle and >1700 for angle[axis]+trim.
In effect three switch positions are acro/stable with rc control/full stable no RC.

Re: A different approach to levelling ? - drift killer?

Posted: Sun Nov 20, 2011 8:57 pm
by shikra
Keeves - thats dissapointing result for you.

What sort of wobble is it? fast/slow.
And if you tilt a long way to the side, does it move back to level quick or slow? I aim for 90 degrees in about 0.5-1 second.

Re: A different approach to levelling ? - drift killer?

Posted: Sun Nov 20, 2011 9:08 pm
by shikra
Bit of a naughty mad flight today. I wouldn't have attempted this with the drift I had before.

The sidewind was quite strong at one point - so is you see it at an angle - it's probably pilot induced!
There was an inexperienced pilot flying his plane and he was blown downwind and struggling to get back so I had to take the tx off him. Could hardly see it in the distance.

http://www.youtube.com/watch?v=Fzk7v4Nyp50

Re: A different approach to levelling ? - drift killer?

Posted: Sun Nov 20, 2011 9:20 pm
by shikra
Just want to restate something guys...

I am sure that for those that calibrate level, but that it drifts considerably in the same direction, then you have an issue such as balance - or uneven thrust on one motor.
This is my problem too - It's not fixed because I want to use it as an opportunity to try to improve the stability via software.#

What we need are few more ideas to try different approaches to this! If you have them please share!

Re: A different approach to levelling ? - drift killer?

Posted: Sun Nov 20, 2011 9:51 pm
by KeesvR
@ Copterrichie: I use the BMA020, I think I need something else.

@ Shikra: A fast wobble, this is the same as a high level P by the normal code.
It moved back slow, I did a short inside test.
For level I like slow reaction, but this looked like slowmotion for me.

For more info I need to test something better, I was a bit disappointed, because Jevermeisters way is also not working for me.

Re: A different approach to levelling ? - drift killer?

Posted: Mon Nov 21, 2011 2:07 am
by ziss_dm
Hi Shikra,

Why this is needed - the cause:

The current method is based upon a PI loop and is theoretically perfect to achieve a level mode.
The further away from level, the greater the force applied. This is reduced gradually as level is reached until theoretic position of perfect level is reached

In real world environment there are external factors which can create unequal forces on a multi-copter .
- ESC's, motors, props are never perfectly matched to each other.
- ESC's may not be perfectly calibrated
- Wind on one side providing a lifting effect under the prop
- CoG out of balance - battery positions etc.
- Differential in motor spacing

And the real issue and cause of "drift" ... and understanding the problem
First understand that the proportional effect of the current method provides a very weak force at low angles away from level.
Forces created by the external factors tip the copter over until the angle is large enough that feedback force created by the level equals that of the external factors. Hence the drifts....

I think, you have small missunderstanding of the current control strategy.. ;) Would you like to discuss it first? ;)

regards,
ziss_dm

Re: A different approach to levelling ? - drift killer?

Posted: Mon Nov 21, 2011 10:40 am
by shikra
Hi ziss
For sure - always open to viewpoints. Full understanding of the issue is the best way to provide a solution. Would have have been better maybe to start post with "what can we do to help those with level issues....
Also I notice from some of the posts I have read recently there are maybe a few interpretations of what drift is.

Also for simplicity of explanations a few liberties were taken... like I level windup

Which bits am I missing? or misunderstood.
Just want to re-iterate, I think the code is good as is, but if can't resolve issues that cause the drift at source, then maybe we can do something in the software algorithm - usually at the expense of another part of its performance.

Like to hear your thoughts...
For me three areas areas seem to be the most consistent raised.
Better avoid "twitching" from noisy/dodgy chips. Can be expensive for the guys to keep trying different boards - or throw away a $100 board
The drift issue
Firmer baro hold. I am not using yet, but soon....

And looking forward so much to ...
GPS ... RTH/HOLD

All will come with time. .

Re: A different approach to levelling ? - drift killer?

Posted: Mon Nov 21, 2011 3:30 pm
by shikra
Hi,
thought I'd try some modelling to visualise the forces to return to level. so can see better impact.

Starting with P level... becaus eit's easy!

Image

So for guys running with higher P's the simple version of this code is going to have less impact quicker than I thought on the drift.
So definately need to go back to my original plan so get the max benefit which is a is only a little more effort.. and if your here reading and tweaking then already it's not an issue...

I'll post shortly...

Re: A different approach to levelling ? - drift killer?

Posted: Mon Nov 21, 2011 7:53 pm
by shikra
OK, so this is what I was originally intending from the first post, but in trying to make it simpler it didn't work across all values people are using.
**I haven't uploaded to a board and tested - so at your own peril** Tied up with work at moment, so not able to test for a couple of days.

constrain((int32_t)errorAngle*P8[PIDLEVEL]/ANGLE,-P8[PIDLEVEL],+P8[PIDLEVEL])

ANGLE is 040 for +-4 degrees
(info: 100 would give same levelling strength as existing code for angles less than 10 degrees, but for angles >10 degrees it would keep that same strength as 10)

Suggest following defaults as starting points..
Autolevel P - 4.0 (Higher = faster return to stable = more strength as before)
Autoloevel I - 0.040 (As per before)
ANGLE 040 (Lower = better lock, but more likely to get small fast shake. Best compromise as always)

The model looks good in excel, but its easy to get something wrong, so suggest carefully testing with something you can afford to loose!!
If you dare try before me, let me know!

This should work better for teh different configs...

Re: A different approach to levelling ? - drift killer?

Posted: Tue Nov 22, 2011 3:49 am
by ziss_dm
Hi,

I would suggest to start from begining. So, the rate PID controller:

Image
RatePID.png
(4.38 KiB) Not downloaded yet


The purpose of this controller is to stabilize angular rates. In simple words that means: you push the stick, it starts rotating. You release sticks it stops. This controller also should be able to cope (till some extent) with all kind external factors which can create unequal forces on a multi-copter. This is bekause of I term. Properly tuned, and you can archive something like this:
http://www.youtube.com/watch?v=n_g2s1nc ... rofilepage
As you can see, this is higly unballanced system and controller able to compensate it.

Now, the level PID:

Image
LevelPI-PD.png
(8.07 KiB) Not downloaded yet


As you can see from the picture, this is actually 2 PID controllers: We still have Rate PID which supposed to stabilize angular rates, and we have level PID controller, which controls angular rates. We also removed I term from the Rate PID and now it is replaced by values from Level PID. As I understand, this lead us to the following:
1) This design works really well in case you have finelly tuned Rate PID and it is able to compensate all external disturbances (and not oscillates by itself). In this case adjusting Level PI is just your personal preference how fast you want return to level
2) The maximum I value you able to put in Rate PID in rate mode dictates the maximum value of the Level PI can produce not causing oscillation.

https://controls.engin.umich.edu/wiki/i ... iderations
Cascade control is best when the inner loop is controlling something that happens at fairly high frequency. Cascade control is designed to allow the master controller to respond to slow changes in the system, while the slave controller controls disturbances that happen quickly. If set up in reverse order, there will be a large propagation of error. Hence, it is important to maintain the hierarchy of information. In summary, the master controller responds to SLOW changes in the system, while the slave controller responds to the high frequency, or FAST changes in the system. This also requires that the inner control scheme be tuned TIGHTLY so error is not allowed to build.


to be continued..

regards,
ziss_dm

Re: A different approach to levelling ? - drift killer?

Posted: Tue Nov 22, 2011 11:12 am
by shikra
Hi Ziss_DM

yes - I agree with you 100% for the diagram - it explains visually very well. It is my understanding too. I have read through the code so many times to understand last week my head hurt.


I think maybe I have explained my suggestion badly: (and my revised post probbaly confused matetrs....)

It's only about controlling the level force a bit more. If your copter already levels well this is not needed. Although may help a little

I believe one of the "drift" issues is related to a multirotor tipping slightly to one side in level.
This is because of unequal force from balance / motor thrust pushes it over slightly.
Closer to level, the force from the code becomes much weaker due to it being related to size of the angle of error.
At some point the force generated by the code = unequal force on the multirotor. This becomes the tilt angle for level - and it drifts off in that direction.

Level I could be used to solve this in perfect world , but it has to be constrained to avoid bad issues... is not generating enough force to overcome the tilt

I have one motor/esc combo which although calibrated the same is generating more thrust and causing the tip. Adding acc trim solves it, but only perfect at one throttle setting. On high throttle, the tri tips one way, and on low the other...
It's only a little, but when testing and turning down P and I it became very pronounced - which is what lead me to investigate further.


Actually I think a constrained level P + I -D combination would be interesting. Help prevent flips/out of control scenarios with gyro too. I wonder what that would feel like to fly.
But I think Acro is perfect now. Wouldn't want to change it.

I have to say that flying mine in level mode slowly now is a much nicer experience with this method....

Any other ideas? You have come up with some great suggestions.....

Cheers,
Shikra

Re: A different approach to levelling ? - drift killer?

Posted: Tue Nov 22, 2011 11:25 am
by jevermeister
@Kees: My Inbflight calibration is not intended to fix a drifting copter. The drift problem is not a calibration problem.

My Idea just helps to calibrate the acc inflight given the fact that you never have even ground or a precisely built copter to do the calibration without trimming afterwards. So if you calibrate inflight you will have calibrated it to the point where there is no drift induced by inbalancies and the lack of trimming. So you do not need to trim afterwards. I think trimming is very anoying. Fly, land trim, fly land trim a.s.o.

The drift problem we are fighting with is induced by something else - but I am not good enough with the code yet to help finding it. But I am working on improving my knowledge.

Nils

ps.: for my setup, the drift issue is gone since 1.9fix2.

Re: A different approach to levelling ? - drift killer?

Posted: Tue Nov 22, 2011 12:38 pm
by ziss_dm
Hi Shikra,

I believe one of the "drift" issues is related to a multirotor tipping slightly to one side in level.
This is because of unequal force from balance / motor thrust pushes it over slightly.
Closer to level, the force from the code becomes much weaker due to it being related to size of the angle of error.
At some point the force generated by the code = unequal force on the multirotor. This becomes the tilt angle for level - and it drifts off in that direction.


The Level PI controller is not producing forces, it is controlling the rate PD controller with commands like this:
- now we need rotate left with rate 3deg/sec
-left 2deg/sec
-stop
-right 1deg/sec
-...
And the rate PD should be tuned "tight" enough to be able to follow. From this point of view increasing Level P just makes everything quicker and cannot cure drift. To cure drift, you need to increase Rate P/and or Level I. (On screenshot of your gui I saw P=3. Why not higher?)

Remember this video?
http://www.youtube.com/watch?v=5pvjKDa6dC4


From other point of view, current implementation of level PI expects level P around 10. Everything lower - you loosing resolution. With level P=3 you get resolution around 0.3-0.4 deg (instead 0.1 deg)

Also in your screenshot one of the stick is not 1500. Is it supposed to be like that?

regards,
ziss_dm

Re: A different approach to levelling ? - drift killer?

Posted: Tue Nov 22, 2011 6:36 pm
by shikra
Thanks for taking the time to read and respond. I like to read all the post from you guys.

mmm - I have a slightly different view of the Level force.

Agree totally the zig/zag to 0 degrees, but I wouldn't say that level rate really fully controls the gyro rate control. Related true, but it does provide the prime directional force. Reduced or increased by the gyro control

Perhaps this is why. I think of the following scenarios :
1 - maintaining required angle (e.g.level).
2 - returning to required angle (..)
3 - angle mode flying - maybe this is covers both 1 and 2

With 1, it is as you say - zig/zag. gyro + level "force"(!!) Both gyro and acc push to return to zero
With 2, imagine flying at 45 degree angle for some time (and gyro data becomes zero), then letting go of stick so RCcommand=0, Level force tries to return to zero, but gyro data tries to stop the change... Level force must be higher.


Agree High P and I makes for nice tight level.

Not sure about the stick at 1500 - I guess that was something I posted elsewhere? Is not in this thread. I may have been playing with controls when the screenshots were snapped. They are all subtrimmed to 1500 if I recall with a deadband of 6 as I have a bit of pot noise like many.

Level P is at 3 because default it is wild overcontrolling and flips.
It is a small tri - short booms, but big motors and props. For lifting gopro / fpv gear - and in tight places.
5 is nice for maintaining nearer level, but in flying FPV, the snap back to zero is just too strong. I have to reduce to 3 for it to be slow.
It still drifts at an angle, but is much much less at 5

The angle resolution is interesting though... I need to understand that a little better.

Anyway, back to my original point -
The real issue is to do with the airframe. It's not the code. That is real good... really.
But for those who do not realise / cannot fix, the force from level P and I at small angles is just not enough to fully overcome and return to level.

I believe this method is a way to help overcome that a little and effectively use a higher P values. Which is as we both recommend for - but maybe is too much .

Yes, I remember the video - awesome! That is what mine is like in level, but it is big and heavy - 4000 battery / gopro/fpv tx and osd... So not change quite so quick. Or aerobatic!


So do you think there is a fundamental flaw here?
It has certainly made mine much more enjoyable to fly and level is much better,

I think if anyone is suffering drift I can say for sure...
Balance can be a cause
Don't assume even calibrated motors/ESC's provide the same lifting forces. Always tilting on a fast climb is a good indicator...


Cheers!
Shikra

Re: A different approach to levelling ? - drift killer?

Posted: Tue Nov 22, 2011 10:19 pm
by KeesvR
jevermeister wrote:@Kees: My Inbflight calibration is not intended to fix a drifting copter. The drift problem is not a calibration problem.

My Idea just helps to calibrate the acc inflight given the fact that you never have even ground or a precisely built copter to do the calibration without trimming afterwards. So if you calibrate inflight you will have calibrated it to the point where there is no drift induced by inbalancies and the lack of trimming. So you do not need to trim afterwards. I think trimming is very anoying. Fly, land trim, fly land trim a.s.o.

The drift problem we are fighting with is induced by something else - but I am not good enough with the code yet to help finding it. But I am working on improving my knowledge.

Nils

ps.: for my setup, the drift issue is gone since 1.9fix2.


Yes I know, i called it drift but it isn't I said it wrong. It is out of trim.
Drift in my understanding is when it drifts away in different directions when when the trim is set right.

When i set the trim right in V1.9 it stays really good in one place.
I had the drift as i described in V1.8.

I think there is some misunderstanding about what drift means.
Correct me if I'm wrong.

Kees.

Re: A different approach to levelling ? - drift killer?

Posted: Wed Nov 23, 2011 12:14 am
by UndCon
If I calibrate acc and gyro on my floor I expect the copter to at least try to get same level during flight in both acro and stable mode
If not it is drifting in any direction and should not really be needed to compensate for.
//UndCon

Re: A different approach to levelling ? - drift killer?

Posted: Thu Nov 24, 2011 4:19 pm
by matbogdan
How about the fuzzy ... can we use this for autolevel ?
The different approach will be to use the fuzzy logic (easier to understand by humans) and we will have to control how fast the fuzzy logic compensate the auto-level with a step granularity calculation.
I remember at some point i was doing some Ball on Plate with fuzzy logic and worked like a charm to keep a ball on a defined position.
I think we could use the Ball on Plate fuzzy logic example to get the auto-level more human like feeling considering that some of the variables we are dealing with are still ... hmmm... fuzzy. This will solve lots of problem you get with PID control loops.
I will try in December to code something like this when i will get my hands on a new 9DOF sensor plate, or if someone else have the time to seek this alternative ... i will be glad to let him.

The pro for fuzzy logic is that is easy to setup and understand, based with experiments, will be the same results for everyone once is done no more crazy like PID adjusting.
The cons is ... i do not know ... maybe someone find the cons.

Re: A different approach to levelling ? - drift killer?

Posted: Mon Nov 28, 2011 7:55 pm
by mahowik
Hi matbogdan,

Are you going to use Artificial Neural Nnetwork (ANN) for this?
How you are going to "train" the copter? :) What will be the input data for this and how you will say to system that is correct behavior for that inputs? I mean that you should be verrryyyy good pilot to train ANN on the flight! :))

Also are sure that Arduino can do that work?! I'm talking about memory on board and microcontroller power...

thx-
Alex

Re: A different approach to levelling ? - drift killer?

Posted: Tue Nov 29, 2011 2:13 am
by matbogdan
mahowik wrote:Hi matbogdan,

Are you going to use Artificial Neural Nnetwork (ANN) for this?
How you are going to "train" the copter? :) What will be the input data for this and how you will say to system that is correct behavior for that inputs? I mean that you should be verrryyyy good pilot to train ANN on the flight! :))

Also are sure that Arduino can do that work?! I'm talking about memory on board and microcontroller power...

thx-
Alex

Fuzzy logic is not a learning architecture... is not actually a artificial intelligence. Fuzzy logic is a logic ... http://en.wikipedia.org/wiki/Fuzzy_logic better read this page.

So if you really understand fuzzy logic, you will see that is somehow suited for our problems ... auto level the drone.

Is just an idea ... that i will try to explore and post the results here. Problem sounds like this: i can read the x/y inclination (input variables) and i want to hold them in a limit value (desired position) by adjusting the output (motors throttle).
Is working similar to PID control but is easier to process and understand by humans. No abstract mathematics involved....

Re: A different approach to levelling ? - drift killer?

Posted: Tue Nov 29, 2011 3:54 pm
by mahowik
matbogdan wrote:that i will try to explore and post the results here. Problem sounds like this: i can read the x/y inclination (input variables) and i want to hold them in a limit value (desired position) by adjusting the output (motors throttle).
Is working similar to PID control but is easier to process and understand by humans. No abstract mathematics involved....


Hmmm... It sounds very interesting!
So pls. create a new thread for your idea to avoid the lost...

Re: A different approach to levelling ? - drift killer?

Posted: Fri Dec 02, 2011 3:07 pm
by pen
Just tried Shikra's code mod and for the first time, I flew my whole 7 minute pack in level mode! Thx for sharing

Re: A different approach to levelling ? - drift killer?

Posted: Fri Dec 02, 2011 4:54 pm
by shikra
Thanks for feedback and trying. I have been a little busy so not able to follow up this last week. I have finished all my testing and will post a final conclusion on Monday.
Will make it a little simpler, but keep to same principle - higher PI near center, but constrained maximum away to prevent too strong force.

How did you find it it to fly with? What did you like / dislike?

I have been quite pleased with the results, but at least I now know why I had drift on one copter.

Re: A different approach to levelling ? - drift killer?

Posted: Sat Dec 03, 2011 6:25 pm
by pen
I flew it on my small tri with 8" arms. Attached is a screen capture of the GUI settings. Level P was set at 6.0 and I was set at 0.006. Return to level was a bit slow but always returned. I might like it a little quicker but its OK. There was a little bit of wobble once in a while but it was barely noticeable and not an issue. I liked it but only have the one full battery of flight time on it. Will let you know what I think when I get a few more flights. About time to put FPV gear on it and give it a try.

I don't have a lot of multirotor flight time but I have about 2000 flights of 3D heli time. My tri flies quite like a collective pitch heli when its in rate mode (gyros) and like a coax heli when its in level mode. I can't get altitude hold set correctly now.

Re: A different approach to levelling ? - drift killer?

Posted: Thu Dec 08, 2011 11:39 am
by shikra
After a bit of testing, I really do like this option

This would be my final suggestion...
Simple minor change
Gives same effect as what I was trying to achieve without the complexity or understanding

Either permanent change or a #Define as alternative levelling option

Use currently unused "level D value" on the GUI /LCD setups to control the max rotational speed in returning to level .....

replace
PTerm = (int32_t)errorAngle*P8[PIDLEVEL]/100;
to:
PTerm = constrain((int32_t)errorAngle*P8[PIDLEVEL]/100,-D8[PIDLEVEL],+D8[PIDLEVEL])

A high D8[PIDLEVEL] would give same levelling as current method - so it could be made permanent

Suggesting a default of 100 and Reducing down to a real world value in range 30-100 will provide a much more controlled return to level.
Would allow a higher Level P value than normal to help those with certain drift issues
VERY nice for flying in level / angle mode - removes those unsettling sharp return to level situations

(note as D8[PIDLEVEL] isn't a used value in the published code so you will need to it will need to be set somewhere to test!! )



Any thoughts??

Re: A different approach to levelling ? - drift killer?

Posted: Thu Dec 22, 2011 12:20 am
by Noctaro
Hi Shikra,
i would like to test your latest attemp for level lock, i found the line that needs to be replaced,but i am not sure where and how to set D8[PIDLEVEL], may you help me out?
D8[PIDLEVEL] = 100;
Would that be the correct line?
Sorry i am a coding noob...

greetings
Noctaro