MultiWii

copterrichie wrote:I think the main issue with the current MWC is the YAW does not hold as liked by many however, for me, it is working fairly well when the YAW PID are set correctly for the given build. I have never, repeat, never been able to use the Default settings especially the YAW. FYI, In my opinion, PID Settings are as unique as each person and build.

Yes, I didn't talk about PID settings itself. I'm talking about the risk of having serious BUGs in the modified calculation method itself.

I know and understood that, just stating my perspective.

nhadrian wrote:What was the main problem of the previous PID implementation??? Can anybody tell me?

From a pilot´s point of view basic control was poor easily outclassed by simple 15.- $ FCs. IMO yaw rates were ridiculous and reducing PID Gains a questionable way to increase agility while sacrificing stabilitiy when it is particularly needed.

I am no programmer at all but I cannot imagine how cascaded loops should be able to control e.g. altitude or position properly when a skilled pilot isn´t able to fly without constantly being scared to loose control, expecting the FC to do do something unexpected.

Ardupilot is miles away in terms of autonomous functions so why not concentrate on basic things, make them rock solid to build upon?

Sorry to say that, but I feel that the current state of MWI would need other improovements better than changing PID or IMU, the "base"!!!!!

I am very glad that people commit their improvements to this community. What is wrong in evolving something ? The response in this thread shows, that it seems to make sense to work on PID implementation. I personally see a great improvement in flight performance. And I'm not talking about hovering. I did a lot of flips and loop and all that in gusty winds. AND there is still the choice of using the oldshool implementation. This is what MultiWii is all about. Having the choice to adopt it to your personal needs and hardware.

If you want other improvements, feel free to commit them and listen to the feedback as Hamburger did in this case. I see it as an success how fast this idea came to a working solution. That is a great job !!!

nhadrian wrote:I'm talking about the risk of having serious BUGs in the modified calculation method itself.

You always have to take risks trying something new but in this particular case it is very worth doing it!

After the upgrade I made some pretty cautious first attempts but confidence grew quickly and after a few minutes I banged sticks to the limitis like I did never before with my poor Gaui! Full throttle to the limits of visibility, kinds of funnels, huge loops to flips on the spot, Immelmann, Split S, Cuban Eight, not everything clean because rolls always tend to be barrels but recognisable, even something like Rainbows but ending with flips instead of proceeding inverted, it is still fixed pitch! There is no tendency to pitch up at high speed and in fast vertical descends into its own downwash the copter remains perfectly controllable. Briefly said, how could it be better?

So I am quite confident that as long as x configured quads in the size of a Gaui 500X are concerned (did not try anything else) no GPS and/or Baro controlled manoeuvre should be harsh enough to reveal unexpected reactions of the central PID loops of this MW modification. As Chris just said Alex obviously did a really good job!

A video would be very helpful.

Example: mwc hexa - flyduspider aerobatics

anyone willing to do further maintenance / improvement of current alexK pid controller?
At the least, post a screenshot of your pid settings, so what works in most cases as good starting point could be found. For as many copters as possible it would need to suffice conditions
- already flyable for almost all copters (small, large, #motors etc.)
- performance is reasonably well (already shows typical characteristics in flight behaviour),
- individual improvement in getting closer to optimum (?) is straight forward from starting point

copterrichie wrote:A video would be very helpful.

Thank you for yours! That´s the typical climb-flip-hover acro style not beeing afflicted with speed induced pitch up or imprecise yaw stop or blending out PIDs. Try to maintain speed after a loop or through a roll or in Speedcircles or fly kind of Walls or sharp turns from high speed to hover then you know what I´m talking about.

Let your video speak for itself please.

Hamburger:
Checking for "defined SERVO" for exclude yaw constrain is bad idea. The SERVO is defined on any copter with gimbal or CamTrig enabled.

nhadrian wrote:Yes, I didn't talk about PID settings itself. I'm talking about the risk of having serious BUGs in the modified calculation method itself.

move to a 32bit system and do all PID calculation in floats or int32, problem solved.
this bullshit of counting cycles and bitshifts making code unreadable just to fit into tarduino328 is getting tiring.
worst example of this is in current pid where it does if (someshit < 640) { do int16 } else { do int32 }. Horrible waste.

copterrichie wrote:Let your video speak for itself please.

I will try to find a camera, a camera man and someone spending hours on cutting and uploading to convince you that I´m not talking trash.

Phil S. wrote:

copterrichie wrote:Let your video speak for itself please.

I will try to find a camera, a camera man and someone spending hours on cutting and uploading to convince you that I´m not talking trash.

I prefer just talking trash, its so much easier.

Phil S. wrote:

copterrichie wrote:Let your video speak for itself please.

I will try to find a camera, a camera man and someone spending hours on cutting and uploading to convince you that I´m not talking trash.

It is not that I do not believe it, just that I enjoy analyzing video. there is sooooo much information in a video and not just the imaginary but the sound as well.

Well, apart from this correct PID control loop implementation by alex.khoroshko, it's worth pointing out that this isn't the first time a reworked PID Control loop has been implemented in MultiWii: https://code.google.com/p/multiwii/sour ... i_gke_Lite

Anyway, let the testing continue. As Hamburger requested: post your flying brick specifications and PID values so some normalised defaults can be adopted.

felixrising wrote:Well, apart from this correct PID control loop implementation by alex.khoroshko, it's worth pointing out that this isn't the first time a reworked PID Control loop has been implemented in MultiWii: https://code.google.com/p/multiwii/sour ... i_gke_Lite

It is SAD things like this gets buried because Gke knows his stuff.

one question:

Oldschool:


AlexK:


Mistake ?

chris_kmn wrote:one question:...Mistake ?

Interesting. That is going to show us if any of the followers will step up and maintain that code.

chris_kmn wrote:one question:

Oldschool:

Code: Select all

 axisPID[axis] =  PTerm + ITerm - DTerm;

AlexK:

Code: Select all

    axisPID[axis] =  PTerm + ITerm + DTerm;

Mistake ?

No, it is OK this way

The D of the original Controller is based on this:
delta = gyroData[axis] - lastGyro[axis];

The D of the other Controller boils down to this:
delta = - gyroData[axis] - lastGyro[axis];

But there is always one way to find out: Change the sign and test it


@copterrichie: How is the flightexperience of the GKE approach compared to the original or the altered one we are discussing here? (I just ask because i have no flight ready mwii anymore at play to check it out quickly)

Another note to the alex.khoroshko controller (if i get it right):
Angle mode takes (besides the acro controller) just the level P into account.
Horizon mode takes (besides the acro controller) just the level I into account.
Shouldn't we re-introduce the Level D as constrain, like in the "original" controller? As i remember right it was introduced to dampen the "wobble of death".

Cheers
Rob

Crashpilot1000 wrote:
@copterrichie: How is the flightexperience of the GKE approach compared to the original or the altered one we are discussing here? (I just ask because i have no flight ready mwii anymore at play to check it out quickly)

My understanding is, GKE authored the UAVX firmware and is a professor at a school in Australia

Here is his thread on RCG: http://www.rcgroups.com/forums/showthread.php?t=1093510

copterrichie wrote:

Crashpilot1000 wrote:
@copterrichie: How is the flightexperience of the GKE approach compared to the original or the altered one we are discussing here? (I just ask because i have no flight ready mwii anymore at play to check it out quickly)

My understanding is, GKE authored the UAVX firmware and is a professor at a school in Australia

Here is his thread on RCG: http://www.rcgroups.com/forums/showthread.php?t=1093510

Thank you very much for the link! I can't find the original ARM F4 sourcecode on his site: http://code.google.com/p/uavp-mods/ just compiled hex files. Perhaps he fears someone bitching about his codingstyle .

Crashpilot1000 wrote:...
The D of the original Controller is based on this:
delta = gyroData[axis] - lastGyro[axis];

The D of the other Controller boils down to this:
delta = - gyroData[axis] - lastGyro[axis];
...

Just a typo here in the text? I did not check the coding.
Unary- has higher precedence than arithmetics, correct should be:
delta = -(gyroData[axis] - lastGyro[axis]);
or
delta = - gyroData[axis] + lastGyro[axis];

Yes, actually it wasn't meant as real C code respecting "unary". So not a typo but not thought through.
Well, look at the code and shuffle around the signs yourself as well and you will see that "+D" in the final equation is correct.

Crashpilot1000 wrote:

copterrichie wrote:

Crashpilot1000 wrote:
@copterrichie: How is the flightexperience of the GKE approach compared to the original or the altered one we are discussing here? (I just ask because i have no flight ready mwii anymore at play to check it out quickly)

My understanding is, GKE authored the UAVX firmware and is a professor at a school in Australia

Here is his thread on RCG: http://www.rcgroups.com/forums/showthread.php?t=1093510

Thank you very much for the link! I can't find the original ARM F4 sourcecode on his site: http://code.google.com/p/uavp-mods/ just compiled hex files. Perhaps he fears someone bitching about his codingstyle .

I don't think he's that secretive about it.. https://code.google.com/p/multiwii/sour ... i_gke_Lite

Well, actually i am not really interested in that 8Bit stuff. I am interested in his GPS / INS fusion part. And that seems undisclosed. There are some "opensource" projects online that are suddenly obscured when you get to the interesting part. Or they try to hide it by digging it deep into some "tree".

Crashpilot1000 wrote:Well, actually i am not really interested in that 8Bit stuff. I am interested in his GPS / INS fusion part. And that seems undisclosed. There are some "opensource" projects online that are suddenly obscured when you get to the interesting part. Or they try to hide it by digging it deep into some "tree".

Seems to me, the logical thing to do is to talk directly with him, we never know what can happen by being direct and open.

Another note to the alex.khoroshko controller (if i get it right):
Angle mode takes (besides the acro controller) just the level P into account.
Horizon mode takes (besides the acro controller) just the level I into account.
Shouldn't we re-introduce the Level D as constrain, like in the "original" controller? As i remember right it was introduced to dampen the "wobble of death".

Cheers
Rob

No, AlexK only used P for Level and Horizon, and Level_I in the GUI is really Horizon_P.

Yes, that is exactly what i actually meant. The Level P value for Angle and the Level I value for Horizon (I should have written: interpreted as "P").
That is something like the KK2.0 boards do when level - i think.

Crashpilot1000 wrote:Well, actually i am not really interested in that 8Bit stuff. I am interested in his GPS / INS fusion part. And that seems undisclosed. There are some "opensource" projects online that are suddenly obscured when you get to the interesting part. Or they try to hide it by digging it deep into some "tree".

the implementation would remain the same.
the f4 source is kept as a secret.

brm wrote:

Crashpilot1000 wrote:Well, actually i am not really interested in that 8Bit stuff. I am interested in his GPS / INS fusion part. And that seems undisclosed. There are some "opensource" projects online that are suddenly obscured when you get to the interesting part. Or they try to hide it by digging it deep into some "tree".

the implementation would remain the same.
the f4 source is kept as a secret.

here is a thread started by Gke on the topic: viewtopic.php?f=23&t=2831

Hello, I've just received the PM telling that my offer on PID is included into the code. Now I feel bad, that I left so early - sorry to all! I would look though the code, test, and then we can continue on fine tuning it. Are there current unsolved issues with it?

alex.khoroshko wrote:Hello, I've just received the PM telling that my offer on PID is included into the code. Now I feel bad, that I left so early - sorry to all! I would look though the code, test, and then we can continue on fine tuning it. Are there current unsolved issues with it?

Yea, around here, one has to have balls of steal and the temperament of a Goat. LOL

Welcome back.

alex.khoroshko wrote:Hello, I've just received the PM telling that my offer on PID is included into the code. Now I feel bad, that I left so early - sorry to all! I would look though the code, test, and then we can continue on fine tuning it. Are there current unsolved issues with it?

Yes.
We /YOU / someone has to provide good dwfault values which
* are good starting point for indiv8dual tuning
* work for almost all coptertypes in different sizes

IMO it would be better to have "safe" default values (that will never overshoot on any machine). As no copter is the same, and people pretending they use default values are lucky if it works or are not aware it could be 100x better with the right values for a given copter.
manu
PS:could we have the "more/less" (0-100%) PID values implemented, this will so much clearer.

alll wrote:PS:could we have the "more/less" (0-100%) PID values implemented, this will so much clearer.

+1

@copterrichie: Thanks for the link, that was an interesting link. Esp. the person that warned gke about the rude manners and aggression here. Yes this forum has quiet frequently narrow minded "bad karma" at play but on the other hand there are nice and helpful persons as well.

@alex.khoroshko: I am very glad to hear that you made up your mind and rejoined the discussion. Your input as a "person in the know" is always very appreciated. Finding correct "average joe copter" values may not be easy but i wouldn't bother about that too much as long as the "dimensions" are right and not off by x1000 .

The 0-100% Pid is basically a good idea but since both pid controllers have different behaviour and interprete some values differently it will be not an easy task.
I also thought that stockpids of all zero could be also an idea - that would force people to read and understand the PID controls. That idea is probably very unpopular.

Cheers Rob

alll wrote:PS:could we have the "more/less" (0-100%) PID values implemented, this will so much clearer.

no difference at all. Both ranges [0;100] and [0;255] (or [0;0.255]) are of the same category - numbers with no resemblance to real world. One is not in any way better than the other - in both cases users have to learn the impact of changing that particular variable.Only drawback of the 0-100% range is it has less granularity when mapped to the true integer representation. I agree we could drop the decimal representation in the gui but then again pleny of people are accustomed to that already.

I think part of the problem is, many do not understand what the PID process is or not to tune it. This Explanation should be incorporated into the Wiki.
http://www.rcgroups.com/forums/showthread.php?t=1890703

Hamburger wrote:

alll wrote:PS:could we have the "more/less" (0-100%) PID values implemented, this will so much clearer.

no difference at all. Both ranges [0;100] and [0;255] (or [0;0.255]) are of the same category - numbers with no resemblance to real world. One is not in any way better than the other - in both cases users have to learn the impact of changing that particular variable.Only drawback of the 0-100% range is it has less granularity when mapped to the true integer representation. I agree we could drop the decimal representation in the gui but then again pleny of people are accustomed to that already.

So, lets make all parameter granularity to be at least 0..255 (byte), let the code do the math to lower/increase the scaling factor, and show in the gui only values for all pid-parameters to be from 0..255.

manu

copterrichie wrote:I think part of the problem is, many do not understand what the PID process is or not to tune it. This Explanation should be incorporated into the Wiki.
http://www.rcgroups.com/forums/showthread.php?t=1890703

He also only talks about "increasing", "back off", "speed", ...
manu

alll wrote:

copterrichie wrote:I think part of the problem is, many do not understand what the PID process is or not to tune it. This Explanation should be incorporated into the Wiki.
http://www.rcgroups.com/forums/showthread.php?t=1890703

He also only talks about "increasing", "back off", "speed", ...
manu

Which is why I made this statement:

This is very good, excellent in fact! The only misgiving I can see is, if the P value is too low from the start, it will oscillate also but somewhat more radical, maybe totally uncontrollable. This can be mistaken as be too much P value.

but yet, it is the BEST I have seen as of today.

copterrichie wrote:
but yet, it is the BEST I have seen as of today.

Yes i like these kind of "simple" explanations, you see he "knows" by experience.

copterrichie wrote:This is very good, excellent in fact! The only misgiving I can see is, if the P value is too low from the start, it will oscillate also but somewhat more radical, maybe totally uncontrollable. This can be mistaken as be too much P value.

But then your copter is IMO unstable by design, on one of my quads, i can fly with p almost to zero

alll wrote:But then your copter is IMO unstable by design, on one of my quads, i can fly with p almost to zero

LOL, I am not about to get into stability debate because ALL Multi-rotor copters are inherently unstable. Because you are using a very low P factor simply means, you have a very high power to weight ratio.

Welcome back alex!

I think the discussion on obfuscating PID values with "user friendly" 0-100 scale is off topic. Related perhaps, but start another thread if it's so important.

So far I've seen only two sets of working PIDs posted here, please post your PIDs!.

My experiments with the Ziegler-Nichols Pot tuning code over here in conjunction with the new PID Controller left me surprised by the range of values that do work with the Z-N ballpark stuff, I'm talking Kp of 2.5 to ~10! However Level Kp effect changes a lot with different Roll/Pitch Kp values - from not maintaining level flight to strong oscillations.

First of all, welcome back Alex! Ithink this is good news for MW community.

I have written this before, to me PID setup got a lot easier with the new implementation. My quad was controllable over a wide PID range, e.g. P for roll and pitch started working not far over 2.0 and was still not bad at 5.0, impossible with the old PID loops.

I spent a lot of hours flying different kind of stuff over the last couple of years and observed the development of flybarless helicopter systems let´s say during the last three years. Simply said In the beginning there was a lot to adjust but they worked poor now they are plug and play more or less and work well with defaults from 250 heli size to 700 plus.

In the middle of 2012 Futabas CGY750 was V1.2, one had to fiddle with PIDs a lot sometimes even mixers were needed but especially in smaller sized helis control was frequently far from ideal. This changed totally with V1.3, just enter heli size and one of five flight modes from beginner to champion, adjust gain for yaw a little bit, that´s it. Gains on roll and pitch usually work with defaults, rising or lowering the values does not change a lot but a perfectly running system doesn´t need to be changed!

It was pretty similar with other FBLs and installing Alex´modification IMO resembles this development pretty much, its easier to adjust AND works a lot better!

So from a pilot´s point of view: Keep it up! Keep it simple! Only a few parameters to adjust with as few steps as possible (really 255 required?).

Microbeast FBL system e.g. has a single potentiometer for roll and pitch gain (called "Cyclic Gain", P and D together?) and a six step cyclic I gain (called "Pitching Uo Behaviour"). There are two more potentiometers for direct feed on cyclic and yaw. P gain for yaw as the most important value for single rotors is set via radio, yaw I gain is called "Heading Lock Gain", again six steps. That´s all with stabilization, a few more settings are kind of expo and D/R.
With all these values on defaults almost every single rotor flies pretty well. The manual describes shortly but precisely how parameters work, what they do when raised or reduced and how the heli reacts when they are set too high or too low. Not a single word about proportional or integral all the PID loop stuff simply not needed. All you have to do is attaching the little box into your heli and plugging in the servos. Without being Einstein It takes just a few lipos to finish setup and get a perfectly controlled single rotor.

It´s even more simple with KK5.5 board. Two important pots, the third works on 50% in most cases. Start with 25% Roll (P roll + pitch, D fixed?) 0% Pitch (I roll + pitch). Increase Roll until oscillation starts and reduce a bit. Increase Pitch until speed pitch up disappears. Period.

All these systems described above are perefctly controllable by direct pilot input. Is there such a big difference whith input coming from baro sensor or GPS unit?

Oh, that's a good idea! All the coefficients (P, I and D) are scaled by the trust to weight ratio. So, we can make the common parameter, which would adjust them all at the same time (not change their values, but is a scale factor, which implicitly multiplied by them all). It would work as good, as possible for people, who can not/do not want to understand the difference between all the gains. It can be done very efficiently -by scaling of error value - single multiplication is only needed.
This should look like this:
Gain [0:255], P[-100%:+100%], I[-100%:+100%], D[-100%:+100%].
Or, PIDs gains correction can be done in our favorite [-127:127]. It needs testing - quite possible that the range of about 10% would work for all. The only potential drawback here is D - it may make aircraft twitchy if the vibrations are bad, so there should be a way to make it zero (-100% correction should be accessible).

Also, I still remember about redoing the horizon mode to make it tunable from minor leveling (like I did initially) to the same behaviour, as horizon is in the initial version of PID. Would do that ASAP.

Also, why changing with a pot? Let's make any PID value assignable to any channel via GUI? You fly and tune - the best way possible, IMO. The only problem here is how to save the settings. Saving every second seem nice, but it needs asynchronous EEPROM write routine. I have one, if that would be needed.

And I thought about self-tuning PIDs. Ziegler-Nichols method won't work well, because different multirotors (not only different types, but also different frames) have different amplitude-phase characteristic - some ESC may introduce dynamic influence early, some - may not etc. For example (I said it earlier) my bad quad needs very low P and most of the control is done through the I gain (without it the quad is barely flyable). So just setting the gains proportionally is not the solution for all the problems, it's a good idea to start tuning, though (as I've written above)

felixrising wrote:Welcome back alex!

I think the discussion on obfuscating PID values with "user friendly" 0-100 scale is simply off topic. Related perhaps, but start another thread if it's so important.

So far I've seen only two sets of working PIDs posted here, please post your PIDs!.

My experiments with the Ziegler-Nichols Pot tuning code over here in conjunction with the new PID Controller left me surprised by the range of values that do work with the Z-N ballpark stuff, I'm talking Kp of 2.5 to ~10! However Level Kp effect changes a lot with different Roll/Pitch Kp values - from not maintaining level flight to strong oscillations.

So, if you think it is off topic, give us examples of PID's and tell us how to interprete them. I really don't see what you will do with those PID's without knowing the mechanics of the multicopter!
So if it is so important those PID values, start another thread that gives us the relation between PID and multicopter physical setup.
manu

Most important for us to be able to tune the different PID values (0..255 is to explain (the developer of the PID loop) how and what the ERROR is and how it is calculated, this for each PID.
And the PID formula in speudo code : eg:


The PID implementation drawing Alex.k posted is also very, very useful, a necessity!

angular velocity PID error for roll/pitch/yaw : Rx[axis]-Gyro[axis] (knowing that gyro is angular velocity)
level PID : ...
...

Thanks,
manu
A drawing is wort 1000 words

felixrising wrote:Welcome back alex!

I think the discussion on obfuscating PID values with "user friendly" 0-100 scale is off topic. Related perhaps, but start another thread if it's so important.

So far I've seen only two sets of working PIDs posted here, please post your PIDs!.

My experiments with the Ziegler-Nichols Pot tuning code over here in conjunction with the new PID Controller left me surprised by the range of values that do work with the Z-N ballpark stuff, I'm talking Kp of 2.5 to ~10! However Level Kp effect changes a lot with different Roll/Pitch Kp values - from not maintaining level flight to strong oscillations.

I had the same results with the "oldschool" PID algorithm and Z-N pot tuning: In gyro mode the range of usable value is quite large... It makes very easy to find an acceptable tuning point. 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.

In Level (angle) mode, it is more difficult though.