Using mixers on the IO side had a remote benefit of being able to
override all control surfaces with a radio remote on a fixed wing.
This ended up not being used that much and since the original design
10 years ago (2011) we have been able to convince ourselves that the
overall system stability is at a level where this marginal benefit,
which is not present on multicopters, is not worth the hazzle.
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
Co-authored-by: Daniel Agar <daniel@agar.ca>
* 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
-moved rc.mavlink to the boards optional rc additions (now it's called rc.board_mavlink) to handle board specific mavlink needs (mavlink over usb, ethernet, additional streams, etc.)
-mavlink module will be responsible to usb defaults, therefore less args are needed to be passed to mavlink module if one wants to use mavlink over usb.
-the way to check if connection is usb is by it's designated variable and not by config mode.
* 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
chfriedrich98