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.
to save the time running the installer for every build
which was necessary before because the folder exceedes
the maximum of 1GB cache of the appveyor free plan
Unlike pipes, unix sockets provide bi-directional
communication with each connected client.
- No need to generate a unique uuid per client anymore.
- The client doesn't have to create its own pipe anymore.
- Since there is no risk of multiple client's writes getting mixed up,
messages don't need to fit in a single write anymore, removing the
limit on command length.
- Since the server can detect a connection closing, the client no longer
needs to handle signals. When the client is killed, the connection is
automatically closed, which will cause the server to kill the related
px4 thread.
Since this does not rely on handling signals and the client sending an
additional message, this is much more reliable.
- Client is no longer a singleton.
- The protocol is simplified. Standard output is directly written to the
socket back to the client, without wrapping it in any protocol
message.
- Because of the simple protocol, one could now even use netcat to run a
px4 command:
$ echo hello | netcat -UN /tmp/px4-sock-0
Also removes a few race conditions.
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
David Sidrane
Daniel Agar
Paul Riseborough
Matthias Grob
TSC21
dkang
bresch
Mara Bos
Julian Oes
Hamish Willee
Beat Küng