Open the UART after adding the instance: mavlink_open_uart() might block,
and in that case the parent task waiting for mavlink to be started times
out.
And while waiting for the USB UART device to come up:
- check for _task_should_exit
- check for check_requested_subscriptions()
Side-effects when USB is not plugged in during boot:
- reduces boot duration by 100ms
- fixes duplicate instance name in 'top':
201 mavlink_if0 1 0.000 1328/ 2572 100 (100) w:sig 3
204 mavlink_if0 572 4.221 1632/ 2540 100 (100) w:sig 4
- 'mavlink stop-all' now stops the usb instance as well
The navigator has a notion of resetting the triplets which means the
triplet setpoints are set to invalid and therefore not to be used by
downstream modules such as flight tasks.
However, before this patch, the triplets were not published if invalid
meaning that a valid triplet would stay the truth until a new valid
triplet would get published.
E.g. this lead to the corner case case where we publish a valid triplet
with an IDLE setpoint on ground in HOLD and then don't update the
triplet while flying in POSCTL mode. Later, when RTL is engaged, the
flight task will use IDLE until navigator (which runs slower) has
published the next triplet.
The fix involves two main changes:
- Publish invalid triplets to avoid stale triplets.
- Avoid publishing the triplet on every iteration in manual modes by not
setting `_pos_sp_triplet_published_invalid_once = false`.
When testing this I realized that a mission upload during RTL would stop
RTL. This is because the mission is updated while the mission navigation
mode is not active and reset_triplets() is called from there. This is
now only done for the case where we are actually in mission navigation
mode. The fact that a mission is updated when not active also seems
wrong and is something to fix another time.
Exclusive open is not required, but we now need to ensure the queue size
is set atomically.
It avoids a race condition between 2 single-instance advertisers,
where one of them would fail to open the node with -EBUSY.
Possible race conditions (they all happen between the check of existence
of a topic and trying to create the node):
- single instance, with multiple advertisers during the first advertise:
both advertisers see the topic as non-existent and try to advertise it.
One of them will fail, leading to an error message.
This is the cause for telemetry_status advert failure seen in SITL in
rare cases.
- multi-instance: subscription to non-existing instance -> px4_open fails,
and the subscriber tries to create the node. If during that time a
publisher publishes that instance, the subscriber will get (instance+1)
(or fails if the max number of instances is exceeded).
This is a race that goes pretty much unnoticed.
- multi-instance: 2 publishers can get the same instance (if is_published()
is false in case both have not published data yet).
This can also go unnoticed.
Therefore the patch changes where _advertised is set: it is now set
directly during the advertisement instead of during publication.
When running in HITL mode, pwm_out_sim publishes actuator_outputs.
px4io unconditionally publishes the uOrb actuator_outputs. When HITL
is configured, the px4io copy of the uOrb has all zeros.
The result is that there are two publications, one valid, and one
all-zeros. This causes the HIL_ACTUATOR_CONTROLS mavlink message
to be incorrect (all-zeros) and the SERVO_OUTPUTS_RAW mavlink
message to be inconsistent, as it takes the data from one or the
other uOrb randomly each cycle.
The fix is to let px4io know that HITL is in effect when it is
started, and modify px4io to suppress publication in this case.
This is a bigger more complicated fix than I would like, but I
think it is conceptually correct.
Signed-off-by: Nik Langrind <langrind@gmail.com>
The interrupt driven card detect logic was enabled
but the auto mounter was not. That interrupt was
calling mmcsd_mediachange.
There is a reentrancy issues in the kinetis callback logic.
Toplevel calls mmcsd_mediachange calls SDIO_CALLBACKENABLE
that calls kinetis_callbackenable that calls kinetis_callback
that calls mmcsd_mediachange.
This fixes spuriously occuring mag spikes in the external mag of Here2.
The reason for the spikes was that the fact that the I2C registers were
not read out correctly as suggested in the datasheet.
Before we were reading out ST1, data, and ST2 in one pass and ignoring
the data ready bit (DRDY) in ST1. This meant that we could run into race
conditions where the data was not ready when we started reading and
being updated as the registers are read.
Instead, we need to check the read the ST1 register first to check the
data ready bit and then read the data and ST2 if the data is ready. By
reading ST2 we then trigger the next measurement in the chip.
Note: the author name was removed because this file has almost no
resemblence with the code written by that author 4 years ago, has been
copied to new places, and was initially commited without author anyway.
Also, my opinion is that the version control system should take care of
attribution, and not outdated comments.
This fixes the case where the mixer_module would subscribe and use its
own test_motor publication which was created only to make sure the
topic is advertised and subsequent updates will work properly.
This happened in SITL lockstep because the timestamp would be 0 at the
very beginning, and hence elapsed time would be 0 as well.
This lead to an actuator publication which would then get lockstep out
of sync causing poll errors on the Gazebo side.
getLockGuard relies on copy elision to work correctly, which the compiler
is not required to do (only with C++17).
If no copy elision happens, the mutex ends up being unlocked twice, and the
CS is executed with the mutex unlocked.
The patch also ensures that the same pattern cannot be used again.
I don't understand why we should wait to parse incoming MAVLink traffic
just because we don't have the source address initialized. We still
check the source address before doing a sendto.
This should fix serial MAVLink communication on FMU5x where both serial
and UDP is available. There the serial connection previously did not
work because nothing was connected over UDP.
The constrainAbs function was not prioritizing the minimum value
that produces the autocontinue behaviour. This caused zig-zag
paths when the waypoints were almost -but not exactly- aligned.
dt could drive the alpha filter crazy because of the small dt
approximation during the computation of the coefficient.
- Remove unused bitmask packing of the innovation checks
* ekf2: Add FirstOrderLpf and InnovationLpf classes for innovation lowpass filtering
* ekf2: use InnovLpf filter class in preflight checks
* ekf2: move selection of yaw test limit for pre-flight check in function
* ekf2: Move pre-flight checks into separate function
* ekf2: use static constexpr insetead of inline for sq (square) function
* ekf2: Split pre-flight checks in separate functions
Also use the same check for all the innovations:
innov_lpf < test and innov < 2xtest
* ekf2: Add optical flow pre-flight check
* ekf2: Combine FirstOrderLpf and InnovationLpf in single class
* ekf2: check vel_pos_innov when ev_pos is active as well
* ekf2: transform InnovationLpf into a header only library and pass the
spike limit during the update call to avoid storing it here
* ekf2: Static and const cleanup
- set spike_lim constants as static constexpr, set innovation
- set checker helper functions as static
- rename the mix of heading and yaw as heading to avoid confusion
* ekf2: use ternary operator in selectHeadingTestLimit instead of if-else
* ekf2: store intermediate redults in const bool flags. Those will be used for logging
* ekf2: set variable const whenever possible
* ekf2: create PreFlightChecker class that handle all the innovation
pre-flight checks.
Add simple unit testing
Use bitmask instead of general flag to have more granularity
* PreFlightChecker: use setter for the innovations to check instead of sending booleans in the update function
This makes it more scalable as more checks will be added
* ekf: Use booleans instead of bitmask for ekf preflt checks
Rename "down" to "vert"
Some of these perf counters were useful during initial development, but realistically aren't needed anymore, some are redundant when we can now see the average interval from `work_queue status` and some of them simply aren't worth the cost at higher rates.