playing with acc-z altitude hold

ronco · Post by **ronco** » Mon Jul 02, 2012 4:14 pm

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

LuFa · Post by **LuFa** » Mon Jul 02, 2012 6:16 pm

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

Did you have any Flightvideos of your code ?

ronco · Post by **ronco** » Thu Jul 05, 2012 7:37 am

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

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

shikra · Post by **shikra** » Thu Jul 05, 2012 11:03 am

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 · Post by **ronco** » Thu Jul 05, 2012 1:38 pm

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

Crashpilot1000 · Post by **Crashpilot1000** » Thu Jul 05, 2012 5:14 pm

@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 · Post by **p25o1** » Sun Jul 08, 2012 1:32 pm

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

shikra · Post by **shikra** » Thu Jul 12, 2012 3:32 pm

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?

Bledi · Post by **Bledi** » Thu Jul 12, 2012 3:48 pm

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

shikra · Post by **shikra** » Thu Jul 12, 2012 4:43 pm

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 · Post by **ronco** » Thu Jul 12, 2012 5:42 pm

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

marbalon · Post by **marbalon** » Fri Jul 13, 2012 2:33 pm

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

Quadraf · Post by **Quadraf** » Fri Jul 13, 2012 2:47 pm

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

ronco · Post by **ronco** » Fri Jul 13, 2012 2:54 pm

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

Sebbi · Post by **Sebbi** » Fri Jul 13, 2012 2:59 pm

Marbalon,

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

Pyrofer · Post by **Pyrofer** » Fri Jul 13, 2012 3:39 pm

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

marbalon · Post by **marbalon** » Fri Jul 13, 2012 4:58 pm

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.

Quadraf · Post by **Quadraf** » Fri Jul 13, 2012 10:14 pm

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

Hans

alexia · Post by **alexia** » Sat Jul 14, 2012 12:23 am

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 · Post by **ronco** » Sat Jul 14, 2012 10:19 am

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:

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 · Post by **marbalon** » Sat Jul 14, 2012 10:47 am

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

alexia · Post by **alexia** » Sat Jul 14, 2012 11:05 pm

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

ronco · Post by **ronco** » Sun Jul 15, 2012 10:09 am

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

regards felix

EOSBandi · Post by **EOSBandi** » Sun Jul 15, 2012 10:45 am

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

crashlander · Post by **crashlander** » Sun Jul 15, 2012 11:48 am

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 · Post by **ronco** » Sun Jul 15, 2012 6:11 pm

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

marbalon · Post by **marbalon** » Sun Jul 15, 2012 9:27 pm

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.

shikra · Post by **shikra** » Sun Jul 15, 2012 10:25 pm

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

ronco · Post by **ronco** » Tue Jul 17, 2012 10:08 am

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

Hamburger · Post by **Hamburger** » Tue Jul 17, 2012 11:32 am

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 · Post by **ronco** » Tue Jul 17, 2012 12:12 pm

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

Hamburger · Post by **Hamburger** » Tue Jul 17, 2012 1:00 pm

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

marbalon · Post by **marbalon** » Tue Jul 17, 2012 1:26 pm

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.

dramida · Post by **dramida** » Tue Jul 17, 2012 1:35 pm

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 · Post by **ronco** » Tue Jul 17, 2012 4:00 pm

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 · Post by **LenzGr** » Tue Jul 17, 2012 4:49 pm

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 · Post by **Sebbi** » Tue Jul 17, 2012 11:34 pm

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 · Post by **Alexinparis** » Thu Jul 19, 2012 11:56 pm

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 · Post by **timecop** » Fri Jul 20, 2012 12:29 am

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 · Post by **Crashpilot1000** » Fri Jul 20, 2012 2:44 am

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 · Post by **Sebbi** » Fri Jul 20, 2012 10:21 am

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 · Post by **Crashpilot1000** » Fri Jul 20, 2012 11:42 am

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 · Post by **Deet** » Sat Jul 21, 2012 12:40 am

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 · Post by **Tazzy** » Sat Jul 21, 2012 8:17 am

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

Crashpilot1000 · Post by **Crashpilot1000** » Sat Jul 21, 2012 9:46 am

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