Hi - I come from a space systems/sensor/microcontroller perspective; I teach this stuff and I have access to virtually all bits of electronic test equipment imaginable. However, I’ve tried to set up a very basic pixhawk mini / fixed wing system, and I have spent perhaps 40 frustrating hours dealing with a long list of problems (noisy sensors, frankly schizophrenic use of the I2C bus to transmit flight critical parameters such as airspeed through long wiggly unshielded cables, problematic ESCs, intermittent compass errors, and completely uninformative error messages).
Either I’m completely clueless, or there is room for improvement in QGroundControl. Judging from all the forums, there must be dozens or hundreds of people dealing just with airspeed sensor problems (unknown thermal compensation characteristics, weird offsets etc).
The general flaw of QGroundControl is that it assumes the hardware is good, and that the setup process involves only trivial calibrations (e.g. which way is up, and what’s the intercept of the airspeed ADC). However, the reality is that for any nontrivial system, most of the time there will be a hardware issue/limitation of some sort, and many of those will be intermittent.
Imagine a world in which QGroundControl had a tab that said “Check and validate my hardware”. For example, when I click airspeed sensor, I would get a chartplotter that shows me the raw data coming from the sensor, and a parallel plot of the running StandardDeviation of the signal. Then I could e.g. move the airspeed sensor WRT the telemetry transmitter, and figure out optimal placement in about 10 seconds, or wiggle the cable to see if there is a bad solder joint or whatever. The software architecture goal should be to empower a typical user to fix a typical problem (interference, broken wires, misleading documentation about pinout assignments, whatever it is) in seconds rather than hours. Happy to help with that, provided there is traction/enthusiasm, and I’m not just the only one.