I am proficient in coding but by no means an expert. Looking at the code (in IMU.cpp, MW version 2.3), I see that the barometer is used with a simple low pass filter:
alt.EstAlt = (alt.EstAlt * 6 + BaroAlt * 2) >> 3; // additional LPF to reduce baro noise (faster by 30 µs)
Later, I see that a complimentary filter is used to combine the vertical velocity, calculated from differentiating the baro readings, with that calculated by integrating the vertical accelerometer reading, to better estimate actual vertical velocity:
vel += accZ * ACC_VelScale * dTime;
// apply Complimentary Filter to keep the calculated velocity based on baro velocity (i.e. near real velocity).
// By using CF it's possible to correct the drift of integrated accZ (velocity) without loosing the phase, i.e without delay
vel = vel * 0.985f + baroVel * 0.015f;
However, the complimentary filter seems to only be used for the velocity term (i.e. the D term of the PID controller). Is does not seem to be implemented for the alt.EstAlt variable, which is used to calculate error for the P and I terms of the althold control loop. As I understand things, alt.EstAlt seems to be based solely on the baro reading. Is this correct? If so, the P and I terms do not use accelerometer readings at all, only the D term does. Why not implement a similar complimentary filter for P and I too?
I am thinking about experimenting with rewriting the althold algorithm, starting by using a complimentary filter to estimate altitude by combining readings from both sensors, and only applying PID control later. I am also thinking about including a subroutine to check if the sonar is in range, and if it is then use this value instead of the baro to calculate alt.EstAlt. I will report back with how it goes - but first I need to work out how to query the sonar reading from the i2c module that it is connected to. So many fun projects!
Matt