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>
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.
Jacob Dahl
Freey0
Anil KircalialiandMatthias Grob
mahima-yoga
Claudio Chies
Marin D
Phil
Silvan
Julian Oes
Alex KlimajandJacob Dahl
Beat Küng
Gennaro GuidoneandMatthias Grob
Michael FritscheandSilvan
James CahillandJacob Dahl
msl-dev
Balduin
alexcekay
Marko T