A different approach to levelling ? - drift killer?

[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

[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]

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

[matbogdan]

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]

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]

Just tried Shikra's code mod and for the first time, I flew my whole 7 minute pack in level mode! Thx for sharing

[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]

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.

[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]

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

[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]

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]

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

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

Again a great thanks to Alex.

JP

[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]

Hi Alex,

Thank you for this prompt reply to a non FCWii man
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]

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]

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]

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]

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

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

JP

[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!

[shikra]

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

http://vimeo.com/34157960

[PatrikE]

Nice place.