A different approach to levelling ? - drift killer?

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