Integrators can declare read-only parameters in a per-board YAML file:
readonly_params.yaml.
There are two ways to define the read-only params:
- "block": default writable, explicitly list params to be locked
- "allow": default readonly, explicitly list params to be writable
Enforcement is activated by `param lock` in rcS after all startup
scripts have run, so board defaults and airframe scripts can still set
params during init.
The feedback via MAVLink uses the new
MAV_PARAM_ERROR_READ_ONLY as part of the PARAM_ERROR message.
* offboard: report specific failures
Figuring out offboard failures is quite difficult because the user currently
gets a single, very generic error message that does not identify the actual
missing requirement.
This change aims to improve the user experience by:
- moving offboard failure reporting into OffboardChecks, where the exact cause is known
- reporting specific arming failures for missing local position, local velocity and attitude estimates
- keeping the generic offboard signal error only as a fallback for true signal-loss cases
- removing the duplicate offboard check from ModeChecks (as already invoked by HealthAndArmingChecks)
Signed-off-by: Onur Özkan <work@onurozkan.dev>
* offboard: handle attitude mode in offboard check
Signed-off-by: Onur Özkan <work@onurozkan.dev>
---------
Signed-off-by: Onur Özkan <work@onurozkan.dev>
The previous logic used GITHUB_HEAD_REF, which on a pull request is
the source (PR author's) branch name. For backport PRs (e.g.
mrpollo/backport-26781-1.17), no matching branch exists in
px4-ros2-interface-lib, so the script fell back to main and the
build broke from uORB message divergence.
Switch to GITHUB_BASE_REF, which on a PR is the branch the code is
being merged into (main or release/X.Y), and fall back to
GITHUB_REF_NAME for direct pushes. This always resolves to a real
branch in px4-ros2-interface-lib.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Adds an explicit Citation section before Governance so researchers can
copy a canonical BibTeX entry without clicking through to Zenodo. Uses
the same author list and concept DOI as CITATION.cff so the citation
always resolves to the latest release. Follows the pattern used by
borglab/gtsam and huggingface/transformers.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Split badges into two rows: release/DOI/Discord on top, and LF-ecosystem
health signals (OpenSSF Best Practices, LFX Health Score, Contributors,
Active Contributors) below. Removed the noisy "Build all targets" badge
and switched the Discord badge from the pixelated widget PNG to the
shields.io SVG endpoint so it renders crisply on HiDPI displays.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Upgrades the project Code of Conduct from Contributor Covenant v1.4
(2016) to v2.1 (2021). v2.1 adds the Enforcement Guidelines section
(Correction / Warning / Temporary Ban / Permanent Ban) and modernizes
the language around inclusion and community leadership.
Replaces the personal reporting address (lorenz@px4.io) with an
institutional one (coc@dronecode.org) so Code of Conduct reports flow
to the Dronecode Foundation rather than a single maintainer's inbox.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Add 'if: startsWith(runner.name, "runs-on--")' to the mirror swap step
in both workflows so fork users can see at a glance that the step only
fires on runs-on runners and is a no-op on standard GitHub-hosted
runners. The script keeps its internal RUNS_ON_AWS_REGION check as
defense in depth for callers outside these workflows.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The mirror swap was duplicated across two workflows. Move it into
Tools/ci/use_aws_apt_mirror.sh and call the script from each workflow
after checkout but before any heavy apt work like Tools/setup/ubuntu.sh.
The script no-ops outside runs-on (RUNS_ON_AWS_REGION unset), so it is
safe to call from forks, self-hosted runners, or local container runs
without changing behavior there. The region is read from the runs-on
environment instead of being hardcoded, so future region changes only
need updating where the runner is provisioned.
The bootstrap 'apt install git' step keeps the default mirror because
git is one package and is unlikely to hit the dep11 desync issue that
broke ubuntu.sh.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The compile_ubuntu workflow's apt operations talk directly to
archive.ubuntu.com, which round-robins across community mirrors that
occasionally serve out-of-sync index files mid-sync and break apt update
for everyone until the upstream catches up.
Apply the same mirror swap as build_deb_package.yml: rewrite the
container's apt sources to point at us-west-2.ec2.archive.ubuntu.com
before any apt operation runs, so both the inline 'apt update' and the
later Tools/setup/ubuntu.sh call benefit from the regional mirror.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The SIH image is the canonical PX4 SITL container, so drop the redundant
-sih suffix and publish it as px4io/px4-sitl. Gazebo continues to publish
as px4io/px4-sitl-gazebo.
Decouples the published image name from the matrix.image identifier by
introducing a matrix.repo field, so renames like this don't require
touching the matrix logic.
This is a breaking change for anyone pulling px4io/px4-sitl-sih directly;
the old tags remain available but no new ones will be published under
that name.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The default archive.ubuntu.com round-robin can serve out-of-sync index
files mid-sync, which makes apt-get update fail with 'File has unexpected
size' errors and breaks the deb build job for everyone until the upstream
mirror catches up.
Rewrite the container's apt sources to point at us-west-2.ec2.archive.
ubuntu.com instead. The EC2 archive mirrors are Canonical-operated,
region-local to the runs-on instances, and sync aggressively, eliminating
the round-robin lottery as a CI failure mode.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The SIH container entrypoint resolves host.docker.internal via getent
hosts and feeds the first result to mavlink -t and uxrce_dds_client -h.
On Docker Desktop for Windows the lookup can return an IPv6 ULA first,
and both PX4 modules only parse IPv4, so they error out with
'invalid partner ip' and PX4 boots with no working MAVLink or DDS link.
Switch to getent ahostsv4, which only returns IPv4 records, so the IP
injected into the startup scripts is always parseable.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The current workflow_dispatch path builds whatever HEAD of the dispatch ref
is, labels the resulting image with px4_version, and publishes. That's
fine for rebuilding current state but it cannot rebuild the exact commit
a release tag points to, because the dispatch loads the workflow file
from one ref and implicitly checks out the same ref for the build.
This matters for release recovery. When the v1.17.0-rc2 tag push failed
to publish containers back on 2026-03-13 (the v1 GHA cache protocol
removal in RunsOn v2.12.0), the tag was not re-pushed, so the only way
to publish rc2 containers now is via workflow_dispatch. Without this
change, a dispatch against release/1.17 builds release/1.17 HEAD and
labels it v1.17.0-rc2, which produces a container whose contents do not
match the rc2 tag's actual code. That is not a faithful recovery.
Add a build_ref input that controls only the checkout ref, defaulting
to empty which falls back to github.ref (preserving current behavior
for both push events and dispatches that omit the input). With this,
a release recovery looks like:
gh workflow run dev_container.yml --repo PX4/PX4-Autopilot \
--ref release/1.17 \
-f px4_version=v1.17.0-rc2 \
-f build_ref=v1.17.0-rc2 \
-f deploy_to_registry=true
The workflow loads from release/1.17 HEAD (which has the cache fix
from 39b0568 and the hardening from d74db56a), but the build uses
Tools/setup/Dockerfile from the rc2 tag. The published image has
rc2 contents under the rc2 label, as if the original tag push had
worked.
All three actions/checkout steps (setup, build, deploy) take the same
ref expression so every job sees a consistent workspace. Non-dispatch
events (push, PR) evaluate github.event.inputs.build_ref to empty and
fall back to github.ref exactly as before.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Drops --upload from the ROS integration test runner so CI runs no
longer publish ULogs to the public logs.px4.io server on every run.
Failure debugging is unaffected: the existing Upload failed logs step
already captures logs as GitHub Actions artifacts on failure.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Extract the repeated `offboard_control_mode_s` population logic into a shared
`fill_offboard_control_mode()` helper in MavlinkReceiver and, similar to
`fill_thrust()`, reuse it in both local and global position target handlers.
Reduces the code duplication without changing any behavior.
Signed-off-by: Onur Özkan <work@onurozkan.dev>
Three related fixes to prevent a repeat of the v1.17.0-rc2 incident, where a
post-push GHA cache-export 404 failed the arm64 build after both registry
pushes had already succeeded, fail-fast cancelled amd64, and the deploy job
was skipped, leaving the registries with only a partial arm64 publish and no
multi-arch manifest.
- Mark cache export as non-fatal via ignore-error=true on cache-to. A
successful registry push should never be undone by a cache-layer flake.
This alone would have let rc2 publish correctly.
- Decouple the deploy job from the build job's exit code. Change its if:
gate to !cancelled() + setup success only, and promote the existing
"Verify Images Exist Before Creating Manifest" step from a warning into
a hard precondition. Deploy now runs whenever both per-arch tags actually
exist in the registries, which is its real precondition, and fails loudly
if a tag is missing.
- Bump every action to the current major (runs-on/action v2,
actions/checkout v5, docker/login-action v4, docker/setup-buildx-action v4,
docker/build-push-action v7, docker/metadata-action v6). This gets the
workflow off Node 20 before GitHub's June 2 2026 forced runtime switch
and keeps runs-on/action on the same major as the runs-on platform.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* Remove unused parameters from function signature and make the parameter accessors consistent
* Update the caller function signature
* Update src/modules/navigator/rtl.cpp
---------
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
Use timestamp_sample instead of time_now_us for the rate limiter check
to sync to the sensor clock rather than the wall clock.
Switch from direct timestamp assignment to epoch-advance
(_last_publication_timestamp += interval_us) with a catch-up guard to
prevent aliasing artifacts when the sensor sample rate is close to the
configured publication rate.
getPreviousPositionItems() already decrements the start index
internally before searching. The call in on_activation() at line 227
passed _inactivation_index - 1, causing a double-decrement that made
the vehicle resume at waypoint n-2 instead of n-1.
All other call sites (rtl_mission_fast_reverse.cpp:81,
rtl_mission_fast_reverse.cpp:133, mission_base.cpp:1149) pass the
index directly without pre-decrementing.
The bug has been present since commit 007ed11bbe (June 2023).
Closes#26795
Signed-off-by: Pavel Guzenfeld <pavelgu@gmail.com>
The FC-side DroneCAN sensor bridges (accel, gyro, rangefinder) used
hrt_absolute_time() in the receive callback as timestamp_sample,
adding ~3-16ms of systematic CAN transport delay.
For messages with a uavcan.Timestamp field, the cannode can publish
the actual sample time via UAVCAN GlobalTimeSync. The RawIMU publisher
already did this for IMU data; apply the same pattern to the range
sensor publisher, and update all three FC bridges to prefer the
message timestamp with a fallback to hrt_absolute_time() for nodes
that don't set it.
* fix: added comment explaining why dev id address can only be 3 or 4
* fix: change link to point to main px4 repo
* fix: typo
* formatted
* chore: formatting
The packaging script only placed all_events.json.xz in an events/
subdirectory, but the firmware advertises the metadata URI at the
board directory top level. New build targets added after the
Jenkins-to-GHA migration had no legacy top-level copy, causing
QGC to get a 404 when fetching component metadata.
Fixes#26963
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The asset file was renamed from X25-EVO.jpg to x25_evo.jpg in git but
all four locale files (en, ko, uk, zh) still referenced the old name.
macOS hid this because its filesystem is case-insensitive, but Linux CI
(case-sensitive) intermittently failed to resolve the reference during
Rollup bundling.
Fixes#26958
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
When EKF2_HGT_REF=2 (range sensor) with no GPS, optical flow could
never start. The starting condition required isTerrainEstimateValid()
or isHorizontalAidingActive(), but terrain is never "estimated" when
range is the height reference (ground is the datum, terrain state is
fixed at 0), and there's no horizontal aiding without GPS.
HAGL is directly known from the range measurement in this case, so
optical flow has everything it needs to fuse. Add the range height
reference check to the optical flow starting conditions.
Fixes: https://github.com/PX4/PX4-Autopilot/issues/25248
Add :latest tag alongside version tags for per-arch images and
multi-arch manifests on both Docker Hub and GHCR.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Add cmake/cpack infrastructure for building .deb packages from
px4_sitl_sih and px4_sitl_default targets. Includes install rules,
package scripts, Gazebo wrapper, and CI workflow.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Set BOARD_FLASH_SECTORS to 13 so the bootloader does not erase the
parameter sectors (14 and 15) during firmware updates. Previously set
to 14 which allowed the bootloader to erase sector 14, potentially
wiping stored parameters.
Three issues caused the monthly audit to report already-resolved submodules:
1. The audit workflow grepped for "NOASSERTION" anywhere in the output,
matching the Detected column even when the Final column had a valid
override (e.g. libtomcrypt detected as NOASSERTION but overridden to
Unlicense). Changed to grep for "<-- UNRESOLVED" marker instead.
2. Submodules with an explicit NOASSERTION override in license-overrides.yaml
(like libfc-sensor-api, which is proprietary) were still counted as
failures. Now treated as "acknowledged" since someone intentionally
added the override entry.
3. Added missing BSD-3-Clause override for sitl_gazebo-classic (PX4 org
project with no LICENSE file in repo).
Fixes#26932
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Add MAVLink stream that maps EstimatorFusionControl uORB message to
ESTIMATOR_SENSOR_FUSION_STATUS, exposing per-sensor intended/active
bitmasks to the GCS.
Split FusionSensor into available (CTRL param != disabled) and enabled
(runtime-toggleable). intended() = enabled && available. EKF core aid
sources now set available themselves and use intended() or _params
directly for CTRL-level checks. Remove drag/imu from FusionControl,
add aspd/rngbcn. Add AGP sourceFusingBitmask() for active-status.
* ci(claude): add review-pr skill for domain-aware PR reviews
Add a Claude Code skill that reviews pull requests with checks
tailored to the domains touched (estimation, control, drivers,
simulation, system, CI/build, messages, board additions).
Built from analysis of 800+ PR reviews across 8 PX4 maintainers.
Includes merge strategy recommendation, interactive dialog for
submitting reviews, and human-sounding PR comment formatting.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* ci(copilot): add domain-scoped review instructions for GitHub Copilot
Add .github/instructions/ files that give GitHub Copilot PR reviews
the same domain-aware context as the Claude Code review-pr skill.
Each file is scoped via applyTo to the relevant source paths:
core review, estimation, control, drivers/CAN, simulation, system,
CI/build, messages/protocol, and board additions.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* fix(claude): address Copilot review feedback
- Fix step reference in review-pr skill (step 8 -> step 9)
- Capitalize CMake consistently in skill and Copilot instructions
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
---------
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Several helper scripts assumes bash is available at /bin/bash. That breaks on systems
such as NixOS, where bash is resolved from PATH instead of a fixed /bin location and
causes failures like `bad interpreter` during `make format`, e.g., on my host machine:
```sh
$ make format
/PX4-Autopilot/Tools/astyle/check_code_style.sh: /PX4-Autopilot/Tools/astyle/fix_code_style.sh: /bin/bash: bad interpreter: No such file or directory
```
This change switches these entrypoints to `#!/usr/bin/env bash` so they locate bash properly.
No functional changes intended.
Signed-off-by: Onur Özkan <work@onurozkan.dev>
Disable EKF2 fusion features with no corresponding hardware:
- px4_fmu-v2: optical flow, range finder (~17 KB saved)
- mamba-f405-mk2: optical flow, range finder, external vision,
aux global position, aux velocity, baro compensation,
drag fusion (~42 KB saved)
Before this change, filtered test runs still built every gtest target
because `test_results` depended on all unit and functional gtest targets.
This updates both `px4_add_unit_gtest()` and `px4_add_functional_gtest()`
to use the filtered dependency helper so filtered runs only build the
selected targets.
Signed-off-by: Onur Özkan <work@onurozkan.dev>
The MPL3115A2 ADC conversion at OSR 2 (ratio 4) takes ~18ms. The
driver polls until the conversion completes, so the read time is at
the end of the integration window. Correct timestamp_sample to the
midpoint by subtracting CONVERSION_TIME / 2.
The LPS25H one-shot measurement is integrated over a ~40ms window
(at 25Hz-equivalent internal averaging). The read time corresponds to
the end of the integration window. Correct timestamp_sample to the
midpoint by subtracting CONVERSION_INTERVAL / 2.
The LPS22HB one-shot measurement is integrated over a ~40ms window
(at 25Hz-equivalent internal averaging). The read time corresponds to
the end of the integration window. Correct timestamp_sample to the
midpoint by subtracting CONVERSION_INTERVAL / 2.
Same fix as MS5611: the MS5837 ADC conversion at OSR 1024 takes
~2.28ms, but the data is read after a 10ms scheduling delay. Correct
timestamp_sample by subtracting (CONVERSION_INTERVAL - CONVERSION_TIME/2)
from the read time.
The MS5611 ADC conversion at OSR 1024 takes ~2.28ms, but the data is
read after a 10ms scheduling delay. The current code timestamps the
read time, which is ~8.9ms after the true integration midpoint.
Correct timestamp_sample by subtracting the full offset
(CONVERSION_INTERVAL - CONVERSION_TIME/2) from the read time.
The BMP581 pressure measurement is integrated over a configurable
window (~23ms at 32x pressure / 2x temperature oversampling). The
read time corresponds to the end of the integration window, introducing
a systematic timing bias. Correct timestamp_sample to the midpoint by
subtracting measurement_time / 2.
The BMP280 pressure measurement is integrated over _measure_interval
(~43ms at 16x pressure / 2x temperature oversampling). The read time
corresponds to the end of the integration window, introducing a
systematic timing bias. Correct timestamp_sample to the midpoint by
subtracting measurement_time / 2.
Set all high_rate_sensors_topics to 100hz (10ms interval) and add
vehicle_air_data, vehicle_thrust_setpoint, estimator_aid_src_baro_hgt,
and vehicle_magnetometer.
The BMP388 pressure measurement is integrated over a configurable
window (e.g. 37ms at 16x oversampling). The previous code used the
read time as timestamp_sample, which is the end of the integration
window. Correct to the midpoint by subtracting half the measurement
time, with a guard against unsigned underflow.
rc.mc_defaults sets MAV_TYPE=2 (quadrotor) which the hex airframe
never overrides. Set MAV_TYPE=13 (hexarotor) so the heartbeat
correctly identifies the vehicle type.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* Swap joystick surge/heave mapping in manual, stabilized and acro modes to make it similar to position modes
* docs: update UUV/BlueROV2 modes and joystick mapping
* Document basic control axes and joystick mapping
Added basic control axes and stick mapping for BlueROV2.
* Fixed formatting issue
* Enhance clarity of control axes and stick mapping
Clarified descriptions of motion axes and joystick controls for BlueROV2.
The MAVLink standard defines ACTUATOR_OUTPUT_FUNCTION_MOTOR1=1..MOTOR16=16,
but PX4 internally uses OutputFunction::Motor1=101..Motor12=112. The DShot
driver only handled PX4 internal values (101+) and QGC legacy values (1101+),
so any standards-compliant GCS sending the MAVLink enum values would get
VEHICLE_CMD_RESULT_UNSUPPORTED back from MAV_CMD_CONFIGURE_ACTUATOR.
Add a mapping from MAVLink standard values (1-16) to PX4 internal values
(101-116) by adding 100, matching the existing QGC backwards-compat pattern.
* fix(commander): add tab character to critical system loss messages
* fix(commander): extend timeout for traffic avoidance system heartbeat check
* Commander: Only Warn the user about traffic avoidance system loss if COM_ARM_TRAFF is set
Signed-off-by: Claudio Micheli <claudio@auterion.com>
---------
Signed-off-by: Claudio Micheli <claudio@auterion.com>
Co-authored-by: Claudio Micheli <claudio@auterion.com>
GCC 14.3.0 emits `-Wstringop-overflow` when `RtcmTest::buildRawFrame()`
is optimized and inlined.
This change marks the helper `noinline` to keep it out of that optimization path.
Preserves the existing logic and only changes how the compiler emits the test helper.
Fixes https://github.com/PX4/PX4-Autopilot/issues/26875
Signed-off-by: Onur Özkan <work@onurozkan.dev>
When all subscription topics are commented out in dds_topics.yaml,
the build failed in two ways:
1. KeyError in generate_dds_topics.py when the subscriptions key is
absent from YAML — fixed by using dict.get() with fallback to
empty list, consistent with how subscriptions_multi is handled.
2. Unused variable errors (-Werror) in the generated dds_topics.h
when no subscriptions exist — fixed by guarding on_topic_update(),
time_offset_us, and uxr_set_topic_callback() with conditional
template blocks. Also marked create_data_reader() as
__attribute__((unused)) since it is only called from generated
subscription code.
Closes#26799
Signed-off-by: Pavel Guzenfeld <pavelgu@gmail.com>
* [feat] allowed to assign up to 16 ESC CAN
* Update EscStatus.msg
lowered down to 12 motors, hardware tested
* Update module.yaml
lowered down to 12 motors, hardware tested
---------
Co-authored-by: klelkov <kon.lelkov@yandex.ru>
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
Add INA226 and INA228 power monitor drivers to the voxl2 SLPI board
config and add startup options in voxl-px4-start to select them via
the POWER_MANAGER environment variable.
Give the operator the optiont to configure a "Hold at position where
the data link was still coming through" by setting NAV_DLL_ACT to Hold
and the new param NAV_LTR_LAST_DL to 1.
Signed-off-by: Silvan <silvan@auterion.com>
Existing saved parameters store RC*_REV as float. The parameter
import system does strict type checking and would silently skip
these on firmware update. Add migration to preserve user settings.
RC*_REV parameters are binary toggles (-1 or 1) immediately converted
to bool. Using int32 allows reverting the module schema enum key type
from number back to integer, keeping validation strict.
All parameters are now defined in YAML module configuration files.
Remove the cmake infrastructure that discovered and processed
legacy params.c files:
- Remove GLOB_RECURSE for *params.c/*parameters.c
- Remove .c file scanning from DISABLE_PARAMS_MODULE_SCOPING
- Remove module_list from px_process_params.py --src-path
- Remove PX4_MODULE_PATHS usage (no longer needed for param scanning)
- migrate_c_params.py: preserve newlines and paragraph breaks in long
descriptions, use YAML block scalars for multi-line strings
- generate_params.py: support @value tags on float type parameters
(fixes RC*_REV enum values being lost during yaml generation)
Reject pressure readings outside the sensor's operating range
(30-125 kPa) to detect I2C data corruption. When I2C transfers
complete successfully but return corrupted data, this check
prevents invalid samples from being published.
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
The failure_detector_status bitmask in vehicle_status duplicates the
separate FailureDetectorStatus topic. Remove it and read directly from
the dedicated topic in failureDetectorCheck and HIGH_LATENCY2.
* feat(pps_capture): allow selecting GPS receiver by device ID
Add PPS_CAP_GPS_ID parameter to select which GPS receiver's data
is used for PPS timestamp correlation. Matches by device ID rather
than uORB instance index, which avoids dependence on instance ordering.
When set to 0 (default), uses the first available instance for
backward compatibility.
* docs(pps_capture): document PPS_CAP_GPS_ID for multi-GPS setups
* fix(pps_capture): use GPS_MAX_RECEIVERS constant and mark PPS_CAP_GPS_ID reboot-required
Extend the arm throttle safety check to all vehicle types including
rovers, which were previously excluded. Unify the two separate throttle
checks into a single evaluation at arm-time that accounts for vehicle
type and control mode: rovers require centered stick, climb-rate modes
require stick at or below center, and manual/stab/acro modes require
stick at bottom.
This is not only needed for engine warmup but in general, when the
vehicle is static on the ground, relying on fixed position to maintain a
valid global position estimate before takeoff, even when bumping it or
starting the engine.
* boards: corvon 743v1 support (Docs and LED alignment)
This PR addresses #24769 by providing the required official documentation, while simultaneously aligning the board's LED semantics entirely with the PX4 standard.
Key Changes:
- Add complete corvon 743v1 hardware documentation and manufacturer link.
- Fix LED out-of-bounds bug and strictly align RGB states to Pixhawk standard (LED_BLUE=0, LED_RED=1, LED_GREEN=3).
- Update bootloader pin config (hw_config.h) to use red LED for boot/error, and update pre-built bootloader.bin.
* Prettier and file reduce
* docs: address reviewer feedback & board ID fix
* Apply suggestion from @hamishwillee
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* docs: resolve final reviewer feedback (PPM, Debug Port, Manufacturer List)
---------
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Co-authored-by: Ramon Roche <mrpollo@gmail.com>
When a CRSF frame arrives with packet_size < 2 (PACKET_SIZE_TYPE_SIZE),
the subtraction `packet_size - PACKET_SIZE_TYPE_SIZE` underflows the
uint32_t working_segment_size to 0xFFFFFFFF. The subsequent overflow
check also wraps and fails to catch it. Since working_segment_size is
static, the parser is permanently stalled — no further CRSF messages
can be processed until reboot.
Validate packet_size >= PACKET_SIZE_TYPE_SIZE early, before any
subtraction, protecting both the known variable-length and unknown
packet branches in a single check.
Supersedes #26782 which only guarded the unknown-packet branch.
The flow output table shows forward movement producing +Y flow and
rightward movement producing -X flow, which confuses users whose sensors
have X-forward/Y-right coordinate systems. Add an info note explaining
that integrated flow values are angular rotations (radians) about the
body axes using the right-hand convention, which is why the axes are
cross-coupled with translational motion.
Add reusable skill definitions for common contributor workflows:
- commit: creates conventional commits with proper type(scope) format
- pr: creates PRs with conventional commit titles
- rebase-onto-main: handles rebasing onto main when parent branches
were squash-merged
Add a scalable .deb packaging framework for VOXL2, built on the
existing cmake/package.cmake CPack infrastructure. The framework
handles multi-processor boards by having the POSIX (_default) build
own the .deb and pull in the companion SLPI build's artifacts.
Board-specific files:
- cmake/package.cmake: CPack variable overrides (name, deps, version)
- cmake/install.cmake: install() rules for all .deb contents
- debian/postinst: px4-* symlinks, DSP signature, directory setup
- debian/prerm: service stop, symlink cleanup
- debian/voxl-px4.service: systemd unit (after sscrpcd)
Infrastructure changes:
- cmake/package.cmake: hook for board-specific CPack overrides
- platforms/posix/CMakeLists.txt: hook for board install.cmake
- Makefile: %_deb pattern rule (build _default, then cpack -G DEB)
- CI: auto-discover _deb targets, collect .deb artifacts, upload
to GitHub Releases
Future boards: add cmake/package.cmake + cmake/install.cmake and
CI discovers it automatically. No new file formats or tools needed.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Read companion_targets files from board directories and exclude those
targets from CI grouped builds. The parent target builds them via
Make prerequisite, avoiding redundant CI jobs.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Add Makefile rules so that both `make modalai_voxl2` and
`make modalai_voxl2_default` build the SLPI DSP firmware first.
Add companion_targets file listing modalai_voxl2_slpi so CI knows
to exclude it from independent build groups.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Consolidate the VOXL2 SLPI (DSP) board from a separate directory into
the existing voxl2 board as a variant. Multi-processor SoCs like the
QRB5165 should use one board directory with multiple .px4board files
rather than separate directories per processor.
Changes:
- Add slpi.px4board (QURT/DSP) alongside default.px4board (POSIX/apps)
- Merge board_config.h with __PX4_QURT / __PX4_POSIX preprocessor guards
- Merge CMakeLists.txt with PX4_PLATFORM conditionals
- Split bus definitions into platform-specific files (i2c/spi_posix/qurt)
- Reorganize drivers into drivers/posix/ and drivers/qurt/ subdirectories
- Guard cmake/init.cmake and cmake/link_libraries.cmake for posix-only
- Update build and install scripts for new target names
- Delete boards/modalai/voxl2-slpi/ entirely
Build targets change:
- modalai_voxl2-slpi_default -> modalai_voxl2_slpi
- modalai_voxl2_default (unchanged)
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* ci(ros): use matching branch for px4-ros2-interface-lib
When running on release branches, the ROS integration tests now
check if a matching branch exists in px4-ros2-interface-lib and
clone it instead of always using main. This prevents build failures
caused by uORB message divergence between main and release branches.
Fixes https://github.com/Auterion/px4-ros2-interface-lib/issues/184
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* ci(ros): dispatch release branch creation to px4-ros2-interface-lib
Add a standalone workflow triggered by the create event that fires a
repository_dispatch to Auterion/px4-ros2-interface-lib when a
release/X.Y branch is created. Also supports manual workflow_dispatch.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* ci(ros): add empty permissions block to dispatch workflow
Fixes code scanning alert about missing GITHUB_TOKEN permissions.
This workflow only uses a PAT secret, not GITHUB_TOKEN, so no
permissions are needed.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
---------
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
There are many settings falling into the RC_* category
that definitely should be reset when e.g. placing the autopilot
into a new airframe.
And even for RC calibration values: it's not the worst
if those are newly calibrated after a reset. Or if they
are not expected to change one can bake them into the
airframe file.
Signed-off-by: Silvan <silvan@auterion.com>
PR #25799 added 'servo-launch-lock' to apply_identifiers (6 items) but
did not add a corresponding 6th entry to the 19 rule item arrays, causing
QGC to reject all servo-type rules with "unexpected num items expected: 6".
Remove the @volatile flag from ASPD_SCALE_1/2/3 so the estimated
airspeed scale persists across reboots and can be transferred between
vehicles of the same model. The scale is primarily determined by pitot
position on the airframe, not the individual sensor.
To avoid corrupting the param transfer hash with negligible changes
every flight, raise the save threshold from FLT_EPSILON to 3% relative
change, per dev-call consensus.
Supersedes #22760
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Update the opencyphal/public_regulated_data_types submodule to latest
master which renames all .uavcan files to .dsdl, eliminating ~456
Nunavut deprecation warnings per build.
The N after MB was parsed as "play note 0" (rest) rather than "Music Normal" mode, since M already consumed B. Replacing it with a trailing P matches the ERROR_TUNE pattern and provides an intentional inter-repetition pause at the correct tempo.
After #25648, when performing RTL mission fast reverse, the vehicle would go to the waypoint before the previous one (i.e., two waypoints back). If the drone was already on its way to the first waypoint at that moment, it would even fly to the second waypoint first, and only then reverse back toward the takeoff point. This PR fixes that bug. #25648 was intended to address issues with NAV_CMD_CONDITION_GATE. The modification proposed in this PR also correctly bypasses NAV_CMD_CONDITION_GATE waypoints.
Line 319 used nested quotes inside f-strings, a feature only available
in Python 3.12+. The CI Docker image (px4-dev-base-focal:2021-08-18)
runs Python 3.8, causing the "msg file docs" Jenkins stage to fail on
every main build since 6bf73d9d89.
Extract the join expressions into local variables to restore
compatibility with Python 3.8+.
* sensors: add per-receiver GPS delay parameters
Add SENS_GPS{0,1}_DELAY params to vehicle_gps_position, following the
same device-ID matching pattern used for antenna offsets. Each receiver
can now have its own measurement delay relative to the IMU.
The delay is applied to timestamp_sample before blending. When PPS time
correction is active it takes priority over the parameter-based delay.
When a GPS driver already provides its own timestamp_sample the
per-receiver delay is not applied on top of it.
* fix(ekf2): remove EKF2_GPS_DELAY and perform param transation
* fix(param_translation): fix GPS param migration return values
Add missing return for EKF2_GPS_POS_Z and remove incorrect return for
EKF2_GPS_DELAY (1-to-many migration should not return PARAM_MODIFIED).
* fix(sensors,ekf2): rename pps_compensation and clarify delay default
* fix(ekf2): account for SENS_GPS*_DELAY in observation buffer sizing
* fix(docs): migrate EKF2_GPS_DELAY param
* sensors: move GPS antenna offsets to per-receiver parameters
Move antenna position configuration from the single EKF2_GPS_POS_X/Y/Z
parameter set into per-receiver SENS_GPS{0,1}_OFF{X,Y,Z} parameters in
the sensors module. Each offset slot is matched to a physical receiver
by device ID (SENS_GPS{0,1}_ID), falling back to uORB instance index
when no IDs are configured.
The antenna offset is now carried through the SensorGps uORB message
and blended alongside other GPS states when multi-receiver blending is
active, so EKF2 receives the correct lever arm for whichever receiver
(or weighted combination) is selected.
- Add antenna_offset_{x,y,z} fields to SensorGps.msg
- Remove EKF2_GPS_POS_X/Y/Z params; EKF2 reads offset from gnssSample
- Add SENS_GPS{0,1}_ID and SENS_GPS{0,1}_OFF{X,Y,Z} params (module.yaml)
- Blend antenna offsets in GpsBlending (weighted average)
- Add unit tests for single, blended, and failover antenna offset cases
- Migrate params.c to module.yaml for the vehicle_gps_position module
* sensors: gps_blending: add asymmetric weight and fallthrough offset tests
Add two additional antenna offset test cases:
- dualReceiverAsymmetricWeightAntennaOffset: verify that unequal eph
values produce correctly skewed blend weights (0.8/0.2) and that the
output antenna offset reflects the weighted average
- blendingFallthroughAntennaOffset: verify that when blending is enabled
but can_do_blending evaluates false (eph=0), the non-blending path
correctly assigns the selected receiver's antenna offset
* feat(param_translation): translate EKF2_GPS_POS_ to SENS_GPS0_OFF_
* fix(msgs): proper formatting
* chore(msg): 0 if invalid/unknown
* fix(ROMFS): migrate EKF2_GPS_POS_ params
* fix(docs): migrate EKF2_GPS_POS_ params
* fix(blending): unsigned param
* Update msg/SensorGps.msg
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* fix(sensors/gps): remove 'values:' tag in module.yaml
* fix(sensors/gps): unsigned instance index
* fix(blending): restore const on gps_blend_states()
Move antenna offset blending into blend_gps_data() where the
weights are computed, keeping gps_blend_states() const.
* fix(sensors/gps): fix msg annotation and restore SENS_GPS_PRIME values
Remove incorrect @invalid NaN annotation from antenna offset fields
(0.0 default is correct, not a sentinel). Restore values tag for
SENS_GPS_PRIME so QGC shows a dropdown.
* fix(gps_blending): fix pre-existing bug to clear _gps_updated flags
The loop iterates over i but always clears gps_select_index. The intent is to clear
all updated flags, but only the selected one gets cleared (N times)
* test(gps_blending): add stale update flag regression test
Overhauls the DShot driver with per-timer BDShot selection, multi-timer
sequential capture, Extended DShot Telemetry (EDT), and AM32 ESC EEPROM
read/write via MAVLink. Expands ESC support from 8 to 12 channels.
BDShot:
- Per-timer BDShot protocol selection via actuator config UI
- Multi-timer sequential burst/capture on any DMA-capable timer
- Adaptive per-channel GCR bitstream decoding
- Per-channel online/offline detection with hysteresis
Extended DShot Telemetry (EDT):
- Temperature, voltage, current from BDShot frames (no serial wire)
- New DSHOT_BIDIR_EDT parameter
- EDT data merged with serial telemetry when both available
AM32 EEPROM:
- Read/write AM32 ESC settings via MAVLink ESC_EEPROM message
- ESCSettingsInterface abstraction for future ESC firmware types
- New DSHOT_ESC_TYPE parameter
Other changes:
- Per-motor pole count params DSHOT_MOT_POL1–12 (replaces MOT_POLE_COUNT)
- EscStatus/EscReport expanded to 12 ESCs with uint16 bitmasks
- Numerous bounds-check, overflow, and concurrency fixes
- Updated DShot documentation
2026-03-17 16:38:33 -08:00
1296 changed files with 39982 additions and 33801 deletions
description: Create a conventional commit for PX4 changes
disable-model-invocation: true
argument-hint: "[optional: description of changes]"
allowed-tools: Bash, Read, Glob, Grep
---
# PX4 Conventional Commit
Create a git commit: `type(scope): description`
**NEVER add Co-Authored-By lines. No Claude attribution in commits.**
Follow [CONTRIBUTING.md](../../CONTRIBUTING.md) for full project conventions.
## Steps
1.**Read [CONTRIBUTING.md](../../CONTRIBUTING.md)** for commit message format, types, scopes, and conventions.
2. Check branch (`git branch --show-current`). If on `main`, create a feature branch. Use `<username>/<description>` format where `<username>` comes from `gh api user --jq .login`. If unavailable, just use `<description>`.
3. Run `git status` and `git diff --staged`. If nothing staged, ask what to stage.
4. Follow the commit message convention from CONTRIBUTING.md: pick the correct **type** and **scope**, write a concise imperative description.
5. Body (if needed): explain **why**, not what.
6. Run `make format` or `./Tools/astyle/fix_code_style.sh <file>` on changed C/C++ files before committing.
7. Check if GPG signing is available: `git config --get user.signingkey`. If set, use `git commit -S -s`. Otherwise, use `git commit -s`.
8. Stage and commit. No `Co-Authored-By`.
If the user provided arguments, use them as context: $ARGUMENTS
description: Create a pull request with conventional commit title and description
disable-model-invocation: true
argument-hint: "[optional: target branch or description]"
allowed-tools: Bash, Read, Glob, Grep
---
# PX4 Pull Request
**No Claude attribution anywhere (no Co-Authored-By, no "Generated with Claude").**
Follow [CONTRIBUTING.md](../../CONTRIBUTING.md) for full project conventions.
## Steps
1. Check branch. If on `main`, create a feature branch. Use `<username>/<description>` format where `<username>` comes from `gh api user --jq .login`. If unavailable, just use `<description>`.
3. PR **title**: `type(scope): description` — under 72 chars, describes the overall change across all commits. This becomes the squash-merge commit message.
4. PR **body**: brief summary + bullet points for key changes. No filler.
5. Push with `-u` if needed, then `gh pr create`. Default base is `main` unless user says otherwise.
6. Return the PR URL.
If the user provided arguments, use them as context: $ARGUMENTS
description: Rebase a branch onto main, handling squash-merged parent branches cleanly
argument-hint: "[optional: branch name, defaults to current branch]"
allowed-tools: Bash, Read, Glob, Grep, Agent
---
# Rebase Branch onto Main
Rebase the current (or specified) branch onto `main`, correctly handling the case where the branch was built on top of another branch that has since been squash-merged into `main`.
## Background
When a parent branch is squash-merged, its individual commits become a single new commit on `main` with a different hash. A normal `git rebase main` will try to replay the parent's original commits, causing messy conflicts. The fix is to **cherry-pick only the commits unique to this branch** onto a fresh branch from `main`.
## Steps
1.**Identify the branch.** Use `$ARGUMENTS` if provided, otherwise use the current branch.
2.**Fetch and update main:**
```
git fetch origin main:main
```
3. **Find the merge base** between the branch and `main`:
```
git merge-base <branch> main
```
4. **List all commits** on the branch since the merge base:
```
git log --oneline <merge-base>..<branch>
```
5. **Identify which commits are unique to this branch** vs. inherited from a parent branch. Look for:
- Squash-merged commits on `main` that correspond to a group of commits at the bottom of the branch's history (check PR titles, commit message keywords).
- The boundary commit: the first commit that belongs to *this* branch's work, not the parent's.
- If ALL commits are unique (no parent branch), just do a normal `git rebase main` and skip the rest.
6. **Create a fresh branch from `main`:**
```
git checkout -b <branch>-rebase main
```
7. **Cherry-pick only the unique commits** (oldest first):
```
git cherry-pick <first-unique-commit>^..<branch>
```
The `A^..B` range means "from the parent of A through B inclusive."
8. **Handle conflicts** if any arise during cherry-pick. Resolve and `git cherry-pick --continue`.
9. **Replace the old branch:**
```
git branch -m <branch> <branch>-old
git branch -m <branch>-rebase <branch>
```
10. **Verify** the result:
```
git log --oneline main..<branch>
```
Confirm only the expected commits are present.
11. **Ask the user** before force-pushing. When approved:
-`gh pr checks <PR>` (exit code 8 means some checks are pending, this is normal, not an error)
-`gh pr diff <PR>` -- if this fails with HTTP 406 (300+ files), do NOT retry. Instead use `gh api repos/OWNER/REPO/pulls/NUMBER/files --paginate` to get the full file list in one call, then fetch patches for key infrastructure files individually and sample representative changes from each domain touched.
-`gh api repos/OWNER/REPO/pulls/NUMBER/comments --paginate --jq '.[] | {user: .user.login, body: .body, path: .path, created_at: .created_at}'` to get inline review comments
-`gh api repos/OWNER/REPO/issues/NUMBER/comments --paginate --jq '.[] | {user: .user.login, body: .body, created_at: .created_at}'` to get PR conversation comments
From the PR metadata, note:
- **Assigned reviewers**: who has been requested to review (from `reviewRequests`)
- **Existing reviews**: who has already reviewed and their verdict (from `reviews` -- approved, changes_requested, commented, dismissed)
- **PR comments and inline comments**: read all existing feedback to avoid duplicating points already raised by other reviewers, and to build on their discussion rather than ignoring it
2.**Check CI status.** From the `gh pr checks` output in step 1, summarize pass/fail/pending. If there are failures, fetch logs with `gh run view <run-id> --log-failed`. Include CI status in the output.
3.**Recommend merge strategy.** Analyze the commit history and recommend squash or rebase merge. This decision informs all subsequent commit hygiene feedback.
**Recommend rebase merge** when:
- Commits are atomic, each builds/works independently
- Each commit has a proper `type(scope): description` message
- The PR intentionally separates logical changes (e.g., refactor + feature, or one commit per module)
- The commit history tells a useful story that would be lost by squashing
**Recommend squash merge** when:
- There are WIP, fixup, or review-response commits
- Commit messages are messy or inconsistent
- The PR is a single logical change spread across multiple commits
- There are "oops" or "make format" commits mixed in
Include the recommendation in the output. If recommending rebase, flag any commits that break atomicity or have bad messages. If recommending squash, don't bother flagging individual commit messages (they'll be discarded) but ensure the PR title is correct since it becomes the squash commit message.
4.**Check conventional commit title.** Verify the PR title follows `type(scope): description` per CONTRIBUTING.md. The PR title becomes the commit message on squash-merge, so it must be accurate and descriptive. Verify the scope matches the primary area of changed files. If the PR introduces breaking changes, the title must include `!` before the colon. If rebase merge was recommended in step 3, also scan individual commit messages for anti-patterns: vague messages ("fix", "update"), missing type prefix, review-response noise ("apply suggestions from code review", "do make format"), or WIP markers. Flag these for rewording.
5.**Identify domains touched.** Classify changed files into domains based on paths (a PR may touch multiple):
- **Type safety**: int16 overflow, float/double promotion, unsigned subtraction, use `uint64_t` for absolute time
- **Initialization**: uninitialized variables, missing default construction
- **Buffer safety**: unchecked array access, stack allocation of large buffers, snprintf bounds
- **Magic numbers**: every numeric literal needs a named constant or justification
- **Framework reuse**: use PX4_ERR/WARN/INFO, existing libraries (AlphaFilter, SlewRate, RateControl), MAVLink constants from the library
- **Naming**: accurate, no unjustified abbreviations, current terminology (GPS -> GNSS for new code)
- **Unnecessary complexity**: can code be removed instead of added? Is there a simpler pattern?
- **Test coverage**: new features should include unit or integration tests; bug fixes should include regression tests where practical. When automated testing is infeasible (hardware-specific), require a flight log link from https://logs.px4.io or bench test evidence.
- **PR hygiene**: focused scope, no unrelated formatting, no stale submodule changes. Commits should be atomic and independently revertable. Multiple WIP or review-response commits should be squashed. Clean, logical commits will be preserved individually on main via rebase merge. **Do NOT assume PRs are squash-merged. Both squash and rebase merge are enabled; merge commits are disabled.** Verify the PR targets `main` unless it is a backport or release-specific fix.
- **Formatting**: `make format` / `make check_format` (astyle) for C/C++ files; `clang-tidy` clean. Python files checked with `mypy` and `flake8`. PRs failing CI format or lint checks will not be merged.
- **Coding style**: C/C++ must follow the [PX4 coding style](https://docs.px4.io/main/en/contribute/code.html)
- **Necessity**: challenge every addition with "Why?" Is this actually needed or just copied? Can we change a default instead of adding runtime detection?
- **Root cause vs symptom**: is this fixing the real problem or masking it?
- **Ecosystem impact**: what does this change mean for QGC users, log analysis tools, and third-party integrations?
- **Sustainability**: who will maintain this? Does it create long-term burden?
- **Architecture fit**: does the code live in the module that naturally owns the data? Are there unnecessary cross-module dependencies?
- **End user impact**: will parameters confuse less-technical users? Are error messages actionable in QGC?
7.**Apply domain checks** based on step 5:
**Estimation:**
- Singularities in aerospace math (euler angles near gimbal lock, sideslip at low airspeed)
- Aliasing from downsampling sensor data without filtering
- Ubuntu LTS support policy (latest + one prior only)
- Build time impact
- CMake preferred over Makefiles
**Messages/Protocol:**
- Backwards compatibility: will this break QGC, post-flight tools, or uLog parsers?
- uORB: `timestamp` for publication metadata, `timestamp_sample` close to physical sample, include `device_id`
- Don't version messages unless strictly needed
- Parameter UX: will this confuse users in a GCS? Every new param is a configuration burden
- MAVLink: use library constants, don't implement custom stream rates
**Board Addition:**
- **Flight logs**: require a link to https://logs.px4.io demonstrating basic operation for the vehicle type (hover for multicopters, stable flight for fixed-wing, driving for rovers, etc.); short bench-only logs are insufficient
- **Documentation**: require a docs page in `docs/en/flight_controller/` with pinout, where-to-buy, connector types, version badge, and manufacturer-supported notice block
- **USB VID/PID**: must not reuse another manufacturer's Vendor ID; manufacturer must use their own
- **Board naming**: directory is `boards/{manufacturer}/{board}/`, both lowercase, hyphens for board name
- **Unique board_id**: registered in `boards/boards.json`, no collisions
- **Copied code cleanup**: check for leftover files, configs, or comments from the template board; "Is this real or leftover?"
- **RC configuration**: prefer `CONFIG_DRIVERS_COMMON_RC` over legacy `CONFIG_DRIVERS_RC_INPUT`
- **No board-specific custom modules**: reject copy-pasted drivers (e.g., custom heater) when existing infrastructure works
- **Bootloader**: expect a bootloader defconfig (`nuttx-config/bootloader/defconfig`) or explanation of shared bootloader
- **CI integration**: board must be added to CI compile workflows so it builds on every PR
- **Flash constraints**: verify enabled modules fit in flash; we are running low across all board targets
- **Port labels**: serial port labels must match what is physically printed on the board
- **Hardware availability**: for unknown manufacturers, verify the product exists and is purchasable (no vaporware)
8.**Format output** as:
- **CI status**: pass/fail summary, link to failed runs if any
- **Merge strategy**: recommend squash or rebase merge with reasoning
- **Title check**: pass/fail with suggestion
- **Review status**: list assigned reviewers and any existing reviews (who approved, who requested changes, key points already raised). Note if your review would duplicate feedback already given.
- **Domains detected**: list which domain checks were applied
- **Summary**: one paragraph on what the PR does and whether the approach is sound
- **Issues**: numbered list, each with file:line, severity (blocker/warning/nit), and explanation. Skip issues already raised by other reviewers unless you have something to add.
- **Verdict**: approve, request changes, or needs discussion
After the structured output, also display a **draft PR comment** formatted using the PR comment formatting rules from step 9. This gives the user a preview of what would be posted.
9.**Interactive dialog.** After displaying the review, present the user with these options:
Present options based on the verdict:
If verdict is **approve**:
```
What would you like to do?
1. Chat about this PR (ask questions, explore code) [default]
2. Approve this PR and post the review comment
3. Adjust the review or draft (tell me what to change)
4. Done for now
```
If verdict is **request changes**:
```
What would you like to do?
1. Chat about this PR (ask questions, explore code) [default]
2. Request changes on this PR and post the review comment
3. Adjust the review or draft (tell me what to change)
4. Done for now
```
If verdict is **needs discussion**:
```
What would you like to do?
1. Chat about this PR (ask questions, explore code) [default]
2. Post the review as a comment (no approval or rejection)
3. Adjust the review or draft (tell me what to change)
4. Done for now
```
Wait for the user to choose before proceeding. If they pick:
- **1 (chat)**: enter a free-form conversation about the PR. The user can ask about specific files, code paths, or decisions. When done, loop back to the options. This is the default if the user just presses enter.
- **2 (submit)**: use the draft PR comment already shown. Before posting, check if you have review permissions: run `gh api repos/OWNER/REPO/collaborators/$(gh api user --jq .login)/permission --jq .permission` -- if `admin` or `write`, submit as a formal review with `gh pr review <PR> --approve --body "..."` or `gh pr review <PR> --request-changes --body "..."` based on the verdict. If no write access, fall back to `gh pr comment <PR> --body "..."`. Always confirm with the user before posting.
- **3 (adjust)**: ask what to change, update the review and draft, then loop back to the options.
- **4 (done)**: stop.
**PR comment formatting rules** (for the draft):
When writing the GitHub comment, rewrite the review to sound like a human reviewer, not a structured report. Do NOT include the full skill output. Instead:
- Drop most meta-sections (CI status, title check, domains detected, severity labels) but keep the merge strategy recommendation (e.g., "I'd suggest a rebase merge here since the commits are clean and atomic" or "This should be squash-merged, the commit history is messy")
- Write conversationally: "Nice work on this. A few things I noticed:" not "Issues: 1. file:line (warning):"
- Lead with a brief take on the overall change (1-2 sentences)
- List only actionable feedback as natural review comments, not numbered checklists
- Skip nits unless they are particularly useful
- End with a clear stance: looks good to merge, needs a few changes, or let's discuss X
- Post with `gh pr comment <PR> --body "$(cat <<'EOF' ... EOF)"`. Do not post without explicit confirmation.
If the user provided arguments, use them as context: $ARGUMENTS
In addition to the core code review guidelines, when reviewing new board additions:
- **Flight logs**: require a link to https://logs.px4.io demonstrating basic operation for the vehicle type (hover for multicopters, stable flight for fixed-wing, driving for rovers, etc.); short bench-only logs are insufficient
- **Documentation**: require a docs page in `docs/en/flight_controller/` with pinout, where-to-buy, connector types, version badge, and manufacturer-supported notice block
- **USB VID/PID**: must not reuse another manufacturer's Vendor ID; manufacturer must use their own
- **Board naming**: directory is `boards/{manufacturer}/{board}/`, both lowercase, hyphens for board name
- **Unique board_id**: registered in `boards/boards.json`, no collisions
- **Copied code cleanup**: check for leftover files, configs, or comments from the template board. Ask "Is this real or leftover?"
- **RC configuration**: prefer `CONFIG_DRIVERS_COMMON_RC` over legacy `CONFIG_DRIVERS_RC_INPUT`
- **No board-specific custom modules**: reject copy-pasted drivers (e.g., custom heater) when existing infrastructure works
- **Bootloader**: expect a bootloader defconfig (`nuttx-config/bootloader/defconfig`) or explanation of shared bootloader
- **CI integration**: board must be added to CI compile workflows so it builds on every PR
- **Flash constraints**: verify enabled modules fit in flash; we are running low across all board targets
- **Port labels**: serial port labels must match what is physically printed on the board
- **Hardware availability**: for unknown manufacturers, verify the product exists and is purchasable (no vaporware)
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
Examples of behavior that contributes to a positive environment for our community include:
*Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
*Focusing on what is best for the community
*Showing empathy towards other community members
*Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
*Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
*Focusing on what is best not just for us as individuals, but for the overall community
Examples of unacceptable behavior by participants include:
Examples of unacceptable behavior include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* The use of sexualized language or imagery, and sexual attention or advances of any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Publishing others' private information, such as a physical or email address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
## Enforcement Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at lorenz@px4.io. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at coc@dronecode.org. All complaints will be reviewed and investigated promptly and fairly.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series of actions.
**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within the community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.1, available at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder][Mozilla CoC].
For answers to common questions about this code of conduct, see the FAQ at [https://www.contributor-covenant.org/faq][FAQ]. Translations are available at [https://www.contributor-covenant.org/translations][translations].
<a href="https://insights.linuxfoundation.org/project/px4"><img src="https://insights.linuxfoundation.org/api/badge/active-contributors?project=px4" alt="LFX Active Contributors"></a>
</p>
---
@@ -99,6 +104,22 @@ make px4_sitl
We welcome contributions of all kinds — bug reports, documentation, new features, and code reviews. Please read the [Contribution Guide](https://docs.px4.io/main/en/contribute/) to get started.
## Citation
If you use PX4 in academic work, please cite it. BibTeX:
```bibtex
@software{px4_autopilot,
author={Meier, Lorenz and {The PX4 Contributors}},
title={{PX4 Autopilot}},
publisher={Zenodo},
doi={10.5281/zenodo.595432},
url={https://px4.io}
}
```
The DOI above is a Zenodo concept DOI that always resolves to the latest release. For a version-pinned citation, see the [Zenodo record](https://doi.org/10.5281/zenodo.595432) or our [`CITATION.cff`](CITATION.cff).
## Governance
The PX4 Autopilot project is hosted by the [Dronecode Foundation](https://www.dronecode.org/), a [Linux Foundation](https://www.linuxfoundation.org/) Collaborative Project. Dronecode holds all PX4 trademarks and serves as the project's legal guardian, ensuring vendor-neutral stewardship — no single company owns the name or controls the roadmap. The source code is licensed under the [BSD 3-Clause](LICENSE) license, so you are free to use, modify, and distribute it in your own projects.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.