Commit 5fe82aa added mutex protection in ~Mavlink() to fix a race
condition when start_helper() deleted an instance without holding the
mutex. However, this caused a deadlock because stop_command() and
destroy_all_instances() already hold mavlink_module_mutex when calling
delete, and the mutex is non-recursive.
Fix by moving instance cleanup to the callers:
- All callers now hold the mutex and remove the instance from
mavlink_module_instances BEFORE calling delete
- The destructor no longer touches mavlink_module_instances
- Event handoff remains in destructor (works because `this` is already
removed from the list when destructor runs)
This hopefully fixes the original race condition while avoiding the
deadlock that caused USB mavlink to hang on reconnect.
* mavlink: fix potential use-after-free
If a mavlink instance is force stopped, the main thread might be out of
scope and the receiver thread would be doing a use-after-free.
Instead the receiver thread needs to check its own _should_exit flag.
* mavlink: protect shared data by mutex in dtor
I'm not sure if this potentially fixes any of the segfaults we have seen
on stopping mavlink instances but it potentially could matter if the
mavlink_receiver thread is killed after a timeout and tries to send any
messages as a zombie.
Counts active mavlink instances atomically when instances
are claimed or released and uses that value to early-exit
the forwarding logic.
It means on single-instance scenarios this will skip taking
the mavlink_module_mutex lock and will not iterate over
mavlink_module_instances on every received message.
Signed-off-by: Onur Özkan <work@onurozkan.dev>
I don't think it makes sense to ignore required streams that easily.
If we do use some streams that are only in the MAVLink development.xml
dialect, then we will have to properly and explicitly ifdef them
everywhere that we use them. Otherwise, this basically means that we
will just swallow this warning on most (non mavlink-dev) platforms which
can mask issues.
* mavlink: esc: fix ESC_STATUS and ESC_INFO message emission.
Fixes mavlink messages emission for ESC messages. Actuator --> MotorNumber mapping was not respected, the mavlink messages should be reporting the ESC status in motor number order not actuator order.
* Update src/modules/mavlink/streams/ESC_STATUS.hpp
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Update src/modules/mavlink/streams/ESC_INFO.hpp
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* remove dependency on mixer_module/output_functions.hpp
* add actuator function definitions to EscReport.msg
* clean up
* add missing header
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
There was a race condition when closing the shell:
- the main thread checks if _mavlink_shell is not nullptr (which is true)
- the receiver thread closes the shell, which clears _mavlink_shell
- the main thread continues with _mavlink_shell->available()
* AUTOPILOT.capabilities includes gimbal manager protocol bit
Sets MAV_PROTOCOL_CAPABILITY_COMPONENT_IMPLEMENTS_GIMBAL_MANAGER bit in AUTOPILOT.capabilities
* mavlink: update submodule
* mavlink: only set gimbal flag if gimbal param set
We should probably only set the flag if the gimbal manager is actually
set up using the MNT_MODE_IN parameter.
* mavlink: make param optional
If the gimbal module is not built in we don't have the MNT_MODE_IN
param, so we need to deal with that.
* gazebo-classic: update submodule
---------
Co-authored-by: Julian Oes <julian@oes.ch>
* usb: Added parameter to enable always starting mavlink on USB.
Refactored cdcacm_init into a module and added a paramter to allow always starting mavlink on
USB, also added a paramter to choose the mode. The current default behavior is to wait and listen
for data on USB and auto-detect the protocol (mavlink, nsh, ublox). This results in the mavlink
stream not starting until something else on the mavlink network sends a packet first. The new
default behavior is to always start mavlink.
Added parameters
MAV_USB_ENABLE -- default 1 (always start mavlink on USB)
MAV_USE_MODE -- default 3 (onboard)
* added 3 retries for opening serial port in mavlink, removed sleep before sercon
* added DRIVERS_CDCACM_AUTOSTART to ark-v6x default.px4board
* added CONFIG_DRIVERS_CDCACM_AUTOSTART=y to default.px4board for boards with CONFIG_CDCACM in their nsh/defconfig
* format
* remove PGA460 from COMMON_DISTANCE_SENSOR to save flash
* remove LIS2MDL from COMMON_MAGNETOMETER to save flash
* disable CONFIG_DRIVERS_CDCACM_AUTOSTART for fmu-v5 protected.px4board
* moved and renamed parameters, removed mode logic in mavlink
* changed parameter names, added mode none
* remove parameters from mavlink
Regression from https://github.com/PX4/PX4-Autopilot/pull/23043
Also avoids a race condition by making sure the command ack is handled
before sending out the mavlink message (in case an external component
reacts immediately to the mavlink message).
- warn about full traffic conflict buffer at 1/60hz.
- add conflict expiry for buffer.
- use only events for buffer full warning. mavlink_log_critical no longer needed.
- use icao address for conflict warnings id, stop using uas_id. UTM_GLOBAL_POSITION assumed deprecated.
- stop spamming when buffer is full
- fix warning wording if buffer is full.
- remove UTM_GLOBAL_POSITION
Fixes failing unit test:
* [adsbTest] Reduce conflict timestamps - not enough time has passed in ci
- failed ci output - (passes locally with make tests TESTFILTER=AdsbConflict)
- Timestamp: 6000000000
- Time now: 457720038
- Time since timestamp: 0
- Old Conflict warning expired: 0
- --------------------
- adsb_conflict._traffic_state 0
- ../../src/lib/adsb/AdsbConflictTest.cpp:244: Failure
- Value of: adsb_conflict._traffic_state == TRAFFIC_STATE::REMIND_CONFLICT
- Actual: false
- Expected: true
Previously uORB queue size was an awkward mix of runtime configurable (at advertise or IOCTL before allocate), but effectively static with all queue size settings (outside of test code) actually coming from the topic declaration (presently ORB_QUEUE_LENGTH in the .msg). This change finally resolves the inconsistency making the queue size fully static.
Additionally there were some corner cases that the muorb and orb communicator implementation were not correctly handling. This PR provides fixes for those issues. Also correctly sets remote queue lengths now based on the topic definitions.
* Made setting of uORB topic queue size in based on topic definition only
* Fixes to the ModalAI muorb implementation
* Removed libfc sensor from format checks
* msg/TransponderReport.msg ORB_QUEUE_LENGTH 8->16 (was set to higher in AdsbConflict.h
---------
Co-authored-by: Eric Katzfey <eric.katzfey@modalai.com>
Co-authored-by: Daniel Agar <daniel@agar.ca>
Julian Oes