The TECS controller belongs really into the ECL (estimation & control library) where we have collected a number of vehicle control systems. It is being replaced by a new implementation of the algorithm, contributed by Paul Riseborough.
This adds support for parsing git tags which include a vendor version.
E.g. vX.Y.Z-A.B.Crc1, whereas X.Y.Z are numbers defining the upstream
version and A.B.C is the vendor version.
* NuttX cmake
* px4_macros:Pass the stringified predicate as second arg to static assert
CC_ASSERT mapes to the c++ static_assert or provides the same
funtionality for c via the other macros. The c++ static assert
takes 2 argumants the prdicate and a message. This fixes the
lacking second argument.
* Updated nuttx and apps submodule to upstream nuttx 7.21+==master
This is the latest uptake of upstream nuttx and apps.
* ROMFS generate with xxd instead of objcopy
* delete nuttx-patches
* NuttX update submodules to latest px4_nuttx-master
* fix nuttx apps and board dependency
* docker_run update to latest container 2017-08-29
* cmake ROMFS portable sed usage
* NuttX update submodules to latest px4_nuttx-master
Note: ecl needs to be updated at the same time
because as soon as the ecl is compiled within PX4 Firmware
the matrix submodule checked out by PX4 Firmware is used
for every call to a matrix or quaternion.
* For some reason cppcheck complains with `fp != nullptr` but accepts truthiness
of handle by itself.
* Note that the expressions are equivalent according to the C++ standard ("A
prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member
type can be converted to a prvalue of type bool. A zero value, null pointer
value, or null member pointer value is converted to false; any other value is
converted to true. A prvalue of type std::nullptr_t can be converted to a
prvalue of type bool; the resulting value is false.")
1) Add hwtypecmp command to allow rc to further enumerate PX4FMU_V2
for sub types of 'V2' -FMUv2 'V2M' PixhawkMini, 'V30' Cube
2) Extend hw to report to display
HW type
HW version
HW revision
* update ecl to latest
* EKF2_GPS_DELAY change default 200ms -> 110ms
- 110msec is more representative of what most users are flying
* EKF2_ASP_DELAY change default 200ms -> 100ms
The EKF is relatively insensitive to airspeed sensor delays and the effective delay is installation specific, so it has been set to a value that does not cause the data buffers to be longer than is required to accomodate GPS delays.
Paul Riseborough