A different approach to levelling ? - drift killer?

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

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

Post 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

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

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

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

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

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

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

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

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

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

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

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

Post 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

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

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

Post 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

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

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

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

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

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

Post 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

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

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

Post 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

KeesvR
Posts: 194
Joined: Fri May 27, 2011 6:51 pm
Location: The Netherlands

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

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

User avatar
UndCon
Posts: 293
Joined: Mon Feb 21, 2011 2:10 pm

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

Post 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

User avatar
matbogdan
Posts: 29
Joined: Wed Nov 23, 2011 9:35 am
Contact:

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

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

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

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

Post 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

User avatar
matbogdan
Posts: 29
Joined: Wed Nov 23, 2011 9:35 am
Contact:

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

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

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

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

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

pen
Posts: 3
Joined: Tue Oct 04, 2011 6:45 pm

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

Post 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

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

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

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

pen
Posts: 3
Joined: Tue Oct 04, 2011 6:45 pm

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

Post 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.
Attachments
Capture.JPG

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

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

Post 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??

Noctaro
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am
Contact:

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

Post 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

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

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

Post by shikra »

I'll provide a version over the hols if you want.
Mine is done very much on the fly without savingg or coding properly to release

Noctaro
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am
Contact:

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

Post by Noctaro »

Hey,
i tested the code line you posted in your first post.
It seems to work. I still got some noticable drift, but the overall performance if flying smooth and slow seems a way better now.
I can handle the drift at least.
:)
Its kind of a strange feeling, if i see my quad stabilizing this way. Like hanging on a rope trying to maintain attitude. If i get used to it,
this will be ok i think.

It would be great if you could share your changes. As i am very intrested in this mode.

thanks and greets
Noctaro

btw. my quad:
Software: 1.9p2(+Jevermeister inflight calibration+shikra level lock using recommended settings)
paris v3
quad x (~1kg+gopro)
bma180
orig. wmp+
hmc5883l
bmp085
robbe roxxy 2827-34
dys 30A ESC
10" GAUI Props

freedom2000
Posts: 5
Joined: Mon Dec 26, 2011 3:29 pm

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

Post by freedom2000 »

shikra wrote:After a bit of testing, I really do like this option

This would be my final suggestion...

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


Any thoughts??


Hi,

First of all let me introduce myself :

I am not a FCWii flyer... as I am rather on the Microchip side of the force :oops:. I have been designing my JPWiiMultiCopter board and soft for more than one year, starting from KKcopter code, then Mike Barton's one then had a look to Alex's code... How impressive job
So I would like to thanks Alex for all the job he did for this wonderful firmware.

So I definitively wrote my own firmware and designed my own board based on PIC24FJ256GB106. It is a 16bits MCU with a lot of powerful options includng hardware multiplication on 16bits (one clock step) and 9 very efficient hardware PWM (to control motors easily)

If you want to know more on my quad, my boards and all this stuff jump here : http://www.modelisme.com/forum/aero-autres-modeles/158474-jp-wii-multi-copter.html

I am currently flying with ITG3200 Gyros + BMA180 accelero. Both are coupled using the FCWii 1.9 hybridation technics (adapted to PIC) and latest PID stuff also adapted to PIC.

Until today only the Rate mode was working well (very well indeed) but the LEVEL mode was also drifting... quite a lot as my quad isn't very new and the propeller really unbalanced (one has even a hole on the trailing edge...)

I have thus implemented the ACCTrim and it worked better.
And I have, right now, tested your latest proposal to "clip" the PTerm range. The result is great and I have no longer "loops of the death" which is also very confortable !
However the drift is always there... and my understanding of the PID force me to say that it should be cause by something else than the PID...
I have compensated it with the ACCTrim.
I must alos say that as I am using the BMA180 Accelero and as it is calibrated from factory, I do not perform Pre flight calibration of accelero...

So I like your idea to limit the range of the PTerm :

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

and on my PIC it gives : PTerm = constrain((long)(errorAngle)*Kp[LEVEL]>>5, -300, 300) ; (pretty much the same but don't compare the values, both MCU are very different... my errorAngle is 16*angle(deg)... my Rc range is +-1000 etc...

A question to the Arduino Pros : is the division hardware coded on Atmega ? If not (as on the PIC) you'd rather use the "shift" operation and manage to divide by a power of 2 to gain time...


And to finish a video of my quad with your code :D

http://www.youtube.com/watch?v=4jP0EEwm43M

Again a great thanks to Alex.

JP
Last edited by freedom2000 on Mon Dec 26, 2011 5:50 pm, edited 1 time in total.

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

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

Post by Alexinparis »

Hi JP,

The suggested mod here is nice to smooth the LEVEL mode and to avoid to much variation by constraining the PID output.
I will adopt it as D is currently not used for LEVEL mode.

But this won't solve the ACC drift problem as this problem is due to angle calculation.
In 1.9, there is the possibility to disable the ACCZ to avoid this term in calculation (by default disabled).
It helps to reduce the angle error.
But the real solution is probably to use an increased range +/- 8G in the ACC sensor config as described in some other posts.

freedom2000
Posts: 5
Joined: Mon Dec 26, 2011 3:29 pm

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

Post by freedom2000 »

Hi Alex,

Thank you for this prompt reply to a non FCWii man :oops:
I have also uploaded a video. I have just noticed that my radio is not perfectly centered... I will have to add a "deadband" around the neutral points.

I can't imagine that the drift is due to the 8g ... My quad is drifting just when taking off very gently... 1.1g max.
But I will try to change the mode in the BMP config.

[kidding mode]BTW if you want to jump to PIC stuff, just tell it to me it will be a pleasure to help you [/kidding mode]

JP

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

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

Post by Alexinparis »

freedom2000 wrote:I can't imagine that the drift is due to the 8g ... My quad is drifting just when taking off very gently... 1.1g max.

The problem seems to be subtle: the average value can be 1G, but the instantaneous values could exceed 2G due to vibrations. You won't even see the problem by analyzing the output of the I2C sensors as most averaging calculation are done inside the chip.

[kidding mode]BTW if you want to jump to PIC stuff, just tell it to me it will be a pleasure to help you [/kidding mode]

Atmega are still powerful enough for what we make ;)

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

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

Post by mahowik »

Alexinparis wrote:But the real solution is probably to use an increased range +/- 8G in the ACC sensor config as described in some other posts.


viewtopic.php?f=8&t=849&start=10#p5220

Yes, as for me it works now with bma020.

Noctaro
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am
Contact:

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

Post by Noctaro »

For me the drift is coming from the gyro (WMP+).
Around 7 minutes of airtime acro mode rolls right and pitches front noticable. (Seems not depend to temp as this wills also happen after 2 Lipos with ~17Min airtime each at the same location)
It will also have an bad effect on Levelmode. (Resetting Gyro does the trick.)
Is there any way to neutralize this gyro drift using the BMA180? (The strange thing, if connecting to GUI after flight, gyro readings are at 0, no matter if i did reinit or not.)
greetings
Noctaro

btw.
animated gif of the drift in acro mode with 2nd Lipo ~40 Minutes (should be acclimated) allover flighttime. Last gyro reinit was done minute ~7 minutes before taking this captures->
http://www.quadrocopter.at/fotos/quaddrift.gif
(did only push stick to left, and backwards to get back to the road)
(after gyro reinit acro is very stable again)

freedom2000
Posts: 5
Joined: Mon Dec 26, 2011 3:29 pm

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

Post by freedom2000 »

Alexinparis wrote:
freedom2000 wrote:I can't imagine that the drift is due to the 8g ... My quad is drifting just when taking off very gently... 1.1g max.

The problem seems to be subtle: the average value can be 1G, but the instantaneous values could exceed 2G due to vibrations. You won't even see the problem by analyzing the output of the I2C sensors as most averaging calculation are done inside the chip.


I enjoy subtlety --> I will give a try to 8G :D

Thanks for your help guys --> I have spent two hours reading the ACC Z integration to give accurate altitude combined with baro... Very clever !
You are much more advanced than I am with my PIC :oops:

JP

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

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

Post by shikra »

Nice to see some activity after being busy with xmas!

JP - well done. Just gonna watch your vid. Glad it helped too.

Noctaro - I know what you mean - it's kinda weird watching it stabilise - is as you put - like someone holding it on a rope. Makes so easy to fly...

Alex - thanks to include in some form. It's great for flying FPV. I realised this week that when the P constrain is low for slow reaction to changes - it is best to have a low I - because when flying in level, the error angle can change quickly and become large error angle - putting the I windup to its maximum. By testing i ended up with a very low I value to stop overshoots. I think it may be worth noting that. I for smooth flight. Very different scenario to using just for level.


Oh and lots of definitions of drift - just to remind - my original post was related to frame issue! Not gyro / acc drift from sensors etc.

Merry xmas / new year to all!

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

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

Post by shikra »

Oh and my most recent vid!! ...many thanks Alex.

http://vimeo.com/34157960

PatrikE
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

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

Post by PatrikE »

Nice place.

Post Reply