If logger is started very early, orb_exists() will fail for a lot of
topics, they will be advertised within the next few seconds.
Logger already dynamically adds subscriptions during logging, but if we
do that before as well, we'll avoid any delays and having to subscribe
to a lot of topics all at once.
To keep track of the configured interval, we store it as negative file
descriptor, until we do the subscription.
This frees up a considerable amount of file descriptors in most use-cases.
Existing users of orb_exists:
- logger (dynamic subscribe to multi-instances)
- mavlink (orb subscription)
- sdlog2
- preflightcheck (check for home_position)
- wait_for_topic shell command (it's not used)
- orb_group_count() (sensors: dynamic sensor addition)
All use-cases benefit from the changed semantics: they are really only
interested if there is a publisher, not another subscriber.
arming_state_changed was not set in all places where an arming transition
occurred, for example when calling arm_disarm() from auto-disarm.
We did not notice because the state is published with at least 5 Hz already.
- initialize rc lost with true
- refactor for simpler downstream code-plugin
- allow for the addition of different binding commands
- fix st24 RC lost logic
The config mode uses high rates for many streams, leading to high CPU usage
(9-10% for the mavlink sender). The normal mode contains almost the same
set of messages but at lower rates.
This reduces the CPU load on a Pixracer by 3-4%.
- use select_responder from tap_esc_common namespace (same definition)
- switch pwm output to uint16, that's what's used in send_esc_output()
- use SCHED_PRIORITY_ACTUATOR_OUTPUTS instead of SCHED_PRIORITY_MAX
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.
At 90 degrees the yaw is extremely unstable (tested with HIL), it
overshoots and only very slowly converges to the correct value.
This behavior is also noticable with lower angles, but not so extreme.
It definitely needs to be looked into further, but for now this makes it
safer.
param save is an expensive operation that can take several 100ms. And
previously it was possible that a param_get() caller was blocked on a
save operation. If this happened due to a param change notification,
important modules, such as sensors, could have been blocked for a longer
period (and affecting the flight performance).
With this patch, this situation is not possible anymore, because a param
save now uses the reader lock and a separate file lock.
However it is still possible that a param_set() needs to wait for a save
operation, thus blocking for a longer time. param_set() thus needs to be
avoided in important modules when the system is armed.
In the case of mavlink it works, since it does not affect the flight if
the mavlink receiver is blocked over a longer time. It is only problematic
if a joystick is used as input or in offboard control.
if _ftp_on is true, message_buffer was created and read, but it was
actually never written to, so this is not needed. It can only ever be
written to if _forwarding_on is true.
And the maximum number of configured file descriptors.
Note that this is per group, not per thread, so that e.g. logger and
log_writer_file show the same number.
VDev::getDev() is used in px4_access, which is used in orb_exists. And if
the topic does not exist, it iterates over all 500 indexes, which is slow.
It was slow even if the topic existed, the map reduces runtime from linear
to logarithmic (there are around 80 items in the container).
This is only used on posix.
control_data needs to be able to be set to nullptr in case if the input
is already active. Otherwise the output will think there's always new
requests and reset it's state.
Beat Küng