It does seem silly to use all of them, but I can see some sort of
niche fields where you'd be using both. It makes me wonder whether
there could be some sort of use for Kalman filtering the attitude from
the thermopiles and the IMU and statistically determining which is
better (I believe this statistical analysis is inherently apart of the
Kalman filter from what I've learned in classes.)
To take advantage of a Kalman filter you need to know the "uncertainty" of your measurement, so basically know when the measurement is getting bad.
Also good sensor/measurement models that can at least approximately deal with, e.g. thermopiles near buildings, vibrations on IMU, ...
These are hard to model.
Also, thinking about the defines, I'm struggling to think of a reason
you would use IMU and IR together, so maybe just assume that (on top
of the actual define of ADC_CHANNEL_GYRO_P|Q|R) if an IMU is defined
and your AHRS is defined as INFRARED, then activate the gyros (and
maybe magnetometers?). Something like:
#ifdef (ADC_CHANNEL_GYRO_P || ( IMU && AHRS_INFRARED)) //i'm not sure
what the specific defines are for IMU and AHRS as infrared and if you
can even use more complex conditional group preprocessor macros in C
I removed the old gyro files and integrated it into the imu_analog subsystem. Makes things easier to have a consistent interface.
E.g. you use an analog roll gyro together with thermopiles: add the imu_analog subsystem and only configure the roll gyro (instead of all of them).
So USE_IMU is also defined... I added the checks for the gyro channels, because with IR + gyro you can't assume that even if you are using the IMU interface that you actually have all 3 axes...
Also you do that in ahrs_infrared.c there is obviously no need to check if you are using AHRS_INFRARED...