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.
Due to higher bias, V open circuit on the ADC is high with a 1M
termination. This override the default connected threshold on
V5 HW. Revist once lowe termination is chosen.
BOARD_ADC_OPEN_CIRCUIT_V is the voltage present on an ADC due
to the bias current on the terminition resistor.
BOARD_VALID_UV is the under voltage min set by resistors on a
board's Power selector.
A battery is considered connected when the Voltage measures is
greater than BOARD_ADC_OPEN_CIRCUIT_V.
In the case where BOARD_ADC_OPEN_CIRCUIT_V is greater then
BOARD_VALID_UV we can use the HW to qualify connected.
The data sheet for the F4, F7 indicate a maximum of 36 Mhz
in the 2.4-3.3 volt Soc operating range. This change sets
the clock based on the STM32_PCLK2_FREQUENCY.