* add support for unmanned underwater vehicles:
* airframe uuv_generic + uuv_hippocammpus including mav_type = 12 for submarines
* mixer for UUVs with X-shaped thruster setup similar to quadcopter
* add module uuv_att_control for underwater robot attitude control
* add rc.uuv_defaults/apps for autostarting e.g. ekf2 and uuv_att_control app
This target was never fully supported and is heavily dependent on a number of DriverFramework drivers that have no in tree equivalents (bebop bus, flow, rangefinder, etc). Deleting this will make it easier to fully drop DriverFramework shortly.
* The X-UAV Mini Talon airframe with the new type Plane V-Tail uses the new AAVVTWFF_vtail mixer.
The new mixer is derived from the AAVVTWFF mixer and is a generic V-Tail mixer. I left the flaps and wheel although there are no flaps and wheels on the mini talon to keep it generic. The airframe configuration is derived from the Albatross A-Tail.
* Lists ROMFS files explicity instead of using GLOB_RECURSE
Previously, when ROMFS files that were not airframes were touched, the ROMFS
would not be rebuilt. The ROMFS files are now specified explicityl in a
CMakeLists.txt file that is located in the root ROMFS directory.
Now when one of the ROMFS files is touched the whole ROMFS is rebuilt.
When new files are added to the ROMFS, they need to be explicity added to
the CMakeLists in the ROMFS root directory.
* ROMFS: adds individual CMakeLists files in each subdirectory
Also moves the temporary ROMFS build directory to ${PX4_BINARY_DIR}/ROMFS/genromfs
so that the cmake_install.cmake files and the CMakeFiles directories (generated whenever
are not add_subdirectory() is called) are not generated in the temporary ROMFS directory
from which the ROMFS binary is created.
* cmake ROMFS generate add px4_add_romfs_files function
* ROMFS CMakeLists: adds explanatory comment to px4_add_romfs_files function
* ROMFS CMakeLists: updates copyright headers
This is the new interface to control external LED's (user-facing).
Features:
- Supports maximum N Leds (where the board can define N)
- on/off/blink M times
- Different priorities
- Allows setting a single led or multiple at once
It makes more sense to set the optimization flags on a platform basis
instead of individually for each module. This allows for different
optimization options for SITL, NuttX, Snapdragon, etc.