* feature(new-mode): Add new parking mode
This mode is an extension of the manual mode.
It is to be used to manoevre platforms precisely in tight spaces, such as when parking rovers or when docking a boat.
It is designed to be used with a joystick and allows for precise control of the vehicle's position and orientation.
* feat(rover): implement manual parking modes and add docs
* fix(rover): move from percent based to normalized max throttle in manual parking mode
* fix(rover): improve parking mode description in docs
---------
Co-authored-by: Michael Fritsche <frimi999@gmail.com>
The ROI forwarding path only needs GIMBAL_MANAGER_STATUS from an external
manager: it provides discovery (manager sysid/compid, gimbal device id) and
control ownership. GIMBAL_MANAGER_INFORMATION only added capability flags and
angle limits, which nothing uses until RC forwarding (deferred).
Carrying the extra uORB topic and its receiver handler pushed the tightest
board variant over its flash budget (ark_pi6x_encrypted_logs overflowed by
500 bytes). Drop the external_gimbal_manager_information topic; discovery and
ownership come from the status topic. It can return with RC, which actually
needs the angle limits.
Signed-off-by: Julian Oes <julian@oes.ch>
Add an output mode (MNT_MODE_OUT[2]=3) that makes PX4 act as a gimbal
manager client rather than driving a gimbal device: it discovers an
external gimbal manager from the awareness topics, requests primary
control via DO_GIMBAL_MANAGER_CONFIGURE while there is an active setpoint,
and streams the computed pitch/yaw as GIMBAL_MANAGER_SET_PITCHYAW.
This lets a smart camera-gimbal that runs its own manager still be pointed
by PX4's ROI/mission logic: PX4 does the geo-pointing (reusing the same
OutputBase math as the v2 device output) and forwards the resulting
pitch/yaw, using the standard MAVLink gimbal manager messages.
Control ownership follows the spec: it changes only via acquire/release,
and control is released on an idle (neutral) setpoint so a ground station
can take over. While this mode is selected PX4 no longer advertises itself
as the gimbal manager, since it is a client of the external one.
RC forwarding (GIMBAL_MANAGER_SET_MANUAL_CONTROL) and vehicle-yaw-assisted
ROI are intentionally left for follow-ups.
Signed-off-by: Julian Oes <julian@oes.ch>
PX4 today only produces GIMBAL_MANAGER_INFORMATION/STATUS (as its own gimbal
manager); it has no way to learn about a gimbal manager running on another
component. To interoperate with an external gimbal manager (e.g. a smart
camera-gimbal that runs its own manager), PX4 needs to discover it and track
who currently controls it.
Decode incoming GIMBAL_MANAGER_INFORMATION and GIMBAL_MANAGER_STATUS from
other components into the new external_gimbal_manager_information and
external_gimbal_manager_status uORB topics, carrying the manager's sysid and
compid from the message frame. Messages originating from our own
system/component are ignored so we don't ingest our own streamed manager
messages.
This is the awareness layer that a gimbal-manager client output builds on.
Signed-off-by: Julian Oes <julian@oes.ch>
* fix(navigator): report a failed geofence load instead of leaving a fragment
_updateFence() resets _num_polygons and rebuilds the fence from dataman one
polygon at a time. It can stop early two ways: loadWait() failing for an entry,
or the array resize failing to allocate. Both logged to the console and left
whatever had been loaded so far in place.
A fragment of a fence is worse than no fence. Missing inclusion polygons permit
positions the fence excluded, missing exclusion polygons open up areas it
protected, and unlike an empty fence it still looks to the operator like a fence
is loaded.
Drop what was loaded on either failure and report it with mavlink_log_critical
and an event, so the state is unambiguous and the operator is told the fence is
not active rather than finding out in flight.
Reported by @lihnucs, who found the allocation path.
Assisted-by: Claude:claude-opus-5[1m]
Signed-off-by: Julian Oes <julian@oes.ch>
* rework(navigator): use _clearFence in ~Geofence()
* refactor(navigator): move new functions in hpp
* fix(navigator): pub GF_STATUS_FAILED when _updateFence fails and ensure GF is reloaded if previously failed with new request with same opaque id
* refactor(navigator): remove redundant check
* feat(msg): add GF_STATUS_FAILED to GeofenceStatus.msg
* refactor(navigator): rename _fence_updated to _fence_loaded
The flag now means the requested fence was loaded successfully, and
"updated" reads like a uORB or dataman change. Default it to false
since nothing is loaded at boot.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julian Oes <julian@oes.ch>
---------
Signed-off-by: Julian Oes <julian@oes.ch>
Co-authored-by: jonas <jonas.perolini@rigi.tech>
* fix(msg): correct comments regarding default values
The mentioned defaulting happens in
FwLateralLongitudinalControl::updateLongitudinalControlConfiguration,
where they clearly default to the climb / sink rate _setpoint_, not the
respective maximum.
No new message version needed as only comment is changed.
* fix(msg): correct stale publisher reference in FixedWingLateralGuidanceStatus
fw_pos_control was split into fw_mode_manager and
fw_lateral_longitudinal_control; the topic is published by
the mode manager.
* feat(gps): log GNSS info from UBX_MSG_MON_SPAN and UBX_MON_RF for improved GNSS debugging capabilities.
Introduction of two new uorb messages to log the content of UBX_MSG_MON_SPAN and UBX_MON_RF on a per-band level per receiver.
Gated behind Kconfig GPS_UBX_SPAN and new parameter GPS_UBX_SPECTRUM.
* feat(gps): deactivate Kconfig option GPS_UBX_SPAN by default
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
* feat(gps): update submodule
* chore(gps): remove unnecessary comment and whitespace
* feat(boards/px4_fmu-v6c): activate CONFIG_GPS_UBX_SPAN
---------
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
* feat(navigator): precision takeoff with the vision target estimator
* fix(navigator): only remove the liftoff freeze when an actual target is detected
* feat(logger): log prec_takeoff_status as optional topic
* chore(vte): minor format
* fix(logger): move to topic behind CONFIG_MODULES_VISION_TARGET_ESTIMATOR
* fix(navigator): preserve corrected position on takeoff handoff
* docs(vte): rephrase VTE_AID_MASK
* rework(vte): clarify that home is used as the pad's abs position during prec takeoff
* fix(vte): clear cached relative mission position once task starts
* fix(takeoff): keep xy freez until TAKEOFF_STATE_FLIGHT
* feat(navigator): delay prec takeoff corrections by MIS_TKO_PREC_DLY
---------
Co-authored-by: jonas <jonas.perolini@rigi.tech>
* feat(mavlink): stream manual input status which specifies the active source for manual control setpoint generation on the autopilot
---------
Signed-off-by: RomanBapst <bapstroman@gmail.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Co-authored-by: Matthias Grob <maetugr@gmail.com>
* fix(commander): scale mag cal offset limit with sensor full-scale range
The hard 1.3 Ga offset limit assumes ~1.9 Ga full scale, so modern mags (5-49 Ga full scale) fail calibration on large hard-iron offsets they can measure without saturating.
Drivers now report their range in sensor_mag and the limit becomes range minus
0.65 Ga worst-case earth field, keeping the 1.3 Ga fallback when the
range is unknown.
* fix(drivers): correct ADIS16448 and AK8963 mag ranges
* refactor(sensors): address review comments
- kConstant cal limits
- uT conversion helper
unitName()/typeName() lacked the FAILURE_UNIT_DATALINK_*/FAILURE_UNIT_BUS_* units, so `failure can off` was announced as unit "unknown". FailureInjection.msg and VehicleCommand.msg also disagreed on FAILURE_TYPE_DRIFT (MAVLink FAILURE_TYPE 8).
Name every unit and type, add FAILURE_TYPE_DRIFT to both messages and the `failure` console command, and add a test that fails whenever a message constant has no name.
Run() published heater_status at both GPIO edges, 200 Hz for a 100 Hz
controller, and the default log profile recorded it at full rate. At
100 % duty the off phase ran with a zero delay, so the element was
switched off and back on every period and heater_on read false for that
instant. heater_current and supply_voltage were battery_status.current_a
and voltage_v, already logged there, and nominal_multiplier read 0 unless
HEATERn_NOM_V compensation was active.
The off phase no longer publishes and is skipped at full duty; the status
goes out once per controller cycle with heater_on meaning the element is
driven this period. The two battery fields are removed (the voltage is
still read for the V_nom compensation), nominal_multiplier is 1 when no
scaling is applied, and heater_status is logged at 1 Hz by default.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* feat(uavcan): parse STATUS_FLAG_CHARGING from BatteryInfo
- Map UAVCAN STATUS_FLAG_CHARGING to uORB STATE_CHARGING
- Cover both Raw and Filter data paths
- Enables MAVLink BATTERY_STATUS.charge_state to report CHARGING(7)
* refactor(msg): rename STATE_UNHEALTHY/STATE_CHARGING to WARNING_UNHEALTHY/WARNING_CHARGING
Rename for naming consistency: these enum values belong to the
'warning' field, so they should use the WARNING_ prefix like the
other values (WARNING_NONE, WARNING_LOW, etc.).
Also fix @enum annotation from 'WARNING STATE' to 'WARNING'.
* fix(land_detector): latch rotational_movement between publications
* fix(land_detector): latch all purely diagnostic flags
such that we don't have to publish on every change e.g. every movement threshold corssing but still see the least land detection friendly state per publish period.
---------
Co-authored-by: Matthias Grob <maetugr@gmail.com>
* feat(sensors): decouple sensor internal/external classification from the bus
A sensor's internal/external classification was derived from its bus
(px4_i2c_bus_external / px4_spi_bus_external), but a bus is a wire: one bus
routinely serves both chips soldered on the FC and a pinned-out connector, and
any onboard sensor on such a shared bus was classified external. That hands an
onboard mag an operator-settable rotation instead of the board rotation, feeds
an onboard baro's self-heated die temperature into air density as if it were
ambient, and inverts the 75/50 default priority. FMU-v6C and AirBrainH743
worked around it with hand-rolled device_id whitelists behind
BOARD_OVERRIDE_I2C_DEVICE_EXTERNAL; FMU-v6XRT's second onboard baro was simply
misclassified.
Classify the device instead of the bus: drivers publish is_external in
sensor_accel/gyro/mag/baro, derived from the device id by default and
overridden by the new -O start flag ("onboard") for onboard sensors that share
a bus with an external connector. -I/-X stay pure bus probe filters.
The question "is this sensor external" had four answers. It now has one, with
a single override point:
-O -> I2CSPIDriverConfig::external -> Device::set_external() and the
PX4* wrappers -> is_external in the sensor topic
px4_i2c_device_external() was px4_i2c_bus_external() with a device id decode in
front, and calibration::DeviceExternal() forwarded to device_is_external();
both are gone. Device::external() stops being a bus query: it is non-virtual,
defaults to device_is_external(), and takes the declared value through
set_external(), so the five I2C/SPI overrides that used to answer it from the
bus are deleted and cannot diverge again. device::I2C and device::SPI set it
from the config, so every driver built on the bus framework follows -O without
doing anything. px4_i2c_bus_external() and px4_spi_bus_external() survive as
what they honestly are - bus predicates - reachable only through the fallback.
-O is opt-in per driver (BusCLIArguments::support_onboard), the same way -k is:
a flag that every driver advertised but only a handful honoured would be a
silent no-op on the rest. This also drops the special case for the mcp23009 and
mcp23017 GPIO expanders, which use -O for their output state and simply do not
opt in.
sensor_gyro_fifo carries is_external too. VehicleAngularVelocity prefers the
FIFO topic for any IMU that publishes one, so without it the rate controller
would take its rotation from the bus while VehicleIMU took it from the topic -
the same chip, two classifications.
The BOARD_OVERRIDE_I2C_DEVICE_EXTERNAL hook is removed along with both board
implementations, replaced by -O on the affected rc.board_sensors lines.
FMU-v5x, MR-CANHUBK3, KakuteF7, NXT-Dual and MicoAir H743-Lite each start an
onboard barometer on an external bus and get the flag as well.
Assisted-by: Claude:claude-fable-5, Claude:claude-opus-5[1m]
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* feat(sensors): treat shared buses as first-class topology
A boolean internal/external flag cannot describe a bus that carries both
hard-mounted chips and a connector. -O was an opt-in override for that
case, so most drivers silently ignored it and classification still
followed the bus.
Declare Internal / External / Shared on the bus, probe External and
Shared, and classify each sensor from -I/-s vs -X/-S.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* fix(ci): drop stale ITCM symbols and clang-tidy errors
ITCM lists still named calibration::DeviceExternal and
px4_spi_bus_external after both were removed. The host test stubs
forwarded varargs in a way the analyzer rejected, and stripped I2C
headers kept extra trailing newlines.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* fix(sensors): inline device_is_external into the header
Reaching it through drivers__device pulled the kernel-only library into
the userspace image of a protected build; giving it a library of its own
put an archive referencing px4_i2c_buses/px4_spi_buses after the board
library that defines them. Inlining sidesteps both.
* fix(sensors): compile tcbp001ta and probe canhubk3 GPS mag
tcbp001ta is not an I2CSPIDriver, so config.external does not exist; it
only ever starts on internal SPI. -X on canhubk3 I2C2 never ran because
that bus is Internal.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
---------
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* fix(drivers/imu): clip FIFO samples against the declared range, not the int16 rail
updateFIFO() counted a sample as clipped only within 1 LSB of INT16_MIN
or INT16_MAX, while update() compares against _clip_limit (range/scale).
The two agree only for sensors whose sensitivity is exactly range/32768.
ST parts leave headroom in the word: the LSM6DSV80X high-g channel at
+/-80 g and 3.904 mg/LSB saturates at 20492 counts, its gyro at
+/-4000 dps and 140 mdps/LSB at 28571, the LSM9DS1 and ADIS16607 are
similar, and the BMI055's 12-bit accel word never reaches the rail at
all. None of them could report a clip on the FIFO path, so the EKF's
delta-velocity clipping handling never engaged on those sensors.
Compare against _clip_limit on the FIFO path as well. For rail-scaled
sensors the threshold moves from 32766 to 32735 counts (the existing
0.999 margin), which is what the non-FIFO path already used.
* docs(msg): SensorGyroFifo/SensorAccelFifo counts are raw, not SI
x/y/z are int16 counts; SI is count * scale. The comments called them
rad/s and m/s^2, which is what sensor_gyro/sensor_accel carry.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
---------
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Both the Navigator and the mode manager decided when the climbout was over,
each by comparing an altitude of its own. They only agreed because they read
the same number.
Report the end of the climbout from the mode manager and act on it in
the Navigator, so that it is decided in one place. No behaviour change with
the default parameters.
Signed-off-by: mahima-yoga <mahima@auterion.com>
* feat(gps): Galileo HAS mode for the ZED-X20P and GPSDrivers bump
GPS_UBX_MODE 8 selects the new UBXMode::GalileoHAS. The receiver only
processes HAS while host corrections are off, which makes RTCM and SPARTN
from the autopilot dead input, so it is an explicit mode rather than a
default and the description says what it gives up.
The submodule bump also brings UBX-SEC-SIG jamming state for F9 HPG 1.51
and X20, where the MON-RF flag is deprecated and always 0, and stops the
F9P-L1L2 path from warning about a missing jamming monitor on 1.51.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* feat(sensor_gps): report the correction protocol, not just RTCM status
The u-blox driver now reads UBX-RXM-COR, which covers RTCM3, SPARTN and
Galileo HAS, so rtcm_msg_used and rtcm_crc_failed no longer describe
only RTCM. They become corrections_msg_used and corrections_crc_failed,
and corrections_protocol says which protocol the last message was: the
only receiver-side confirmation that a SPARTN stream or HAS is actually
being consumed, and the first time either field has moved on an X20.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
---------
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* feat(failure_injection): add ADS-B traffic-avoidance failure injection
Wire up FAILURE_UNIT_SYSTEM_TRAFFIC_AVOIDANCE (107) for the MAVLink-based
traffic avoidance path:
- OFF suppresses and STUCK freezes the incoming transponder_report, applied
both at the MAVLink ADS-B ingestion (handle_message_adsb_vehicle) and at
the navigator consumer (check_traffic), so it works for real ADS-B over
MAVLink, simulated ADS-B and the fake_traffic command.
- OFF additionally marks the ADS-B/FLARM heartbeat unhealthy so the traffic
avoidance system health check fails, using a message-less process()
overload.
- Add the unit to the capability catalogue (OK/OFF/STUCK), the failure
console command, the RC-switch unit selector and the docs.
The matching MAVLink FAILURE_UNIT enum entry lives in the mavlink submodule
(common.xml) and is handled by a separate PR; the uORB mirrors in
VehicleCommand.msg and FailureInjection.msg are included here.
* feat(failure_injection): enhance battery failure injection with severity levels
* feat(failure_injection): improve battery failure handling with dynamic threshold parameters
* refactor(failure_injection): remove traffic avoidance example from documentation
* docs(docs): subedit
* feat(failure_injection): add variance setting for distance sensor and integrate rangefinder in simulator
* feat(docs): add failure injection to release notes
* docs(docs): Add sim_mavlink back to heading
* fix(failure_injection): update default battery failure injection severity to Emergency
* docs(docs): get away from footnotes
* feat(failure_injection): enhance battery failure injection handling and update traffic unit support
* feat(failure_injection): add traffic avoidance handling tests and configurations
* [AUTO COMMIT] update EKF change indication
See .github/workflows/checks.yml for more details
* Apply suggestion from @hamishwillee
* feat(failure_injection): update failure types and handling for traffic avoidance and ESC telemetry
* fix(typo)
* [AUTO COMMIT] update EKF change indication
See .github/workflows/checks.yml for more details
* fix(docs): clarify notes on GPS and airspeed handling in failure injection documentation
---------
Co-authored-by: Claudio Chies <chiesc@chies.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* feat(fueltank): support multi-fueltanks by changing supscription from single- to multi-instance
use fuel_tank-id instead of node_id to allow multible fuelt_tanks per cannnode.
Add a WEIGHT_FUEL parameter for the mass of a full fuel load. When set,
the weight used for trim throttle, min/stall airspeed, and climb/sink
rate scaling is reduced by the burned fuel mass derived from
fuel_tank_status (filtered to reject sloshing). Disabled by default.
* feat: track Node updates
* feat: prevent arming while updating
* fix: used make format
* fix: added dedup logic & use dynamic list
* fix: cleaned up arming_blocker
* feat: add circuit breaker for arming_blocker
* chore: used make format
* fix: fix some formating issues
* chore: make format again
* fix: implemented requested changes
* feat(camera_feedback): gate CAMERA_IMAGE_CAPTURED by param
Some cameras implementing the MAVLink Camera Protocol (e.g. reached via
TRIG_INTERFACE=MAVLink) report CAMERA_IMAGE_CAPTURED themselves. The
autopilot's camera_feedback also emitted this message, so the ground
station saw duplicate capture messages for every shot.
Add a bool 'report' field to the camera_capture message, set from the new
CAM_CAP_REPORT parameter, and gate the CAMERA_IMAGE_CAPTURED stream on it.
When reporting is disabled the capture is still published and logged for
geotagging; only the MAVLink message to the ground station is suppressed.
CAM_CAP_REPORT applies live (no reboot); it only gates a MAVLink message,
unlike CAM_CAP_FBACK which reconfigures the capture pin.
* fix(camera_feedback): update docs
* 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>
Build all targets / Scan for Board Targets (push) Has been cancelled
Build all targets / Seed [${{ matrix.chip_family }}] (push) Has been cancelled
Build all targets / Build [${{ matrix.runner }}][${{ matrix.group }}] (push) Has been cancelled
Build all targets / Upload Artifacts (push) Has been cancelled
Checks / Gate Checks [check_format] (push) Has been cancelled
Checks / Gate Checks [check_newlines] (push) Has been cancelled
Checks / Gate Checks [module_documentation] (push) Has been cancelled
Checks / Gate Checks [shellcheck_all] (push) Has been cancelled
Checks / Gate Checks [validate_module_configs] (push) Has been cancelled
Checks / Unit Tests (push) Has been cancelled
MacOS build / build (push) Has been cancelled
Ubuntu environment build / Build and Test (ubuntu:22.04) (push) Has been cancelled
Ubuntu environment build / Build and Test (ubuntu:24.04) (push) Has been cancelled
Container build / Set Tags and Variables (push) Has been cancelled
Container build / Build Container (amd64) (push) Has been cancelled
Container build / Build Container (arm64) (push) Has been cancelled
Container build / Deploy To Registry (push) Has been cancelled
Failsafe Simulator Build / build (failsafe_web) (push) Has been cancelled
ITCM check / Checking nxp_mr-tropic (push) Has been cancelled
ITCM check / Checking nxp_tropic-community (push) Has been cancelled
ITCM check / Checking px4_fmu-v5x (push) Has been cancelled
ITCM check / Checking px4_fmu-v6xrt (push) Has been cancelled
ROS Integration Tests / build (push) Has been cancelled
ROS Translation Node Tests / Build and test [humble] (push) Has been cancelled
ROS Translation Node Tests / Build and test [jazzy] (push) Has been cancelled
SITL Tests / Testing PX4 iris (push) Has been cancelled
Docs - Orchestrator / T1: Detect Changes (push) Has been cancelled
Docs - Orchestrator / T2: Metadata Sync (push) Has been cancelled
FLASH usage analysis / Analyzing px4_fmu-v5x (push) Has been cancelled
FLASH usage analysis / Analyzing px4_fmu-v6x (push) Has been cancelled
Python CI Checks / build (push) Has been cancelled
Sync ROS 2 messages to px4_msgs / sync_to_px4_msgs (push) Has been cancelled
Docs - Orchestrator / T2: PR Metadata (push) Has been cancelled
Docs - Orchestrator / T2: Link Check (push) Has been cancelled
Docs - Orchestrator / T3: Build Site (push) Has been cancelled
Docs - Orchestrator / T4: Deploy (push) Has been cancelled
FLASH usage analysis / Publish Results (push) Has been cancelled
Static Analysis / Clang-Tidy (push) Has been cancelled
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.
Andrea Bernasconi
yannickpoffetandMichael Fritsche
Silvan
Julian Oes
Hamish Willee
Balduin
Thomas StauberandJacob Dahl
Jonas Peroliniandjonas
Mahima Yoga
Claudio Chies
Freey0
Anil KircalialiandMatthias Grob
Marin D
Phil
Alex KlimajandJacob Dahl
Beat Küng