Page 1 of 6

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

Posted: Sat Jun 15, 2013 4:19 pm
by chris_kmn
alex.khoroshko wrote:Yes, would be done! I'm in progress of drawing the full diagram including maximum variables values etc (I like well documented projects). Would post ASAP.

Thanks for your support on this !

The thing is - I like horizon to help just a bit, not be the level mode at sticks centered, so I didn't think it would be needed. It would be cool to make horizon mode fit everyone's vision of it by just changing the single coefficient value.
I would be glad to hear your thoughts on horizon, what in your opinion should it be.


I agree that it's a good way to not having too much level for nice acro flying. I also don't like to allways counteract against level with the sticks. Maybe a deadband or so could be nice to disable level when sticks are out of center. but in that case you have to hold the value of the integrator cause it would wind up and if sticks then come back to center it is just too big.

1. Rates are way too high? I used it at around 0.50 value (I like sharp control). I doubt someone would need it higher, so I can scale it down.


I think downscaling of about 20 to 50% would be good.

2. autolevel shut-off at extreme sticks needed (in form of mixing - the more sticks inclination, the less autolevel).


I think mixing could be an issue cause the integrator could wind up and work against stick input. Maybe a small deadband could be better and then higher I-values or even I and P

Again thanks a lot for that nice contribution ! :-)

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

Posted: Sat Jun 15, 2013 7:11 pm
by chris_kmn
Some flights later.....

I increased the I value up to 1 and still almost no leveling in horizon mode. How high can/should I set the I value ?

Yaw is in my opinion to hard. Due to the high rev differences between the props the whole copter is getting instable. Maybe the yaw should be scaled down more than the roll/nick scaling. I used 0.4 for yaw rate and it still was very hard.

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

Posted: Sat Jun 15, 2013 7:48 pm
by BarneyG
I just added this into my code along with the Gyro Scaling changes. Unfortunately I'd also removed the expo from the MultiWii config as I had that set up in my RX as well :roll: so it wasn't a direct comparison. I reset my PID's to the defaults set in the code after making a backup of my existing ones.

Being a beginner I fly in Angle mode most of the time and this test run was really no different also since I'm a beginner I'm not sure exactly how informed my observations are :). The sticks are loads more sensitive to input (that will be in part due to the removing of the double expo) but in the complete opposite to what I was worried about when I first discovered this it actually made it easier to control. Loads of wind here just now and while the quad was being blown about there wasn't much in the way of judder when it was compensating. There was also very little/no oscillation when it was descending slowly, through its own prop-wash, or rapidly.

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

Posted: Sat Jun 15, 2013 10:43 pm
by Phil S.
Alex, you are a genius!

Your mod is not less than a revolution. Control is perfect, turning rates on all axes are adjustable to any level you like, yaw is now even better than with my so far favourite, the HK copy of the KK5.5. At the same time setup is easy and far from beeing critical. I started with zeroeing I and D, and a P on roll and pitch of 2,5 (controllable but no fun to fly), from around 3,0 it went acceptable, getting better and better, started to oscillate between 4,8 and 5,0, but oscillations were slight, noncritical. The copter is now literally nailed to the sticks, has not the least tendency to pitch up at high speeds. Yo can flip on the spot or fly really big loops or everything in between. Used Plüschis IMU mod as well, so activating angle mode at any time levels perfectly. Angle mode is fast, the position of the copter follows the stick movement almost instantly. Position Hold, Coming Home, Alt Hold, really good, not as good as my ArduCopter DJI F450 (using ACC in addition to baro for Alt Hold and kind of waypoints for Coming Home resp. Return To Launch), but not far from it. There are definitely no oscillations at all, even if you try to provoke it with very fast stick input. When P and D gets too high, it becomes a bit difficult to control altitude, but it needs even higher values until oscillation begins.

Attached my current setup of my Gaui 500X with a Crius AIOP V2.0. The quad has motors and ESCs right out of the box, no SimonK upgrades, cheap plastic props out of the bag, did not balance them.

You wouldn´t think it to be possible until you fly. What you managed within a few hours is IMO a giant leap for MultiWii FCs! Thank you, Alex!

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

Posted: Sun Jun 16, 2013 9:32 am
by alex.khoroshko
Thanks for such a good response!
Here's a sketch of the implementation. I've also attached the PDF version (it's hard to read from image). I would try to increase the readablitity (increase font size or something).
pid alex.k11.png

but in that case you have to hold the value of the integrator cause it would wind up

There's no integrator for horizon mode - regulator just requests the angle rate proportionally to angle difference (I used "I" value because it was free. it should be renamed into "horizon P"). The system integrates by itself, because angle is integral from angle rate. As for horizon strength - coefficient of 16 corresponds to the same leveling strength, as 1 for "level" mode (they have equal implementation, only the scaling is different).
For the next version, I've made out the fix for that as well - I just squared the coefficient, so the more you increase GUI value, the faster real coefficient is increased. Should give very weak leveling at 1 (the way I like it) and really locked-in leveling at 4 (like in angle mode - the way you seem to want it to be). Would test myself and then post here (together with scaling fix (all modes) and extreme sticks mix-up for horizon).

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

Posted: Sun Jun 16, 2013 9:52 am
by timecop
I added this as selectable PID controller to baseflight - set pid_contoller=1 (per-profile setting) to try out.

I gave it a brief hover and it seems to work with the PIDs posted couple posts above, though rate mode was WAY too fast, and my only flying frame (iconic-x) has yaw issues where it almost drops out like a naza when you yaw too fast (it's not related to this code, it does that in general, too).

Snap back to level was much better than what I've seen in multiwii so far.

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

Posted: Sun Jun 16, 2013 10:23 am
by chris_kmn
Is there any chance to get a version based on the actual V2.21 together with this Plüschi IMU (I don't know anything about this but it seems to be helpful) ?

And then we need to find a way to get it all to an official release :-)

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

Posted: Sun Jun 16, 2013 11:42 am
by BarneyG
Am I right in saying v 2.21 is in the trunk/MultiWii_shared folder in svn ?

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

Posted: Sun Jun 16, 2013 11:54 am
by -ralf-
BarneyG wrote:Am I right in saying v 2.21 is in the trunk/MultiWii_shared folder in svn ?

You are right .... but don't forget to use the latest multiwiiconf.pde.

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

Posted: Sun Jun 16, 2013 12:34 pm
by chris_kmn
is there any chance to get a tutorial how to work with the google.code site ?

which tools do I need for example to update all the releases up to r1474 (somebody references the r1474 changes to this thread) based on the last official release r1391 ?

update: I used SVN to download the _shared. Hope that that includes the r1474 . there is no reference in miltiwii.ino. just says 2.21. Is there already the new PID control loop integrated ?

And for what is the PDE file ?

meanwhile I updated the new gyro scale from Plüschi and it changed a lot for me. I can rise the PID values way more and now the I - value for horizon is working fine. I like the new implementation very much !

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

Posted: Sun Jun 16, 2013 12:46 pm
by alex.khoroshko
Hey guys! So, what's the deal with SVN updates? How should I proceed? Take the last version and update it to my implementation, post here, if test successful commit to SVN?
Also, as multiwii aims the .c and .h files style, would anybody mind if I create separate file filters.c and move the PID (and later other filters) there? The idea is it would be possible to use one PID code for all loops in style:

Code: Select all

pPID_desc->input = var;
PID (pPID_desc);
output = pPID_desc->output;

This would save a lot of space and also increase performance (reduce processing time) a bit.

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

Posted: Sun Jun 16, 2013 12:49 pm
by BarneyG
-ralf- wrote:
BarneyG wrote:Am I right in saying v 2.21 is in the trunk/MultiWii_shared folder in svn ?

You are right .... but don't forget to use the latest multiwiiconf.pde.



In which case the IMU fix is already in place in the current _shared directory :)
Edit and I'm also very confused ... there is an awful lot of changes for a 2.2 -> 2.21 style release :) this looks more like the current dev release of 2.3 ?

and another edit :

r1474
- based on some ideas from this thread:
viewtopic.php?f=8&t=3671
- the sticks scaling is no more affected by PID coefficients
- yaw rate (to the right of the PIDs in GUI) now works as stick scaling
- default yaw rate is increased (with yaw rate at 0)
- yaw PID principle is now different from PITCH&ROLL PID:
- yaw ITerm windup is very high, allowing an 'elastic' direction return after a
manual perturbation
- yaw ITerm is also constrained with a windup independent limit
- yaw PTerm is constrained in order to counter the yaw jump effect (maybe to
refine)
- yaw ITerm is canceled if the yaw stick is not centered
Today (14 hours ago)
dubusal

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

Posted: Sun Jun 16, 2013 2:11 pm
by Alexinparis
Hi,

There are a lot of aspects in this thread.

So let's try to isolate things.

1) PITCH/ROLL acro PID update:
- PID coef must not have impact on stick scalling, OK
- cycleTime should be included in I and D Term computation. Does it really have a noticeable effect on flight performance ? For sure it has a noticeable effect on computation time.
- D component doesn't take into account stick position at all. Again, from wiki link: “In most commercial control systems, derivative action is based on PV rather than error.”. Does it really have a noticeable effect on flight performance to take error rather than PV in the equation ?
- 32bit implementation for I term: Does it really have a noticeable effect on flight performance ?

2) YAW PID update:
I think 32bit Ierror term is interresting not to gain more accuracy (from a flight performance point of view), but to gain more windup.
Is there any other approach to counter the yaw jump effect ?

3) ANGLE/HORIZON mode update
I think Horizon mode (relativly new) have good feedback so far, but why not update it
If feedbacks on it are better.

4) wrong MPU scale:
it was reported by ovaltineo
viewtopic.php?f=8&t=3480
and is corrected in _shared
It affects mainly angle calculation after many flips. Nothing to do with PID.

5) versions:
There is no 2.21 version.
The last official version is 2.2.
All other variant after are just dev version for testing purpose based on _shared repository.
And sometimes I create a zip of intermediate dev versions

6) the deal with SVN update
There are few committers that can update it, based on what they think useful.
The best way to suggest evolution is what you did: explain the mod in the forum, share a zip code and get feedbacks.

7) why so many compromises on the code ?
Because it's always a challenge to keep computation time and code size low. More than a challenge, it's also for me a fun way of coding.
I understand it could be disturbing from a theory or coder point of view.

which tools do I need for example to update all the releases up to r1474

You only need to get the last r1474 files.


Snap back to level was much better than what I've seen in multiwii so far.

Did you try to increase LEVEL P with the stock code ?

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

Posted: Sun Jun 16, 2013 2:50 pm
by alex.khoroshko
- cycleTime should be included in I and D Term computation. Does it really have a noticeable effect on flight performance ?

I component: flight - no. Tune performance - well, it should be. I would try to compile the code with and without loads of functions to see, whether I meaning change when it is not time corrected. Then it would be clear, whether correction needed or not. Also, D correction is needed IMO - it feels a bit better with it, it may be placebo effect though. But it looks logical, that if dt is very different every time, D response would not be consistent.
Does it really have a noticeable effect on flight performance to take error rather than PV in the equation

Yes, at least I feel the difference. When the stick is moved rapidly it creates something like short impulse. Too high D lead to overshoot though.
- 32bit implementation for I term: Does it really have a noticeable effect on flight performance ?
Not quite sure, quite possible that no. Should be carefully tested.
YAW PID update:
I think 32bit Ierror term is interresting not to gain more accuracy (from a flight performance point of view), but to gain more windup.
Is there any other approach to counter the yaw jump effect ?

There is a limiting, which prevents from wind up. Jump effect needs fixing, I agree. Harder limiting would help (just reduce the limits separately from roll and pitch)
ANGLE/HORIZON mode update

It would work the same as old one when coefficient is set high. With low coefficient it would slowly drift towards horizontal position (how me, and, I think, some other FPVers like)
Did you try to increase LEVEL P with the stock code ?

My little comment - original code does pretty much the same as mine, except that it is now clearly arranged as one control loop inside another, internal is already fine-tuned for acro mode, external is easily tuned with single coefficient. Also, gyro-based correction was initally P-controlled only with this line:

Code: Select all

 PTerm -= ((int32_t)gyroData[axis]*dynP8[axis])>>6; 

New code in repository does the same. My version's internal loop is full PID regulator, that's why additional I for level mode is not needed.

And, what do you think about moving filters to separate file? I'm sure that it would decrease image size at least, but is it compatible with multiwii overall coding style?

P.S. I see where to save A LOT in terms of performance. The I2C transfers should be made asynchronous (interrupt driven). This would allow process I2C transfer in background while at the same time processing the main loop. Drawbacks - increased jitter for software PWM and a little increased code size. I would try and then create separate thread if it would be good.

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

Posted: Mon Jun 17, 2013 3:07 am
by Plüschi
alex.khoroshko wrote:I would be glad to hear your thoughts on horizon, what in your opinion should it be.


I would like it as you say "centered - goes towards horizontal position with the set rate, extreme sticks - pure ACRO".
Horizon as it is now allows more inclination than angle but doesent allow flips.

One thing i dont understand is running the loop as fast as i goes. My version uses a fix 3.666ms loop time, and i cant feel any difference to the jittering 2.9ms loop time the default code uses. Considering the reaction time of ESC and motors is more in the 100ms range what does 2ms loop time buy?

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

Posted: Mon Jun 17, 2013 8:21 am
by scrat
Phil S. wrote:
scrat wrote:If you're just a pilot...then mwii is not for you.

That´s been a bit of exaggeration. Wouldn´t be to much of a problem modifying code as you described but i am not too keen on it! On the other hand it seems to me that some of the guys programming MultiWii are good in writing code but not too keen on flying!

Guys like you and Alex doing both (at higher levels) appear to be a minority group.

Alex, did you rewrite PIDs for all three axes or just for roll and pitch?


Sorry for my exaggeration. It wasn't meant like that. Sorry again.

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

Posted: Mon Jun 17, 2013 8:34 am
by scrat
BarneyG wrote:Alex ... any reason why you've changed the #define I2C_SPEED 400000L to #define I2C_SPEED 100000L for the Crius AIOP v1 definitions ?


Did you know if you have Crius AIOP v1, V1.1 or v2 you can have I2C speed commented out. I have it like that and don't have I2C errors anymore.

/********************************** I2C speed ************************************/
//#define I2C_SPEED 100000L //100kHz normal mode, this value must be used for a genuine WMP
//#define I2C_SPEED 400000L //400kHz fast mode, it works only with some WMP clones

Because there is in def.h file for AIOP vX already defined:

#if defined(CRIUS_AIO_PRO_V1)
#define MPU6050
#define HMC5883
#define MS561101BA
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = -X; accADC[PITCH] = -Y; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = Y; gyroADC[PITCH] = -X; gyroADC[YAW] = -Z;}
#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = X; magADC[PITCH] = Y; magADC[YAW] = -Z;}
#define MPU6050_I2C_AUX_MASTER // MAG connected to the AUX I2C bus of MPU6050
#undef INTERNAL_I2C_PULLUPS
#define I2C_SPEED 400000L //400kHz fast mode

Posted: Mon Jun 17, 2013 9:11 am
by BarneyG
I've got a v2 ... The reason I asked is that it is the line you bolded has been changed to 100000 in Alex's code :)

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

Posted: Mon Jun 17, 2013 10:05 am
by Phil S.
scrat wrote:Sorry for my exaggeration. It wasn't meant like that. Sorry again.

"Exaggeration" was pointed at my statement beeing just a pilot not at yours! Wanted to state that I am interested in a bit more than just banging sticks. No need to apologize, I´m not huffy at all!

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

Posted: Mon Jun 17, 2013 11:15 am
by Hamburger
Plüschi wrote:Horizon as it is now allows more inclination than angle but doesent allow flips.

Plain wrong. I do it all the time.

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

Posted: Mon Jun 17, 2013 11:55 am
by Plüschi
Hamburger wrote:Plain wrong. I do it all the time.


Why does mine not flip in horizon, but does in angle with acrotrainer enabled ?

Re:

Posted: Mon Jun 17, 2013 1:43 pm
by scrat
BarneyG wrote:I've got a v2 ... The reason I asked is that it is the line you bolded has been changed to 100000 in Alex's code :)


I know. I have both commented out because in file def.h there is already defined. This apply for v2 too.

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

Posted: Mon Jun 17, 2013 6:29 pm
by crashlander
Plüschi wrote:
Hamburger wrote:Plain wrong. I do it all the time.


Why does mine not flip in horizon, but does in angle with acrotrainer enabled ?


What are your PID's, pitch roll RATE and RC RATE? I found it difficult to flip it even in ACRO mode until I upped both RATE's (I'm flying wii-esc flashed ESC and gyro PID's P around 8)!

Regards
Andrej

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

Posted: Mon Jun 17, 2013 6:49 pm
by shikra
Cool developments in places.

Crashlander -
Low D helps with fast flips as well as rates. In standard implementation

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

Posted: Mon Jun 17, 2013 10:49 pm
by brm
alex.khoroshko wrote:Thanks for such a good response!
Here's a sketch of the implementation. I've also attached the PDF version (it's hard to read from image). I would try to increase the readablitity (increase font size or something).
pid alex.k11.png

but in that case you have to hold the value of the integrator cause it would wind up

There's no integrator for horizon mode - regulator just requests the angle rate proportionally to angle difference (I used "I" value because it was free. it should be renamed into "horizon P"). The system integrates by itself, because angle is integral from angle rate. As for horizon strength - coefficient of 16 corresponds to the same leveling strength, as 1 for "level" mode (they have equal implementation, only the scaling is different).
For the next version, I've made out the fix for that as well - I just squared the coefficient, so the more you increase GUI value, the faster real coefficient is increased. Should give very weak leveling at 1 (the way I like it) and really locked-in leveling at 4 (like in angle mode - the way you seem to want it to be). Would test myself and then post here (together with scaling fix (all modes) and extreme sticks mix-up for horizon).

looking at the code is always problematik.
in essence you are cascading two control loops.
instead of naming it 'tmp' name it desiredRate. this rate is scaled according to mode you are flying.
separating the two loops could lead to code which is more understandable.

on the d-term it is not so simple.
i don't like averaging buffers.
a pt1 element is more predictable.
doing not so the changes on the dterm can saturate your esc.
also the d-term can be calculated on the state or the error.
both have different flightbehaviours.
in general i like the cascaded approach and the error on the d-term.

to prove what you said you need a vicon-system to verify your point of view.
also looking only at the loop/cycletime is wrong - you need the whole feedback loop.
your command has to come through.

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

Posted: Mon Jun 17, 2013 11:56 pm
by Mis
Did you know if you have Crius AIOP v1, V1.1 or v2 you can have I2C speed commented out. I have it like that and don't have I2C errors anymore.

Do you know, that "#define I2C_SPEED" definition have no effect in most cases because "sensors.ino" have own I2C speed definitions for every sensors ?
BTW this is waste flash, CPU time ect, and cause that I2C work in most cases with 400kHz, even if you declarate "#define I2C_SPEED 100000".
The "#define I2C_SPEED" definition is only usable with old WMP and nunchuk sensors.

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

Posted: Mon Jun 17, 2013 11:59 pm
by copterrichie
Mis wrote:Do you know, that "#define I2C_SPEED" definition have no effect in most cases because "sensors.ino" have own I2C speed definitions for every sensors ?
BTW this is waste flash, CPU time ect, and cause that I2C work in most cases with 400kHz, even if you declarate "#define I2C_SPEED 100000".
The "#define I2C_SPEED" definition is only usable with old WMP and nunchuk sensors.


there is ALLOT of optimizing that can be done. Seriously.

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

Posted: Tue Jun 18, 2013 9:45 am
by scrat
Mis wrote:
Did you know if you have Crius AIOP v1, V1.1 or v2 you can have I2C speed commented out. I have it like that and don't have I2C errors anymore.

Do you know, that "#define I2C_SPEED" definition have no effect in most cases because "sensors.ino" have own I2C speed definitions for every sensors ?
BTW this is waste flash, CPU time ect, and cause that I2C work in most cases with 400kHz, even if you declarate "#define I2C_SPEED 100000".
The "#define I2C_SPEED" definition is only usable with old WMP and nunchuk sensors.


No I didn't know that. Thanks for info Mis.

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

Posted: Wed Jun 19, 2013 11:12 am
by felixrising
Just took this process loop implementation on baseflight/stm32 for a test flight, very nice! Great work alex.k!!! The values posted here by Phil.S are great, though I added a little more RC Expo.. I'll maiden it on one of my Crius AIO Pros on the weekend...

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

Posted: Wed Jun 19, 2013 11:30 am
by felixrising
Alex.k... I hear you like documentation... please ask Hamburger or Alexinparis for a wiki ID and do your worst... :D

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

Posted: Thu Jun 20, 2013 10:31 am
by Crashpilot1000
Hi i just tested the new Pid controller and it does great but i think the levelP should be prescaled (division by 3?) otherwise people will crash when not turning down their "known" level P. Just an safety - idea.

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

Posted: Thu Jun 20, 2013 5:21 pm
by alll
alex.khoroshko wrote:
pid alex.k11.png

Image


This is realy, realy helpful to understand and afterwards tune the PID's!
Many thanks for that!

Is this the current multiwii2.2 or an adapted version, which SVN release?

Manu

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

Posted: Fri Jun 21, 2013 11:37 am
by Crashpilot1000
@alex.khoroshko: First of all a big thank you for actually rethinking and improving core parts of the flightcontrol !!!
While fiddeling around with your new controller i was wondering if the frequency cut of the D term used in the arducopter2.7.X/multi GPS code could also help your main pid controller (http://code.google.com/p/multiwii/sourc ... GPS.ino#39)? Currently i am implementing it and was wondering what frequency cut off might be useful. I will start with 20Hz, but do you have any suggestion concerning that cutoff frequency?
An indoor Hand-test suggests a cut off frequency below 10Hz, 5Hz seems fine. Constant rain here, cant wait to test it.
Cheers Rob

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

Posted: Fri Jun 21, 2013 9:19 pm
by chris_kmn
Is there already a SVN release with the new controller implementation ?

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

Posted: Sat Jun 22, 2013 7:19 am
by alex.khoroshko
No, and I guess there wouldn't - some changes were introduced by someone, but the implementation is still in the mazy form. I have a version, which fits my needs better than original, nobody of the developers seem to care - the fun part here is complete.
So now I decided to quit and go build my own flight control software with blackjack and hookers, and here's why. I have 2-3 students per year, who need to write their graduate thesis (I'm a teacher in Siberian Aerospace university). It was always such a pain to make out the topic related to control systems and aircrafts (this year the topic was the control system for cooling equipment needed to perform the degradation tests of lithium-ion batteries for satellites - imagine, how far that is, lol). Now the problem is solved. I first thought to do that within the multiwii project, but then I realized that separate development better fits the constraints of the graduate thesis.

So, good luck to everyone!

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

Posted: Sat Jun 22, 2013 8:21 am
by brm
alex.khoroshko wrote:No, and I guess there wouldn't - some changes were introduced by someone, but the implementation is still in the mazy form. I have a version, which fits my needs better than original, nobody of the developers seem to care - the fun part here is complete.
So now I decided to quit and go build my own flight control software with blackjack and hookers, and here's why. I have 2-3 students per year, who need to write their graduate thesis (I'm a teacher in Siberian Aerospace university). It was always such a pain to make out the topic related to control systems and aircrafts (this year the topic was the control system for cooling equipment needed to perform the degradation tests of lithium-ion batteries for satellites - imagine, how far that is, lol). Now the problem is solved. I first thought to do that within the multiwii project, but then I realized that separate development better fits the constraints of the graduate thesis.

So, good luck to everyone!


ahh,
welcome in the club!
you are facing the behaviour of the developper core.
way to slow for quite a few people.

i would invite you to use timecops baseflight hw and sw.
would be interesting to develop new things.
i hope your development is not too isolated.

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

Posted: Sat Jun 22, 2013 8:31 am
by brm
Let’s focus first in the ACRO mode for understanding.
The scheme is mainly correct.

in essence nothing wrong ... in theory.
the d-term needs to more controlled - use a pt1 element to dampen the changes comming from the d-term.
the result is more predictable.
a 08-15 pid controller must have a pt1 element.

the pid calculation as a whole sucks.
the implementation is too sensitive with regards to vibrations.
you get int16_t overruns...
also the dyn pid also has a problem with heavy vibrations.
here i need more time for investigations.

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

Posted: Sat Jun 22, 2013 8:45 am
by alll
alex.khoroshko wrote:...nobody of the developers seem to care - the fun part here is complete....
So, good luck to everyone!


Come on, the "non-developers/comiters" do also want to have fun ;)
You could at least ask a separate branch as casquad got for the code reorganisation! , "commiters", can you make this happen?
Thanks,
manu
PS: IMO a proper "simple/standard (without too many special tricks)" PID control loop is mandatory, the right PID values will make the difference!

Posted: Sat Jun 22, 2013 9:59 am
by BarneyG
Indeed ... At least post your latest version for those of us who are seeing the benefits of your efforts :)

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

Posted: Sat Jun 22, 2013 11:08 am
by Crashpilot1000
@brm: "the d-term needs to more controlled - use a pt1 element to dampen the changes comming from the d-term."
Yes, absolutely! - Came to the same conclusion while fiddeling with that altered Pid controller. The gps "D" part didn't do it :( . (It is basically the same but missing the averaging part)
I put everything on "floats" in the pidcontroller and can not complain, works nice. The flightfeeling is different compared to the convetional mwii controller but i like both now. I think mwii should somehow implement that altered Pid controller as an option to choose from. On the other hand who really cares? The soft is opensource. It's just a matter of days, till someone comes up with a more polished version of that. Maybe mahowik?
Cheers
Rob

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

Posted: Sat Jun 22, 2013 12:52 pm
by alll
Crashpilot1000 wrote:...I think mwii should somehow implement that altered Pid controller as an option to choose from. On the other hand who really cares? The soft is opensource. It's just a matter of days, till someone comes up with a more polished version of that. Maybe mahowik?
Cheers
Rob


Or make it more "pluggable", everybody should be abe to "plug" its PID controller into mwiii ! :roll:
manu

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

Posted: Sat Jun 22, 2013 1:04 pm
by copterrichie
alex.khoroshko wrote:No, and I guess there wouldn't - some changes were introduced by someone, but the implementation is still in the mazy form. I have a version, which fits my needs better than original, nobody of the developers seem to care - the fun part here is complete.
So now I decided to quit and go build my own flight control software with blackjack and hookers, and here's why. I have 2-3 students per year, who need to write their graduate thesis (I'm a teacher in Siberian Aerospace university). It was always such a pain to make out the topic related to control systems and aircrafts (this year the topic was the control system for cooling equipment needed to perform the degradation tests of lithium-ion batteries for satellites - imagine, how far that is, lol). Now the problem is solved. I first thought to do that within the multiwii project, but then I realized that separate development better fits the constraints of the graduate thesis.

So, good luck to everyone!


SAD but understandable. I hope you will reconsider.

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

Posted: Sat Jun 22, 2013 4:31 pm
by disq
felixrising wrote:Just took this process loop implementation on baseflight/stm32 for a test flight, very nice! Great work alex.k!!! The values posted here by Phil.S are great, though I added a little more RC Expo.. I'll maiden it on one of my Crius AIO Pros on the weekend...


Also in baseflight i_level is limited to 0.20 ("200") and multiwiiconf limits it to 0.25. So Level_I=0.30 posted by Phil is not possible at the moment (and probably not tested/not set, I didn't check but probably not in multiwii as well since the values are 8-bit ints)

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

Posted: Sat Jun 22, 2013 4:50 pm
by -ralf-
disq wrote:
felixrising wrote:Just took this process loop implementation on baseflight/stm32 for a test flight, very nice! Great work alex.k!!! The values posted here by Phil.S are great, though I added a little more RC Expo.. I'll maiden it on one of my Crius AIO Pros on the weekend...


Also in baseflight i_level is limited to 0.20 ("200") and multiwiiconf limits it to 0.25. So Level_I=0.30 posted by Phil is not possible at the moment (and probably not tested/not set, I didn't check but probably not in multiwii as well since the values are 8-bit ints)

When using WinGUI like Phil the limitation on Level_I is 2.54 .....

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

Posted: Sat Jun 22, 2013 4:57 pm
by timecop
So sounds like WinGUI I is 0.030 then and not 0.3

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

Posted: Sat Jun 22, 2013 5:13 pm
by -ralf-
timecop wrote:So sounds like WinGUI I is 0.030 then and not 0.3


Just tried it - you are right. Setting the Level-I in WinGUI to 0.3 will be
read as 0.03 in MultiWiiConf .....

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

Posted: Sat Jun 22, 2013 5:42 pm
by alll
0.3 / 0.03 what units. I already said these PID values do not mean much if the implementation details are not know or wel documented. IMO all mwii PID values should be shown in the GUI's like 0..100%. Really, on the field i am NOT interested in the real values/units of measure, just "more" or "less".
I would really appreciate it could be done, and should solve at the same time these kind of confusion(s) in the GUI's.
manu

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

Posted: Sat Jun 22, 2013 6:52 pm
by -ralf-
alll wrote:0.3 / 0.03 what units. I already said these PID values do not mean much if the implementation details are not know or wel documented. IMO all mwii PID values should be shown in the GUI's like 0..100%. Really, on the field i am interested in the real values/units of measure, just "more" or "less".
I would really appreciate it could be done, and should solve at the same time these kind of confusion(s) in the GUI's.
manu

+1 I agree .... make the values readable ....

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

Posted: Sat Jun 22, 2013 7:47 pm
by Phil S.
alex.khoroshko wrote:So, good luck to everyone!

I am really sorry that you leave as fast as you came. But I understand your motives! To me, MultiWii is definitely part of history if the devs do not understand that people like you could prevent the whole project from sinking further into insignificance. In terms of autonomous functions, ArduCopter & Co. are way ahead and acro flying is quite poor without your mod, resp. a lot more fun with KK & Co. So what´s the sense in using MultiWii?

Alex, many thanks for your inputs and good luck too you! Best regards, Philipp

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

Posted: Sat Jun 22, 2013 7:55 pm
by copterrichie
To the best of my recall, MultiWii started with the focus on meeting the needs of the hobbyist community with an easy to build, low cost Flight Controller. It has since grown to rival many of commercial packages costing much more performance wise when configured correctly. Agreed, this is not an easy task for a totally new comer however, there are many using the firmware to accomplish some amazing tasks. With this understanding, there are some fundamental questions introduced as to where is this project headed?

I don't believe I have ever read anywhere of anyone objecting to the usage of MultiWii Code in full or in part for any other project and in fact, I believe it is encouraged. There is nothing stopping folk developments from the main code as long as credit is given to the source. Considering the number of board manufactures and existing boards already available, it comes as no surprise the reluctance to incorporate radical changes to quickly. Especially considering the history of people coming and going on this project. Expanding the community was suggested in the past however that suggestion was met with resistance and for obvious good reasons at the that time. this is not a commercial venture with many developers having full time jobs and families. The development as well as flying is a pastime and enjoyment. With any growth or expansion to any project, there come new problems related to personality clashes and differences of opinion. Believe it or not, this is a very positive sign because any venture of this magnitude is subject to GroupThink (Yes people) that will just flow with the program regardless. The disagreements and clashing is a way of weeding out the bugs in the system.

Without going into great detail, the hobbyist has come under allot of scrutiny and some criticism too with many States in the US attempting to create laws to govern the usage of these aerial vehicles. As long as the project remains in the hobby realm, there is little harm with the exception of a few NUT Cases that exist in project of this nature.