Cross-correlation scripts to measure CAN transport delay from flight
logs. Compares CAN sensor signals against the FC's directly-connected
IMU to estimate the total pipeline latency.
- range_sensor_latency.py: cross-correlates range rate with IMU-derived
vertical velocity
- flow_sensor_latency.py: cross-correlates flow sensor gyro with FC gyro
* platforms/common/uORB/uORB.h: Add definition for orb_sub_t and handle check functions
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
* uORB: Change subscriber id:s from int to orb_sub_t
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
* uxrce_dds_client: Change polling of transport device from px4_poll to poll
Use posix poll directly, there is no need to use px4_poll unless uORBs are
being polled.
The one used here is a normal filesystem/device poll, so we can use normal "poll",
this is the common pattern in the codebase.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
* Fix linking for protected build
This fixes errors for memalign not linking on some configurations.
Memalign exists in nuttx kernel-side mm library and it may fail in configurations
where kernel and userspace are separated. This has no effect on other than
"CONFIG_BUILD_PROTECTED" or "CONFIG_BUILD_KERNEL" NuttX builds.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
---------
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Co-authored-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
* feat(Commander): add COM_FLTMODE_BOOT parameter for configurable flight mode on boot
This adds COM_FLTMODE_BOOT, an enum parameter (Altitude/Position/Hold/Stabilized, default Hold) that controls the nav_state set on boot, before any user mode command is received.
The navStateFromParam() translation function (previously a ManualControl method) has been moved to mode_util::navStateFromFlightModeParam() in ModeUtil/conversions.hpp so COM_FLTMODE_BOOT can follow the same enumeration as COM_FLTMODE* params.
* chore(commander): use nav_state for mode mapping
* feat(commander): extend list of modes available
* chore: fix style
* refactor(commander): simplify COM_FLTMODE_BOOT boot mode initialization
Apply the configured boot flight mode directly in the Commander
constructor.
Also removes the stick-presence-based mode logic (everHadModeChange
check in manualControlCheck), and changes the default to Position (NAVIGATION_STATE_POSCTL).
* chore: remove accidental whitespace
* chore: set default COM_FLTMODE_BOOT to Hold (nav_state 4)
* feat: add Takeoff state to COM_FLTMODE_BOOT
This fixes the issue that the External mdoes were all shifted down by one,
causing issues on the ground station with identifying the correct mode.
Signed-off-by: Silvan <silvan@auterion.com>
Option to keep a gimbal pointing at a fixed attitude, not linked to any user input.
Roll and Yaw angle setpoints are 0, Pitch can be set in separate parameter.
Both Vtx.msg and InputRc.msg exist upstream but were never wired up
as DDS topics. The VTX driver (added in c0c265cd) publishes vtx status
and InputRc has existed since 2015. Expose them over DDS so companion
computers and ROS2 nodes can monitor VTX state and raw RC input.
Signed-off-by: Phil-Engljaehringer <philipp.engljahringer@auterion.com>
#27605 gated the dshot/pwm_out start on `param compare -s PASSTHRU_EN 0`.
PASSTHRU_EN is registered only when the serialpassthrough driver is
compiled in, which is not the case on most boards (e.g. fmu-v5x). There
param_find() fails, `param compare` returns "no match", the else branch
runs, and the FMU outputs never start: the PWM_AUX group disappears from
the Actuators screen and motors wired to those pins won't arm. SITL uses a
separate init.d-posix rcS and is unaffected, so CI did not catch it.
Use the start-unless-explicitly-enabled idiom already used elsewhere in
rcS (`param greater -s`): only skip the outputs when PASSTHRU_EN is
explicitly > 0. A missing or zero parameter starts the outputs as before.
* docs(hardware): rewrite board support guide around real process
The board support guide described a theoretical category-first process that
no longer matches how board support actually happens. Manufacturers were
left unsure of the concrete steps, leading to repeated email requests for
guidance.
Restructure the guide around the actual GitHub-driven flow: build your own
firmware target, reserve a board ID via a PX4-Bootloader PR, provide a
unique USB VID/PID, demonstrate flight with logs, and open the PR. Keep the
support categories as a reference section that explains support
responsibility rather than process.
Spell out that QGroundControl uses the USB VID/PID to identify hardware, and
warn that reusing another vendor's pair causes misidentification. Promote
the ArduPilot board-ID alignment note and point it at the current hwdef
location. Demote VER/REV ID to a clearly-deprecated edge case: explain the
resistor/EEPROM mechanism and its original cross-vendor baseboard/FMU intent,
note the ecosystem has deviated from it, and that Dronecode no longer offers
standards validation. Update the Discord link to chat.dronecode.org.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* docs(hardware): align porting guide with board support guide
The porting guide's 'Officially Supported Hardware' section restated the
board support process and contradicted the rewritten board support guide.
It also told manufacturers to ship hardware to the dev team for port
validation, a service Dronecode no longer offers.
Replace that section with a short pointer to the board support guide, which
is now the single source of truth for the support process, and keep only the
high-level support benefits and maintenance expectations. The technical
porting content (architecture, file layout, host OS config, RC UART wiring)
is unchanged.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* docs(hardware): make board support guide discoverable for manufacturers
The board support guide was only reachable by navigating into the hardware
integration section. A manufacturer browsing the user-facing autopilot pages,
the exact audience, had no path to it, and one of those pages still stated
the obsolete 4-month compatibility commitment.
Add 'how to get your board supported' pointers from the manufacturer-supported
and experimental autopilot pages, the flight controller index, and the
development landing page. Remove the stale 4-month rule from the
manufacturer-supported page. Strengthen the guide's opening paragraph so the
phrases manufacturers actually search appear up front.
Word the links to avoid conflating the guide (how to get a board supported)
with the 'Manufacturer Supported' category (one of several support levels).
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* docs(docs): Minor tweaks
---------
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Remove broken anchor link to modules_driver.md#rc-input which does not
exist. Use inline code formatting instead.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Add hardware documentation for the VOLOLAND NarinFC-H7 flight controller
including pinouts, serial port mapping, PWM output groups, and analog
inputs. Fix version badge to v1.17 and clarify RC_IN is wired directly
to FMU via RC_INPUT driver.
Based on work by @vololand and @hamishwillee from PR #26542.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* fix(fw_latlon_control): do not reset alt err time constant on every param update
https://github.com/PX4/PX4-Autopilot/pull/23519 introduced this reset
using setForcedValue in the constructor of FixedwingPositionControl
https://github.com/PX4/PX4-Autopilot/pull/24056 accidentally moved it
from the constructor to the parameters_update
This means that now the time constant is reset to the tighter
low-altitude value (intended for use below FW_T_THR_LOW_HGT by
https://github.com/PX4/PX4-Autopilot/pull/23519) even though we could be
arbitrarily high.
Fix: Move both slew rate (given by a static constexpr) and initial reset
to constructor.
* style(fw_latlon_control): remove superficial newline
