EagleTree ALT-V4 Baro Integration. Success!

[mr.rc-cam]

I've been having problems with Baro Altitude Hold on my quad. It is a moderately sized model, approx 50 ounces and has ~22 inch motor to motor diameter. Initially I was using the BMP085 baro sensor. But its data is a bit "noisy" and so I wondered if it was causing some of my alt-hold problems. So I searched around for something better.

The specs on EagleTree's ALT-V4 sensor (sold everywhere, $38 USD) looked interesting so I integrated it into the 1.8p2 release. This baro sensor has awesome performance. It is a I2C based device that internally performs all the calculations, so the reduced firmware overhead frees up a lot of MultiWii code space. It provides the altitude in decimeters (signed 16-bit), which is a good match for the MultiWii baro functions. The data is VERY stable (I see only 1 bit of jitter) and the update rate is ~10Hz.

So with the ALT-V4 installed I've had a few extended hovers in light wind where the model stayed within 1 meter, which is something I've never been able to do before. But alt-hold is still very fragile and small PID changes have big effects.

The main issue I have at the moment is that the VEL P term does not work as expected. Values above zero cause the model to gain altitude (it is a constant elevation increase, with the P value effecting it). The problem is not caused by the baro sensor; The source is within the EstVelocity calculation. I will add details about what I find.

[mr.rc-cam]

I noticed in the code that the EstVelocity value in the getEstimatedAltitude() function is affected by the ACC sensor. So tonight I watched EstVelocity in the GUI (added a debug value) and it starts out as 0 with the motors off. But as I increased throttle the value would become negative (for example, about -6 at mid throttle while I held the model in my hand). So I rechecked the props' balance a few minutes ago and they needed to be cleaned (bug guts) to achieve balance again. I still see some negative EstVelocity values, but the magnitude is much smaller.

It's too dark to try more test flights today, so until the sun comes up, are there any other things I should check/re-check? Has the Alt-hold PID tuning procedure changed in 1.8p2, or is it the still the same as ziss_dm kindly published in his late June post?

In case there is interest, as soon as the altitude hold feature is working to my satisfaction I will post the code and any other details. But for now I need a little guidance on making the PID's cooperate.

[Niclas Hedlund]

Can you see what sensor-chip that is located on the board?

[mr.rc-cam]

Can you see what sensor-chip that is located on the board?

http://www.servoflo.com/pressure-sensor ... ory_id=233

[mr.rc-cam]

Cleaning/balancing the props did not resolve the problem. There are times I get reasonable altitude hold, but before long the Quad will runaway skyward.

I monitored the InstAcc value in getEstimatedAltitude(), which in V1.8p2 is computed as follows:
InstAcc = (accADC[YAW] * (1 - acc_1G * InvSqrt(isq(accADC[ROLL]) + isq(accADC[PITCH]) + isq(accADC[YAW])))) * AccScale + (Ki) * AltErrorI;

With the model at a fixed elevation, and motors running, the data is always negative. InstAcc is a float and the data is fractional. With the motors off the InstAcc value bounces around ±0.002. Increasing throttle increases the data's negative magnitude. Past half stick I see values that exceed 2.0. It requires fast upward movement to make the InstAcc data move to a positive value.

If I force the InstAcc value to zero the runaway problem stops. But then the VEL P and D terms are essentially disabled and alt-hold PID's cannot be correctly tuned.

So at the moment I'm not sure what to do and need some expert advice. BTW, I'm using the BMA180 accel sensor. For those of you with good performing altitude hold, what accel chip are you using?

[ziss_dm]

Hi,

Could you please force BaroAlt to fixed value and check results?

regards,
ziss_dm

[mr.rc-cam]

Could you please force BaroAlt to fixed value and check results?

Hello ziss_dm, That is an excellent test. I forced BaroAlt to 10.0 and confirmed that the GUI's ALT field showed 10.0 at startup. But when I apply throttle the GUI's ALT starts to decrease and it reports about 7.0 with mid-stick throttle. With the motors stopped the ALT value went to 9.9. The InstAcc debug value shows the negative bias exactly the same as before, with higher magnitude data as I increased throttle. I also had a debug value in the GUI for BaroAlt and it remained at 10 during the entire test.

BTW, thank you for lending a helping hand!

[ziss_dm]

Hi

Could you also replace accADC[] with accSmooth[]?

InstAcc = (accSmooth[YAW] * (1 - acc_1G * InvSqrt(isq(accSmooth[ROLL]) + isq(accSmooth[PITCH]) + isq(accSmooth[YAW])))) * AccScale + (Ki) * AltErrorI;

regards,
ziss_dm

[mr.rc-cam]

I switched to the accSmooth[] method and the bench tests appeared to be the same as before (InstAcc goes negative with throttle). The sun was setting so I moved fast and tried a quick hover flight. Unfortunately it still has the altitude runaway issue. I was quite surprised by this since I hoping to see a change due to the filtered data; Maybe this is a useful clue about the problem?

Just as a sanity check, would you mind including more parentheses on the expression so all math precedence is stated? I know how the compiler expects do it, but would feel more confident by confirming that the math expression is evaluated in the intended order.

By chance have you checked your model to see if it has the same accSmooth bias with throttle? That kind of information may help us isolate my problem. For sure, if you have more experiments to try then please let me know. Solving this problem has become my passion and so I appreciate your help.

[Alexinparis]

Hi,
Just for information (I know this won't immediatly solve the issue).
The best Alt hold I could achieve was with the default settings only:ie ATL P only and ALT I&D = 0, VEL P&I&D = 0

VEL PID control loop was at the beginning a cascading PID after the ALT PID.
It's now 2 justaposed PID control loops, but the principle remains.
I encountered exactly the problem of mr.rc-cam with VEL PID <> 0, and I didn't investigate further having quite good results even with the BMP085.

[mr.rc-cam]

Just for information (I know this won't immediatly solve the issue).
The best Alt hold I could achieve was with the default settings only:ie ATL P only and ALT I&D = 0, VEL P&I&D = 0

That is very interesting and perhaps hints at some evidence of the problem I am having. I envy you because with only the Alt P term, success will be dependent on the model's characteristics. Unfortunately with just the P term the best I can get is the Yo-Yo effect.

VEL PID control loop was at the beginning a cascading PID after the ALT PID.
It's now 2 justaposed PID control loops, but the principle remains.

I prefer the latest version over the earlier cascading. In a perfect world my preference would be that the ALT and VEL PID's would be totally independent and not have to rely on each other at all.

I encountered exactly the problem of mr.rc-cam with VEL PID <> 0, and I didn't investigate further having quite good results even with the BMP085.

Maybe your model has a bit of the problem I am experiencing. BTW, which ACC chip?

[mr.rc-cam]

More experiments to report, but no success:

Last night I pulled the props off and ran the motors. The negative altitude bias still occurred, but was a smaller magnitude than with the props installed. I lubricated each motor and replaced one that had a bearing that sounded "dry." I did the prop-less throttle test again and the bias was still there, but it was reduced a bit more. I also put on fresh balanced props (the old one had about 50 hours on them). The new props are from HobbyKing, and although they look the same as the old ones, they feel softer (cheap feeling).

I did a some test hovers this morning. The model flies differently with the new props and is mushy. So when I have time I will play with the usual PID's. But more importantly, the runaway alt-hold problem still occurred, but it did not happen as often. I experienced excessive altitude yo-yo issues using the same VEL & ALT PIDs as yesterday. So I think the new props require retuning the VEL & ALT PIDs. But first I need to fix that silly altitude runaway problem.

I have a new observation to report. While watching the GUI I noticed that my ITG3200 gyro data intermittently (1-5 times in a minute) flashes some corrupted data. For example, while resting with 0's being reported, I occasionally see 16 or 32 in all the gyro fields (all other sensors are fine). I think this is real (versus a GUI problem) because it may explain why I have some intermittent Yaw during flight. As a test, I removed the ALT-V4 altimeter, changed the ITG3200's I2C clock to 100KHz, and added some 10uS delays to each of its I2C R/W buss accesses. The problem persists, so it is not a timing issue. I only mention this in case it rings a bell on what could be going on with my Alt Hold (or maybe someone has a solution for the random corrupted gyro data).

[mr.rc-cam]

There is a very simple test that appears to identify the problem, even if a baro sensor is not installed. Just watch the ACC's Z data in the GUI.

On my model, as throttle is advanced the Z data noticeably starts to decrease. For example, my Z data is 512 with motors off; It decreases to about ~350 with 3/4 throttle. I believe this is the source of the unwanted bias in the baro's Z-axis velocity estimator. It makes the estimator think the model is losing altitude, so the Alt-Hold is fooled into increasing the throttle. I believe this is the cause of the runaway altitude issue.

It would be helpful to hear if anyone else sees this effect when they watch the GUI Z data. If it is always a data decrease then I think it would indicate a software problem or a peculiar BMA180 ACC sensor characteristic. But if various users see a data increase, and some see a decrease, then it would probably indicate a vibration nuisance (but doubtful since my motor/prop vibration remedies have not cured it).

[Alexinparis]

There is a very simple test that appears to identify the problem, even if a baro sensor is not installed. Just watch the ACC's Z data in the GUI.

On my model, as throttle is advanced the Z data noticeably starts to decrease. For example, my Z data is 512 with motors off; It decreases to about ~350 with 3/4 throttle. I believe this is the source of the unwanted bias in the baro's Z-axis velocity estimator. It makes the estimator think the model is losing altitude, so the Alt-Hold is fooled into increasing the throttle. I believe this is the cause of the runaway altitude issue.

It would be helpful to hear if anyone else sees this effect when they watch the GUI Z data. If it is always a data decrease then I think it would indicate a software problem or a peculiar BMA180 ACC sensor characteristic. But if various users see a data increase, and some see a decrease, then it would probably indicate a vibration nuisance (but doubtful since my motor/prop vibration remedies have not cured it).

Hi,

I think you got here an important point that can explain both the altitude VEL PID yoyo and the LEVEL drift problem if confirmed. I will check this point on my configs (all with a BMA180)
About the LEVEL drift: if the ACC data are not was they should be when the motors are not running, the resulting angle is probably corrupted.

[mr.rc-cam]

About the LEVEL drift: if the ACC data are not was they should be when the motors are not running, the resulting angle is probably corrupted.

With motors off (and Quad level) the ACC roll/pitch/z data is 0/0/512. With motors on the ACC roll and pitch data looks very good through all throttle ranges (only a small amount of data bounce). But the Z data decreases significantly as throttle is increased. What does your Quad do?

[Alexinparis]

Hi,

I won't be able to test this until friday.
But this second observation could explain also why some users have better results with the LEVEL mode of v1.7 because the Z ACC is not used for small angles in this implementation.
So it's a new idea to tweak more the 1.8 LEVEL mode

However, I think it's strange the corrupted data affects only the Z axis.
I would have expected that vibrations issues would have impacted all axis.
Let's say for instance 0/0/512 with no motors => 50/50/462 with 50% throttle

[mr.rc-cam]

I would have expected that vibrations issues would have impacted all axis.

I agree. Honestly, I expected it to affect X & Y more since those axis are in the same plane with the rotating props, so that is where I expect more vibration. I don't know if the odd issue is a characteristic of the BMA180, a firmware problem, unusual vibration migration within my frame, or electronic demons requiring witchcraft.

One vibration related theory I have is that it is affected by the model's size and weight. Larger heavier models swing bigger props and have bigger motors, so the magnitude of vibrations are greater. The little models don't shake things up as much, so maybe that explains why some quads have working alt-hold. But this does not say much about what the real problem is.

For sure, I'm very interested in hearing what you report when you test your Quad with V1.8p2. Actually, anyone can do the test if they have an ACC sensor installed in their Quad and are using V1.8. So any of you out there that are interested in helping please report what you see in your ACC Z data.

[KeesvR]

I've tested this today with BMA020.
I gave a little bit of throttle, just above minthrottle.
The roll and pitch values are normal, straight lines.
The ACC Z is moving a lot. Normal value is 258, with throttle 210. A very noise line.
Also the Mag yaw line had some movement.

[mr.rc-cam]

The roll and pitch values are normal, straight lines.
The ACC Z is moving a lot. Normal value is 258, with throttle 210. A very noise line.

Thanks for doing the test. Seems that your BMA020 has the issue too. It would be great if more users report their results in case it helps us determine the cause.

[KeesvR]

It's sure vibration related, i took of the complete controller of the frame and did the same test holding it in my hand.
The result was a nice straight line on the Z axis.

[mr.rc-cam]

It's sure vibration related, i took of the complete controller of the frame and did the same test holding it in my hand.

Yes, but the mystery is why does the vibration cause a significant Z data bias rather than average near zero like the other two axis? It seems like something suspicious is occurring.

General Info to those that do the test: When the test is performed do not do it with the model on the ground (otherwise the bouncing may affect the results). Instead, hold the model tightly in your hand and be careful of the props!

[mr.rc-cam]

I have an handheld electric engraver that is a convenient vibration maker. Here are the results when I press the engraver against each axis of the Arduino/sensor board:

Press into front: ACC pitch data jumps around 0.
Press into rear: Same, jumps around 0.

Press into right: ACC roll data jumps around 0.
Press into left: Same.
So far, so good.

Z axis test with the model level ...
Press into top: ACC Z data is reduced from 512 to about 250. Altitude data decreases 10 meters.
Press into bottom: Same, ACC Z data is reduced.
The unwanted bias is evident in the Z axis.

Z axis test with the model pitched 90 degrees so that Z data is nominally 0 ...
Press into top (model's top): ACC Z data jumps slightly around 0. Altitude data does not change.
Press into bottom (model's bottom): Same, jumps around 0.
Bias is gone when the Z axis orientation is 90 degrees.

BTW, if I position the model so that the other axis data is nominally 512, they too show the bias problem.

[Alexinparis]

Hi,

I did some tests today: (I have a BMA180 on all setups)

1) and 2) are 2 quad with KEDA 20-50S style, with Gaui 8'' props.
There is nearly no vibration, and the Z ACC is quite constant around 500, even at full throttle firmly hold level in my hand.
This explains why I wasn't impacted too much by this problem.

3) is a micro quad, 2S, 2000kv 10g motor, and 5x3 props (GWS + 5.3R manually balanced from HK)
There is a lot of vibration and the Z ACC could decrease at nearly 200 at full throttle.

So obviously, the problem is here and is probably tied to a dampening problem.
Incompatible with the current BARO algorithm.
So if you want to test the BARO, I would suggest to remove InstAcc in the calculation of the altitude (IMU.pde)
It would be less accurate, but more exploitable.

[mr.rc-cam]

Thanks for reporting the test results.

There is nearly no vibration, and the Z ACC is quite constant around 500, even at full throttle firmly hold level in my hand.

That is good to hear. I've done a variety of things to damp vibration and cannot achieve that success, so I am a bit jealous.

There is a lot of vibration and the Z ACC could decrease at nearly 200 at full throttle.

That is similar to my Quad.

So obviously, the problem is here and is probably tied to a dampening problem.
Incompatible with the current BARO algorithm.

I agree that it can be masked by removing all vibration, but I think that this is not the real problem (it is just the stick that pokes at the problem). My last vibration tests (engraving tool, see above) showed that the model's attitude affects the bias error. Rotating the model's orientation 90 degrees (so nominal Z data is zero), with the vibration source in the EXACT same place, makes the problem go away. So it just seems like it is a computational error some place or an unexpected ACC chip characteristic.

So if you want to test the BARO, I would suggest to remove InstAcc in the calculation of the altitude (IMU.pde)
It would be less accurate, but more exploitable.

I've tried that and alt-hold performance was not satisfactory on my particular Quad. Essentially the D term is lost, which is unfortunate. At this point I will abandon the alt-hold feature with the hope that someone will eventually find a reliable fix. In the meantime, I think anyone that is interested in using the Alt-Hold feature should do the vibration test to see if their model is subject to experiencing the runaway altitude problem. Perhaps the Z axis vibration test should be added to the baro's FAQ.

[avazdo]

Hi. first of all, I'm sorry by my wrong English.
I purchased BMA180, BMP085 sensor and I had some problems with both of them.
Trouble #1: cumulative drift in stable mode (It is widely discussed yet)
Trouble #2: runaway lift off in baro mode (wrong accelerometer measures?, wrong baro montage? code bugs?)

I'd like to tell you my "sucesses"
I took the barometer out lunchbox, I wraped it into 2 turns of a black very porous thin foam sheet. (It'll protect sensor against wind, heat and sunlight) and I put it lid down under the lunchbox (electronics container).
Altering the code (V1.8p2)
- Pressure variable is averaged (factor 4)
- I do not use neither EstAlt nor EstVelocity. I always use AltBaro (averaged factor 4). I suppose my accelerometer datas corrupt these variables.
- YO-YO effect is an enemy we must fight

In sensor.pde file

Code: Select all

....
pressure = p + ((x1 + x2 + 3791) >> 4);
  pressure = (pressure + average_press * 3 +2)>>2; // average_press is a new declared variable (init. value=101325)
  average_press = pressure;
....

In MultiWii_1_8_patch2.pde file: (It have in the beginning, a new declared variable: static int32_t average_press = 101325;)

Code: Select all

if(BARO) {
      if (rcOptions & activate[BOXBARO]) {
        if (baroMode == 0) {
          baroMode = 1;
          AltHold = BaroAlt;    // <--- CHANGED   Instead AltHold = EstAlt;
          initialThrottleHold = rcCommand[THROTTLE];
          errorAltitudeI = 0;
          lastVelError = 0;
          EstVelocity = 0;
        }

And here is the mother of the lamb, In MultiWii_1_8_patch2.pde file:

Code: Select all

if(BARO) {
    if (baroMode) {
      if (abs(rcCommand[THROTTLE]-initialThrottleHold)>20) {
        baroMode = 0;
        errorAltitudeI = 0;
      }
      //**** Alt. Set Point stabilization PID ****
      error = constrain((AltHold - BaroAlt)*10, -100, 100); // <---CHANGED  EstAlt  for  BaroAlt
      errorAltitudeI += error;
      errorAltitudeI = constrain(errorAltitudeI,-5000,5000);
      delta = error - lastAltError;                                               // Note 1
      if (millis() > (Tprevio + 300)) {lastAltError = error; Tprevio = millis();} // Note 2
      DTerm = (int32_t)(delta * D8[PIDALT] + 5)/10;                               // Note 3
      if (error < 8 && error > -8) error = 0;                                     // Note 4
      if (error<0)error=-(error*error+6)/12; else error=(error*error+4)/8;        // Note 5
      PTerm = P8[PIDALT]*error/100;
      ITerm = (int32_t)I8[PIDALT]*errorAltitudeI/4000;
      AltPID = constrain(PTerm + ITerm,-100,100) ;
      rcCommand[THROTTLE] = initialThrottleHold + AltPID + DTerm;
    }
  }

Note 1: news declared variables in loop() function. static int16_t lastAltError =0; static uint32_t Tprevio =0;
Note 2: without this line, ALT Dterm will always be zero. (averaged Barometer is a very slow sensor)
Note 3: I added Dterm to try to prevent entry into a YO-YO effect loop
Note 4: Hysteresis. It can increase some small YO-YO effect but it should reduce the big effect
Note 5: Error value (for P-ALT calc.) is squared and I introduced some asymmetry between + and - values to avoid a large yo-yo effect
Current PID Alt. settings: P=10; I=0; D=30. (DTerm must be a high value)
The first test was very promising even in Acrobatic-Baro mode
It seems this (sensor-code-my quad) setting works reasonably fine for me. On wednesday I'm goint to try it again. I'll try to take a video.
I'm sure this code can be quite optimized. I'm a beginner.

Thanks for so long reading.

Regards

[mr.rc-cam]

I'd like to tell you my "sucesses"
I took the barometer out lunchbox, I wraped it into 2 turns of a black very porous thin foam sheet. (It'll protect sensor against wind, heat and sunlight) and I put it lid down under the lunchbox (electronics container).
Altering the code (V1.8p2)
- Pressure variable is averaged (factor 4)
- I do not use neither EstAlt nor EstVelocity. I always use AltBaro (averaged factor 4). I suppose my accelerometer datas corrupt these variables.
- YO-YO effect is an enemy we must fight

Please keep us posted on your progress. I've also made some code changes and removed the ACC from the alt-hold functions. I derive the D term from the baro data. Some tests this morning were promising but it needs some optimization. So maybe I will be able to have an alt-hold success story soon too.

BTW, last week I added a wireless Bluetooth board for wireless GUI access. This is a real time saver and highly recommended to those that need to constantly experiment with PID values.

Lastly, an interesting observation about the Z-axis ACC problem is that the vibration induced Z-bias goes away if the model is tilted 90 degrees (motors are horz instead of vert). Maybe this clue will help identify the bias problem?

[mr.rc-cam]

This afternoon the experimental baro code was optimized a bit more. I am happy to report that I finally have altitude hold success!

I went through several packs while hovering and it worked beyond my expectations. Most of the time the altitude remained within 1/4 meter. Jabbing the sticks to add some moderate pitch or roll attitudes would still result in the model holding within 1 meter overall. Even though it was calm conditions, I've never come close to this kind of alt-hold performance before. I can't wait to try it out when there is a breeze to see if it can handle less than perfect conditions.

The success was with EagleTree's ALT-V4 baro altimeter. As soon as I am satisfied the performance is stable, I will modify the BMP085 baro code to determine if the new techniques will work well with that sensor too. If all goes well I will publish the details so that others can try it out.

Long term I think that the existing ACC based velocity estimator method would be best for the alt-hold function. So hopefully someone will come up with a software solution that solves the Z-axis vibration related problem.

[ziss_dm]

Hi mr.rc-cam,

Z axis test with the model level ...
Press into top: ACC Z data is reduced from 512 to about 250. Altitude data decreases 10 meters.
Press into bottom: Same, ACC Z data is reduced.
The unwanted bias is evident in the Z axis.

Z axis test with the model pitched 90 degrees so that Z data is nominally 0 ...
Press into top (model's top): ACC Z data jumps slightly around 0. Altitude data does not change.
Press into bottom (model's bottom): Same, jumps around 0.
Bias is gone when the Z axis orientation is 90 degrees.

This is really sounds like sensor is saturating. (1g+ vibration acceleration exceed the sensor range). Can you switch sensor to 4g range? Or try 1.7 (we had 3g range, as I remember). And repeat engraver tes?

EDIT: In 1.8 we relay on factory eeprom settings for BMAxxx. Maybe they are not the same for all sensors?

Can you also try this initialization routine:

Code: Select all

#if defined(BMA180)
void ACC_init () {
  uint8_t control;
  // Perform Soft Reset
  i2c_writeReg(BMA180_ADDRESS, 0x10, 0xB6);
  delay(100);
  // Set ee_w
  // Necessary for being able to update image registers, even if we do not write to EEPROM
  control = i2c_readReg(BMA180_ADDRESS, 0x0D);
  control |= 0x10;
  i2c_writeReg(BMA180_ADDRESS, 0x0D, control);
  delay(50);
  // Set bandwith
  // Note: 150Hz is the default bandwidth on startup (If the EEPROM content was not changed)
  control = i2c_readReg(BMA180_ADDRESS, 0x20);
  control &= 0x0F; // Mask tcs calibration and clear bandwith (= 10Hz bandwith!)
  i2c_writeReg(BMA180_ADDRESS, 0x20, control);
  delay(50);
  // Set range
  // Note: 2g is the default range on startup (If the EEPROM content was not changed)
  control = i2c_readReg(BMA180_ADDRESS, 0x35);
  control &= 0xF1; // Mask offset_x calibration bits, smp_skip and clear range
  control |= 0x04; // Set range to 4g
  i2c_writeReg(BMA180_ADDRESS, 0x35, control);
  delay(50);
  acc_1G = 512;
}

void ACC_getADC () {
  TWBR = ((16000000L / 400000L) - 16) / 2;  // Optional line.  Sensor is good for it in the spec.
  i2c_getSixRawADC(BMA180_ADDRESS,0x02);
  //usefull info is on the 14 bits  [2-15] bits  /4 => [0-13] bits  /8 => 11 bit resolution
  ACC_ORIENTATION(  - ((rawADC[1]<<8) | rawADC[0])/16 ,
                    - ((rawADC[3]<<8) | rawADC[2])/16 ,
                      ((rawADC[5]<<8) | rawADC[4])/16 );
  ACC_Common();
}

regards,
ziss_dm

[mr.rc-cam]

This is really sounds like sensor is saturating. (1g+ vibration acceleration exceed the sensor range). Can you switch sensor to 4g range? Or try 1.7 (we had 3g range, as I remember). And repeat engraver test?

I loaded V1.7. The engraver tests shows it also has the Z-axis ACC issue.

In 1.8 we relay on factory eeprom settings for BMAxxx. Maybe they are not the same for all sensors?

The data sheet says it should have factory default of ±1g. But your comment brings up a question: When V1.7 is used it changes the range to ±3g (per register 0x35 bit assignment 3<<1); Is this value written to the BMA180's non-volatile EEPROM or is a volatile write? If it is a non-volatile write then the factory default would be changed and would be wrong for V1.8. Can you clarify this for me?

BTW, what ACC sensor you have?

BMA180.

[ziss_dm]

Hi,

This one: http://www.sparkfun.com/datasheets/Sens ... 000-03.pdf Page 26. Section "EEPROM content upon delivery"
Says: range: 010b, which is 2g

We usually writing to the shadow registers, not to EEPROM. But maybe they just changed default?

Can you also try BMA180 driver from my previous post?

regards,
ziss_dm

[mr.rc-cam]

Says: range: 010b, which is 2g

Oops, my eyes saw ±2g but my fingers typed ±1g.

We usually writing to the shadow registers, not to EEPROM.

Thanks for the explanation. I saw the V1.7 comment that said "set bit ee_w to 1 to enable writing" and I was worried it meant that the ee_w bit enabled EEprom write (rather than shadow write).

Can you also try BMA180 driver from my previous post?

I will try the code snippet and report back.

[ziss_dm]

Hi,

Thanks for the explanation. I saw the V1.7 comment that said "set bit ee_w to 1 to enable writing" and I was worried it meant that the ee_w bit enabled EEprom write (rather than shadow write).

Page 47: This bit must be set to 1 first, to be able to write anything to the image registers (20h-3Bh)

regards,
ziss_dm

[mr.rc-cam]

Page 47: This bit must be set to 1 first, to be able to write anything to the image registers (20h-3Bh)

Thanks for information, it is helpful.

Can you also try BMA180 driver from my previous post?

I tried the new BMA180 code on V1.8p2 and the engraver test showed the same Z-axis ACC problem. In case the engraver was not a fair test I also tried the model hand hold method while increasing throttle. Same as before, as throttle reached mid-stick the GUI showed the altitude had fallen 10 meters. If you have not tried this test then please do it. Maybe you will see the same thing on your model.

My expectation is that the ACC's nominal Z data will be 1g static acceleration when the model is level/motionless, plus the measured dynamic acceleration contribution from the motor's vertical vibration. So I think I understand why you suspect that the ACC sensor scaling could be too low and cause sensor saturation. Is that correct?

The part that completely confuses me is when I pitch or roll the model 90 degrees; As I rotate the Quad, with motors running, the vibration related Z ACC offset is proportionally reduced. Once the model is exactly at 90 degrees tilt (motors horz, props vert) there is NO measured Z axis vibration and the altitude is no longer corrupted by the ACC data. The GUI's Z data is calm and noise free. I am very curious about how/why it does this. Any ideas?

[ziss_dm]

Hi,

This symptomps would be perfectly explained by saturation, as you removing 1g from Z axis when you tilting it. But not sure how we possible can rich 4g (Unless I have made mistake somethere. ). I have also found this topic:
http://arduino.cc/forum/index.php?PHPSE ... ic=53062.0
The guys have better results using 2.4v for powering sensor (This is nominal voltage, 3.3v is maximum). I have 3.0v, as I remember.
Tonight, I will try test and will report my readings.

regards,
ziss_dm

[mr.rc-cam]

This symptoms would be perfectly explained by saturation, as you removing 1g from Z axis when you tilting it.

But the odd thing is that when it is fully tilted there is no vibration reported. The ACC's Z data is as quiet as a church mouse even at high throttle. That is the part that is making my brain hurt.

I have also found this topic: http://arduino.cc/forum/index.php?PHPSE ... ic=53062.0

Interesting discussion.

The guys have better results using 2.4v for powering sensor (This is nominal voltage, 3.3v is maximum). I have 3.0v, as I remember.

If reducing voltage solves this then that would be easy to implement. BTW, on my custom sensor board I am using 3.3V. Power enters the board as 5V, goes through an LC filter, then to a linear 3.3V LDO VReg. The BMA180's analog power (pin 2) has another LC filter on it to maintain clean voltage from the VReg. The sensor's digital 3.3V power (pins 5 & 10) is from the same 3.3V VReg but the digital power supply path is not shared with the LC filtered 3.3V path. The analog/digital power isolation should help reduce power supply noise on the BMA180, at least that was my intent.

[avazdo]

I leave a video showing only barometric alt-hold. A few days ago I posted about code mods what works fine for me.
A video can be seen here: http://www.youtube.com/watch?v=i1wA9C6LYFs it's a little bore
Windy day. It was satisfactory Alt-hold for several minutes, but when vbat droped, multi tended to come down and YO-YO effect appeared although it was self-limiting.
My accelerometer only work fine indoor. It became crazy in sunlight (temperature issue). Barometer kept alone for the baro mode job.
I'll continue making changes.

Regards

[mr.rc-cam]

I leave a video showing only barometric alt-hold. A few days ago I posted about code mods what works fine for me.

Thanks for the video and comments. I see several meters variation in your alt-hold example. My goal is to have more precise alt-hold performance; The recent tests show that less than one meter variation is practical, even on a fat stubborn model like mine. Not everyone cares about such high performance and so I appreciate any help I can get on making my baro dreams come true.

[ziss_dm]

Hi,

As I promised, this is screenshots of my GUI static and Hover point

regards,
ziss_dm

[mr.rc-cam]

As I promised, this is screenshots of my GUI static and Hover point

Thanks for reporting your results. You lucky dog, your model appears problem free. I think it would be helpful if you could see the issue. Do you have other models to test?

Edit: Can you describe how you have mounted your BMA180? My sensors are contained on a small PCB that is mounted with soft silicone GEL pad. The interconnect wires are light gauge. The sensor board sits on a Paris V3 shield that is mounted with rubber grommets. This seems to work well for everything but Alt-Hold since I can run with high PID gains without problems, so it does not seem to have any of the common vibration issues. But maybe there is something I can do to make it less sensitive to the Z-accel issue?

[ziss_dm]

Hi,

Thanks for reporting your results. You lucky dog, your model appears problem free. I think it would be helpful if you could see the issue. Do you have other models to test?

Maybe in a week or two.

Edit: Can you describe how you have mounted your BMA180? My sensors are contained on a small PCB that is mounted with soft silicone GEL pad. The interconnect wires are light gauge. The sensor board sits on a Paris V3 shield that is mounted with rubber grommets. This seems to work well for everything but Alt-Hold since I can run with high PID gains without problems, so it does not seem to have any of the common vibration issues. But maybe there is something I can do to make it less sensitive to the Z-accel issue?

I have small boards mounted on Paris V3 with quite firm mounting tape. Paris V3 mounted on plastic standoffs.

If there not too much troubles, could you please remove gel and gromets? And for scientific purposes make screenshots of GUI before and after each step?

regards,
ziss_dm

[mr.rc-cam]

I removed the sensor board's gel pad and the Paris shield's rubber grommets. Firm servo mounting tape was installed in place of the gel pad. Firmware was V1.8p2 (no modifications). The vibration problem did not improve. Below are the screenshots.

Gel Pad, model on floor, motors off / static:

Gel Pad, model on floor, motors off

Gel Pad, model on floor, low throttle:

Gel Pad, model on floor, low throttle

Gel Pad, model in hand, mid-throttle:

Gel Pad, model in hand, mid-throttle

Firm Tape, model on floor, motors off / static:

Firm Tape, model on floor, motors off

Firm Tape, model on floor, low throttle:

Firm Tape, model on floor, low throttle

Firm Tape, model in hand, mid-throttle:

Firm Tape, model in hand, mid-throttle

[avazdo]

Hi mr.rc-cam

I derive the D term from the baro data

Could you tell me how you got derivative term from the barometer data?
I only achieve it if I use a very long time to get it because background noise of the barometer masks true values.
Currently, I need 1.2 seconds to get sufficiently high data which protude above noise.

Regards

[mr.rc-cam]

Could you tell me how you got derivative term from the barometer data?
I only achieve it if I use a very long time to get it because background noise of the barometer masks true values.
Currently, I need 1.2 seconds to get sufficiently high data which protude above noise.

I'm using the EagleTree ALT-V4 altimeter sensor. It has good performance (better than my BMP085). Currently the experimental code is using only a 250mS window to achieve a useful derivative term.

More news: today I flew with the firm mounting tape. Using the same PID values as when I had the gel pad, I can occasionally see some minor oscillations in all axis while I hover around in acro and level modes. So I am glad to have done the comparison since it confirms the silicone pads can help reduce vibrations.

[avazdo]

Thank you mr.rc-cam
I hope you show me your code when you have finished it.
I'll keep trying with my noisy BMP085 barometer.

Best regards

[mr.rc-cam]

I hope you show me your code when you have finished it.

I'm waiting for the next formal MultiWii release that has the fixes to the V1.8p2 issues. Then I will add the EagleTree code to it and post it for others to try.

[ziss_dm]

Hi mr.rc-cam,

Just made screenshot of gui with really unbalanced props. (Have added tape. The arms resonating a lot).

regards,
ziss_dm

[mr.rc-cam]

Just made screenshot of gui with really unbalanced props. (Have added tape. The arms resonating a lot).

The Z data still looks good. Very interesting indeed.

[ziss_dm]

Hi mr.rc-cam,
Would you be able to get raw acc values, without calibration and filter? To do that you need to comment:

Sensors.pde

Code: Select all

void ACC_Common() {
  static int32_t a[3];
  
  if (calibratingA>0) {
    for (uint8_t axis = 0; axis < 3; axis++) {
      // Reset a[axis] at start of calibration
      if (calibratingA == 400) a[axis]=0;
      // Sum up 400 readings
      a[axis] +=accADC[axis];
      // Clear global variables for next reading
      accADC[axis]=0;
      accZero[axis]=0;
    }
    // Calculate average, shift Z down by acc_1G and store values in EEPROM at end of calibration
    if (calibratingA == 1) {
      accZero[ROLL]  = a[ROLL]/400;
      accZero[PITCH] = a[PITCH]/400;
      accZero[YAW]   = a[YAW]/400-acc_1G; // for nunchuk 200=1G
      accTrim[ROLL]   = 0;
      accTrim[PITCH]  = 0;
      writeParams(); // write accZero in EEPROM
    }
    calibratingA--;
  }
//  accADC[ROLL]  -=  accZero[ROLL] ;
//  accADC[PITCH] -=  accZero[PITCH];
//  accADC[YAW]   -=  accZero[YAW] ;
}

IMU.pde

Code: Select all

//#define ACC_LPF_FACTOR 8

And repeat the test..

regards,
ziss_dm

[mr.rc-cam]

Would you be able to get raw acc values, without calibration and filter? To do that you need to ... {snip snip}

Here are screenshots for the new test:

On the floor, motors off:

On the floor, motors off.

On the floor, low throttle:

On the floor, low throttle

In my hand, mid throttle:
Note: the Z ACC data will jump around and often goes much lower than shown.

In my hand. mid throttle.

Some comments:
The silicone gel pad has been re-installed.

I originally thought the data looked better with the filter disabled ( //#define ACC_LPF_FACTOR 8). So I restored the original file, ran the test again to observed the "normal" values, then tried again with the filter disabled. In the end I decided there was no improvement to hang my hat on.

[ziss_dm]

Hi mr.rc-cam,
Could you double-check one thing for me: On screenshot "On the floor, low throttle", I can see Gyro spikes. I think, this happened when motors started to spin. But ACC Z started to drop earlier. And even earlier MAG had a spike. Is it what happened?

regards,
ziss_dm