* feat(gps): inject SPARTN corrections alongside RTCM
Add a SPARTN transport-layer framer and feed gps_inject_data through both
RTCM3 and SPARTN parsers so PointPerfect-style SPARTN streams can be
reassembled and written to the receiver the same way RTCM already is.
Gated by CONFIG_GPS_SPARTN (default on). Disabled on px4_fmu-v6x where
flash is already at the limit; enabled on ark_can-rtk-gps.
Depends on PX4-GPSDrivers for automatic u-blox SPARTN input enable.
Signed-off-by: alexklimaj <alex@arkelectron.com>
* fix(gnss): avoid undefined shift in SPARTN CRC-32
Use uint64_t for the CRC working register so n==32 does not perform
1u << 32 (clang-analyzer BitwiseShift).
Signed-off-by: alexklimaj <alex@arkelectron.com>
* make format
* feat(gps): enable SPARTN support in board configurations
* feat(gps): enhance SPARTN support with additional frame tracking and status reporting
* fix(gps): frame RTCM3 and SPARTN from a single buffer
Feeding every inject chunk to an independent framer per protocol let each
one resync inside the other's payloads. That is not symmetric: RTCM3 is
covered by CRC-24Q, but SPARTN's header carries no usable integrity check
(TF006 is 4 bits over a non-byte-aligned field) and TF005 permits an 8-bit
message CRC, so a stray 0x73 in an RTCM3 payload is framed as SPARTN at
roughly 1 in 1024.
RTCM3-only is what every board actually runs, and over 50 MB of it the two
framers produced 211 bogus SPARTN frames (210 declaring CRC-8), each
re-injecting up to 1 kB of the stream back into the receiver. The reverse
direction produced none.
Frame both protocols from one buffer instead: whichever preamble comes
first is framed, and a valid frame consumes its own payload, so bytes
inside one protocol's frame never start the other's. The same 50 MB now
yields zero. Frames are also injected in arrival order rather than all
RTCM3 then all SPARTN, and one buffer replaces two (2248 B/instance,
down from ~4350 B).
Also reject TF002 message types 5-119, which SPARTN reserves, as the one
header field with a checkable range.
CONFIG_GPS_SPARTN was default y, so it built into every target with a GPS
including px4_fmu-v6x, which the flash report showed gaining the framer
despite the intent to keep it off. Default it to n and enable it explicitly
where it is wanted; the ark GPS boards already opt in, and SITL opts in so
the framing tests keep running in CI.
Rtcm3Parser and SpartnParser are replaced by CorrectionFramer; their tests
carry over to it. RtcmStress fed "garbage" drawn from 0x01-0xD2 to avoid a
preamble, which includes 0x73, and RtcmBustedSender ended its stream on a
candidate the framer was still waiting to complete; both now avoid every
preamble and flush respectively.
* feat(gps): enable SPARTN on ARK flight controllers
Covers receivers attached over UART rather than CAN. All four targets
link with margin; fmu-v6xrt has no px4board on this branch yet.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
---------
Signed-off-by: alexklimaj <alex@arkelectron.com>
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* fix(gps): split RTCM corrections and moving-baseline uORB topics
The single gps_inject_data topic served two unrelated purposes:
external fixed-base RTCM corrections (from MAVLink GPS_RTCM_DATA or
UAVCAN RTCMStream) and moving-base-to-rover RTCM 4072. In a
dual-GPS-with-moving-base plus fixed-base setup, the two streams
collided on the same queue and the FMU UAVCAN bridge mirrored
fixed-base RTCM onto the MovingBaselineData CAN message, breaking
rover heading or RTK fix (see PX4/PX4-Autopilot#27088).
Split by role:
- rtcm_corrections (renamed from gps_inject_data): external RTCM
flowing into the vehicle; producers are
MAVLink, UAVCAN RTCMStream, and GPS drivers in
dump mode.
- rtcm_moving_baseline (new): moving-base GPS output intended for a
rover; single producer per vehicle
(MAX_INSTANCES = 1).
The GPS driver routes its own RTCM output to the right topic via
GPSHelper::isMovingBase(), and gates the two inbound streams per role
using new GPSHelper virtuals (PX4-GPSDrivers#212):
shouldInjectRTCMCorrections() is true for any configured receiver, so a
UART2 moving-base rover still accepts fixed-base corrections over its
main link; shouldInjectMovingBaseline() is true only for a UART1/CAN
heading rover, since a UART2 rover gets the baseline directly in
hardware and a moving base produces rather than consumes it. That
submodule PR also renames the ambiguous UBXMode fields to name their
UART explicitly (RoverWithMovingBase -> RoverWithMovingBaseUART2,
MovingBase -> MovingBaseUART2).
Septentrio's publish_rtcm_corrections() always publishes to
rtcm_moving_baseline (only the Secondary moving base calls it).
Rover-side consumers (gps, septentrio, uavcan bridge) drain both topics
independently; each topic gets its own stale-link switchover timer so
corrections failover is not suppressed by moving-baseline traffic, or
vice versa.
FMU UAVCAN bridge: two independent drain loops, one per topic. No
more dual-publish of a single uORB message onto both RTCMStream and
MovingBaselineData CAN streams.
CANnode MovingBaselineDataPub subscribes to rtcm_moving_baseline. The
bus_type == UAVCAN check is kept, now purely as a loop guard so a node
with both CANNODE_PUB_MBD and CANNODE_SUB_MBD does not rebroadcast a
peer's moving-baseline data back onto the bus. CANnode RTCMStream
subscriber maps each CAN source node ID to its own rtcm_corrections
instance (one PublicationMulti per source, capped at MAX_INSTANCES) so
multiple CAN RTCM sources (e.g. dual rovers outputting MSM7 for logging
plus a fixed-base feed) land on independent uORB instances instead of
interleaving on one, which would otherwise defeat the consumer's
per-instance stale-link selection.
Depends on PX4-GPSDrivers#212 (submodule bump included).
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* fix(gps): use separate RTCM parsers for corrections and moving baseline
On a rover injecting both fixed-base corrections and moving-baseline RTCM, feeding both streams through a single parser allowed a fragmented frame from one source to be corrupted by bytes interleaved from the other. Reassemble each stream in its own Rtcm3Parser so frames are recovered independently.
Also collapse the two near-identical topics into a single RtcmData.msg published under both rtcm_corrections and rtcm_moving_baseline (the SensorGps pattern), track corrections and moving-baseline injection on separate perf counters so the reported corrections rate is no longer inflated by moving-baseline traffic, and zero-initialize the CAN DeviceId unions before populating their fields.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* fix(septentrio): avoid bugprone sizeof division on RTCM byte buffer
moving_baseline.data is a uint8_t array, so sizeof(data)/sizeof(data[0]) divides by 1; clang-tidy's bugprone-sizeof-expression flags this as a suspicious sizeof(T)/sizeof(T). Use sizeof(data) directly - the capacity value is unchanged.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* refactor(gps): use dedicated per-stream RTCM drain functions
rtcm_moving_baseline has a single publisher (instance 0), so its
consumers are now a plain uORB::Subscription instead of a 4-instance
SubscriptionMultiArray, and the per-stream selected-instance and
stale-link timer members it no longer needs are removed.
With each RTCM stream now a fixed type with a single caller, the
templated drain helpers (drain_rtcm_subscriptions, the overloaded
drain_rtcm_to_can) bought nothing, so replace them with dedicated
functions: drainRtcmCorrections()/drainMovingBaseline() in the GPS
driver and the UAVCAN bridge, drain_rtcm_corrections()/
drain_moving_baseline() in Septentrio. The UAVCAN bridge calls
PublishRTCMStream/PublishMovingBaselineData directly instead of through
Forward lambdas.
Rename SeptentrioDriver::publish_rtcm_corrections() to
publish_moving_baseline(): it is only reached from the Secondary
moving-base decode path and only ever emits moving-baseline RTCM.
Corrections-path behavior (instance selection, generation-gap warning,
burst cap, self-injection filter) is unchanged.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* refactor(gps): rename RTCM inject gate to receiverReady and simplify chunk helper
Rename GPSHelper::shouldInjectRTCMCorrections() to receiverReady(). The
virtual gates injection of both RTCM corrections and moving-baseline, and
for UBX it simply reports whether the receiver is configured, so the name
now describes what it actually gates rather than implying it only concerns
corrections. Bumps the GPS-drivers submodule to the matching rename.
Drop the vestigial message-type template parameter from publish_rtcm_chunks:
both topics share rtcm_data_s, so only the publication type needs templating.
* fix(septentrio): log dropped RTCM uORB generations
Match the gps driver and warn when the RTCM corrections or moving-baseline
subscription skips a uORB generation, so dropped injection data is visible.
* docs(docs): Docs only update to the RtcmData msg
* chore(gps): pin GPSDrivers to merged main
Contains #212 (RTCM/moving-baseline gating virtuals), #213 (X20 CFG-ODO
NAK tolerance), and #215 (SPARTN input enable, best-effort VALSET).
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* fix(septentrio): reassemble RTCM frames per stream before injecting
Both drains wrote raw uORB chunks to the receiver, so a fragmented frame
on one stream could get the other stream's bytes spliced in mid-frame and
corrupt both. Reassemble each stream in its own parser and only write
complete frames, mirroring the gps driver. Injection stats now count
frames instead of uORB chunks.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* refactor(mavlink)!: remove GPS_RTCM_DATA output stream
GPS_RTCM_DATA is a GCS-to-vehicle correction transport; echoing
rtcm_corrections back out over MAVLink had no consumer and the echo was
lossy anyway (uint8 len and 180-byte payload truncate 300-byte uORB
chunks). Receiving GPS_RTCM_DATA is unchanged.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
---------
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* fix(zenoh): generate the topic catalog into the build tree
Kconfig.topics is fully generated from the uORB message set, but the build
regenerated it into the source tree at configure time. Building any Zenoh
board therefore left the working tree dirty whenever the message set had
changed since the file was last committed (the catalog is board-config
dependent, so it drifts easily).
Generate the catalog into the build directory in cmake/kconfig.cmake, before
Kconfig is parsed, and source it from there via ZENOH_KCONFIG_TOPICS. It is
generated board-independently from every message so it no longer depends on
the msg-gating Kconfig symbols it is sourced alongside; the per-board factory
still gates which topics are actually compiled. Drop the committed catalog.
* chore(zenoh): bump zenoh-pico to the build-tree header fix
Moves zenoh-pico's generated config.h/zenoh-pico.h/library.json out of its
own source tree and into the build tree, so building no longer dirties the
submodule.
Gated on PX4/zenoh-pico#2: the pointer currently references the fix branch on
a fork and must be moved to the merged commit before this is ready.
* bump zenoh-pico
* feat(failure_injection): integrate failure injection support across sensor drivers
* feat(failure_injection): enhance failure injection with RC switch support and instance bitmasking
feat(failure_injection): add disabled failure injection manager and system command support for v5x and v6x boards
* feat(failure_injection): add battery failure injection
Add a value-mutating apply-site for FAILURE_UNIT_SYSTEM_BATTERY. On an
injected OFF the outgoing battery_status is reported as a depleted pack
(zero remaining, emergency warning) so the low-battery failsafe triggers.
The apply-site lives in the shared Battery library, covering the analog
ADC, INA power monitors, ESC battery and SITL in one place, plus the
UAVCAN battery driver which publishes battery_status directly. The
previous SITL-only hack in BatterySimulator is removed in favour of this
shared path so simulation and hardware behave identically.
* fix(failure_injection): change parameter types from int32 to enum
* refactor(failure_injection): disable failure injection manager and system commands across multiple boards
* feat(failure_injection): enhance failure injection with timestamp handling and message-less support
* refactor(failure_injection): simplify has_timestamp_sample implementation and remove unused includes
* refactor(failure_injection):move conditional compilation into helper libary
* refactor(failure_injection): update CMakeLists to include failure_injection dependency across multiple drivers
---------
Co-authored-by: Claudio Chies <chiesc@chies.com>
The cdrstream uORB->IDL->CDR codegen floods the build log with noise:
- CycloneDDS idlc warns once per carried-over .msg comment that the
@verbatim annotation is unsupported (VehicleCommand alone emits 153).
Pass -Wno-unsupported-annotations via the idlc_generate WARNINGS list.
- rosidl_adapter prints a Reading/Writing line per message to stdout.
Filter those in msg2idl.py via builtins.print rather than redirecting
stdout, which the empy template engine breaks on. Errors still go to
stderr.
* feat(navigator): extend detect and avoid module to follow regulatory standards such as ASTM F3442
* docs(docs): minor subedit
* refactor(navigator): reduce flash by grouping notif into same events
* docs(daa): Improve docs readability with ::: details blocks
* fix(navigator): single event when on ground with conflict
* refactor(boards): increase flash length from 4M - 128k to 5M - 128k
* rework(general): define DAA standard at build with new CONFIG_NAVIGATOR_ADSB_F3442
* clean(navigator): minor changes to clean the PR
* feat(boards): add CONFIG_NAVIGATOR_ADSB_FAKE_TRAFFIC in visionTargetEstStatic.px4board
* rework(daa): reduce amount of abstractions and minor cleaning
* refactor(boards): allyes revert flash length to 4M-128K
* refactor(boards): allyes increase flash length to 5M-128K
* rework(daa): rework event notifications to improve clarity
* docs(docs): move details inside of ::: details block
* docs(docs): run npx prettier
* refactor(daa): avoid void mutator functions
* docs(docs): Improve Python helper to decode daa unique id
* rework(daa): move encoded id handling to the adsb lib and refactor on_active
* refactor(daa): naming and zero init
* fix(daa): move dataman dep from daa level to unit test level
* refactor(daa): define common daa_input and rework process_transponder_report
* fix(daa): remove stale todo
* refactor(daa): rename crosstrack_based_daa to crosstrack_standard
* refactor(daa): rename F34_ params to DAA_
* docs(docs): revert changes to autogenerated docs
* docs(docs): Add Detect And Avoid in index.md
* refactor(daa): update message on init failed
* refactor(daa): only publish most_urgent conflict once in on_active()
* refactor(daa): move conflict buffer handling in the adsb lib
* refactor(daa): move notifications into new class ConflictNotifier and only notify once per cycle
* refactor(daa): uninit _cycle_changes to store into .bss (and save flash)
* docs(docs): remove unused image link
* refactor(daa): move automated action policy to the adsb lib
* refactor(daa): move self detection into adsb lib as DaaTrafficFilter
* refactor(daa): minor changes in unit tests
* refactor(daa): merge DaaTrafficFilter and DaaEncoding
* fix(daa): fix CI by removing navigator from the DAA deps
* refactor(daa): reduce stack size
* fix(daa): advertise _fake_traffic_pub in constructor
* refactor(daa): Comments only, simplify and reduce comments
* fix(daa): brief comment missing end star
* Disable CONFIG_NAVIGATOR_ADSB in ark_fpv_default board
* docs(docs): General clarifications and remove the 1.18 badge
* refactor(daa): cleaning
* refactor(daa): minor cleaning
* refactor(adsb): simplify conflict tracker assuming push_back cannot fail
* build(cmake): cleaner fix to protect regex alternations
* refactor(daa): Crosstrack, remove unit test requiring finite yaw (yaw not used by standard)
* refactor(daa): minor cleaning and fix callsign to uint64
---------
Co-authored-by: jonas <jonas.perolini@rigi.tech>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* feat(driver/heater): Add threshold to prevent the heater from always heating.
It only starts heating if the temperature drops below the specified threshold,
and continues until reset.
Since it's 1:1 reflecting a MAVLink message we better also keep the order otherwise it's less easy to follow.
The "flags" title in the status enum is misleading. Those aren't flags, there can only be one status at a time a uint8 would not even have 12 bits to set.
Switches from using VehicleControlMode to a specific setpoint type message
with reply.
Reasons:
- in case a VehicleControlMode was dropped (e.g. when the mode switched
setpoint type), no confirmation was returned, and resulting in wrong
controller flags.
- cleaner interface separation: external modes do not need to configure
(or know) which controller to run for a certain setpoint
- allows for external modes to check for compatibility: e.g. a mode using
fixed-wing setpoint types can now be rejected on a multicopter.
- allows for further extensions, like a setpoint timeout
This makes it a bit more effort to add a new setpoint type. Specifically,
setpoint_types.cpp needs to be extended when adding a new setpoint message.
PX4 internal modes also make use of the setpoint types. The information
flow is:
nav_state -> setpoint type -> vehicle control mode flags
It also adds a timeout to the setpoint config, but is not implemented
yet.
This changes the interface for external modes and thus the compatibility
version is increased.
* feat(manual_control): trigger RC override on stick velocity
COM_RC_STICK_OV is now a velocity threshold (1/s) instead of a deflection percentage.
Default 3.0, range [1.0, 10.0]. A stick held statically cannot trigger override.
* docs(manual_control): update COM_RC_STICK_OV description for velocity-based override
* feat(manual_control): gate RC override with sign-consistency check
* fix(ManualControl): lower threshold and filter constant for RC override, add tests for MovingDiff
* refactor(commander): merge RC override params into COM_RC_OVR_SPEED
Replace the COM_RC_OVERRIDE bitmask + COM_RC_STICK_OV threshold with a
single float COM_RC_OVR_SPEED (stick override velocity, 0 = disabled).
Override now applies uniformly in auto and offboard modes.
- ManualControl: rename param, treat 0 as disabled (FLT_EPSILON guard)
- Commander: drop the per-mode bitmask gate and the RcOverrideBits enum
- param_translation: migrate COM_RC_OVERRIDE on import (enabled -> 1.0,
disabled -> 0.0) and drop the unit-incompatible COM_RC_STICK_OV value
- docs: collapse the two params into one across the mode pages
* fix(manual_override): Move configuration to manual_control module
with MAN_OVERRIDE_SPD parameter and a negative value disabling the feature. All other logic stays in Commander.
* docs(releases): add release note for RC override rework (MAN_OVERRIDE_SPD)
---------
Co-authored-by: Matthias Grob <maetugr@gmail.com>
Disabled if ICE_IDLE_RPM is 0.
The idle state is entered when the commanded throttle is close to zero
or the measured RPM drops below the idle threshold.
The idle state is exited if the commanded thrust is increased to above
the last needed throttle to keep idle.
Signed-off-by: Silvan <silvan@auterion.com>
Co-authored-by: Silvan <silvan@auterion.com>
* fix(fw_mode_manager/navigator): use the correct switch distance
Before https://github.com/PX4/PX4-Autopilot/pull/24056, the fixed-wing
position controller used to publish the acceptance radius (calculated
depending on params and state by DirectionalGuidance::switchDistance) in
the position controller status.
The refactor migrated that to individual lateral/longitudinal topics,
but left the receiving code in the navigator unchanged. As a
consequence, fixed-wing vehicles now rely on NAV_ACC_RAD for the
acceptance radius, rather than the adaptively calculated switchDistance.
As NAV_ACC_RAD is only 10m by default this leads to overshoot,
especially on tight corners.
Fix by reintroducing the publication (now from FixedWingModeManager
through fixed_wing_lateral_guidance_status) and using it in navigator.
* fix(navigator_main): only listen to position controller status if rover
rover_ackermann is the only remaining publisher after #24056
* style(msg): improve field description
- @INVALID NaN
- Describe relation with NAV_ACC_RAD
* style(fw_mode_manager): remove stale include
* docs(navigator): clarify acceptance logic in param description
The ArmingCheckReply uORB queue was sized to 4 (ORB_QUEUE_LENGTH) while
ExternalChecks supports up to MAX_NUM_REGISTRATIONS (8) external modes,
each of which publishes a reply for every ArmingCheckRequest. With more
than 4 registered modes the replies from the 5th+ mode overwrote earlier
ones within a single request cycle, so those modes were flagged
"unresponsive" and silently failed to activate.
Increase ORB_QUEUE_LENGTH to 8 to match MAX_NUM_REGISTRATIONS, and add a
static_assert so the two limits cannot drift apart again.
Fixes#27271
Signed-off-by: Marko T <marko.tavcar@c-astral.com>
Implements a new GUIDED_COURSE navigator mode that maintains a constant
ground-track bearing, altitude, and airspeed without manual stick input.
The mode is activated via MAVLink and accepts real-time in-flight updates:
- MAV_CMD_GUIDED_CHANGE_HEADING (HEADING_TYPE_COURSE_OVER_GROUND): set course
- MAV_CMD_DO_CHANGE_ALTITUDE: adjust target altitude
- MAV_CMD_DO_CHANGE_SPEED: adjust target airspeed
On activation the vehicle captures its current velocity vector as the
initial course bearing. A valid horizontal velocity estimate (GPS or
dead-reckoning) is required; course commands are rejected if unavailable.
* fix(ekf2): report HAGL variance for dist_bottom_var
dist_bottom_var was published as P(terrain, terrain) only. When the
range finder is the EKF height reference (EKF2_HGT_REF=2), the terrain
state is reset to 0 and not directly observed, so this variance does
not represent the actual uncertainty of dist_bottom (HAGL).
Use ComputeHaglInnovVar(P, 0) to report the proper HAGL variance,
which accounts for terrain state, vertical position state, and their
covariance.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* fix(ekf2): clamp HAGL variance to non-negative
H*P*H^T should be >= 0 for a valid covariance, but float drift or
mildly non-PSD P can produce a tiny negative result. Clamp at the
accessor so consumers of lpos.dist_bottom_var never see a negative
variance.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
---------
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* mavlink: reassemble GPS_RTCM_DATA before GPS injection
* Apply minor comment requested changes
* Simplification: remove _completed_sequence asymetric protection
* Handle RTCM payload length which is an exact multiple of 180
* update docs
* lib gnss: new GpsRtcmMessageFragmenter to send RTCM via GPS_RTCM_DATA.hpp
* fix clang
* Remove RTCM fragmenter
* update docs
* Compatibility fallback for older QGroundControl builds that omit the final zero-length fragment
* mavlink receiver, remove while loop to avoid dead lock
* docs(update): Subedit
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* docs(docs): format
---------
Co-authored-by: jonas <jonas.perolini@rigi.tech>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* feat(crsf_rc): add CRSF receiver bind command
Add ability to initiate CRSF receiver binding from QGroundControl or
the NSH console. When MAV_CMD_START_RX_PAIR is received with
RC_TYPE_CRSF, the driver sends the CRSF bind command frame over UART.
Binding is rejected when armed or on singlewire configurations.
Also adds RC_TYPE and RC_SUB_TYPE constants to VehicleCommand.msg and
replaces magic numbers in DsmRc and RCInput drivers.
Based on PX4/PX4-Autopilot#23294.
* style(crsf_rc): use C++ style comment
* style(crsf_rc): zero-init vcmd, remove noisy comments, drop unused enum value
* fix(rc): check write return value in BindCRSF, guard Spektrum bind against invalid sub-type
* fix(rc): warn and deny invalid Spektrum bind sub-type
Previously, an unrecognized param2 sub-type would silently leave
dsm_bind_pulses at 0 and return the generic UNSUPPORTED ACK. Add an
explicit else-branch that logs a PX4_WARN and returns DENIED so users
get clear feedback in QGC.
* feat(gpsRedundancyCheck): add GPS redundancy failsafe with divergence check
- Monitors GPS count and triggers configurable failsafe (COM_GPS_LOSS_ACT) when count drops below SYS_HAS_NUM_GPS
- Tracks online (present+fresh) and fixed (3D fix) receivers separately; emits "receiver offline" vs "receiver lost fix"
- Detects position divergence between two receivers against combined RMS eph uncertainty plus lever-arm separation
- Pre-arm warns immediately; in-flight requires 2s sustained divergence to suppress multipath false alarms
- Adds GpsRedundancyCheckTest functional test suite
New parameters: SYS_HAS_NUM_GPS, COM_GPS_LOSS_ACT
* feat(sensor_gps_sim): publish second GPS instance using SENS_GPS1 lever arm params
When SENS_GPS1_OFFX or SENS_GPS1_OFFY is non-zero, publish a second sensor_gps instance offset by those values from the vehicle position.
fix(sensor_gps_sim): give second instance distinct device_id
Both simulated GPS instances previously shared the same device_id (address 0x00). This prevented testing the device-ID matching path in SITL since both slots would match the same receiver.
* refactor(gpsRedundancyCheck): address code review feedback
* refactor(gpsRedundancyCheck): address code review feedback
* docs: add GNSS check failsafe documentation
Update safety.md and releases/main.md to document the new GNSS check
failsafe (SYS_HAS_NUM_GNSS, COM_GPS_LOSS_ACT) introduced in PX4.
* docs(update): Subedit to taste
* refactor(gps): move GNSS redundancy detection into sensors module
Add GnssRedundancyStatus topic and GnssRedundancyMonitor in
vehicle_gps_position. Commander's gpsRedundancyCheck becomes a thin
consumer of the new topic. Detection lives with blending/fallback in
one module.
Also rename COM_GPS_LOSS_ACT -> COM_GNSS_LSS_ACT.
* docs(safety): clarify GNSS failsafe wording and rename COM_GNSS_LSS_ACT
* refactor(failsafe): consistent default case as fallback for existing option
* Rename COM_GNSS_LSS_ACT -> COM_GNSSLOSS_ACT
for readability
* fix(gnssRedundancyCheck): move logic back into the commander checks and various improvement suggestions
- Rename to GNSS instead of gps
- Use hysteresis
- Small logic refactorings
- Adapt unit tests to different interface
- User reporting on which GPS is offline or doesn't have a fix
* docs(gnssRedundancyCheck): simplify explanations
* refactor(gnssRedundancyCheck): update year numbers in copyright
---------
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Co-authored-by: Matthias Grob <maetugr@gmail.com>
Extend COM_ARM_ODID into a unified arming + in-flight failsafe parameter (0 = Disabled, 1 = Warning, 2 = Return, 3 = Land, 4 = Terminate)
Values >= 2 block arming and trigger the configured action if Remote ID
is lost while airborne.
The nested CycloneDDS CMake invocation in msg/CMakeLists.txt exists
only to produce the 'idlc' IDL compiler as a host-side code-gen
tool. It does not need CycloneDDS's TLS transport or DDS Security
features, but both default to ON in cyclonedds' upstream CMake.
When ENABLE_SSL=AUTO (the default), cyclonedds finds the system
OpenSSL and builds ddsi_ssl.c. On macos-latest the system OpenSSL
is 3.x, which removed the deprecated SSL_get_peer_certificate()
symbol used in our pinned cyclonedds revision (2023). The host
build then fails at link time with:
Undefined symbols for architecture arm64:
"_SSL_get_peer_certificate", referenced from:
_dds_report_tls_version in ddsi_ssl.c.o
This broke every Zenoh-enabled board build on macOS (boards that
select CONFIG_MODULES_ZENOH pull in LIB_CDRSTREAM, which is what
triggers the nested build). v5 and v6x never hit it because they
don't enable Zenoh.
Passing -DENABLE_SSL=OFF -DENABLE_SECURITY=OFF skips compilation of
ddsi_ssl.c and the security plugins entirely. idlc is unaffected
(pure C code generation, no DDS runtime).
Verified locally on macOS ARM64: clean distclean + make
px4_fmu-v6xrt_default completes in 2090/2090 ninja steps, producing
a 2.1 MB .px4 with 59% FLASH used.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* forwarding offboard setpoints in modes using the external mode registration
* requesting offboard setpoint in RAPTOR
* adding old message versions
* bumping vehicle status
* adding message translations
* updating reference to versioned old message on previous translations
Detects when a rotary-wing vehicle drops more than FD_ALT_LOSS metres
below a NED-z reference while altitude control is active,
and immediately triggers flight termination (parachute deployment).
Detection (FailureDetector):
- FD_ALT_LOSS: drop threshold in metres (0 = disabled, default)
- FD_ALT_LOSS_T: hysteresis time
- Guards: rotary-wing only, altitude control active, z_valid, setpoint
fresh (<1 s). Manual, Acro and FW/VTOL-FW modes are excluded.
- Ratcheting reference: initialises to lpos.z on first sample below
setpoint, preventing false triggers on new waypoints
Failsafe action (commander):
- New fd_alt_loss flag in FailsafeFlags.msg
- COM_ALT_LOSS_ACT: -1=Disabled (default), 0=Terminate
- Terminate fires immediately, cannot be overridden, and never clears
until disarm (parachute deployment is irreversible)
