* boards: enable CONFIG_FS_LARGEFILE for NuttX boards with MMC/SD
Without large file support, fsblkcnt_t/off_t are 32-bit and statfs
consumers (procfs /fs/usage, df) compute the volume size as
f_bsize * f_blocks in 32 bits, which wraps at 4GB. Boards with an
SD card or eMMC larger than 4GB report the wrong capacity, e.g. a
32GB SD card on FMU-V6X:
nsh> ls -l /dev/mmcsd0
brw-rw-rw-1850212352 /dev/mmcsd0 (= 31914983424 mod 2^32)
nsh> df -h
vfat 1749M 240K 1749M /fs/microsd
With CONFIG_FS_LARGEFILE=y the same card reports the full 29G.
This enables the option on the 77 boards that build the MMC/SD block
driver (CONFIG_MMCSD=y, SDIO or SPI). Boards without removable storage
and constrained-flash targets (CONFIG_BOARD_CONSTRAINED_FLASH=y) are
left unchanged.
Note: on the px4_firmware_nuttx-10.3.0+ branch the 64-bit file types
are additionally gated on CONFIG_HAVE_LONG_LONG, which is only defined
via nuttx/compiler.h include order, making the option unreliable. That
gating is fixed by the companion NuttX backport PR
(PX4/NuttX, branch backport-fs-largefile, upstream commit 92b2f1bd3d3).
Tested on a custom STM32H743 board with 8GB eMMC and on FMU-V6X with a
32GB SD card.
* fix(boards): enable CONFIG_FS_LARGEFILE for MMC/SD variant configs
The test/console/stackcheck/socketcan/sysview/cyphal/debug/cryptotest
variant configs of boards covered by the previous commit were missed,
leaving them with 32-bit off_t. fmu-v5 protected is intentionally
excluded: protected-mode syscall proxies keep 32-bit widths.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* chore(nuttx): bump submodule for FS_LARGEFILE backport
Picks up the backport of upstream NuttX 92b2f1bd3d3, which gates the
64-bit file types on CONFIG_FS_LARGEFILE alone instead of the
include-order-dependent CONFIG_HAVE_LONG_LONG.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
---------
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
The per-channel send mutex is genuinely recursive: callers hold lock_send()
while the MAVLink C library re-enters send_start()/send_finish() on the same
mutex via MAVLINK_START_UART_SEND. On NuttX a recursive mutex only works with
CONFIG_PTHREAD_MUTEX_TYPES; without it pthread_mutexattr_settype() is a no-op
and the nested lock deadlocks. Only a handful of boards happened to enable the
option (for Zenoh), so mavlink could deadlock at startup on most boards, e.g.
when bringing up a USB link.
Enable CONFIG_PTHREAD_MUTEX_TYPES on the NuttX boards that build mavlink, add
a compile-time guard so a board missing the option fails the build loudly
instead of deadlocking silently, and check the settype() return. Enabling the
option is free in flash and RAM on these boards since they already enable
CONFIG_PRIORITY_INHERITANCE / CONFIG_PTHREAD_MUTEX_ROBUST.
Signed-off-by: Julian Oes <julian@oes.ch>
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
* heater: add multi-instance support, refactor parameter handling, remove legacy params file
This change introduces multi-instance heater support to allow independent temperature control for multiple IMUs.
Main changes:
- Add support for multiple heater instances
- Refactor parameter handling to use per-instance parameters
- Remove the legacy parameter file and migrate to the updated parameter structure
This improves scalability and makes heater configuration consistent across setups with multiple sensors.
* Refactor heater configuration across multiple boards
- Updated heater GPIO definitions to introduce a new naming convention for better clarity and consistency.
- Replaced `GPIO_HEATER_OUTPUT` with `GPIO_HEATER1_OUTPUT` and adjusted the corresponding output enable macros.
- Changed parameter names from `SENS_TEMP_ID` to `HEATER1_IMU_ID` in various board default configurations to reflect the new heater setup.
- Ensured all affected board configurations are updated to maintain functionality with the new heater definitions.
* heater: fix missing HEATER1_OUTPUT_EN control
* heater: fix more missing HEATER1_OUTPUT_EN control
* heater: tidy config, docs, and instance handling
- Remove unused controller period member and use CONTROLLER_PERIOD_DEFAULT
- Improve HEATER${i}_IMU_ID description and instance-related logging/behavior
- Add a guard when HEATER_NUM exceeds HEATER_MAX_INSTANCES
Note: drop intermediate/reverted change around the 'celsius' spelling.
* heater: refactor constructor to remove unused parameter and add instance name function
- Remove unused ModuleParams argument from Heater constructor
- Add heater_instance_name() helper to provide per-instance work queue task names
- Use instance-specific parameter lookup (HEATER{n}_*) during initialization
Use heater_instance_name() to label each instance (heater_1/2/3) in work queue.
Also drop unused ModuleParams argument from constructor and keep per-instance
parameter handle lookup in initialization.
* format
* board: update GPIO configuration for multiple heater instances, add HEATER_NUM for boards using PX4IO
* heater: update heater control to use HEATER1_OUTPUT_EN when using PX4IO for consistency
* heater: add a TODO for px4io multi-instance
* heater: update missing GPIO_HEATER1_OUTPUT in sky-drones
* heater: fix multiple newlines at EOF (resolve CI check failure)
* heater: switch to PublicationMulti for heater_status and log multi-instance
- Changed _heater_status_pub from Publication to PublicationMulti to support independent per-instance publications without overwriting.
- Updated logged_topics.cpp to use add_optional_topic_multi("heater_status")
This fixes the issue where multiple heater instances were writing to the same heater_status topic, causing data overwriting and incorrect update rates in logs.
---------
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
Since we have SYS_DM_BACKEND, the user has to option on all boards
to store the mission on the RAM, thus thus define got obsolete.
Signed-off-by: Silvan <silvan@auterion.com>
* 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
- re-enable once the estimator selector respects configured mag
priority (at least initially) or is otherwise able to automatically
prefer an external mag over internal
- for SITL disabled because the full matrix of esitmator instances
(IMUs X mags) was too many topics for logger currently
- during casual testing on default configs the stack was penetration was reaching ~90% which is a bit too close for comfort
- increasing by 50% to be conservative
* Fixedwing rate control into a separate module
* Start fw_rate_control for vtol
* Move over airspeed related parameters to fw_rate_control
Co-authored-by: Silvan Fuhrer <silvan@auterion.com>
This feature allows user to use a Gripper type pacakge delivery
mechanism on a drone to trigger the delivery during a mission via the
mission item `DO_GRIPPER`.
This is a minimal change that is intended to have simplest pacakge
delivery feature on PX4, however the future scope would extend this
feature out of Navigator, and rather move towards a federated PX4
(flight-mode flexibility) architecture. But until then, this will serve
the purpose.
Update Tools/sitl_gazebo submodule to remove sdf file overwrite error
- There was an error happening due to .sdf file being overwritten, it
was caused by a wrongfully added. sdf file.
- This update pulls in the PR commit: https://github.com/Auterion/sitl_gazebo/pull/147
Initial cut on supporing PAYLOAD_PLACE mission item
Tidy and comment on navigation.h to clarify mission item definition
- Convert vehicle command ack subscription data type to
SubscriptionData, to not care about having a dedicated struct for
copying the latest data
- Tidy and comment on navigation.h to clarify the definition of
mission_item_s, which is confusing as it is an intergration of MAVLink
Standard into PX4's internal Mission Item structure
Rename mission_block's mission item reached function & cleanup navigator
- Isolated Handle Vehicle Commands function inside the Navigator
- Rename mission_block's mission item reached function to 'reached or
completed', as the navigation command can also be an action (e.g.
DO_SET_SERVO, which doesn't make sense to refer to as 'reached' when we
have successfully done executed the command)
Include MAVLink PR commit to include payload_drop message
More changes to add payload_drop MAVLink message support
- Comitting for testing purposes
Add mission item payload_drop to vehicle command payload drop link
- Now with a mission item with the nav_cmd set to 'payload drop', the
appropriate 'payload drop' vehicle command will be issued
Make Payload drop executable via Mission Plan
Implement payload_drop module to simulate payload delivery
- Simple module that acknowledges the payload drop vehicle command after
certain time, to simulate a successful delivery
Additional changes - payload drop module not working yet
- Need to do more thread stuff to make it work :(
Fix Payload Drop enum mismatch in vehicle_command enums
- First functional Payload Drop Implementation MVP
- Simple Ack & resuming mission from Navigator tested successfully
Hold the position while executing payload drop mission item
- Still the position hold is not solid, maybe I am missing something in
the position setpoint part and all the internal implications of
Navigator :(
Add DO_WINCH command support
Some fixes after rebase on develop branch
- Some missed brackets
- Some comment edits, etc
Add DO_WINCH command support
- Still has a problem of flying away from the waypoint while the
DO_WINCH is being executed, probably position setpoint related stuff :(
Apply braking of the vehicle for DO_WINCH command
- Copies the behavior of NAV_CMD_DELAY, which executes a smooth, braking
behavior when executing the delay because of the braking condition in
`set_mission_items` function
- This will not apply to Fixed wings
- The payload deploy getting triggered may be too early, as right now as
soon as the vehicle approaches the waypoint within the acceptance
threshold, the payload gets deployed
Add DO_GRIPPER support
Implement Gripper actual Hardware triggering support
- Currently not working, possibly in the mixer there's a bug
- Implemented the publishing of actuator_controls_1 uORB topic
- Implemented the test command for the payload_drop module, to test the
grpiper functionality
- Edited px4board file to include the payload_drop module
- Added Holybro X500 V2 airframe file, to enable testing on X500 V2
- Created new Quad X Payload Delivery mixer, which maps the actuator
controls 1 topic's data into the MAIN pin 5 output
Make Payload Drop Gripper Work
- Initialization of the Gripper position to CLOSED on Constructor of the
payload_drop module
- Setting the OPEN and CLOSED value to the appropriate actuator controls
input
Set vehicle_command_ack message's timestamp correctly
- By not setting the timestamp, the ack commands were not correctly
graphed in PlotJuggler!
Rename payload drop module to payload deliverer
- I think it's a more complex name (harder to type), but more generic
Add Gripper class (WIP)
Add Gripper class functionalities
- Add gripper uORB message
- Add gripper state machine
Use Gripper class as main interface in payload_deliverer
- Utilizes Gripper class functions for doing Gripper functionality
Remove mixer based package delivery trigger logic
- Remove custom mixer files that mapped actuator controls to outputs
statically
Additional improvements of the payload_deliverer
Fix payload_deliverer module not starting
- _task_id wasn't geting set appropriately in task_spawn function, which
led to runtime failure
Add Gripper Function to mixer_module
- Still not showing up as function mapping in QGC, needs fix
Add parameters to control gripper behavior
- Now user can enable / disable gripper
- Also select which type of gripper to use
Applying review from nuno
Remove timeout fetching from mission item and use gripper's timeout
- Previously, it was planned to use a custom DO_GRIPPER and DO_WINCH
MAVLink message definitions with information on timeout, but since now
we are using original message definition, only relevant timeout
information is defined in the payload_deliverer class
- This change brings in the timeout parameter to the Navigator, which
then sets the timeout in the mission_block class level, which then
processes the timeout logic
Make payload deployment work for Allmend test :P
Support gripper open/close test commands in payload_deliverer
Move enum definition for GRIPPER_ACTION to vehicle_command.msg
Remove double call for ` ${R}etc/init.d/rc.vehicle_setup`
- Was introduced during the rebase
- Was causing module already running & uORB topic can't be advertised
errors
Fix format via `make format` command
Modify S500 airframe file to use for control allocation usage
- Added Control allocation related parameters as default to not have it
reset every time the airframe is selected
Implement mission specific payload deploy timeout and more changes
Switch payload_deliverer to run on work queue
Remove unnecessary files
- Airframe changes from enabling control allocation are removed
Address review comments
- Remove debug messages
- Remove unnecessary or verbose comments & code
- Properly call parameter_update() function
Switch payload_deliverer to scheduled interval work item & refactor
- Switch to Schedeuled on Interval Work Item, as previous vehicle
command subscription callback based behavior led to vehicle comamnd ack
not being sent accordingly (since the Run() wouldn't be called unless
there's a new vehicle command), leading to ack command not being sent
out
- Also, old vehicle commands were getting fetched due to the
subscription callback as well, which was removed with this patch
- Fix the wrong population of floating point param2 field of vehicle
command by int8_t type gripper action by creating dedicated function
- Refactor and add comments to increase readability
Add gripper::grabbing() method and handle this in parameter update
- Previously, the intermediate state 'grabbing' was not considered, and
when the parameter update was called after the first initialization of
the gripper, the grab() function was being called again, which would
produce unnecessary duplicate vehicle command.
- Also replaced direct .grab() access to sending vehicle comamnd, which
unifies the gripper actuation mechanism through vehicle commands.
Navigator: Change SubscriptionData to Subscription to reduce memory usage
- Also removed unused vehicle command ack sub
PayloadDeliverer: Remove unnecessary changes & Bring back vehicle_command sub cb
- new modules/simulation directory to collect all simulators and related modules
- new Tools/simulation directory to collect and organize scattered simulation submodules, scripts, etc
- simulation module renamed to simulator_mavlink
- sih renamed to simulator_sih (not a great name, but I wanted to be clear it was a simulator)
- ignition_simulator renamed to simulator_ignition_bridge
- large sitl_target.cmake split by simulation option and in some cases pushed to appropriate modules
- sitl targets broken down to what's actually available (eg jmavsim only has 1 model and 1 world)
- new Gazebo consistently referred to as Ignition for now (probably the least confusing thing until we fully drop Gazebo classic support someday)
- 4096 of 3 hex digits each for rev and ver is enough.
#defines used in SPI versions do not be long format, use use the macro
- Board provides a prefix and the formatting is sized and built in
- No need for funky board_get_base_eeprom_mtd_manifest interface
Original mft is used where the abstraction is done with the MFT interface
Co-authored-by: David Sidrane <David.Sidrane@Nscdg.com>
The boot order is now:
1. The PX4 bootloader boots, and starts the camera.
2. The camera starts and sends the boot command to the PX4 bootloader.
3. PX4 starts.
