Mavlink::request_stop() unconditionally called
_sign_control.write_key_and_timestamp() on every instance shutdown,
which created /fs/microsd/mavlink/mavlink-signing-key.bin filled with a
zero key and zero timestamp on FCs that never enabled signing.
The shutdown write is redundant: every signing state transition
(KEY_ACCEPTED, SIGNING_DISABLED) already persists synchronously inside
check_for_signing() before returning. The in-memory state is always
flushed to disk at the moment it changes.
Aggravated by mavlink_main.cpp:3334 calling request_stop() up to 1000
times in a tight loop while waiting for the thread to exit, plus the
~Mavlink() destructor path. Each call re-truncates and rewrites the
phantom file.
Reported by Jake Dahl on two separate flight controllers running
mainline.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The PR-time SBOM license check was using `submodules: false`, so when
generate_sbom.py ran the new submodule directory was empty. The script
treats uninitialized submodules as `(not checked out) -> NOASSERTION
(skipped)` rather than a failure, which let PR #27184 (adding
PX4-OpticalFlow as a submodule) pass without ever inspecting the actual
repo for a LICENSE file. The monthly audit then caught it (#27217)
because it uses `submodules: recursive`.
Switch the PR-time job to `submodules: recursive` so license issues
are caught at PR time rather than on the next monthly audit. The job
only runs when .gitmodules, license-overrides.yaml, or
generate_sbom.py change, so the extra clone cost is bounded.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Bumps the submodule pointer to pick up the BSD-3-Clause LICENSE file
added in PX4/PX4-OpticalFlow#20.
Resolves the SBOM audit NOASSERTION finding without needing a manual
override entry in Tools/ci/license-overrides.yaml.
Fixes#27217
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Remove ASPD_SCALE_NSD, ASPD_BETA_NOISE, ASPD_TAS_GATE, ASPD_BETA_GATE as these
are never changed in practice. Keep ASPD_WIND_NSD and ASPD_TAS_NOISE tunable as
they are relevant for high-altitude (wind NSD) and high-speed (TAS noise) use cases.
* feat: add driver for ADS7128 ADC
* style: used make format
* fix: only read 1 byte in adc_get()
* fix: set correct min/max/def value for VRef
* fix: print i2c address in status
* feat: add threshhold to failures before reset
* feat: add failure_threshhold_count
* style: remove unused variable definition from module.yaml
* fix: removed retry logic from poll functions
* fix: decreased sleep time in probe function
* feat: add driver for ADS7128 ADC
* style: used make format
* fix: only read 1 byte in adc_get()
* fix: changed scheduling logic
* fix: ensure no false values are published
* fix: removed unused variable definition
* style: used make format
* fix: removed merge artifact
* fix: removed some merge artifacts
Integrators can declare read-only parameters in a per-board YAML file:
readonly_params.yaml.
There are two ways to define the read-only params:
- "block": default writable, explicitly list params to be locked
- "allow": default readonly, explicitly list params to be writable
Enforcement is activated by `param lock` in rcS after all startup
scripts have run, so board defaults and airframe scripts can still set
params during init.
The feedback via MAVLink uses the new
MAV_PARAM_ERROR_READ_ONLY as part of the PARAM_ERROR message.
* fix(mavlink): gate UAVCAN param bridge on observed camera heartbeat
Only exclude target_component 100..105 from the MAVLink -> UAVCAN
parameter bridge when a MAVLink HEARTBEAT with MAV_TYPE_CAMERA has
been observed on that component within the last 5s. When no camera
has been seen, forward to the matching UAVCAN node as before.
The bridge maps target_component 1:1 onto UAVCAN node_id, so the
unconditional 100..105 exclusion added in #25651 also made DroneCAN
peripherals assigned those node IDs unreachable via MAVLink params.
This preserves #25651's intent for real MAVLink cameras while
unblocking DroneCAN devices in that ID range.
Fixes#27180
* fix(mavlink): warn when camera shadows DroneCAN node in 100..105
Emit a one-shot mavlink_log_warning per comp ID when both a MAVLink
camera (observed via camera_status / MAV_TYPE_CAMERA heartbeat) and a
DroneCAN node (via dronecan_node_status) are present at the same ID
in 100..105. The camera takes precedence at the UAVCAN parameter
bridge (intent of #25651), so the CAN node's params become unreachable
via MAVLink. The warning surfaces the ambiguity in QGC's message tray
so the user can reassign the CAN node ID.
Fires regardless of which side joined first. Sticky per comp ID for
the boot — the user only sees it once per conflicting ID.
* Update src/modules/mavlink/mavlink_parameters.cpp
* Update src/modules/mavlink/mavlink_parameters.cpp
Onur Özkan
PX4BuildBot
Marco Hauswirth
Ryan Johnston
Ramon Roche
Eric Katzfey
mahima-yoga
Phil-Engljaehringer
remi22
Julian Oes
Hamish Willee
Valentin Bugrov
Matthias Grob
dependabot[bot]
Silvan
alexcekay
Jacob Dahl