by **FHoevi** » Thu Jun 12, 2014 8:53 am

Exactly, the acc vector in the copter's inertial frame gets projected onto the estimated acceleration vector which lives in the earth's inertial frame. If the copter moves horizontally as seen in the earth's frame, the vertical part of this projection should be 1G. It is only differing from that if the copter's motion has a vertical (earth's frame) component, but that's exactly what you are interested in when it comes to AltHold after subtracting earth's constant gravitation. Absolutely right again, accZ in its final form is reduced by accZoffset, that's why it's zero at rest on a level surface after calibration. But now my point again, I think the detour with accZoffset is not necessary since after arming this value remains constant anyway (at 512?) and could easily be replaced by accZ_1G, a sensor specific constant. And right a third time, it is only interesting for AltHold as I was mentioning in the beginning. But again, at rest accZ is just the rebased acceleration in the copter's frame where rebasing means subtracting exactly 1G which is always present. As viewed from the copter the only linear forces which could act are a) gravitation (could be pointing into any direction in this frame) and b) the copter's own thrust which always only could point up or down in the copter's frame. The other forces/accelerations are angular ones (pitch, roll, yaw). Thus, at rest, the raw, smoothed value for acc_yaw you could see in real time is indeed the real one, it should indeed show the value of 1G pointing down. accZ measures only additional accelerations on top of the earth's gravitation which are acting on the copter.

Imagine the case if you did anything well before launch, accZ = 0, let the copter fly to a different location, get it down there and disarm. The accZoffset calculation starts over, leads to a different value for (almost) sure when arming again. But nothing fundamentally changed in the meantime but you lost control of accZoffset since you do not know whether the copter lifts off from levelled ground. The earth's gravitational field's direction certainly did not change in the meantime. But now, at least in terms of the AltHold mode, the copter "thinks" it was different. And that leads to problems in AltHold mode which I would like to point to. Just imagine the case if the bank/pitch angle were 90° when arming, accZOffset would be vanishing.

If you always arm at the same level place as where acc gets calibrated there should not be material problems. But the only thing I'm saying is that there may be if not. In my case there were such odd things happening but anything is fine after removing that accZoffset which, again, should be at 512 anyway. OK, I'm using a different signal for AltHold but the general principle is the same.

Now, the "raw" vertical acc value gets reduced by a value which actually is too small (512 * cos(tilt angle)). So, even if the copter is hovering the vertical component accZ is not equal to zero as it should be in that case, right? In the next step the vertical velocity gets estimated by numerically integrating a properly scaled accZ over time. The constant offset of accZ translates to an increasing offset or a drift of the vertical velocity vel. In the plain version of AltHold this value enters the "D" section of the AltHold PID, perhaps you lose a bit of the effect by all the applications of the deadband function like

//D

int16_t vel_tmp = vel;

applyDeadband(vel_tmp, 5);

BaroPID -= constrain(conf.D8[PIDALT] * vel_tmp >>4, -150, 150);

which cuts off potentially interesting information but which in turn could lead (after some tuning) to a more stable AltHold. But anyway, as the vel error piles up the D correction erroneously kicks in, the copter reduces throttle and goes down since it "thinks" its vertical velocity vel is too big. After a while P and I should kick in by lifting the copter again to reduce the error in respect of the desired altitude according to the barometrically measured value when the AltHold mode has beeen switched on. That means that instability enters the system even if the PID calibration for AltHold has been done thoroughly. The D correction to BaroPID from above is limited by +/- 150 but this could offset the similar range of initial BaroPID P values if the signs were opposite. Just the I correction could help in that case.