This commit is the groundwork to fix the power LED
blinking on V5
Background:
----------
Early boards only had an AMBER LED that was used to
indicate a High Load condition.
This change defines the new logical inteface
the LED_<color> should not be used in application
code moving forward, only the minipulator macros
should be used.
Logical usage Legacy default
------------------------+-------------
BOARD_OVERLOAD_LED | LED_RED
Later boards defined BOARD_HAS_CONTROL_STATUS_LEDS
and added the use of a BLUE and GREEN LED that were
used as follows:
Logical usage Legacy default
------------------------+-------------
BOARD_ARMED_LED | LED_BLUE
BOARD_ARMED_STATE_LED | LED_GREEN
With this PR a board may now define _only_ a subset
the leds and map them at the board level to the
color LED it wants to use.
Logical usage Legacy default
------------------------+-------------
BOARD_OVERLOAD_LED | LED_RED
when BOARD_HAS_CONTROL_STATUS_LEDS is defined
BOARD_ARMED_LED | LED_BLUE
BOARD_ARMED_STATE_LED | LED_GREEN
If any of the BOARD_{OVERLOAD|ARMED|ARMED_STATE}_LED are not
defined. The code output generates a null action for that
LED.
Also update some comments.
In case we activate the task and don't have a locked yaw, we should
initialize the yaw setpoint with NAN to avoid any abrupt changes.
When switching back from rate to attitude control, the code depended on a
vehicle_control_mode topics update, but the publication frequency of that
is low. So the switch was noticeably delayed.
- better in terms of dependencies:
- the position controller code depended on position topics for yaw
- mc_pos_control does not have to be run for Stabilized mode
- the code path is much simpler, and thus less error prone. This is
especially important since Stabilized is often used as a fail-safe flight
mode.
Previously when switching e.g. from stabilized from acro, the stabilized
flight task kept running and publishing setpoints.
Luckily it caused no problems, but the log showed arbitrary attitude
setpoints.
As there is only one bit used in 'flags', and it is only used in case
update_interval is not null, we can move the bit to UpdateIntervalData.
The size of UpdateIntervalData does not increase (on 32 bit).
Reduces RAM usage by 3.6KB (tested on a Pixracer).
- move the update after the integration: a new computed jerk has an impact at the next epoch only
- add jerk reduction in case of too large integration time: when a jerk of "min_jerk" during dt is too much
- add jerk reduction if the integration time is larger than the predicted one and that integrating that jerk would lead to an acceleration overshoot
- rename some variables
- do not set zero throttle during the entire back-transition because otherwise
we need to make the back-transition really short
- added ramping up of throttle setpoint during backtransition to avoid
step inputs
- back-transition ends after back-transition time and not when motors are fully
rotated updwards. previously the vehicle would enter hover mode at high speed
which was not handled well by the mc position controller
Signed-off-by: Roman <bapstroman@gmail.com>
* Add attitude sub to mc_pos_control for yaw usage.
* Initialize pos control _states struct.
* Remove unnecessary init for struct in mc pos ctrl.
* Only use att topic for yaw setting in FlightTask.
David Sidrane
Daniel Agar
Paul Riseborough
TSC21
bresch
Julian Oes
Beat Küng
Roman
James Goppert