The job ran brew update and then installed whatever Homebrew was publishing, except Gazebo, which stayed on one commit. Those were built against different protobufs, so a release upstream failed the build with no commit here. Check the package repos out at commits recorded in the tree and do not update them. Run on macos-15 only, so the OS label cannot move either.
Assisted-by: Grok:grok-4.7
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
The build runs brew update and then pours Gazebo from one pinned tap commit while the rest of the install, including protobuf, comes from current Homebrew. A release in either repo fails the check with no commit here, and the GitHub-hosted image moves on its own, so the job cannot be a closed set. Drop the build and the weekly pin refresh. The setup script, the pins, and the refresh script stay for local use.
Assisted-by: Grok:grok-4.7
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
whitelisting only PX4 source directory made git commands
fail when executed on the submodules
Signed-off-by: Beniamino Pozzan <beniamino.pozzan@gmail.com>
* docs(mavlink): present link encryption alongside message signing
The hardening guide told integrators that production deployments must
enable message signing, presenting it as the only way to secure a MAVLink
link. Encrypting the link below MAVLink, with an encrypted radio, a VPN or
IPsec, is at least as strong: it uses standard, reviewed cryptography, it
gives confidentiality as well as authentication, and it covers every
interface on the link rather than only MAVLink.
Present both options, and reword the passages that assumed signing was the
only one.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julian Oes <julian@oes.ch>
* docs(security): develop security fixes in public pull requests
Record that fixes are developed as ordinary public pull requests, with no
private forks and no embargoed branches.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julian Oes <julian@oes.ch>
* docs(security): add security scope document
Describe the boundary the code implements today: what PX4 protects, what it
assumes about the layers beneath it, what the shipped default does and does
not do, and two lists for what is always in scope and what is out. It
describes the boundary rather than pre-deciding reports. A finding that fits
neither list stays a judgement call that maintainers make on the report.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julian Oes <julian@oes.ch>
* docs(security): list a security maintainer for report triage
Security report triage had no named owner, so an unacknowledged report had
nowhere to go except the release managers. Add a Security block to the
maintainers list, and point the follow-up path in SECURITY.md at it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julian Oes <julian@oes.ch>
* docs(mavlink): note that the first signing key is unauthenticated
The guide already says to provision over a trusted link, and the info box says
that changing or disabling a key requires a signed message. It does not say that
setting the first one cannot, since there is no key to sign with yet, so a reader
can come away believing provisioning itself is protected.
Say plainly that the window exists, what an attacker gets from it, and how to
recover.
Assisted-by: Claude:claude-opus-5[1m]
Signed-off-by: Julian Oes <julian@oes.ch>
* Apply batched suggestions from code review
Co-authored-by: Sheren N <sherenyn@ad.uni-paderborn.de>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Co-authored-by: Julian Oes <julian@oes.ch>
* feat(security): more review fixup
* fix(security): only 1.18 gets security bugfixes
* fix(security): link to SECURITY_SCOPE
* fix(securiy): small wording fixups
* docs(security): scope by attacker position, not bug class
The "Always in scope" list made any memory corruption, race or hang a
vulnerability regardless of who can reach it. That is not how reports
have been handled: sanitizer runs in SITL have found and fixed many
such bugs as ordinary PRs, and a peer on an unsecured link already has
a shell.
Replace it with one test: a finding is a vulnerability when it gives
capability to an attacker who has neither the operator's access nor
physical access. Keep the in-tree board configuration rule, point to
the sanitizer docs, and fix two typos.
Assisted-by: Claude:claude-opus-5[1m]
Signed-off-by: Julian Oes <julian@oes.ch>
* fix(docs): formatting
* fix(maintainers): add Ramon to security as well
* docs(security): draw the boundary as a mermaid diagram
GitHub renders mermaid natively, so the boundary diagram no longer has to
be maintained as hand-aligned ASCII. Label the two zones with the wording
of the sentences below it, so the picture and the prose say the same
thing.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julian Oes <julian@oes.ch>
* fix(docs): review fixups
* docs(security): say how to isolate the offboard transports
A direct cable between flight controller and companion is not enough on
its own: the agent or router republishes into the DDS or Zenoh network
on the companion, so that network is inside the boundary too.
Keep the scope document to what is inside the boundary and put the
isolation advice next to the uXRCE-DDS and Zenoh setup instructions.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julian Oes <julian@oes.ch>
---------
Signed-off-by: Julian Oes <julian@oes.ch>
Co-authored-by: Sheren N <sherenyn@ad.uni-paderborn.de>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* docs(releases): add v1.18 notes for five backported fixes
The estimator selector, VTOL mission return, analog battery filter,
home altitude filter and mission end fixes are on release/1.18 now,
this adds their entries to the release notes.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Saibernard Yogendran <bernie97@seas.upenn.edu>
* MOve entries
* docs(releases): add the v1.18 note for the position controller filter fix
#28534 merged onto release/1.18 after the first five entries.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Saibernard Yogendran <bernie97@seas.upenn.edu>
---------
Signed-off-by: Saibernard Yogendran <bernie97@seas.upenn.edu>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* feat(failure-injection): implement motor failure injection with soft and hard modes
* feat(failure-injection): update motor failure injection descriptions and behaviors for annunciated and un-annunciated modes
* feat(failure-injection): update motor failure injection terminology to detected and undetected modes
* feat(failure-injection): refine motor failure injection handling for detected and undetected modes
* fix(boards): remove FailureInjector::update() from itcm_functions
FailureInjector was replaced by the shared failure_injection library, so
the symbol no longer exists and the ITCM check fails on the boards that
still list it. Its successor failure_injection::Config::update() is an
inline no-op unless MODULES_FAILURE_INJECTION_MANAGER is enabled, which
none of these boards do, so there is no replacement symbol to map.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Claudio-Chies <61051109+Claudio-Chies@users.noreply.github.com>
---------
Signed-off-by: Claudio-Chies <61051109+Claudio-Chies@users.noreply.github.com>
Co-authored-by: Claudio Chies <chiesc@chies.com>
* feat(ros2): add Humble development images and distro releases
Build Humble on Jammy without replacing its ROS DDS libraries: Agent 2.4.3
links private, pinned Fast DDS/CDR dependencies. Publish Humble and Jazzy
tags independently while leaving packaged runtime images Jazzy-only.
Assisted-by: Copilot:gpt-6-astra
* refactor(ros2): share pinned Agent DDS libraries across distros
Build the Agent against the same private Fast DDS and Fast CDR pins on Humble and Jazzy, without replacing either ROS underlay. Remove distro-specific build branches and name the dependency manifest for its shared role.
Assisted-by: Copilot:gpt-6-astra
Address the review feedback from @hamishwillee: add a board photo,
mechanical and electrical data, a Radio Control section stating that RC
is wired directly to the FMU, and per-connector pinout tables taken from
the manufacturer documentation.
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Julian Oes <julian@oes.ch>
The NWBlue Pro H757 is a 30x30 mm FPV flight controller built around the
CubePilot CubeNode H757 module: STM32H757, on-module ICM45686 IMU and
on-carrier DPS368 baro on SPI3, IIS2MDC magnetometer on I2C3, microSD on
SDMMC2, 9 DShot/PWM outputs, CAN1 and six UARTs.
Pin assignments follow the ArduPilot NWBLUE_PROH757 hwdef, including board
ID 5730. The sensor rotations do not: the hwdef specifies ROTATION_ROLL_180
for the IMU, but on this hardware both the IMU and the magnetometer are
unrotated, confirmed on the bench and by compass calibration.
PLL1P runs at 480MHz so the timer clock is 240MHz, which DShot600 divides
into exactly 20 ticks per bit. At 400MHz that division truncates and every
bit comes out 4.2% short, which some ESCs reject. Bidirectional DShot works
on every output except FMU_CH6: that one is TIM4_CH4, and the H7 DMAMUX has
no request line for it.
Timers: TIM1/2/3/4 drive the outputs, TIM8_CH3 the buzzer so a passive
piezo produces a real tone, TIM12 the HRT and TIM6 the uavcan clock. TIM5
is deliberately left unallocated - the HRT does not work there (every
periodic work item runs once and is never rescheduled, while
interrupt-driven peripherals keep going so the board still looks alive),
and it is also the H7 default for the uavcan clock, where it kept DroneCAN
from coming up.
There is no analog OSD chip, so an HD VTX has to render the OSD itself over
MSP DisplayPort on the VTX connector (USART6 / TEL2). MSP_OSD_CONFIG is
left unset so that port can equally serve as a plain TEL2.
px4_uploader learns the board's USB ID (CubePilot VID 0x2DAE, PID 0x2001).
bringup.md records what has been verified on hardware and what has not.
Assisted-by: Claude:claude-opus-5[1m]
Signed-off-by: Julian Oes <julian@oes.ch>
Make the standalone ROS toolchain available from the same registries as the ROS runtime images. Preserve opt-in publication, existing GHCR tags and both architecture SBOM indexes.
Assisted-by: Copilot
Gazebo ROS image publication exceeds BuildKit 0.32's 40 MiB attestation limit. Pin the builder daemon to 0.33.0 for its 80 MiB limit while preserving the existing scanner and complete package/file coverage.
Assisted-by: Copilot:gpt-6-astra
Build each PR firmware and matching ROS workspace from source against the digest-pinned Jazzy toolchain. Run the interface library unit and SIH integration suites without reusing stale firmware or generated messages.
Assisted-by: Copilot:gpt-6-astra
Provide a supported Jazzy environment for SIH/Gazebo development and source builds, with pinned tooling and reproducible multi-architecture image publishing. Separate package and container assets from ROS source preparation, and keep checkout workspaces fresh through a Python CLI.
Assisted-by: Copilot:gpt-6-astra
We would like to refactor agam-robotics directory to agam for ease of use
and brevity. boards/agam-robotics becomes boards/agam, making the build
target agam_fmu-v6xrt_default. The bundled bootloader is rebuilt under the
new target name.
Introduces a general UAVCAN_QUIRKS bitmask so workarounds for other
non-compliant DroneCAN devices can be added as new bits without
introducing a new parameter each time. Bit 0 covers the Hobbywing
ESC esc_index off-by-one quirk.
This adds siyi_unifc-6-pico flight controller board in addition to the docs provided for the same board in this PR.
Co-authored-by: zhucaigui <zhucaigui@siyi.biz>
* feat(navigator): precision takeoff with the vision target estimator
* fix(navigator): only remove the liftoff freeze when an actual target is detected
* feat(logger): log prec_takeoff_status as optional topic
* chore(vte): minor format
* fix(logger): move to topic behind CONFIG_MODULES_VISION_TARGET_ESTIMATOR
* fix(navigator): preserve corrected position on takeoff handoff
* docs(vte): rephrase VTE_AID_MASK
* rework(vte): clarify that home is used as the pad's abs position during prec takeoff
* fix(vte): clear cached relative mission position once task starts
* fix(takeoff): keep xy freez until TAKEOFF_STATE_FLIGHT
* feat(navigator): delay prec takeoff corrections by MIS_TKO_PREC_DLY
---------
Co-authored-by: jonas <jonas.perolini@rigi.tech>
* feat(afbrs50): static rate/DFM profiles, pipeline hardening, range offset calibration
The distance-based short/long range switching only re-evaluates after a
valid measurement, so once the target leaves the range the driver latches
short-range mode and the sensor stays blind; frames that fail evaluation
were never published, leaving consumers on the stale last value. Flight
characterization of the LV85D and LX85D showed frame rate is the dominant
range knob and DFM 4X beats the mode-default 8X on validity, spread and
wrong-window returns at every rate, so the switching is replaced by
SENS_AFBR_RATE / SENS_AFBR_DFM / SENS_AFBR_PROF with per-module defaults,
SENS_AFBR_MODE gains Auto (module default) with fallback when the API
rejects a mode, and the rate is clamped to the API's 5 Hz frame-time floor
that previously put CONFIGURE in a silent retry loop.
Invalid or quality-gated (SENS_AFBR_QMIN) frames now publish
max_distance + 1 with quality 0 so uavcannode emits TOO_FAR, and the max
distance is bounded by the configured unambiguous range.
Pipeline fixes: measurementReadyCallback dereferenced g_dev after its null
check, stop() deleted the object while a callback could still arrive, the
DRDY interrupt stayed bound to the destroyed handle, S2PI_Abort left the
bus BUSY forever, S2PI_Init leaked on restart, setRateAndDfm spun
unbounded, and a lost completion callback or wedged device stalled the
state machine for good. Non-OK result codes are counted by name for
'afbrs50 status'.
'afbrs50 cal' runs the vendor absolute range offset calibration on a
low-priority task (the sequence busy-waits and would starve the IWDG
feeder on wq:uavcan) and persists the offsets to SENS_AFBR_OFS_LO/HI.
* fix(afbrs50): evaluate every completed frame and guard CONFIGURE against stale completions
Argus_EvaluateData is what releases the API's raw data buffer, and the
API refuses new measurements and rejects configuration writes once two
buffers are held. An error-status callback skipped it, so two bad frames
wedged the driver into the stall recovery with nothing published.
The abort completion of that recovery, arriving from the SPI thread,
could overwrite CONFIGURE with TRIGGER and skip the reconfigure.
Also note the removed parameters in the 1.18 release notes.
* refactor(afbrs50): run the driver in its own task and the SPI transfers on the bus work queue
The transfer work item ran on wq:SPI0 (which does not exist on STM32
targets) purely for its near-top priority: before API 1.6.6 a DRDY
firing within ~60 us of the last SPI clock was lost unless the transfer
callback had already run. Since 1.6.6 ADS_SPI_Callback re-checks the
IRQ pin and recovers a DRDY that arrives before the callback, so the
deadline is gone and the transfer item can live on the work queue of
the bus the sensor actually sits on, at its conventional priority. The
blocking exchange stays on a work queue because the API requests
transfers from hrt interrupt context.
The state machine cannot share that thread: the API's configuration
calls spin in ADS_AwaitIdle until the transfer they queued completes.
It previously borrowed hp_default, whose 2800 byte stack
Argus_EvaluateData overflows and whose priority puts the driver's
blocking configuration waits ahead of dshot and pwm_out. It now runs as
a SCHED_PRIORITY_SLOW_DRIVER task woken by the completion callback
through a semaphore, so the range offset calibration no longer needs
its own task either: the driver drops to SCHED_PRIORITY_DEFAULT for the
duration of the sequence, below the wq:uavcan IWDG feeder, and a stop
request aborts it.
* fix(afbrs50): publish only NO_OBJECT as too far, reinit on stuck CONFIGURE, protect calibration
Every evaluation failure and quality-gated frame went out as max_distance + 1, which collision prevention clamps to max_distance and enters as free space regardless of signal_quality, so a sensor fault on a horizontal mount cleared a real obstacle. Only the device's own STATUS_ARGUS_NO_OBJECT is published that way now; errors and gated frames are counted and left to the consumers' stream timeouts.
CONFIGURE drains a raw buffer an abort may leave behind, since the API rejects configuration writes until it is evaluated, and falls back to Argus_ReinitMode after ten consecutive failures because a sticky error status never returns to IDLE on its own.
The vendor calibration sequence blocks longer than ModuleBase's 5 s stop deadline while holding pointers into the task stack, so 'afbrs50 stop' is refused while it runs and a stop clears a not-yet-started request. The sequence also rewrites the per-pixel offset tables, which cannot be persisted; they are restored afterwards so the sensor runs in the state the stored global offsets re-create at boot. The destructor now also stops the API's periodic timer, the last path that could reach the completion callback after ModuleBase has deleted the instance.
* fix(afbrs50): publish invalid frames with signal quality 0 instead of dropping them
Dropping errored and quality-gated frames left a receiver unable to tell a sensor returning invalid readings from one that fell off the bus. Every frame is published again with signal_quality 0 marking the invalid ones. The distance sent with it is chosen for collision prevention, which ignores quality: NO_OBJECT stays beyond max_distance (free space, TOO_FAR on DroneCAN), errors carry min_distance (discarded, UNDEFINED on DroneCAN), and a gated frame keeps its measured distance with the quality floored to 0.
On NuttX these are two things: / is the filesystem root, and /fs/microsd is the
SD card mounted under it. MAVLink FTP serves the root and confines writes to the
SD card, so the read-only ROMFS at /etc is visible but cannot be written.
On POSIX they were the same directory. PX4_ROOTFSDIR and PX4_STORAGEDIR both
resolved to CONFIG_BOARD_ROOT_PATH, which on SITL is ".", so the working
directory was simultaneously the FTP root and the only writable area. The
consequences were that the ROMFS symlink sat inside the FTP root, and that
_validatePathIsWritable() had nothing meaningful to check against and so was
compiled out on POSIX entirely, leaving no write restriction at all.
Give POSIX the same split. CONFIG_BOARD_ROOT_PATH keeps its meaning as the
storage directory, and a new CONFIG_BOARD_FS_ROOT_PATH names the root FTP
serves, defaulting to the storage path so every existing board is unchanged.
SITL sets the root to "." and storage to "./fs", which mirrors NuttX: logs,
parameters, dataman and eeprom move under ./fs, and etc/ stays in the root as
read-only data.
With storage distinct from the root, the write restriction now applies on every
platform rather than NuttX only, and no longer compares against a hardcoded
prefix length that was wrong for any board not using /fs/microsd.
Assisted-by: Claude:claude-opus-5[1m]
Signed-off-by: Julian Oes <julian@oes.ch>
Expose PX4 guidance and workflows to Codex while keeping root instructions concise and reusing tracked Claude workflows where possible.
Assisted-by: Copilot:gpt-6-astra
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The macOS setup page has not been edited since 2026-04-20, while
Tools/setup/macos.sh changed five times after that. The page still
describes the px4-sim Homebrew formula, which has been a deprecated
no-op in PX4/homebrew-px4 since 2026-04-20, and tells users to add
simulation later with `brew install px4-sim`, which installs nothing.
On Homebrew 6.0+ it does not even load, because the page never mentions
the tap trust the script now performs.
Stop enumerating the script's packages and taps in the page; that list
is what went stale. Say what the script does in one sentence, point at
macos.sh as the source of truth, and document only the user-facing
behaviour: Gazebo, XQuartz and a JDK come with --sim-tools, that path
needs sudo, taps are trusted for Homebrew 6, and the way to add
simulation later is to re-run the script with --sim-tools. Drop the
Python prerequisite; the script installs Python and creates the venv
itself.
Fix the pages it links to that contradict it: the simulation overview
still marked Gazebo on Apple Silicon as unstable (pre-dates the
2026-04-20 fix), the supported-targets table claimed Gazebo Classic on
macOS with nothing installing it, the jMAVSim page said Java must be
installed manually on macOS, and the build troubleshooting page
recommended ulimit 300 and running mac_set_ulimit.sh as a script (which
cannot change the caller's shell limit).
Assisted-by: Claude:claude-fable-5
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Co-authored-by: Farhang <46557204+farhangnaderi@users.noreply.github.com>
