* feat(zenoh): add support for configuring zenoh publisher options
Add zenoh parameters for common default options for all publishers. Options exposed are reliability, priority, congestion control and is_express
Allow override of common publisher options for specific publisher through its config: config fille supports additional row where multiple options can be specified with csv string
Expose config options through zenoh config add publisher.
Allow options per publisher to be specified for default config in zenoh/dds_topics.yaml
* fix(zenoh): Put individual zenoh publisher config override feature under config option ZENOH_PUB_OPTION_OVERRIDE
Enabled ZENOH_PUB_OPTION_OVERRIDE on targets with enough flash memory
* fix(zenoh): added publication options for default publications in dds_topics.yaml
Rare messages that are important to arive: set as reliable, enabled express and with blocking congesiton control
Fast vehcile position messages that can impact control decision making: set as best enabled express and with drop congestion control
* docs(zenoh) : added documentation for zenoh publisher options usage
* docs(docs): Link to params
---------
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
The bootloader boot-delay feature has been mechanically broken on
every modern FMU board since the STM32F7/H7 transition. It has three
independent bugs that prevent it from ever working:
1. Offset mismatch: BOOT_DELAY_ADDRESS is hardcoded to 0x1a0, but the
NuttX vector table is 504 B (F76x) to 664 B (H743) long. The
linker places _bootdelay_signature at ALIGN(32) past end of
vectors (e.g. 0x2a0 on CubeOrange), never at 0x1a0. The bootloader
reads random exception_common pointers in place of the magic and
never matches BOOT_DELAY_SIGNATURE1/2. Verified on CubeOrange with
objdump of cubepilot_cubeorange_default.elf.
2. Flash cache never flushes: fc_write() stores arbitrary writes in
cache line 1 and only flushes on a very specific condition tied
to the sequential firmware upload flow. A standalone write during
PROTO_SET_DELAY is cached forever. fc_read() then returns the
cached value, so the post-write verify lies and the bootloader
reports success. Nothing ever reaches flash.
3. H7 write granularity: the STM32H7 flash controller requires a
full 32-byte program cycle per write. Single 32-bit writes from
flash_func_write_word() would not be accepted by the controller
even if they reached it.
The feature has been silently dead on every H7/F7 FMU board for
years and no one noticed, which is strong evidence nothing actually
depends on it. Rather than fix it (which would mean rewriting
PROTO_SET_DELAY, the flash cache path, and the H7 flash programming
path), remove it.
Changes:
- bl.c: PROTO_SET_DELAY case now immediately NACKs (goto cmd_bad)
so clients that still send the command get a clear rejection
instead of the previous silent fake-success. The opcode stays in
the protocol enum for backwards compatibility.
- bl.h: drop BOOT_DELAY_SIGNATURE1/2 and BOOT_DELAY_MAX.
- stm/stm32_common/main.c, nxp/imxrt_common/main.c: drop the
startup boot-delay sig check block.
- image_toc.c: decouple find_toc() from BOOT_DELAY_ADDRESS.
BOARD_IMAGE_TOC_OFFSET is now the required define when
BOOTLOADER_USE_TOC is enabled. The body is wrapped in #ifdef
BOOTLOADER_USE_TOC and falls back to a stub returning false when
the TOC is not in use (no upstream board currently enables it).
- Linker scripts: strip EXTERN(_bootdelay_signature) and the
FILL/. += 8 block from all 142 affected .ld files across boards/.
- hw_config.h: strip the #define BOOT_DELAY_ADDRESS and its comment
block entry from all 48 affected boards.
- Tools/px4_uploader.py, Tools/teensy_uploader.py: remove --boot-delay,
set_boot_delay(), and SET_BOOT_DELAY client-side counterpart.
Smoke-built on cubepilot_cubeorange_default and
cubepilot_cubeorange_bootloader; no link errors, no unresolved
symbols, flash usage unchanged.
Tested:
- New BL, new FW
- Old BL, old FW
- Old BL, new FW
- New BL, old FW
* refactor: make timer_io_channels[].timer_channel 0-indexed
timer_channel was 1-indexed (1-4) to mirror STM32 hardware naming
(TIM_CH1-CH4), but this was purely cosmetic — the ccr_offset field
already handles register mapping. Every consumer did timer_channel - 1
to get a 0-based index, creating underflow bugs when the guard was
missing (e.g. dshot.c capture_complete_callback,
output_channel_from_timer_channel, up_bdshot_get_erpm).
Changes:
- STM32: Timer::Channel enum starts at 0, initIOTimerChannel assigns
directly, removed all timer_channel - 1 in dshot.c and io_timer.c
- NXP (kinetis, s32k1xx, s32k3xx): removed the + 1 in
initIOTimerChannel, removed timer_channel - 1 in io_timer.c,
led_pwm.cpp, and input_capture.c
- RPI: Channel enum starts at 0, removed timer_channel - 1 in
io_timer.c
- Validity checks updated from timer_channel <= 0 || >= 5 to
timer_channel >= 4
Closes#26747
Signed-off-by: Pavel Guzenfeld <pavelgu@gmail.com>
* fix: complete 0-indexed timer_channel migration across all platforms
Address review feedback for incomplete migration:
1. STM32H7 io_timer_hw_description.h: update standalone
initIOTimerChannel() to assign timer_channel from enum
(0-based) instead of hardcoded 1/2/3/4
2. Switch case labels: update all switch(timer_channel) blocks
from 1/2/3/4 to 0/1/2/3 in:
- stm32_common: input_capture.c (4 blocks), led_pwm.cpp (3),
io_timer.c DMA base register switch
- kinetis: input_capture.c (2 filter blocks)
- s32k1xx: input_capture.c (2 filter blocks)
- spix_sync.c (ark/fpv + ark/pi6x, 3 blocks each)
3. Sentinel checks: replace timer_channel != 0 / == 0 (which
now conflicts with valid channel 0) with gpio_out-based
checks in:
- io_timer_validate_channel_index() across all 5 platforms
- led_pwm_channel_init() and led_pwm_servo_get() in all
led_pwm.cpp variants (STM32 + 4 NXP)
- spix_sync_channel_init() and spix_sync_servo_get()
Tested: px4_fmu-v6x_default (H7) build OK, px4_sitl_default
build OK, 154/154 unit tests pass, ASan build clean.
* fix: update NXP board led_pwm_channels to 0-indexed timer_channel
These 4 board files manually specify led_pwm_channels[] with
1-indexed timer_channel values. Since the platform code no longer
subtracts 1, decrement all values to match the new 0-indexed
convention.
* fix: correct FTM CH3 filter mask in kinetis and s32k1xx input capture
Case 3 in up_input_capture_set_filter() was using CH2FVAL_MASK/SHIFT
instead of CH3FVAL_MASK/SHIFT due to a copy-paste error, causing
channel 3 filter writes to modify channel 2's filter register instead.
---------
Signed-off-by: Pavel Guzenfeld <pavelgu@gmail.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
It was added at a time where the triplet target was directly fed as position setpoint to the controller.
Since the smoothing improvements to FlightTaskAuto(SmoothVel) and removing the previous "aggressive" FlightTaskAuto variant there should be no need anymore for this logic. It can sometimes lead to unexpected sideffects. E.g. the vehicle would suddenly change direction when exceeding some arbitrary threshold.
* rt106x: Use platform SPI hal layer
* rt106x: Add romapi support and reboot to isp/bootloader
* bootloader: imxrt_common: Add rt106x support
* NXP MR-Tropic initial commit
* Add missing file for mr-tropic bootloader
* nxp-mr-tropic:Bootloader Alow Assertion debugging & Keep Ram Vectors
* nxp-mr-tropic: Firmware Boot from bootloader
* nxp-mr-tropic:Add Bootloader bin file
* mr-tropic: Update config and linker
Fixes enet issues with write-back and some code cleanup.
Furthermore increase NOR LittleFS to 256kB to reflect on linker
* Update NuttX
* mr-tropic: fix itcm apping and add mr-tropic to itcm check
---------
Co-authored-by: David Sidrane <David.Sidrane@NscDg.com>
* s32k3xx: EMIOS allow independent frequencies for each channel
* mr-canhubk3: update config
* mr-canhubk344: Fix adap board detect
* mr-canhubk344: Use LPSPI1 (Port P1A) for SD card
* airframes: Add B3RB Ackermann rover config
See https://nxp.gitbook.io/mr-b3rb for more information about the NXP
B3RB platform. PX4 Support basic control for now
- split up old module into two, one handling setpoint generation, one control
- add lateral and longitudinal control setpoints topics that can also be
injected from companion computer
- add configuration topics that (optionally) configure the controller
with limits and momentary settings
Signed-off-by: RomanBapst <bapstroman@gmail.com>
192.168.0.x is often used by routers for WIFI/ethernet networks, and thus
can create conflicts.
This can happen for example if a companion is connected to the FMU via
ethernet and at the same time connects to a WIFI network as DHCP client.
* usb: Added parameter to enable always starting mavlink on USB.
Refactored cdcacm_init into a module and added a paramter to allow always starting mavlink on
USB, also added a paramter to choose the mode. The current default behavior is to wait and listen
for data on USB and auto-detect the protocol (mavlink, nsh, ublox). This results in the mavlink
stream not starting until something else on the mavlink network sends a packet first. The new
default behavior is to always start mavlink.
Added parameters
MAV_USB_ENABLE -- default 1 (always start mavlink on USB)
MAV_USE_MODE -- default 3 (onboard)
* added 3 retries for opening serial port in mavlink, removed sleep before sercon
* added DRIVERS_CDCACM_AUTOSTART to ark-v6x default.px4board
* added CONFIG_DRIVERS_CDCACM_AUTOSTART=y to default.px4board for boards with CONFIG_CDCACM in their nsh/defconfig
* format
* remove PGA460 from COMMON_DISTANCE_SENSOR to save flash
* remove LIS2MDL from COMMON_MAGNETOMETER to save flash
* disable CONFIG_DRIVERS_CDCACM_AUTOSTART for fmu-v5 protected.px4board
* moved and renamed parameters, removed mode logic in mavlink
* changed parameter names, added mode none
* remove parameters from mavlink
Vuk-SFL
Matthias Grob
Julian Oes
Pablo
Andrew Brahim
Pavel Guzenfeld
palvarben
Jacob Dahl
Jacob Dahl
PX4 BuildBot
Peter van der Perk
Peter van der Perk
Claudio Chies
Alexander Lerach
chfriedrich98
Silvan
RomanBapst
co63oc
Peter van der Perk
BazookaJoe1900
Beat Küng