* [autopilot] compiling generated AP for fixedwing
* update some old variable names for autopilot mode
* prevent oscillation on the ground with real aircraft
* add guidance loop to 'new' control
all this guidance code should really be better factorized
* fix rotorcraft autopilot for new API
* read guidance RC if needed
* use generated autopilot as soon as an autopilot file is defined
* autopilot node at airframe, firmware or target level
The autopilot can be specific to one of the firmware, or one of the
target.
At the moment, it will fail at runtime if more than one autopilot in the
same airframe since server don't know which target is in use.
* [autopilot] refactor autopilot API for both firmwares
With this, fixedwing and rotorcraft are mostly using the same interface
for the autopilot. Some specific code and messages handling are still
firmware dependent.
A large part of the autopilot logic of the fixedwing is moved from
main_ap to autopilot_static.
More getter/setter functions are provided.
* [autopilot] update the rest of the system and the conf
for using the refactored autopilot API
* [autopilot] fix some errors from CI servers
* [actuators] use dummy actuators module to prevent autoloading
* Rename Bart_heliDD_INDI.xml to tudelft_bs_helidd_indi.xml
* Rename Bart_heliDD_pid.xml to tudelft_bs_helidd_pid.xml
* Delete tudelft_course2016_bebop_colorfilter.xml
* Delete tudelft_course2016_bebop_avoider.xml
* [actuators] don't autoload actuators when set to 'none'
* [gcs] autodetect firmware for strip mode button
By default the original static autopilot is used. A config flag can
enable the use of the generated AP code.
A basic autopilot description is provided (4 modes + failsafe modes).
The server is capable of using the list of generated mode to properly
display mode names.
Tested in NAV and GUIDED mode in sim, and direct attitude control on
real aircraft.
Gautier Hattenberger
Felix Ruess