1. Probably most interesting because related to recent discussions: Pitch loop. I started manually and commanded to home circle. Altitude hold was really bad, looking at the data, there is a phase offset from desired climb to desired pitch which led to huge oscillation around desired altitude. Looking at the code, I think the reason are the integrators of the auto pitch loop winding up and taking time to desaturate.. The values of the integrators (limits in the code, not gains) seem quite high. Is this dependant on control frequency?
1.a There is no setting file for airspeed in "old control" (like basic_airspeed). I wrote one, probably should be integrated?
Should "new control" perform better anyway? Then it should/could be made standard in the example airframes, which it is not at the moment...
The old control is indeed quite poor and probably sufficient in some cases but certainly not all. There is a new control loop and even a total energy control loop in the tudelft/tudelft4.0 branch and already in the paparazzi/master. We are all working very hard to finish the code and significantly upgrade paparazzi.
2. The Airspeed sensor works on the I2C2 port with 3.3V (also written in the specs). But initialisation seems to be a problem. Only after (Luftboot)programming, the sensor delivers data. If I just plug the battery in, airspeed is constant 8.. Sensor display shows numbers like usual. Should there be some kind of pause in the ETS init? Or is this an I2C related problem?
This problem is also known and a hacked solution is also in the tudelft/tudelft4.0/sw/airborne/arch/stm32/mcu_periph/i2c_arch.c
3. The V_BATT voltage reading was wrong with the standard conversion value. I had to alter it from 0.00485*adc to 0.00459*adc. Were there different values of resistors in the production in the voltage divider?
Known issue. Fixed at several places in downstream code. Will be released soon.
4 GPS... The performance of the Lea-4 (navilock module) seems to be much worse with the configuration of the gps_ubx_ucenter.xml module compared to the offboard configuration with the conf/gps/ublox_conf.c. Especially altitude is drifting like crazy and z_dot looks bad (most times close to 0 and not fitting to the actual altitude changes). The differences seem to be Airborne 2G instead 4G and EGNOS activated. I will check this in future flights but confirmation of this issue by others would be good.
This one is actually interesting: we would like feedback on which modes perform well on which hardware. then the module can configure depending on the hardware.