- increase the minimum pwm value for multirotor mode since we experienced
the rear motor stalling in certain situations when throttle was low
Signed-off-by: Roman <bapstroman@gmail.com>
Change to be coherent with the change on NuttX upstream, in the future
STM32_BKP_BASE will be removed. This is using the definition over stm32_rtc.h interface.
* Batt_smbus. Added complementary filter to remaining capacity, reversed warning state checks, and added remaining/discharged out of range checks to handle bad battery calibrations
* Changed errx to PX4_ERR
* Added PX4_ERR returns
- On initialization _v_att_sp got filled with zeros
leaving invalid quaternions
- While not armed mc_pos_control did not publish any
attitude setpoint which makes no sense
- The attitude control just uses the data in _v_att_sp
if it was (ever) updated or not
While operating on exactly normalized float quaternions
it can aparently still happen that one of the elements
gets just slightly above 1 or below -1 and hence out of
the domain of the acosf and asinf functions resulting in
NaN. The constrain function uses stricly smaller/bigger
comparisons and catches all tested cases.
- Delete left over identity matrix.
- Corner case with a zero element when using the signum function:
We always need a sign also for zero.
- Corner case with arbitrary yaw but and 180 degree roll or pitch:
Reduced attitude control calculation always rotates around roll
because there's no right choice when neglecting yaw. In that small
corner case it's better to just use full attitude contol and hence
rotate around the most efficient roll/pitch combination.
According to the paper the quaternion controller is built on
the yaw weight represents the ratio between the roll/pitch and
the yaw attitude control time constant. It also states that as a
thumb rule a value of ~0.4 works alright for most multicopter
platforms. The default attitude gains of PX4 which were determined
independent of the paper from experimental results have a ratio of
2.8/6.5 = 0.43 which matches.
Because the parameter does not make sense from a control theory
perspective. Either you have a gain with the unit 1/s or an inverse
gain or time constant with the unit s. But the time constant parameter
was neither bound to any exact unit nor did it apply instead of a gain.
Rather it adjusted multiple gains from rate and attitude control
according to an arbitrary scale. This can only by accident lead to
good tuning.
to prioritize yaw compared to roll and pitch by combining
the shortest rotation to achieve a total thrust vector with
the full attitude respecting the desired yaw
not by scaling down the control output with the gains
If the EXTERNAL_MODULES_LOCATION variable has been set, and the
EXTERNAL_MODULES_LOCATION/msg/ directory exists containing a
CMakeLists.txt file with the following format:
set(config_msg_list_external
message1.msg
message2.msg
message3.msg
...
PARENT_SCOPE
)
then the messages defined in config_msg_list_external are added to the
msg_files list in Firmware/msg/CMakeLists.txt and are used to generate uORB
message headers. The generate uORB message headers are generated in the same
location as the normal uORB message headers in the build directory, namely,
<build_dir>/uORB/topics. The uORB topic sources are generated in
<build_dir>/msg/topics_sources.
