Hamburger wrote:Plain wrong. I do it all the time.
Why does mine not flip in horizon, but does in angle with acrotrainer enabled ?
Hamburger wrote:Plain wrong. I do it all the time.
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
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 ?
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).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).
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.
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.
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.
alex.khoroshko wrote:
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!
Let’s focus first in the ACRO mode for understanding.
The scheme is mainly correct.
alex.khoroshko wrote:...nobody of the developers seem to care - the fun part here is complete....
So, good luck to everyone!
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
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!
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...
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)
timecop wrote:So sounds like WinGUI I is 0.030 then and not 0.3
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
alex.khoroshko wrote:So, good luck to everyone!
copterrichie wrote:... when configured correctly. Agreed, this is not an easy task for a totally new comer however, ...
Crashpilot1000 wrote:@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
Code: Select all
if ( f.HORIZON_MODE ) prop = min(max(abs(rcCommand[PITCH]),abs(rcCommand[ROLL])),512);
//----------PID controller----------
for(axis=0;axis<2;axis++) {
Code: Select all
prop = min(max(abs(rcCommand[PITCH]),abs(rcCommand[ROLL])),500); // range [0;500]
//----------PID controller----------
for(axis=0;axis<3;axis++) {
Code: Select all
diff -u MultiWii/EEPROM.ino MultiWii-new/EEPROM.ino
--- MultiWii/EEPROM.ino 2013-03-11 15:08:47.000000000 +0900
+++ MultiWii-new/EEPROM.ino 2013-06-14 21:49:58.000000000 +0900
@@ -101,8 +101,8 @@
}
void LoadDefaults() {
- conf.P8[ROLL] = 33; conf.I8[ROLL] = 30; conf.D8[ROLL] = 23;
- conf.P8[PITCH] = 33; conf.I8[PITCH] = 30; conf.D8[PITCH] = 23;
+ conf.P8[ROLL] = 28; conf.I8[ROLL] = 10; conf.D8[ROLL] = 7;
+ conf.P8[PITCH] = 28; conf.I8[PITCH] = 10; conf.D8[PITCH] = 7;
conf.P8[YAW] = 68; conf.I8[YAW] = 45; conf.D8[YAW] = 0;
conf.P8[PIDALT] = 64; conf.I8[PIDALT] = 25; conf.D8[PIDALT] = 24;
@@ -110,7 +110,7 @@
conf.P8[PIDPOSR] = POSHOLD_RATE_P * 10; conf.I8[PIDPOSR] = POSHOLD_RATE_I * 100; conf.D8[PIDPOSR] = POSHOLD_RATE_D * 1000;
conf.P8[PIDNAVR] = NAV_P * 10; conf.I8[PIDNAVR] = NAV_I * 100; conf.D8[PIDNAVR] = NAV_D * 1000;
- conf.P8[PIDLEVEL] = 90; conf.I8[PIDLEVEL] = 10; conf.D8[PIDLEVEL] = 100;
+ conf.P8[PIDLEVEL] = 30; conf.I8[PIDLEVEL] = 32; conf.D8[PIDLEVEL] = 0;
conf.P8[PIDMAG] = 40;
conf.P8[PIDVEL] = 0; conf.I8[PIDVEL] = 0; conf.D8[PIDVEL] = 0;
Code: Select all
diff -u MultiWii/EEPROM.ino MultiWii-new/EEPROM.ino
--- MultiWii/EEPROM.ino 2013-03-11 15:08:47.000000000 +0900
+++ MultiWii-new/EEPROM.ino 2013-06-14 21:49:58.000000000 +0900
@@ -101,8 +101,8 @@
}
void LoadDefaults() {
- conf.P8[ROLL] = 33; conf.I8[ROLL] = 30; conf.D8[ROLL] = 23;
- conf.P8[PITCH] = 33; conf.I8[PITCH] = 30; conf.D8[PITCH] = 23;
+ conf.P8[ROLL] = 28; conf.I8[ROLL] = 10; conf.D8[ROLL] = 7;
+ conf.P8[PITCH] = 28; conf.I8[PITCH] = 10; conf.D8[PITCH] = 7;
conf.P8[YAW] = 68; conf.I8[YAW] = 45; conf.D8[YAW] = 0;
conf.P8[PIDALT] = 64; conf.I8[PIDALT] = 25; conf.D8[PIDALT] = 24;
@@ -110,7 +110,7 @@
conf.P8[PIDPOSR] = POSHOLD_RATE_P * 10; conf.I8[PIDPOSR] = POSHOLD_RATE_I * 100; conf.D8[PIDPOSR] = POSHOLD_RATE_D * 1000;
conf.P8[PIDNAVR] = NAV_P * 10; conf.I8[PIDNAVR] = NAV_I * 100; conf.D8[PIDNAVR] = NAV_D * 1000;
- conf.P8[PIDLEVEL] = 90; conf.I8[PIDLEVEL] = 10; conf.D8[PIDLEVEL] = 100;
+ conf.P8[PIDLEVEL] = 30; conf.I8[PIDLEVEL] = 32; conf.D8[PIDLEVEL] = 0;
conf.P8[PIDMAG] = 40;
conf.P8[PIDVEL] = 0; conf.I8[PIDVEL] = 0; conf.D8[PIDVEL] = 0;
diff -u MultiWii/MultiWii.ino MultiWii-new/MultiWii.ino
--- MultiWii/MultiWii.ino 2013-03-11 15:08:47.000000000 +0900
+++ MultiWii-new/MultiWii.ino 2013-06-14 21:49:58.000000000 +0900
@@ -362,7 +362,7 @@
// ************************
// EEPROM Layout definition
// ************************
-static uint8_t dynP8[3], dynD8[3];
+static uint8_t dynP8[3], dynD8[3], dynI8[3];
static struct {
uint8_t currentSet;
@@ -536,6 +536,8 @@
}
dynP8[axis] = (uint16_t)conf.P8[axis]*prop1/100;
dynD8[axis] = (uint16_t)conf.D8[axis]*prop1/100;
+ dynI8[axis] = (uint16_t)conf.D8[axis]*prop1/100;
+
if (rcData[axis]<MIDRC) rcCommand[axis] = -rcCommand[axis];
}
tmp = constrain(rcData[THROTTLE],MINCHECK,2000);
@@ -867,14 +869,14 @@
- int16_t error,errorAngle;
+ int16_t errorAngle;
int16_t delta,deltaSum;
int16_t PTerm,ITerm,DTerm;
- int16_t PTermACC = 0 , ITermACC = 0 , PTermGYRO = 0 , ITermGYRO = 0;
- static int16_t lastGyro[3] = {0,0,0};
+ uint16_t CycleTime[3] = {0,0,0};
+ static int16_t lastError[3] = {0,0,0};
static int16_t delta1[3],delta2[3];
- static int16_t errorGyroI[3] = {0,0,0};
- static int16_t errorAngleI[2] = {0,0};
+ static int32_t errorGyroI[3] = {0,0,0};
+ static int32_t errorAngleI[2] = {0,0};
static uint32_t rcTime = 0;
static int16_t initialThrottleHold;
static uint32_t timestamp_fixated = 0;
@@ -1308,54 +1310,75 @@
nhadrian wrote:Hi all,
does anybody succeed with this new code? How safe it is?
I'm especially interrested in tri-copter...
OFF
you know guys, when I made my first changes in baro code and nav code, I got hard comments on why posting BUGGY codes, although it was not in any repository but only in attached ZIP files, and I wrote out with capital that TRY IT ON YOUR OWN RISK...
And now, since 1474, there are many broken/untested/not working/dangerous things around PID in shared. (Tricopters are unflyable with 1474, not only for me but for other users in Hungary....)
I just can't understand what changed around Multiwii community...
ON
BR
Adrian
PS.: good luck on new PID calc!!!!!!!!!!
Hamburger wrote:... with both the original alexK pids and the new philS pids.
Horribly sensitive for my taste, ...