playing with acc-z altitude hold
playing with acc-z altitude hold
Hi,
as you may know im not good with sensor calculations so please dont mind me if there are bad calculations
i tried some things with implementing a acc-z in altitude hold .. the current state does something .. but it is far away from beeing good or stable.
see http://code.google.com/p/multiwii/source/browse/branches/ronco/accZ_playground/MultiWii/IMU.ino#263 (based on dev20120622)
in this comunity are many people that are more talented on calculating such things so any help is welcome
if you have corrections or improvements, feel free to commit it into this branch.
my current strategy:
- smooth the baro readings to have them just to hold the rough scale.
- correct the angle errors of acc z a little
- auto calibrate acc z alt permanently
- get the extreme of the acc z fluctuations
- scale them into EstAlt
- slowly decrease them to get some kind of acting time
regards felix
as you may know im not good with sensor calculations so please dont mind me if there are bad calculations
i tried some things with implementing a acc-z in altitude hold .. the current state does something .. but it is far away from beeing good or stable.
see http://code.google.com/p/multiwii/source/browse/branches/ronco/accZ_playground/MultiWii/IMU.ino#263 (based on dev20120622)
in this comunity are many people that are more talented on calculating such things so any help is welcome
if you have corrections or improvements, feel free to commit it into this branch.
my current strategy:
- smooth the baro readings to have them just to hold the rough scale.
- correct the angle errors of acc z a little
- auto calibrate acc z alt permanently
- get the extreme of the acc z fluctuations
- scale them into EstAlt
- slowly decrease them to get some kind of acting time
regards felix
Re: playing with acc-z altitude hold
Alexmos have done a very good fusion off ACC-Z and Baro
Did you have any Flightvideos of your code ?
Did you have any Flightvideos of your code ?
Re: playing with acc-z altitude hold
Hi,
i looked a alexmos code .. but he changed the complete IMU.ino .. so it would be some work to extract just the acc-z code ..
there is also another guy that has done some work with acc -z .. (german) http://fpv-community.de/showthread.php?10765-Funktionieren-bei-Euch-Kompass-und-Baro-vern%FCnftig&p=163807&viewfull=1#post163807
i found a way now that seems to work.. because my "free IMU (MS baro) copter" burned one motor i have just a small one with a bmp085 to test.. and as you may know a acc-z implementation can not rise the resolution of the baro .. it can just slow the movements inside of it.
here is a GPS PSH video with my acc-z code active https://vimeo.com/45212455
you should know that this mini copter is 20cm motor to motor diameter.
i dont know how good this is compared with other copters with a bmp085 because this is the fisrt bmp085 i own but in my testes it is much better with acc-z active. i should be even better with a MS baro.
in the IMU.ino i did some debug settings fo a simpler compersion..
http://code.google.com/p/multiwii/source/browse/branches/ronco/accZ_playground/MultiWii/IMU.ino#269
i dont know if my PID settings work like a PID controller should here the impacts:
- P = the force of the ACC-Z influence
- I = duration of the ACC-Z influence (how long it will act after a movement is detected)
- D = how the force curve will fade away
you can also disable my mod (#define ALT_BARO_ONLY) or test it with just ACC-Z (#define ALT_ACC_ONLY)..
when i recive my replacement motor ill do some tests (videos) with a larger (50cm diameter) MS baro copter
regards felix
i looked a alexmos code .. but he changed the complete IMU.ino .. so it would be some work to extract just the acc-z code ..
there is also another guy that has done some work with acc -z .. (german) http://fpv-community.de/showthread.php?10765-Funktionieren-bei-Euch-Kompass-und-Baro-vern%FCnftig&p=163807&viewfull=1#post163807
i found a way now that seems to work.. because my "free IMU (MS baro) copter" burned one motor i have just a small one with a bmp085 to test.. and as you may know a acc-z implementation can not rise the resolution of the baro .. it can just slow the movements inside of it.
here is a GPS PSH video with my acc-z code active https://vimeo.com/45212455
you should know that this mini copter is 20cm motor to motor diameter.
i dont know how good this is compared with other copters with a bmp085 because this is the fisrt bmp085 i own but in my testes it is much better with acc-z active. i should be even better with a MS baro.
in the IMU.ino i did some debug settings fo a simpler compersion..
Code: Select all
//#define ALT_ACC_ONLY // disables the Baro's values so alt hold works just with ACC-Z .. for debug
//#define ALT_BARO_ONLY // disables ACC z runs just like it was without any mod
int16_t accAltP = 30; // 10-99... 30 is default
int16_t accAltI = 30; // 10-99... 30 is default
int16_t accAltD = 15; // 10-99... 15 is default
http://code.google.com/p/multiwii/source/browse/branches/ronco/accZ_playground/MultiWii/IMU.ino#269
i dont know if my PID settings work like a PID controller should here the impacts:
- P = the force of the ACC-Z influence
- I = duration of the ACC-Z influence (how long it will act after a movement is detected)
- D = how the force curve will fade away
you can also disable my mod (#define ALT_BARO_ONLY) or test it with just ACC-Z (#define ALT_ACC_ONLY)..
when i recive my replacement motor ill do some tests (videos) with a larger (50cm diameter) MS baro copter
regards felix
Re: playing with acc-z altitude hold
Hi Felix - great to see some progress in this area. Sorting baro hold is the next big thing for Multiwii IMHO. Hope to join in at some point in the future now I'm real happy with other areas that troubled me.
but I need a smaller test rig - like yours. What motor / prop / esc/battery combi do you have? Mine is too big .
Need something quick, easy and less dangerous that sharp 10" props. Also cheap!
but I need a smaller test rig - like yours. What motor / prop / esc/battery combi do you have? Mine is too big .
Need something quick, easy and less dangerous that sharp 10" props. Also cheap!
Re: playing with acc-z altitude hold
Hi shikra,
as i said in the first post .. feel free to commit any improvment into this branch
my small test copter:
-12g 3100kv T-Motors (from flyduino)
-10A Dymond Smart ESC's (similar to TGY Plush) .. 10A because i had no smaller ones
-5x3" 3-blade propellers
-800-1000mAh 2s lipos
- nanowii FC (atmega32u4+MPU6050) with a self tinkered I²C GPS+Mag+baro upgrade (atmega328p, mini MT3329, HMC5883, BMP085)
- simple alu + GFK frame
regards felix
as i said in the first post .. feel free to commit any improvment into this branch
my small test copter:
-12g 3100kv T-Motors (from flyduino)
-10A Dymond Smart ESC's (similar to TGY Plush) .. 10A because i had no smaller ones
-5x3" 3-blade propellers
-800-1000mAh 2s lipos
- nanowii FC (atmega32u4+MPU6050) with a self tinkered I²C GPS+Mag+baro upgrade (atmega328p, mini MT3329, HMC5883, BMP085)
- simple alu + GFK frame
regards felix
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: playing with acc-z altitude hold
@Ronco
"...there is also another guy that has done some work with acc -z..."
Yes, i am the guy!
Due to my very limited coding abilities and my limited understanding i am very happy that you picked it up and turned it into a more mature solution.
Due to your outstanding work my struggeling with "C" and Arduino was not senseless after all. And i am very proud that i could inspire you - so you turn it into a solution for our community!
So long
Rob
"...there is also another guy that has done some work with acc -z..."
Yes, i am the guy!
Due to my very limited coding abilities and my limited understanding i am very happy that you picked it up and turned it into a more mature solution.
Due to your outstanding work my struggeling with "C" and Arduino was not senseless after all. And i am very proud that i could inspire you - so you turn it into a solution for our community!
So long
Rob
Re: playing with acc-z altitude hold
just to understand this better,
1-both the baro and acc-z will be used to keep the altitude hold?
2-can this be pushed to have a semi-position hold? i like to dream loud lool
1-both the baro and acc-z will be used to keep the altitude hold?
2-can this be pushed to have a semi-position hold? i like to dream loud lool
Re: playing with acc-z altitude hold
Felix - some thoughts whilst I wait for mini copter bits to arrive....
DJI is well known for good alt hold success. So why is that compared to MultiWii?
BARO....
Hardware - better BARO sensor? - anyone know which one they use? Maybe that is part of the reason...
BARO Sensor in a box? - minimise airflow false readings...
Algorithm of course
AccZ....
Hardware - better ACC sensor? - anyone know which one they use? Again, maybe that is part of the reason...
I recall from long time back that AccZ was not producing expected readings. Does anyone have a link to that? Maybe we can implement a better option for some sensors with the trusted accZ
Again - Algorithm
I just had a quick look at a test board accZ - Its only accurate when perfectly level. Slightest variations in level affect readings. Never going to get a copter that level. Maybe we need some angular compensation for that. Make sit look like the copter is dropping when it tilts.
Algorithm
I have heard this several times now... DJI Seem to use AccZ as the primary control force then BARO to guide in long term.
Anyone else think the same?
How good are there source alt holds? maybe we can gain from that? - and contribute back.
Ziss - you still around? I thoght this was your area of expertise?
DJI is well known for good alt hold success. So why is that compared to MultiWii?
BARO....
Hardware - better BARO sensor? - anyone know which one they use? Maybe that is part of the reason...
BARO Sensor in a box? - minimise airflow false readings...
Algorithm of course
AccZ....
Hardware - better ACC sensor? - anyone know which one they use? Again, maybe that is part of the reason...
I recall from long time back that AccZ was not producing expected readings. Does anyone have a link to that? Maybe we can implement a better option for some sensors with the trusted accZ
Again - Algorithm
I just had a quick look at a test board accZ - Its only accurate when perfectly level. Slightest variations in level affect readings. Never going to get a copter that level. Maybe we need some angular compensation for that. Make sit look like the copter is dropping when it tilts.
Algorithm
I have heard this several times now... DJI Seem to use AccZ as the primary control force then BARO to guide in long term.
Anyone else think the same?
How good are there source alt holds? maybe we can gain from that? - and contribute back.
Ziss - you still around? I thoght this was your area of expertise?
Re: playing with acc-z altitude hold
Did you try to add filter on your Gyro and ACC ?
I use a CRIUS Lite and SE with defaut PID on baro and the result is just perfect (just add a little I)
Most of problem is because gyro is to mutch sensitive and the FC try to make corrections all the time so it's difficult to have a good altitude level
I use a CRIUS Lite and SE with defaut PID on baro and the result is just perfect (just add a little I)
Most of problem is because gyro is to mutch sensitive and the FC try to make corrections all the time so it's difficult to have a good altitude level
Re: playing with acc-z altitude hold
Am finding Baro a little variable between frames though. Our target has to be to get it as good as DJI - if that is possible...
Yes - agree for steady level hold. I use filters. 42 works pretty good for me. I'm very happy with level now. Even little variations in level affect the gyroZ on my test here... Will make significant false input if using accZ with GPS control.
Yes - agree for steady level hold. I use filters. 42 works pretty good for me. I'm very happy with level now. Even little variations in level affect the gyroZ on my test here... Will make significant false input if using accZ with GPS control.
Re: playing with acc-z altitude hold
shikra wrote:Felix - some thoughts whilst I wait for mini copter bits to arrive....
DJI is well known for good alt hold success. So why is that compared to MultiWii?
BARO....
Hardware - better BARO sensor? - anyone know which one they use? Maybe that is part of the reason...
BARO Sensor in a box? - minimise airflow false readings...
Algorithm of course
AccZ....
Hardware - better ACC sensor? - anyone know which one they use? Again, maybe that is part of the reason...
I recall from long time back that AccZ was not producing expected readings. Does anyone have a link to that? Maybe we can implement a better option for some sensors with the trusted accZ
Again - Algorithm
I just had a quick look at a test board accZ - Its only accurate when perfectly level. Slightest variations in level affect readings. Never going to get a copter that level. Maybe we need some angular compensation for that. Make sit look like the copter is dropping when it tilts.
Algorithm
I have heard this several times now... DJI Seem to use AccZ as the primary control force then BARO to guide in long term.
Anyone else think the same?
How good are there source alt holds? maybe we can gain from that? - and contribute back.
Ziss - you still around? I thoght this was your area of expertise?
Hi shikra,
in 1.9 was a code to compansate the angles for ACC Z .. this part works well
Code: Select all
float InvSqrt (float x){
union{
int32_t i;
float f;
}
conv;
conv.f = x;
conv.i = 0x5f3759df - (conv.i >> 1);
return 0.5f * conv.f * (3.0f - x * conv.f * conv.f);
}
int32_t isq(int32_t x){
return x * x;
}
ACCZ = accSmooth[YAW];
AccScale = 980.665f/acc_1G;
accAlt = (ACCZ * (1 - acc_1G * InvSqrt(isq(accSmooth[ROLL]) + isq(accSmooth[PITCH]) + isq(ACCZ)))) * AccScale;
it was with accADC but in my tests it is better to use with accSmooth axis because you want get small accelerations in the unfiltered values (too much noise)
i dont know how DJI does it .. thay use a MS baro + MPU??
the code that is actual in my branch dosent works good .. so my latest attempt is to compute the acc Z alt values in the attitude function to have more/faster readings and to just use some kind of direction instead of the real acc values ..
so if the Z starts to go up rise EestAlt fo a specific time to compensate the drift .. i think this may work better..
but i dont finished it till now .. ill report if i got results
regards felix
Re: playing with acc-z altitude hold
Yesterday I code new algorithm for Alt holt + ACC Z. Idea is simple - It it still standard PID for baro but EstAltit and speed for D is filtered using ACC Z readings. I will post my algorithm in the evening, but it is coded on custom stm32 board but should works on Atmega too. There is only one thing - MS5611 have better precision on when your read it via SPI. In datasheet you can fund information that data line should not bee touched during ADC conversion, but maybe it is important for i2c (missing CS). Here is video.
http://www.youtube.com/watch?v=tEIf7yYl-Pk
http://www.youtube.com/watch?v=tEIf7yYl-Pk
Re: playing with acc-z altitude hold
Hi Marbalon,
This is working great. . I hope there is a quick port to atmega and hope I2C will work.
Thank you for your work .
Hans
This is working great. . I hope there is a quick port to atmega and hope I2C will work.
Thank you for your work .
Hans
Last edited by Quadraf on Fri Jul 13, 2012 9:59 pm, edited 1 time in total.
Re: playing with acc-z altitude hold
looks very good
if we get the half of this stability with a BMP085 ill be happy..
.. lets see how it works on our AVR 's
if we get the half of this stability with a BMP085 ill be happy..
.. lets see how it works on our AVR 's
Re: playing with acc-z altitude hold
Marbalon,
is there magic involved? Level mode seems to work pretty well, too
is there magic involved? Level mode seems to work pretty well, too
Re: playing with acc-z altitude hold
That is indeed very impressive! Please help get this into multiwii before 2.1!
(I know it's not going to happen )
(I know it's not going to happen )
Re: playing with acc-z altitude hold
There is no magic, just dynamic LFP for P and D params. Here is a code:
Sorry that I don't tune it for Atmega but don't have too much time.
Pids on video are 4.0 / 0.015 / 25
Regards,
Marcin.
Code: Select all
//in computeIMU() - this is dirty and should calculated with acc_1G and using samples count in MWC, I don't need it because work on fixed setup with one sensor and fixed looptime 2500us (400Hz) so don't need a time and 1G
...
AccZSum+= AccZLast - accADC[YAW];
AccZLast = accADC[YAW];
...
...
#define UPDATE_INTERVAL 25000
#define INIT_DELAY 4000000
#define DELTA_TAB_SIZE 30
void getEstimatedAltitude() {
static uint8_t inited = 0;
static uint32_t deadLine = INIT_DELAY;
static int8_t deltaHistTab[DELTA_TAB_SIZE];
static int8_t deltaHistIdx=0;
static int16_t deltaSum=0, deltaSumSmooth=0;
int16_t tempPID = 0;
static int32_t lastAlt, AccZSumSmooth;
int32_t temp32;
int16_t AltError;
if (currentTime < deadLine)
return;
deadLine = currentTime + UPDATE_INTERVAL;
// Soft start
if (!inited) {
inited = 1;
EstAlt = BaroAlt;
}
//**** Alt. Set Point stabilization PID ****
//calculate delta using last 20 samples of delta
deltaSum-= deltaHistTab[deltaHistIdx]; //remove oldest value
deltaHistTab[deltaHistIdx] = constrain(BaroAlt - lastAlt,-120,+120);
deltaSum+= deltaHistTab[deltaHistIdx]; //add new value
deltaHistIdx++;
lastAlt = BaroAlt;
if (deltaHistIdx >= DELTA_TAB_SIZE)
deltaHistIdx = 0;
//little filtering for AccZ
AccZSumSmooth = + AccZSumSmooth * 0.8 + AccZSum * 0.2;
//now try to smooth deltaSum and Est Altiture using ACC Z readings
temp32 = constrain(abs(AccZSumSmooth),1,31);
deltaSumSmooth = (deltaSum*temp32 + deltaSumSmooth*(32 - temp32))/32;
EstAlt = (BaroAlt*temp32 + EstAlt*(32 - temp32))/32;
//D
temp32 = cfg.D8[PIDALT]*(deltaSumSmooth) / (DELTA_TAB_SIZE*2);
tempPID-=temp32;
AltError = constrain( AltHold - EstAlt, -1000, 1000);
//P
tempPID += cfg.P8[PIDALT]*constrain(AltError,(-2)*cfg.P8[PIDALT],2*cfg.P8[PIDALT])/100;
tempPID = constrain(tempPID,-150,+150); //sum of P and D should be in range 150
//I
errorAltitudeI += temp32*cfg.I8[PIDALT]/50;
errorAltitudeI = constrain(errorAltitudeI,-30000,30000);
temp32 = errorAltitudeI / 500; //I in range +/-60
tempPID+=temp32;
BaroPID = tempPID;
AccZSum = 0;
}
Sorry that I don't tune it for Atmega but don't have too much time.
Pids on video are 4.0 / 0.015 / 25
Regards,
Marcin.
Re: playing with acc-z altitude hold
Thank you for that code!
Don't worry Macrin this golden egg wil breed out to a nice altitude holding colibri!
Hans
Don't worry Macrin this golden egg wil breed out to a nice altitude holding colibri!
Hans
Re: playing with acc-z altitude hold
félicitation!!!!!!!
thanks for this incredible work!alt hold seem to be almost perfect!
i read on timecop blog than dji (wookong) has not the best baro but very good gyro(same as mk) and the same mag than cirus board...i think ms5611 is a better baro than dji..but we need to put in a box to decrease perturbation
thanks for this incredible work!alt hold seem to be almost perfect!
i read on timecop blog than dji (wookong) has not the best baro but very good gyro(same as mk) and the same mag than cirus board...i think ms5611 is a better baro than dji..but we need to put in a box to decrease perturbation
Re: playing with acc-z altitude hold
Ok
i did the first trie to implement it ..
i just have a BMP085 copter to test it ATM. .. the results are much better then it was with the old method .. ill do a video soon
http://code.google.com/p/multiwii/source/browse/branches/ronco/accZ_playground/MultiWii/IMU.ino#259
i just changed the ACC Z input to be angle compensated and i use the smoothed ACC values .. with ADC the results was very bad .. but if you like to trie it you can change it in IMU.ino here..
change this:
to this:
ill do more tests tomorrow ..(i hope there is better weather then)
regards Felix
i did the first trie to implement it ..
i just have a BMP085 copter to test it ATM. .. the results are much better then it was with the old method .. ill do a video soon
http://code.google.com/p/multiwii/source/browse/branches/ronco/accZ_playground/MultiWii/IMU.ino#259
i just changed the ACC Z input to be angle compensated and i use the smoothed ACC values .. with ADC the results was very bad .. but if you like to trie it you can change it in IMU.ino here..
change this:
Code: Select all
void getACCalt(){
static int16_t AccScale, ACCZ, accZ, AccZLast;
// ACC Z angle correction of 1.9
ACCZ = accSmooth[YAW];
AccScale = 680.0f/acc_1G;
accZ = (ACCZ * (1 - acc_1G * InvSqrt(isq(accSmooth[ROLL]) + isq(accSmooth[PITCH]) + isq(ACCZ)))) * AccScale;
AccZSum += AccZLast - accZ;
AccZLast = accZ;
}
to this:
Code: Select all
void getACCalt(){
static int16_t AccScale, ACCZ, accZ, AccZLast;
// ACC Z angle correction of 1.9
ACCZ = accADC[YAW];
AccScale = 680.0f/acc_1G;
accZ = (ACCZ * (1 - acc_1G * InvSqrt(isq(accADC[ROLL]) + isq(accADC[PITCH]) + isq(ACCZ)))) * AccScale;
AccZSum += AccZLast - accZ;
AccZLast = accZ;
}
ill do more tests tomorrow ..(i hope there is better weather then)
regards Felix
Re: playing with acc-z altitude hold
Thank you merge it in to MWC code and add getACCalt(). Maybe I will try it on my old AtmegaIMU with BMP085.
Re: playing with acc-z altitude hold
thanks!!!!it seem very promising!
perhaps this code will be more mature to put in the next release(perhaps 2.2
perhaps this code will be more mature to put in the next release(perhaps 2.2
Re: playing with acc-z altitude hold
hi,
i did a lot of tests now (and fixed some "port" errors ) and it works much better .. im still waiting for my MS baro coter to do more testes
regards felix
i did a lot of tests now (and fixed some "port" errors ) and it works much better .. im still waiting for my MS baro coter to do more testes
regards felix
Re: playing with acc-z altitude hold
ronco wrote:hi,
i did a lot of tests now (and fixed some "port" errors ) and it works much better .. im still waiting for my MS baro coter to do more testes
regards felix
The question is, how it is working in a windy situation, when pressure changes with the wind.....
-
- Posts: 506
- Joined: Thu May 05, 2011 8:13 am
- Location: Slovenia
Re: playing with acc-z altitude hold
Maybe slight cross-topic observation GPS PH functionality seems to be influenced by good (or not so good) altitude hold.
If I manually (or by alt. hold) introduce stronger throttle jumps during GPS PH I can observe deterioration in PH (under corrections or overshoots).
If I manually (or by alt. hold) introduce stronger throttle jumps during GPS PH I can observe deterioration in PH (under corrections or overshoots).
Re: playing with acc-z altitude hold
EOSBandi wrote:ronco wrote:hi,
i did a lot of tests now (and fixed some "port" errors ) and it works much better .. im still waiting for my MS baro coter to do more testes
regards felix
The question is, how it is working in a windy situation, when pressure changes with the wind.....
... i need better weather outside to answer this question
i did some PID tests and 3.0/30/30 seems to be a good start value for this mod ..
regards felix
Re: playing with acc-z altitude hold
EOSBandi wrote:ronco wrote:hi,
i did a lot of tests now (and fixed some "port" errors ) and it works much better .. im still waiting for my MS baro coter to do more testes
regards felix
The question is, how it is working in a windy situation, when pressure changes with the wind.....
Works better because when ACC Z delta is small altitude is much filtered. I also add one new mod and now works even better:
Code: Select all
...
//P
tempPID += cfg.P8[PIDALT]*constrain(AltError,(-2)*cfg.P8[PIDALT],2*cfg.P8[PIDALT])/100;
if (AltError < 0) //less correction when copter drop down
tempPID *= 0.8f;
tempPID = constrain(tempPID,-150,+150); //sum of P and D should be in range 150
...
Now need to polish alt hold when flying not only in level mode.
Re: playing with acc-z altitude hold
Cool. I always wondered if that would make a difference.
Re: playing with acc-z altitude hold
Hi,
i updated my branch with marbalons new mod and i started a vbat orientated voltage drop compensation
if you enable the baro mode it saves the current vbat value and compensates every change in mV*V_BAT_COMP (i use 2 for V_BAT_COMP).
regards Felix
i updated my branch with marbalons new mod and i started a vbat orientated voltage drop compensation
Code: Select all
BaroPID = tempPID;
#if defined(V_BAT_COMP) && defined(VBAT)
static uint8_t VbatVal = 0;
if (f.BARO_MODE && VbatVal == 0) {
VbatVal = vbat;
}
if (!f.BARO_MODE) {
VbatVal = 0;
}
BaroPID += constrain((vbat-VbatVal)*V_BAT_COMP,-10,10);
#endif
if you enable the baro mode it saves the current vbat value and compensates every change in mV*V_BAT_COMP (i use 2 for V_BAT_COMP).
regards Felix
Re: playing with acc-z altitude hold
Felix,
I do not understand this V_BAT_COMP idea.
vbat varies depending on charge status, motor load and whatevr else, but the baro sensor should never see this as it is powered via a regulator.
So why do you factor in the vbat value?
I do not understand this V_BAT_COMP idea.
vbat varies depending on charge status, motor load and whatevr else, but the baro sensor should never see this as it is powered via a regulator.
So why do you factor in the vbat value?
Re: playing with acc-z altitude hold
it is just to keep the movment inside the baro resolution low.
if you battery drops about 0.2-0.3V it acts like you move the throttle stick down a littele .. so it will go to the lower side of the "baro resolution barriere"..
and it helps also to keep the reaction of baros throttle influence stable..
for example:
if you adjust you alt PID settings with a fresh lipo (means low voltage drop when rising throttle command = > fast motor response (less value to add to get the copter to go up)) but the if you fly for some minutes the lipo will drop down more when it tries to compensate movements .. so there is a higher value needed to get the same reaction..
regards Felix
if you battery drops about 0.2-0.3V it acts like you move the throttle stick down a littele .. so it will go to the lower side of the "baro resolution barriere"..
and it helps also to keep the reaction of baros throttle influence stable..
for example:
if you adjust you alt PID settings with a fresh lipo (means low voltage drop when rising throttle command = > fast motor response (less value to add to get the copter to go up)) but the if you fly for some minutes the lipo will drop down more when it tries to compensate movements .. so there is a higher value needed to get the same reaction..
regards Felix
Re: playing with acc-z altitude hold
But voltage also drops for other reason like increased throttle.
Still not convinced but if it works, ok
Still not convinced but if it works, ok
Re: playing with acc-z altitude hold
I think VBAT is not needed. I param should enough. In most cases alt hold is activated for about few minutes so battery drop compensation is not needed but can be source of some problems. But if you really wan't to use it please define new variable eg. vbatSmooth and create huge LFP for this value.
Re: playing with acc-z altitude hold
Including Vbat in alt hold discussion won't give a benefit because:
Vbat act like a random perturbation for PI altitude control loop, Vbat is not an error response to be used in Altitude PID controller. Vbat decreases randomly, as your lipo is strong or weak.
Vbat act like a random perturbation for PI altitude control loop, Vbat is not an error response to be used in Altitude PID controller. Vbat decreases randomly, as your lipo is strong or weak.
Re: playing with acc-z altitude hold
Hamburger wrote:But voltage also drops for other reason like increased throttle.
and thats the reason .. the voltage drops different if the lipo is fresh or not .. this can be compensated a little.
regards felix
Re: playing with acc-z altitude hold
I must admit I too am in the skeptical camp about the benefit of co-mingling the battery voltage with the barometer. These two parameters aren't directly correlated and I concur with dramida that it likely infuses random noise into the PID loop.
Shouldn't the combination of ACCZ for quick altitude changes combined with the barometer for the more gradual changes suffice? In a way, the ACCZ changes in the vertical direction behave similar to the gyro value changes for pitch and roll, while the baro provides an absolute measurement (similar to the accelerometer values indicating the direction of gravity).
Shouldn't the combination of ACCZ for quick altitude changes combined with the barometer for the more gradual changes suffice? In a way, the ACCZ changes in the vertical direction behave similar to the gyro value changes for pitch and roll, while the baro provides an absolute measurement (similar to the accelerometer values indicating the direction of gravity).
Re: playing with acc-z altitude hold
Since this is a current thread about the altitude hold mode - and i like the idea of using acc-z - I'd like to write about some observations from real flights and a excel sheet "simulator" of the getEstimatedAltitude() function in the 2.1 release:
P.S.: I think some kind of copter simulator/emulator would be a nice thing to test some ideas. Something like the arducopter folks have for simulating their loiter/navigation algorithm (http://code.google.com/p/arducopter/wiki/AC2_loiter_PID)
- Default PIDs are P=1.6, I=0.015, D=7
- The D value is the amplifier value. It is sensitive to the rate of altitude change ... setting it too high will result in oscillations (which is thankfully constrained to throttle +-150) around the target height, setting it too low may result in the copter not being able to compensate external height changes fast enough. Setting it just right depends on the motors and the copterweight and 0,1 difference may result in said oscillations (for me 7 is way too high)
- The I value should smooth out throttle changes over time, but in the 0,015 default range is has very little effect on anything. With the value 0,015 the copter would have to hover 1m below the target height for 400+ seconds to cause a throttlechange of +1 ... however it starts to get interesting in the 100+ range (simulation, the GUI will only let you input 0,250)
- The P value is also an amplifier value, but causes only a minor percentual change to what the D value amplification did, it can't compensate for a too low value and a high value will cause some "jitter" in the throttle
- Because of BARO_TAB_SIZE being 40 the estimated altitude lags behind a little bit ... that could be one cause for the oscillations with the D term as ESC speed changes (or rather climb/descent speed changes) aren't instant either ... depending on the sensor (the MS561 seems to have not a lot of noise) it is a good idea to directly use BaroAlt ... which has been done here
P.S.: I think some kind of copter simulator/emulator would be a nice thing to test some ideas. Something like the arducopter folks have for simulating their loiter/navigation algorithm (http://code.google.com/p/arducopter/wiki/AC2_loiter_PID)
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: playing with acc-z altitude hold
Sebbi wrote:The I value should smooth out throttle changes over time, but in the 0,015 default range is has very little effect on anything. With the value 0,015 the copter would have to hover 1m below the target height for 400+ seconds to cause a throttlechange of +1 ... however it starts to get interesting in the 100+ range (simulation, the GUI will only let you input 0,250)
I noticed also the same, and I suspect the current I term to be useless in the current implementation.
Re: playing with acc-z altitude hold
alexia wrote:i think ms5611 is a better baro than dji..but we need to put in a box to decrease perturbation
it's not, but nice try.
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: playing with acc-z altitude hold
Dear developers!
There is a SEVERE bug in reading out the Barovalues! It's persistent in 1.8,1.9,2.0,2.1 (tested versions).
Bug description:
When you turn on the Transmitter, so the Receiver gets a signal, the "BaroAlt" goes crazy (more than normally). This is reproduceable MOST of the time, but sometimes the BaroAlt is not affected by Transmitter/valid RX signal. It is independent on stickinput. It's an inconstant bug. It is difficult to see on the averaged & constantly scaled Estalt, so take the raw BaroAlt.
Hardware used:
2 different Boards, equally equipped with: Arduino pro mini, orig WMP, BMP085, BMA020, RX: Frsky D4FR (working in PPM) Transmitter: DHT-U,telemetry enabled
Transmitter and Board were displaced by 1m. Distance between them seems to be no problem.
I think its a coding Bug, that should be looked into to improve althold. Perhaps a problem with RX/interrupt?
Here is a video of the problem: http://www.youtube.com/watch?v=GRewMGs2CmI
So long
Rob
There is a SEVERE bug in reading out the Barovalues! It's persistent in 1.8,1.9,2.0,2.1 (tested versions).
Bug description:
When you turn on the Transmitter, so the Receiver gets a signal, the "BaroAlt" goes crazy (more than normally). This is reproduceable MOST of the time, but sometimes the BaroAlt is not affected by Transmitter/valid RX signal. It is independent on stickinput. It's an inconstant bug. It is difficult to see on the averaged & constantly scaled Estalt, so take the raw BaroAlt.
Hardware used:
2 different Boards, equally equipped with: Arduino pro mini, orig WMP, BMP085, BMA020, RX: Frsky D4FR (working in PPM) Transmitter: DHT-U,telemetry enabled
Transmitter and Board were displaced by 1m. Distance between them seems to be no problem.
I think its a coding Bug, that should be looked into to improve althold. Perhaps a problem with RX/interrupt?
Here is a video of the problem: http://www.youtube.com/watch?v=GRewMGs2CmI
So long
Rob
Re: playing with acc-z altitude hold
Crashpilot1000 wrote:Dear developers!
There is a SEVERE bug in reading out the Barovalues! It's persistent in 1.8,1.9,2.0,2.1 (tested versions).
Bug description:
When you turn on the Transmitter, so the Receiver gets a signal, the "BaroAlt" goes crazy (more than normally). This is reproduceable MOST of the time, but sometimes the BaroAlt is not affected by Transmitter/valid RX signal. It is independent on stickinput. It's an inconstant bug. It is difficult to see on the averaged & constantly scaled Estalt, so take the raw BaroAlt.
Looks like a hardware problem, not a software one. Your RX might be too close to your sensors or they are not sufficiently shielded ...
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: playing with acc-z altitude hold
Thats what i thought, but the problem is on two boards the same and nothing is moved or altered - just the powerswitch of the transmitter. If it was an electrical problem, it would have persisted, or randomly occured during operation. But that is not the case. Once started TX/RX without baro disturbance, you can do what you want the disturbance will not occur. I have a 3rd board on my tri (promini/WMP/nunchuk/bmp085) with a standard receiver without telemetry (&no ppm) i can test it on. I really think it's a software initialisation/interrupt/timing error related to a rx input.
So long
Rob
So long
Rob
Re: playing with acc-z altitude hold
Crashpilot1000 wrote:Thats what i thought, but the problem is on two boards the same and nothing is moved or altered - just the powerswitch of the transmitter. If it was an electrical problem, it would have persisted, or randomly occured during operation. But that is not the case. Once started TX/RX without baro disturbance, you can do what you want the disturbance will not occur. I have a 3rd board on my tri (promini/WMP/nunchuk/bmp085) with a standard receiver without telemetry (&no ppm) i can test it on. I really think it's a software initialisation/interrupt/timing error related to a rx input.
So long
Rob
I have two boards on two airframes, both different electronics layouts within the airframes , and I can't replicate your problem. And on one the Rx is only a few millimetres above the sensor board.
Re: playing with acc-z altitude hold
I have also tested my two boards on my copters, and I can't replicate the problem. so it looks to be some hardware problem in your frame / setup.
// Tazzy
// Tazzy
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: playing with acc-z altitude hold
Thank you Tazzy and Deet for testing!
I tried it on my Tri as well and the error was not reproduceable. I messed around with aluminium foil with my faulty setups. Problem solved with this shielding. It is the FRSky Telemetry that disturbes the Baro!
Thank you again for also looking into this. Perhaps this finding is beneficial for other telemetry users.
So long
Rob
I tried it on my Tri as well and the error was not reproduceable. I messed around with aluminium foil with my faulty setups. Problem solved with this shielding. It is the FRSky Telemetry that disturbes the Baro!
Thank you again for also looking into this. Perhaps this finding is beneficial for other telemetry users.
So long
Rob