* AeroFC: Update defconfig
defconfig generated using: make aerofc-v1_default oldconfig
* AeroFC: Disable UART8
It is not used but it share the same pinout in the FC connector with
other pin used as I2C2, so it needs to stay in high-z.
if vmount was enabled in mavlink mode, it was continuously sending mavlink
commmands, which lead to 'command denied during calibration: 205' messages
during calibration.
If you want to go to the limit of what the vehicle can do, you need to be
able to set it so large that it is guaranteed that it's never limited by
software.
Tests showed that it's not a problem to increase it to very high numbers.
360 is too fast if you just want to hover. Next step is to add expo(),
so that we still have fine-grained control at the center and high rates
at the edges.
Previously, the yaw weight was based on the tilt angle of the attitude
setpoint (R_sp(2, 2) == cos(tilt angle)). This makes no sense, it means
the weight is low for high tilt angles even if there is no roll-pitch error
at all.
This patch changes the weight computation to be based on the tilt angle
error: the yaw weight is 1 if there is no roll-pitch error (independent
from current tilt angle), and is reduced for higher tilt angle errors.
The weight was added in 05e9a30573, without any explanation or
derivation of how and why the weight is chosen that way.
However this patch works much better in practice. The yaw control is
improved, though it can be a bit slow to converge if you do continuous &
fast roll-pitch motions (which is expected).
The feedforwarding was applied in the wrong frame: the term is given in
global coordinates, but was directly applied to body coordinates. This
patch adds the missing transformation from global to body frame.
In addition, it moves the feedforwarding before the rate limitation, so
that we cannot exceed the configured rates.
It was setting the rotation value to the I2C slave address
causing it to not be successfully probe.
Changing the constructor paramters order instead of
just fix line instantiating to keep consistency with
the other lidars and sonars.
Depending on the CMake version when we are configuring it emits a
warning about deprecation of CMAKE_FORCE_CXX_COMPILER. However we
rely on this macro and don't want to do what CMAKE_CXX_COMPILER
is doing. Here is what I get with CMake 3.9.1:
CMake Deprecation Warning at /usr/share/cmake/Modules/CMakeForceCompiler.cmake:83 (message):
The CMAKE_FORCE_CXX_COMPILER macro is deprecated. Instead just set
CMAKE_CXX_COMPILER and allow CMake to identify the compiler.
Call Stack (most recent call first):
cmake/toolchains/Toolchain-arm-none-eabi.cmake:37 (cmake_force_cxx_compiler)
/usr/share/cmake/Modules/CMakeDetermineSystem.cmake:94 (include)
CMakeLists.txt:263 (project)
Avoid the warning by passing -Wno-deprecated to cmake.
A battery is considered connected when a) V > BOARD_ADC_OPEN_CIRCUIT_V
and if BOARD_ADC_OPEN_CIRCUIT_V > BOARD_VALID_UV connected
is further qualifed by the Valid signal.
Julien Lecoeur
Jonas Vautherin
Beat Küng
ChristophTobler
José Roberto de Souza
Lucas De Marchi
David Sidrane
Daniel Agar
Lorenz Meier