playing with acc-z altitude hold

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

playing with acc-z altitude hold

Post by ronco »

Hi,

as you may know im not good with sensor calculations ;) so please dont mind me if there are bad calculations :D

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

LuFa
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: playing with acc-z altitude hold

Post by LuFa »

Alexmos have done a very good fusion off ACC-Z and Baro :)

Did you have any Flightvideos of your code ?

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: playing with acc-z altitude hold

Post by ronco »

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.
CIMG3944.jpg


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

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: playing with acc-z altitude hold

Post by shikra »

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!

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: playing with acc-z altitude hold

Post by ronco »

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

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

Re: playing with acc-z altitude hold

Post by Crashpilot1000 »

@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

p25o1
Posts: 33
Joined: Thu Mar 29, 2012 3:19 pm

Re: playing with acc-z altitude hold

Post by p25o1 »

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

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: playing with acc-z altitude hold

Post by shikra »

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?

User avatar
Bledi
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: playing with acc-z altitude hold

Post by Bledi »

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

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: playing with acc-z altitude hold

Post by shikra »

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.

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: playing with acc-z altitude hold

Post by ronco »

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 :D


regards felix

marbalon
Posts: 107
Joined: Thu Aug 18, 2011 10:59 am

Re: playing with acc-z altitude hold

Post by marbalon »

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

User avatar
Quadraf
Posts: 68
Joined: Fri Jan 21, 2011 12:55 am
Location: Deurne Holland
Contact:

Re: playing with acc-z altitude hold

Post by Quadraf »

Hi Marbalon,

This is working great. 8-) . 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.

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: playing with acc-z altitude hold

Post by ronco »

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 :D

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: playing with acc-z altitude hold

Post by Sebbi »

Marbalon,

is there magic involved? Level mode seems to work pretty well, too ;-)

Pyrofer
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: playing with acc-z altitude hold

Post by Pyrofer »

That is indeed very impressive! Please help get this into multiwii before 2.1!
(I know it's not going to happen )

marbalon
Posts: 107
Joined: Thu Aug 18, 2011 10:59 am

Re: playing with acc-z altitude hold

Post by marbalon »

There is no magic, just dynamic LFP for P and D params. Here is a code:

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.

User avatar
Quadraf
Posts: 68
Joined: Fri Jan 21, 2011 12:55 am
Location: Deurne Holland
Contact:

Re: playing with acc-z altitude hold

Post by Quadraf »

Thank you for that code!
Don't worry Macrin this golden egg wil breed out to a nice altitude holding colibri! :mrgreen: 8-)

Hans

alexia
Posts: 85
Joined: Sun Jun 17, 2012 10:23 pm
Contact:

Re: playing with acc-z altitude hold

Post by alexia »

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

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: playing with acc-z altitude hold

Post by ronco »

Ok :D

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

marbalon
Posts: 107
Joined: Thu Aug 18, 2011 10:59 am

Re: playing with acc-z altitude hold

Post by marbalon »

Thank you merge it in to MWC code and add getACCalt(). Maybe I will try it on my old AtmegaIMU with BMP085.

alexia
Posts: 85
Joined: Sun Jun 17, 2012 10:23 pm
Contact:

Re: playing with acc-z altitude hold

Post by alexia »

thanks!!!!it seem very promising!
perhaps this code will be more mature to put in the next release(perhaps 2.2 ;)

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: playing with acc-z altitude hold

Post by ronco »

hi,

i did a lot of tests now (and fixed some "port" errors :oops: ) and it works much better .. im still waiting for my MS baro coter to do more testes :D

regards felix

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: playing with acc-z altitude hold

Post by EOSBandi »

ronco wrote:hi,

i did a lot of tests now (and fixed some "port" errors :oops: ) and it works much better .. im still waiting for my MS baro coter to do more testes :D

regards felix


The question is, how it is working in a windy situation, when pressure changes with the wind.....

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: playing with acc-z altitude hold

Post by crashlander »

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).

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: playing with acc-z altitude hold

Post by ronco »

EOSBandi wrote:
ronco wrote:hi,

i did a lot of tests now (and fixed some "port" errors :oops: ) and it works much better .. im still waiting for my MS baro coter to do more testes :D

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

marbalon
Posts: 107
Joined: Thu Aug 18, 2011 10:59 am

Re: playing with acc-z altitude hold

Post by marbalon »

EOSBandi wrote:
ronco wrote:hi,

i did a lot of tests now (and fixed some "port" errors :oops: ) and it works much better .. im still waiting for my MS baro coter to do more testes :D

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.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: playing with acc-z altitude hold

Post by shikra »

Cool. I always wondered if that would make a difference.

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: playing with acc-z altitude hold

Post by ronco »

Hi,

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

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: playing with acc-z altitude hold

Post by Hamburger »

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?

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: playing with acc-z altitude hold

Post by ronco »

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

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: playing with acc-z altitude hold

Post by Hamburger »

But voltage also drops for other reason like increased throttle.
Still not convinced but if it works, ok

marbalon
Posts: 107
Joined: Thu Aug 18, 2011 10:59 am

Re: playing with acc-z altitude hold

Post by marbalon »

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.

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: playing with acc-z altitude hold

Post by dramida »

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.

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: playing with acc-z altitude hold

Post by ronco »

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

LenzGr
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany
Contact:

Re: playing with acc-z altitude hold

Post by LenzGr »

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).

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: playing with acc-z altitude hold

Post by Sebbi »

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:
  • 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)

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: playing with acc-z altitude hold

Post by Alexinparis »

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.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: playing with acc-z altitude hold

Post by timecop »

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.

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

Re: playing with acc-z altitude hold

Post by Crashpilot1000 »

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

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: playing with acc-z altitude hold

Post by Sebbi »

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 ...

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

Re: playing with acc-z altitude hold

Post by Crashpilot1000 »

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

Deet
Posts: 129
Joined: Sun Jul 08, 2012 1:54 am

Re: playing with acc-z altitude hold

Post by Deet »

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.

Tazzy
Posts: 75
Joined: Sun Jun 19, 2011 4:45 pm
Location: Sweden

Re: playing with acc-z altitude hold

Post by Tazzy »

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

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

Re: playing with acc-z altitude hold

Post by Crashpilot1000 »

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

Post Reply