V2.2 - ACRO PID implementation is wrong, right?

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Hamburger » Fri Jun 28, 2013 10:55 am

crashed the TRI (25cm m2m, 2S, 300gramms) with the new pid controller and defaults.
I had managed to hover it indoors although it was extremely sensitive to any stick input, when flying outside it was introducing weird pitch/roll moves (slow and uncontrollable, not high oscillating) during banking and eventually going into a deadly yaw spiral - final crash. CF frame is broken, rebuild in the works, pid controller experiment over.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Phil S. » Fri Jun 28, 2013 12:09 pm

sorg wrote:My guess is that the Z-N formula make I and D sweetly compensate the P allowing quite a large range of acceptable value for P.

I started setup (as i usually do) with D and I at 0 but still had the wide range of P described above.

@Alex:
Don´t want pots instead of data fields. Just wanted to point out that some existing and in fact perfectly working systems don´t need more than these tiny things. On the one hand Microbeast´s cyclic gain pot does not change parameter value from 0 to infinite but within a range making sense for all possible single rotors. Zero to maximum is suitable from 250 size or smaller upt to 700 and more. But pot zero does not mean that gain is zero. Most helis stay controllable with pot to zero and pot to maximum is suitable for 700 and more without oszillation in most cases. Well, a 450 with maximum pot won´t look to good!
On the other hand the entire range of this pot is practically divided in let´s say thirty steps. One has to turn it at least 10 degrees to feel a difference in flying behaviour.
So why implementing gains far below and way beyond a useful range and dividing it into a useless number of steps?

Another point is the use of appropriate components. A FBL single rotor won´t fly too well with cheapest analog servos and unbalanced wooden blades. Is it abolutely essential that MultiWii has the ability to control copters with worn out brushed motors and 99 Cent ESCs sacrificing simple and effective setup for those spending a reasonable sum on their stuff?

Hamburger, ist it reasonable to fly something outdoor that is critical to control when hovering indoor prior to adjusting gains? I understand your frustration about destroying your copter but is this really and exclusively the controllers fault?
Last edited by Phil S. on Fri Jun 28, 2013 12:33 pm, edited 1 time in total.
Phil S.
 
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby alex.khoroshko » Fri Jun 28, 2013 12:25 pm

CF frame is broken, rebuild in the works, pid controller experiment over

Please, accept my condolence! It sounds like I have to rebuild my tri and start testing. Slow oscillations is usually the result of I set too high.
I would also test everything to overflow - the range of some variables is still not clear to me so I'm going to do some tests. I see no potential problems though - the variables size is kept the same to original implementation.
alex.khoroshko
 
Posts: 27
Joined: Sun Jun 09, 2013 9:17 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby copterrichie » Fri Jun 28, 2013 12:48 pm

I would suggest developing a tuning procedure that would function in connection with the GUI. When I tried this PID Modification, I noticed some abnormal behavior in the GUI but at the time, did not understand what it was signaling to me. My indoor flight test ended with a broken expensive prop and I have not done any more testing.

Note the LEFT Servo reading at 1000 when it should be at about 1500. moving the copter about, the reading will return to 1500, but over time, it will settle back to 1000 or there about.

Image
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Hamburger » Fri Jun 28, 2013 1:21 pm

alex.khoroshko wrote:
CF frame is broken, rebuild in the works, pid controller experiment over

Please, accept my condolence!

I guess the occasional crash when experimenting cannot be avoided completely. Not saying I particularly enjoy that experience.
It sounds like I have to rebuild my tri and start testing. Slow oscillations is usually the result of I set too high.
I would also test everything to overflow - the range of some variables is still not clear to me so I'm going to do some tests. I see no potential problems though - the variables size is kept the same to original implementation.

yes, please. If possible, I urge you to experiment further with several coptertypes. From past experience we know coptertypes with servo(s) to behave quite differently on yaw.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Phil S. » Fri Jun 28, 2013 1:28 pm

I generally do not like the idea of tricopters loosing the brilliant simplicity of multicopters just needing motors and ESCs and nothing else. There is the need of a servo and additional bearings capable of handling the loads of the precession induced by tilting rotor axe and the precession in general causes problems wherever tilting rotors are used in aircraft. So, it is possible, people obviously like it, I don´t but developers have to handle it.

Another problem I encountered upgrading from piezo to MultiWii is often referred to as "Wobble of Death". I tried two or three different FCs because I could not get rid of this phenomenon by just modifying PIDs. Even with P as low as hovering was nearly impossible quite slow but high amplitude oszillation ocurred as soon as I deflected cylic sticks close to limits.
In the end solution was simple: I kept MINTHROTTLE at a value that prevents any of the motors from stopping even with throtle at minimum and cyclic stick deflected to corners. Obviously stopping and restarting motors (compared to slowing down to low revs and speeding up again) is a pretty unresolvable problem for the FC in terms of stabilizing the copter in the air. Never heard and read about this but IMO that´s the way it works!
Phil S.
 
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Hamburger » Fri Jun 28, 2013 1:41 pm

Phil S. wrote:I generally do not like the idea of tricopters loosing the brilliant simplicity of multicopters just needing motors and ESCs and nothing else. There is the need of a servo and additional bearings capable of handling the loads of the precession induced by tilting rotor axe and the precession in general causes problems wherever tilting rotors are used in aircraft. So, it is possible, people obviously like it, I don´t but developers have to handle it.

No problem; you, like everyone else, are entitled to your own private views and preferences. You will have to live with the fact that MWii supports several coptertypes, and so should a pid controller.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby copterrichie » Fri Jun 28, 2013 1:44 pm

Hamburger wrote:No problem; you, like everyone else, are entitled to your own private views and preferences. You will have to live with the fact that MWii supports several coptertypes, and so should a pid controller.


AMEN, it is AMAZING how subjective views (opinions) are projected upon others.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Phil S. » Fri Jun 28, 2013 2:19 pm

I really did not want to affront you, Hamburger, and do not have any problems at all to live with people flying tris.

The second part of my post was by far more important I think. Any comments on that?
Phil S.
 
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby alex.khoroshko » Fri Jun 28, 2013 3:23 pm

high amplitude oszillation ocurred as soon as I deflected cylic sticks close to limits.

Could you please tell me your config? and also, if you can simulate this one more time and film it (or if you have a video allready) - that would be really nice. I've never met this problem with any FC I've used and I have no idea, what specifically is going on. Any info would be very useful.
Also, note to everyone
If someone else have some remarks on unwanted aircraft behavior, related to control, please, report here (the more explained, the better). It's much easier to implement new functions/do corrections at early stage of the development.

As for min throttle - I didn't get it. This function is there for quite a while, to avoid motors restart.
alex.khoroshko
 
Posts: 27
Joined: Sun Jun 09, 2013 9:17 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby shikra » Fri Jun 28, 2013 5:20 pm

Jeez - lot going on in here lately.

Phil - not sure if you are aware multiwii was originally triwii when it first started out - other copter types came later and name changed!! just a useless bit of info....

Alex K- good to have you back .... look forward to getting to the perfect PID.

Phil S. wrote:I really did not want to affront you, Hamburger, and do not have any problems at all to live with people flying tris.

The second part of my post was by far more important I think. Any comments on that?
User avatar
shikra
 
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Hamburger » Fri Jun 28, 2013 5:30 pm

sorry, no video. Cannot reproduce due to crash. pids as suggested by PhilS. everyone seemed to agree on.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby alex.khoroshko » Fri Jun 28, 2013 5:41 pm

sorry, no video.

Oh, it was addressed to PhilS, not you - it wouldn't be very polite to ask reproducing the costly crash, heh.
I was asking about his:
Another problem I encountered upgrading from piezo to MultiWii is often referred to as "Wobble of Death"

- I wonder what config that was and what exactly this wobble looked like.

As for your crash - I never tried tricopter on multiwii (always used KK2.0 for that) - would recover my tri (or may be make the new one specially for testing), test the PID behaviour and then we would be able to discuss the possible reasons of the accident, I guess.
alex.khoroshko
 
Posts: 27
Joined: Sun Jun 09, 2013 9:17 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby copterrichie » Fri Jun 28, 2013 5:45 pm

It is a pretty good wager and I would like to have these odds when visiting Las Vegas that PhilS' PID settings will ONLY work on his copter or one that has the same AUW, Motor Center-line to Motor-Ceter-line, Motor KVs and much much more. This quest for the holly Grail of PID settings is fruitless to me.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby copterrichie » Fri Jun 28, 2013 5:59 pm

if we really want to make a name MultiWiiCopter means something, we SHOULD be focusing our efforts on coming up with a Self-Adjusting Algorithm. Enough said from this no body that love Exotic copters. :)
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby alll » Fri Jun 28, 2013 6:13 pm

+1 richie

Wathever PID control loop implemented,
1st, it should never induce calculation "overflow" when P I and D are maxed ie = 255, never! ;)
2nd, any PID should be able to handle all combinations of PID ie PD-loop (I=0), D-loop-only P&I=0), ...

General rule to set it up:
Knowing the "ERROR" definition of the concerned PID, start with P and I&D=0, ... ;)
and please, if special implementation, document it.

In this case nothing, never can go wrong!!!!!

manu
PS: ho yes, if mwii can come with a "auto PID" tuning, biiiiiiiiiiiingooooooooo! ;) ;) ;) ;)
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Phil S. » Fri Jun 28, 2013 6:34 pm

Sorry, this happened at the very beginning of my MW career and I can´t remember the settings any more. There aren´t any videos existing and I am not to keen on replaying because the story always ended with some broken props at least!

But the description "Wobble to Death" fits, it is quite slow oszillation starting with small amplitudes increasing over three, four periods, ending with uncontrollable quad detonating.

But as I said IMO PIDs did not have any influence. I think the issue is startup behaviour of brushless ESCs in general. Aircraft BL systems usually work sensorless so ESC has to monitor induction current on the powerless phase of the stator to detect rotor position and to determine the correct time for commutation. This needs a minimum speed of rotation otherwise induction won´t be strong enough. So starting from standstill requires some extra effort of the ESC, it has to commutate without feedback from the rotor, is kind of blind and deaf for the first split second. In this short period the relation between PWM signal from ESC and motor output ist kind of nonlinear, probably at random and certainly different to the normal behaviour when motor just changes speed. So it might be difficult for the FC to cope with this irregularity when some motors are reacting properly but others kind of twitch before running smoothly.

Tweaking MINTHROTTLE (Don´t forget rebooting the FC after changing values!) was the road to succes. It´s not necessary in most cases if ESCs are properly calibrated. But to me it has become part of the first preflight check of the day: No props mounted, arming, starting motors by flipping throttle hold switches (Yes, two of them, I really hope you will never experience an accidentally starting 700 size single rotor!), cyclic stick to all corners, stops strictly prohibited!
Phil S.
 
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby chris_kmn » Fri Jun 28, 2013 8:58 pm

Flying with max throttle leads to saturation effects in the control loop. The esc's can just rev down and not rev up. Thats a nonlinearity and could cause the wobling.

Reducing MAXTHROTTLE can compensate this (I thnik)
chris_kmn
 
Posts: 31
Joined: Sun Jun 09, 2013 11:11 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Phil S. » Fri Jun 28, 2013 10:03 pm

Wobbling occurred reproducibly from hovering just by flipping cyclic stick close to its limit being far from full hrottle.

Motor stoppings due to cyclic input were obvious so in my theory FC lowered motor speed as much as possible to reach the required high rate and finally stopped one or two. As a consequence of the delayed restart it came into resonant oszillation maybe because overshoot even provoked further stoppings at the opposite side of the copter hence aggravating the situation.

And as I said before it never happened again after MINTHROTTLE tweaking!

And to make it clear I suppose this is a common problem, not specific to Alex`mod, as it occurred to me with oldschool PIDs!
Phil S.
 
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby chris_kmn » Sat Jun 29, 2013 12:34 pm

Phil S. wrote:And as I said before it never happened again after MINTHROTTLE tweaking!


Of course the saturation effect is on the minthrottle AND on the maxthrottle side. I mentioned the max-side becuase Hamburger stated that his wobbling was at fullthrottle. It's "just" a nonlinearity that could disturbe a non robust calibration of any PID control loop.

So it totally makes sense to have a - let me say - control reserve on the min AND max side of - I dont know - 200 or so... Means MINTHROTTLE at 1100-1200 and MAXTHROTTLE at 1800-1900. But so or so a robust PID calibration should be the main goal.
chris_kmn
 
Posts: 31
Joined: Sun Jun 09, 2013 11:11 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Crashpilot1000 » Sat Jun 29, 2013 2:23 pm

I am no experts in such things but maybe it's also a part of the mwii filter design? From what i understand an lpf is some kind of feeding back filter. Perhaps using a non feeding back approach could make the pid loops more resiliant in general. It will not solve for a poorly tuned PID algo in the first place but perhaps extend it's usability over a greater (throttle?/weight?) range.
Of course, regualtion headroom within max and min throttle is a must.

Cheers
Kraut Rob
User avatar
Crashpilot1000
 
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby chris_kmn » Sat Jun 29, 2013 3:05 pm

Bug report (@Hamburger):

when I compile the rev1503 with oldschool PID I have a strange behaviour at arming:

- not armed: motor PWM output is at 1000
- armed: motor PWM output is at 0. Props start turning at midstick position

with PID set to 2 (AlexK loop) armed PWM ist at MINCOMMAND and normal arming behaviour.

Any Idea on this ?
chris_kmn
 
Posts: 31
Joined: Sun Jun 09, 2013 11:11 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby copterrichie » Sat Jun 29, 2013 3:11 pm

Hope you are doing all this with the props OFF.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby -ralf- » Sat Jun 29, 2013 4:03 pm

chris_kmn wrote:Bug report (@Hamburger):

when I compile the rev1503 with oldschool PID I have a strange behaviour at arming:

- not armed: motor PWM output is at 1000
- armed: motor PWM output is at 0. Props start turning at midstick position

with PID set to 2 (AlexK loop) armed PWM ist at MINCOMMAND and normal arming behaviour.

Any Idea on this ?


Just tried it, cannot confirm .... all works normal with "oldschool".
I'm using S.Bus .....
-ralf-
 
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby chris_kmn » Sat Jun 29, 2013 4:10 pm

-ralf- wrote:
chris_kmn wrote:Bug report (@Hamburger):

when I compile the rev1503 with oldschool PID I have a strange behaviour at arming:

- not armed: motor PWM output is at 1000
- armed: motor PWM output is at 0. Props start turning at midstick position

with PID set to 2 (AlexK loop) armed PWM ist at MINCOMMAND and normal arming behaviour.

Any Idea on this ?


Just tried it, cannot confirm .... all works normal with "oldschool".
I'm using S.Bus .....



Hm, I observed it on a Tri. Maybe it's related to that....
chris_kmn
 
Posts: 31
Joined: Sun Jun 09, 2013 11:11 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby -ralf- » Sat Jun 29, 2013 4:36 pm

chris_kmn wrote:Hm, I observed it on a Tri. Maybe it's related to that....


My board is Crius AIOP 1.1; Coptertype hex ......
MultiWiiConf.pde latest version (self-compiled)
-ralf-
 
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby copterrichie » Sat Jun 29, 2013 4:45 pm

chris_kmn wrote:Hm, I observed it on a Tri. Maybe it's related to that....


Hmmm, this could be related to the behavior I saw because in my situation, the value was 1000 because of the constrain statement. Which axis did this happen on your tricopter?
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby chris_kmn » Sat Jun 29, 2013 7:30 pm

copterrichie wrote:
chris_kmn wrote:Hm, I observed it on a Tri. Maybe it's related to that....


Hmmm, this could be related to the behavior I saw because in my situation, the value was 1000 because of the constrain statement. Which axis did this happen on your tricopter?


It was on all three axis.

And maybe I'm wrong but on my quad it looks as if two opposite props were running according to throttle and the other two were in idle, not reving up with increasing throttle. But I didn't fly it. Went back to rev1391.
chris_kmn
 
Posts: 31
Joined: Sun Jun 09, 2013 11:11 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby -ralf- » Sun Jun 30, 2013 9:04 am

chris_kmn wrote:Flying with max throttle leads to saturation effects in the control loop. The esc's can just rev down and not rev up. Thats a nonlinearity and could cause the wobling.

Reducing MAXTHROTTLE can compensate this (I thnik)


Chris (and PhilS),

look at the end of output.ino. ("normalize the Motors values")
If I read right its not possible to overshoot minthrottle and maxthrottle boundaries.
If a motor value overshoots the maxthrottle, it is reset to maxthrottle and the other
motors are normalized to this. It is also not possible to send a value less then mintrottle.
-ralf-
 
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby chris_kmn » Sun Jun 30, 2013 9:58 am

-ralf- wrote:
Chris (and PhilS),

look at the end of output.ino. ("normalize the Motors values")
If I read right its not possible to overshoot minthrottle and maxthrottle boundaries.
If a motor value overshoots the maxthrottle, it is reset to maxthrottle and the other
motors are normalized to this. It is also not possible to send a value less then mintrottle.


If this is how it works then you are right, Ralf...
chris_kmn
 
Posts: 31
Joined: Sun Jun 09, 2013 11:11 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby chris_kmn » Sun Jun 30, 2013 10:01 am

BUT:

Code: Select all
 if (maxMotor > MAXTHROTTLE) { // this is a way to still have good gyro corrections if at least one motor reaches its max.
      for(i=0; i < LEAVE_HEADROOM_FOR_MOTORS; i++)
        motor[i] -= maxMotor - MAXTHROTTLE;


doesn't the comment in the code exactly tell what we described ?
chris_kmn
 
Posts: 31
Joined: Sun Jun 09, 2013 11:11 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby -ralf- » Sun Jun 30, 2013 10:31 am

chris_kmn wrote:BUT:

Code: Select all
 if (maxMotor > MAXTHROTTLE) { // this is a way to still have good gyro corrections if at least one motor reaches its max.
      for(i=0; i < LEAVE_HEADROOM_FOR_MOTORS; i++)
        motor[i] -= maxMotor - MAXTHROTTLE;


doesn't the comment in the code exactly tell what we described ?


Hmm, we are using different codes, mine looks

Code: Select all
    for(i=0; i< NUMBER_MOTOR; i++) {
      if (maxMotor > MAXTHROTTLE) // this is a way to still have good gyro corrections if at least one motor reaches its max.
        motor[i] -= maxMotor - MAXTHROTTLE;
      motor[i] = constrain(motor[i], conf.minthrottle, MAXTHROTTLE);
-ralf-
 
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby copterrichie » Sun Jun 30, 2013 3:14 pm

copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby alex.khoroshko » Sun Jun 30, 2013 5:00 pm

I'm currently modeling one idea on PID selftuning in-flight. Looks promising for me. If I get the positive simulation results, I would describe it in details.
Unfortunately, I have no time for real-life firmware tests now, and wouldn't have for about 2 days more.
alex.khoroshko
 
Posts: 27
Joined: Sun Jun 09, 2013 9:17 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby alll » Sun Jun 30, 2013 5:53 pm

..., cpp/header organized ;)
User avatar
alll
 
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby brm » Sun Jun 30, 2013 7:10 pm

alex.khoroshko wrote:I'm currently modeling one idea on PID selftuning in-flight. Looks promising for me. If I get the positive simulation results, I would describe it in details.
Unfortunately, I have no time for real-life firmware tests now, and wouldn't have for about 2 days more.

no probem ;)
make a drawing and post some pseudo code.
we can make it fly ...

start creating an oscilation observer.
needed for some pid tuning...

best rob
brm
 
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Phil S. » Sun Jun 30, 2013 9:12 pm

-ralf- wrote:It is also not possible to send a value less then mintrottle.

When MINTHROTTLE is low enough to shut down motors it makes no sense (as I always do and which works perfectly with KK & Co.) using a throttle curve in the radio that prevents motors from being stopped by lowering throttle stick because cyclic stick will continue to do the job!
Phil S.
 
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Noctaro » Mon Jul 01, 2013 11:51 am

Hi guys, i did read about this new implementation for PID controller. :shock:
I am no coder, so i am not sure whats going on. (only some basic knowlegde)
But, may it help doing some testflights? Is there a flyable dev release including your mod?
What behaviour i should focus on, while testing?

I tried to compile latest "svn trunk" but got "MultiWii.cpp: In function 'void getEstimatedAttitude()':
IMU:181: error: 'GYRO_SCALE' was not declared in this scope"
So it seems code is not completed?

Looking forward to test :)

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

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Phil S. » Mon Jul 01, 2013 12:51 pm

I installed this and replaced line 111 in IMU by seven lines as proposed by Plüschi to prevent MPU6050 and ITG3200 sensored boards from loosing orientation when switched to selflevelling modes immediately after flying some flips in a row.

On my stock Gaui 500X with Crius AIOP V2.0 this works perfectly!Here is my PID Setup.
Phil S.
 
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby -ralf- » Mon Jul 01, 2013 1:18 pm

The latest dev is here

http://multiwii.googlecode.com/svn/trunk/

Look at the _shared folders. I compiled r1503 with Alex.K-PID without any
problems.
-ralf-
 
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Noctaro » Mon Jul 01, 2013 3:22 pm

Hey!
Thank you for the fast response! I redownloaded the svn trunk tree. Did update to Arduino 1.05 and now everything compiles as it should. Dont know where the problem was based on. Maybe user error :geek:
Is there any big difference from trunk with the version Phil S. posted?
Do we need to add the seven lines as proposed by Plüschi to trunk for safety?

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

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby -ralf- » Mon Jul 01, 2013 3:48 pm

The version PhilS posted is the official 2.2; there are some bugs in it. The
latest devs have corrected these bugs (included the lines Phil changed) and a
lot of enhancements.

To use the latest dev proper you ever need to compile a new MultiWiiConf from the pde
in multiwiiconf_shared. Here is how to do it:

http://www.multiwii.com/forum/viewtopic.php?f=18&t=190
-ralf-
 
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Noctaro » Wed Jul 03, 2013 9:05 am

Hey!
Thank you for the helpfull link and the info.

Compiling went fine.
I uploaded the REV 1505 to my board.
For now i only tested oldschool pid. The difference to V2.2 is hughe. It feels very touchy now, i like this new behaviour.
Further it was quite stable in ACRO (Defenately better than V2.2), only few wobbles in ground effect. (May be fixed after more fine tuning)
During speedflight the tendency to pitch up seems to be eliminated. (Need to do some longrange testing)
Also at hovering it seemed to be more nailed to its attitude even at low Gyro LPF settings.
I like to use LPF set to 42hz to ensure my copter is proof to unexpected vibration. (f.e. losing some balancing tape from a prop...)

There is one thing that i would like to be changed...If switching between level to acro, a unskilled pilot may crash his machine, as the transfer is too hard, or sharp, dont know how to describe.
I would love to see some dampening on mode change. Cant we just divide the base rc rate by 2 for a secound or two? (Enough time for pilots to activate the switch in their brains :mrgreen: )
With this touchy new input behaviour, the sharp transistion may become a real problem for pilots, especially if they want to fly indoor or in the wood( like me :p ).




Testing copter:
Quad X
Motor to motor: 45cm
Props: 10x6 3 blade GWS
ESC: DYS 30A
Weight(ink. all equipment): 1456g
Motors: Robbe Roxxy 2827-34
Akku: 3s 3300mah

PID-Oldschool (Same as i used for a stable flight in V2.2)
(ACRO only tested!)
Pitch P = 6.5/I = 44/D = 60
Roll P = 6.5/I = 44/D = 60
Yaw P = 8.5/I = 40/D = 0

I bet i can do some usefull testing with alex.k. mod today. Will get you up to date.

greetz Noc

By the way, copterrichie, with some luck i can serve your need for a video to analyze next week as soon as my ADSL is connected. ;)
Last edited by Noctaro on Thu Jul 04, 2013 12:54 pm, edited 1 time in total.
Noctaro
 
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Noctaro » Thu Jul 04, 2013 12:42 pm

Hey again!

Ok, first testflight using Alex.K. PID implementation is done. And it was great :)

I did not listen to your suggestions to change PID and just because i wanted to know what happens, i used the same settings as i used for oldschool pid controller.

My observings so far: (ACRO-mode)
° Attitude:
+Nice and smooth, i did test in calm conditions, with pids that have proofed in MW2.2. Some twitching happened on roll. (PIDs need to be tuned)
+Descending :* I never saw my quad decending that smooth, for now far from critical (Not like in 2.2 where i had some wobbles i couldnt get out of.)
+Precision is definately as good as the oldshchool PID controller in DEV1505. (Managed to fly under my slackline, as i dont like big heights, its only 50cm from ground XD )
+I provoked a "safe crash", to see if hard vibrations and high force attitude changes may create unwanted bahaviour. Nothing i could obsereve, just a normal crash :D (No harm to anything happened :p )
-In ground effect i had some serious wobbles, but still far away from critical. (Should be eliminated as soon as i start PID meditation to find the right numbers)
-Yaw had some strange behaviour at takeoff, yawing around 10° to a random direction. (May be because of my overpowered Yaw P-I setting)

° Fast acrobatic moves:
+ For now, no tendency to pitch up at speedflight (feels similar to the oldschool)
+ I am not sure about but, i had the feeling the copter was more nailed to my stickmovements wich made it easier to control in critical situations. (Did not try loops for now, only tilting around 90° to slow down from fast forward flight and avoid obstacles.)

I will do some further testings and report back, as i got some better PIDs.

Video is captured and should be released next week. PID 1 vs 2 in same conditions, from calm to windy.

Hope my observations will motivate more testpilots. It seems to be a very good alternative. Test it only at safe circumstances.

For now i only can say thanks to alex.k for introducing this mod!

Big up to hamburger for adding the define in shared :) (sorry about your copter)

Greetz Noc
Last edited by Noctaro on Thu Jul 04, 2013 3:53 pm, edited 1 time in total.
Noctaro
 
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Plüschi » Thu Jul 04, 2013 1:37 pm

Noctaro wrote:Hey!
If switching between level to acro, a unskilled pilot may crash his machine


You should NOT use the radio trim to mask a faulty acc calibration. The trims go where they are right for acro, and then you use stick acc calib to get it level in angle / horizon. Your changes from acro to level will be smooth as silk then.
User avatar
Plüschi
 
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Noctaro » Thu Jul 04, 2013 3:19 pm

Hey Plüschi,
thx for your comment, but i know that.
I never used transmitter trims for levelmode.
What i am talking of is following situation:

Copter is in levelmode.
Wind is constant around 25km/h.
To keep my copter at spot i need to apply some stick input to counter the wind situation.
Now i decide to switch back to acro, because i want to change spot in an acrobatic way.
The moment i pull the switch for acro mode, my controlsticks pottis do continue to send a signal for roll lets say around 1400.
To counter the behaviour change and not starting to tilt the copter further in winddirection, we need to react really fast and center our sticks. The unwanted angle change is of course also depending to the rc rate.
The higher the rate, the faster it will start to roll.
It needs some good reaction from the pilot. I am used to it, but would love to see a smother or less agressive option. Thats why i mentioned RC rate division, but i doubt its is the right variable to handle this. As mentioned i do not understand most functions in code (even if i understand some basics), so i was just guessing.

Hope now i nailed the point :)

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

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby copterrichie » Thu Jul 04, 2013 4:35 pm

I am still waiting to see some video with this new PID Implementation. Not that words are not meaningful, just that a picture paints a thousand words and a video is a library. Please, lets see some videos.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Noctaro » Thu Jul 04, 2013 5:20 pm

Hey,
pls be patient with me copterrichie. My only internet connection is via edge handy right now. I captured some hd testfootage and as you probably know, filesize isnt fun, so i dont have a possibility until next 2 weeks to share my library ;)

By the way, i did some further testflights and really rocked my PIDs down and up in big steps to get some usefull feedback.

For now, it was not possible to achive a stable flightstate without a big amount of D.

Last tested PID: (ACRO)
Gyro LPF: 42Hz
Roll -> P=6 /I=0.045/D=60
Pitch -> P=6/I=0.045/D=60
Yaw -> P= 8 /I=0.030/D=20

I will start from scratch again. Most i was aware of the yaw behaviour.

As i leave the minthrottle state and activate fc stabilisation, motors burst up in an unusual manner. (I tried YAW - P from 4-13 without change of the root problem, same with I from 0.000-0.050)
At the moment that i reach the hovering point of throttle, the quads starts yawing, each time right and each time around 10-20°, then it stops and has some good headinghold.
It is reproducable at each takeoff. Maybe this was the problem Hamburger also had?

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

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Alexinparis » Fri Jul 05, 2013 12:32 am

Phil S. wrote:Tweaking MINTHROTTLE (Don´t forget rebooting the FC after changing values!) was the road to succes. It´s not necessary in most cases if ESCs are properly calibrated. But to me it has become part of the first preflight check of the day: No props mounted, arming, starting motors by flipping throttle hold switches (Yes, two of them, I really hope you will never experience an accidentally starting 700 size single rotor!), cyclic stick to all corners, stops strictly prohibited!


Note this was especially the reason why I introduced MINTHROTTLE a very long time ago, explaining exactly this situation.
http://www.multiwii.com/faq#Why_is_it_i ... _the_ESCs_

Note also Multiwii first versions (TriWiiCopter) were tricopter+acro only based.
And note warthox (vimeo.com/warthox) used a kk board before using mw board.
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Alexinparis » Fri Jul 05, 2013 12:56 am

nhadrian wrote:Hi all again,

my major problem is that before r1474 we had a rock solid, well tested PID and IMU implementation, without any known bugs in ALL FLYING SITUATIONS thanks to the high number of users/testers/flights.
I can't understand why we need to modify this core part and start testing from scratch?!?!?!
What was the main problem of the previous PID implementation??? Can anybody tell me?

Unfortunatelly such a major change in PID implementation can't be tested with some "hovering" copters, because there can be still bugs when extreme flight situations occure (ie. calculation overflow?! extreme banking because of wind ghust in GPS hold?! fast forward flying?! etc.....)


Please do not mix everything.

about the mod on the original PID after r1474:

For ROLL&PITCH ACRO PID:
deals with a small mod for ROLL&PITCH ACRO PID: "the sticks scaling is no more affected by PID coefficients"
before: if you set a P of 8 instead of 4, the stick sensitivity seemed reduced twice.
now: the stick sensitivity is independent of P
This is the only modification and it should not modify anything else.
If you feel there is any calculation overflow in the formula, please point it.

For YAW PID:
please reread this post, this is not a sudden and unexpected change:
viewtopic.php?f=8&t=3213
- refactor the YAW PID to have a KK yaw style feeling.
This is a need I saw many times. Multiwii was basically an acro plateform and the yaw control has always been a weak point comparing to other platform (even if it performs quite ok) I think it should be an easy task to change.

2.3 is not yet released and this dev might not be perfect for the moment. I think this is normal in a dev process, and I highly doubt this version could induce a crash only due to this mod.

for other PIDs like angle used for GPS: no change
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

PreviousNext

Return to Software development

Who is online

Users browsing this forum: No registered users and 25 guests

cron