Currently, this bogus number of vertices is reported:
nsh> navigator status
INFO [navigator] Running
INFO [navigator] Geofence: 1 inclusion, 6 exclusion polygons, 0 inclusion circles, 2 exclusion circles, 83345 total vertices
The code that reports it accumulates _polygons[i].vertex_count. But for
circles, that field is a float (union), so we get a random large integer
from casing it implicitly.
struct PolygonInfo {
uint16_t fence_type; ///< one of MAV_CMD_NAV_FENCE_*
uint16_t dataman_index;
union {
uint16_t vertex_count;
float circle_radius;
};
};
Solution: only add vertex_count if we are dealing with a polygon.
Also shorten the overall string slightly, and reorder to make it clear
the vertices belong to the polygons rather than the circles.
* fix(mavlink): reject unsupported params in commands and missions
PX4 accepted any non-NaN value in params it does not use for a given
MAV_CMD, silently storing or ignoring them. This made it impossible for
a GCS to detect that a mission item or command was malformed, and risked
unexpected behaviour if the param meaning is assigned in a future update.
Add mavlink_command_params.h: a header-only sorted lookup table mapping
each supported MAV_CMD to uint8 bitmasks (one for mission items, one for
commands) indicating which of params 1-4 are valid. check_params() does
a binary search and returns the 1-based index of the first offending
param, or 0 if all unsupported params are unset.
A param is considered unset when it is NaN (the MAVLink standard) or 0.0
(the conventional GCS default for unused float fields). Any other value
in an unsupported slot is rejected:
- Mission uploads (MISSION_ITEM / MISSION_ITEM_INT): NACK with
MAV_MISSION_INVALID_PARAMn for the offending param index.
- Commands (COMMAND_LONG / COMMAND_INT): ACK with MAV_RESULT_DENIED.
Validation is placed at the MAVLink ingress boundary
(parse_mavlink_mission_item and handle_message_command_both) before any
downstream processing, keeping Commander and Navigator unmodified.
The table covers all 45 MAV_CMDs handled by PX4's mission and command
parsers. The static_assert enforces sort order at compile time.
Fixes#27483
Signed-off-by: Himaghna <pen314paper@gmail.com>
* fix(mavlink): split mission/command p5-7 masks, fix int_mode branch, add vehicle overrides
Signed-off-by: Himaghna <pen314paper@gmail.com>
* fix(mavlink): fix 142-char lines and Python CI type/style errors
Signed-off-by: Himaghna <pen314paper@gmail.com>
* fix(mavlink): pack p5-7 bits into mission/command byte, fix astyle/type-limits/mypy
* fix(mavlink): range-for over VehicleParamOverrides, fix mypy ignore code
* fix(mavlink): wire check_params_for_vehicle, add int variant, drop non-vehicle check_params
Signed-off-by: Himaghna <pen314paper@gmail.com>
* fix(mavlink): suppress clang unused-function on check_params_*_for_vehicle
Signed-off-by: Himaghna <pen314paper@gmail.com>
* fix(mavlink): rename local vs to avoid shadow in handle_message_command_both
Signed-off-by: Himaghna <pen314paper@gmail.com>
* fix(mavlink): cache vehicle_type_bitmask as member, update on vehicle_status change
Signed-off-by: Himaghna <pen314paper@gmail.com>
* fix(mavlink): use named VEHICLE_TYPE_* consts, fix masks, drop WARN spam, fix int_mode cast
Signed-off-by: Himaghna <pen314paper@gmail.com>
* fix(mavlink): normalize INT32_MAX to 0 for MAV_FRAME_MISSION p5/p6 in int_mode
For MAV_FRAME_MISSION items, x/y are generic p5/p6 params (not lat/lon),
so GCS tools send 0 for unused params — not INT32_MAX. Using
check_params_int_for_vehicle here caused int_param_is_unset(0)=false,
which rejected valid DO_LAND_START and similar items with x=y=0.
Fix by normalizing INT32_MAX to 0.0f before calling check_params_for_vehicle,
so both the MISSION_ITEM_INT sentinel and the conventional float zero are
treated as unset. This restores acceptance of zero-param items like
DO_LAND_START while still correctly rejecting items that carry non-zero,
non-sentinel values in unsupported param slots.
Signed-off-by: Himaghna <pen314paper@gmail.com>
* fix(mavlink): address review feedback on VTOL masks, NaN sentinel, dead enum, and RTL test frame
* fix(mavlink): move param validation test out of mavsdk_tests, rename header to .hpp
* fix(mavlink): dedupe param-scan loop shared by check_params_for_vehicle variants
---------
Signed-off-by: Himaghna <pen314paper@gmail.com>
Setpoints published from the same offboardControl() call come from the
same offboard input update.
Use one timestamp for all of them so messages from the same update do
not get slightly different timestamps.
Signed-off-by: Onur Özkan <work@onurozkan.dev>
* refactor(ROMFS): remove trailing zeros from all airframes
* refactor(ROMFS): remove allignment whitespace from all startup scripts
* feat(romfs_pruner): strip end of line comments in startup scripts
and airframes to not waste any flash.
* feat(romfs_pruner): strip inline multi-whitespace
* fix typo
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
The sihsim_xvert currently tumbles immediately on takeoff. Here is why:
generate_ts_aerodynamics in sih.cpp calculates elevon torques.
everything is rotated into the fixed-wing frame, in which
- positive _u[4] (configured as CA_SV_CS0) generates positive FW roll
torque (left wing pushed up)
- positive _u[5] (configured as CA_SV_CS1) generates positive FW roll
torque (right wing pushed down, note the additional minus)
So in the FW frame, they work like this:
- positive _u[4] + _u[5] -> positive FW roll torque
- positive _u[4] - _u[5] -> positive FW pitch torque
The airframe file however configures all of these in the multicopter
frame. So accounting for the frame conversion, we have:
- MC yaw = -FW roll = -_u[4] - _u[5]
- because FW x points nose-forward while MC z points nose-backward
- MC pitch = FW pitch = _u[4] - _u[5]
or in matrix form:
[ MC yaw ] [ -1 -1 ] [ _u[4] ]
[ MC pitch ] = [ 1 -1 ] [ _u[5] ]
and as this matrix is basically (up to scaling)
[ CS0_TRQ_Y CS1_TRQ_Y ]
[ CS0_TRQ_P CS1_TRQ_P ]
we have to change the CS1_TRQ_* coefficients to be negative.
* feat(manual_control): trigger RC override on stick velocity
COM_RC_STICK_OV is now a velocity threshold (1/s) instead of a deflection percentage.
Default 3.0, range [1.0, 10.0]. A stick held statically cannot trigger override.
* docs(manual_control): update COM_RC_STICK_OV description for velocity-based override
* feat(manual_control): gate RC override with sign-consistency check
* fix(ManualControl): lower threshold and filter constant for RC override, add tests for MovingDiff
* refactor(commander): merge RC override params into COM_RC_OVR_SPEED
Replace the COM_RC_OVERRIDE bitmask + COM_RC_STICK_OV threshold with a
single float COM_RC_OVR_SPEED (stick override velocity, 0 = disabled).
Override now applies uniformly in auto and offboard modes.
- ManualControl: rename param, treat 0 as disabled (FLT_EPSILON guard)
- Commander: drop the per-mode bitmask gate and the RcOverrideBits enum
- param_translation: migrate COM_RC_OVERRIDE on import (enabled -> 1.0,
disabled -> 0.0) and drop the unit-incompatible COM_RC_STICK_OV value
- docs: collapse the two params into one across the mode pages
* fix(manual_override): Move configuration to manual_control module
with MAN_OVERRIDE_SPD parameter and a negative value disabling the feature. All other logic stays in Commander.
* docs(releases): add release note for RC override rework (MAN_OVERRIDE_SPD)
---------
Co-authored-by: Matthias Grob <maetugr@gmail.com>
When GNSS height is configured as height reference and GNSS mode is set
to dead-reckoning, it is now able to be the height reference if starting
can be done without reset.
A seq_cst px4::atomic emits a hardware `dmb` on ARM. That barrier only orders
accesses as seen by a second observer (another CPU core or DMA); for inter-thread
synchronisation on a single-core (uniprocessor) target there is no second core, so
the `dmb` is dead weight - only the compiler ordering is required.
On a NuttX build without CONFIG_SMP, keep full seq_cst semantics but emit a
compiler-only fence (__atomic_signal_fence, zero instructions) instead of the
`dmb`. This mirrors Linux, where smp_mb()/smp_rmb()/smp_wmb() collapse to a
compiler barrier on uniprocessor builds. SMP NuttX and POSIX are unchanged (real
barriers, so SITL under ThreadSanitizer keeps full ordering). 64-bit types (not
lock-free on a 32-bit core) keep the existing interrupts-off critical section,
which already provides both atomicity and ordering.
The public API is unchanged - no per-call ordering knob. Verified on
arm-none-eabi Cortex-M7 that the single-core path emits no `dmb` while keeping
atomicity, and that SMP/POSIX is unchanged:
load (single-core): ldr (signal_fence: 0 instr)
store (single-core): str
fadd (single-core): ldrex/strex loop, no dmb
load (seq_cst/SMP): dmb ish; ldr; dmb ish
store (seq_cst/SMP): dmb ish; str; dmb ish
fadd (seq_cst/SMP): dmb ish; ldrex/strex; dmb ish
Shrinks fmu-v6x by ~2.8 KB (dead barriers removed from atomics already in use),
with no behaviour change. Note: inter-thread ordering only - DMA/device sync
still needs explicit barriers.
The serial port autodetect computed an offset relative to a ">" prompt
without verifying that there were enough preceding bytes in the read
buffer. When the prompt landed near the start of the buffer the size_t
offset arithmetic underflowed and the subsequent copy read before the
buffer.
Replace the buffer_offset heuristic with a direct check that the prompt
sits at least four bytes into the read buffer before computing the port
name offset, and use signed pointer arithmetic on the address difference
so the underflow is no longer reachable.
Refs: GHSA-v78g-fxg8-gv3j
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
List the VID/PID sourcing options in order of preference: buy your own
from USB-IF, obtain a free pair from a community registry or chip-vendor
program, or use the Dronecode VID. Add a note clarifying that Dronecode
membership is not required to get a board supported in PX4.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* add files
* add corvon_V5 docs
docs: fix connectors image path
* docs: address Copilot formatting suggestions
* Subedit
* docs: add radio control wiring details for corvon_V5
* Update docs/en/flight_controller/corvon_V5.md
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* boards/corvon: rename V5 subdirectory to v5
This renames the corvon_V5 board to corvon_v5 to conform to PX4 lowercase naming conventions as requested by @mrpollo. Renames target files, docs, and assets accordingly.
* Apply suggestion from @hamishwillee
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* docs: add DSU7 debug port pinout and warnings for corvon_v5
This addresses reviewer feedback to include debug port information, placed immediately after the Radio Control section as requested.
* Apply suggestion from @hamishwillee
* fix(boards/corvon_v5): remove unused heater and temperature_compensation
- heater: board has no IMU heater; fixes build after #26325 (requires HEATER_NUM)
- temperature_compensation: modern IMU doesn't need it, follow #27015
Signed-off-by: holydust <holydust@live.ca>
* docs(update): Subedit. Add pwm outputs and gps
* Update docs/en/flight_controller/corvon_v5.md
* Update docs/en/flight_controller/corvon_v5.md
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* docs(corvon_v5): add UART flow control, power details, fix broken links
* docs(corvon_v5): fix UART table typo
* fix(boards/corvon_v5): remove unused PX4IO macros. Board has no PX4IO co-processor
Signed-off-by: holydust <holydust@live.ca>
* Apply suggestions from code review
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* docs(corvon_v5): update board images
Signed-off-by: holydust <holydust@live.ca>
* fix(corvon_v5): drop unused dshot, fix can3 and adc comments
- Remove CONFIG_DRIVERS_DSHOT=y from default.px4board: DShot is not
supported on this board (no IO timer is DShot-configured) and the
docs already state it as unsupported.
- Fix ADC1_IN8 GPIO list comment from PB8 to PB0 (PB0 is the correct
pin on STM32F765; matches GPIO_RSSI_IN definition below).
- Clarify CAN3 comment in nuttx-config board.h: the pins are unused
on CORVON_V5 (no transceiver populated). manifest.c already marks
CAN3 as not present.
- Update corvon_v5_pinout.xlsx 'All Pinouts' sheet so PA7 (HEATER)
and PA8/PA15/PH4 (CAN3 RX/TX/SILENT) read 'Unused', matching the
actual hardware.
Signed-off-by: holydust <holydust@live.ca>
* fix(corvon_v5): use MCS Electronics USB VID/PID
Set VID/PID to 0x16D0/0x152A (MCS Electronics) in the app defconfig
and regenerate the bootloader binary, replacing the 3DR FMUv5 IDs
inherited from the reference config.
Signed-off-by: holydust <holydust@live.ca>
---------
Signed-off-by: holydust <holydust@live.ca>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* Add Sony AS-DT1 Distance Sensor and Documentation
* Ensuring Rotation Parameter works
* Sony ASDT1 Sensor and Documentaiton
* Fixed formatting and added additional comments
* Forgot to stage 1 formatting issue
* fix(drivers): use AS-DT1 parameters consistently
remove the Sony-ASDT1 -R command line rotation, as well as some other small fixes. Updated the docs to reflect this as well.
* refactor(drivers): clarify Sony AS-DT1 variable names
---------
Co-authored-by: Sean Hickey <sean@ascendengineer.com>
Co-authored-by: Andrew Brahim <35986980+dirksavage88@users.noreply.github.com>
Subscribe to pps_capture on the node, learn the offset (rtc_timestamp -
timestamp) per PPS edge, and stamp fix2.timestamp = hrt_now + offset so it
is UTC-coherent with gnss_timestamp. Unfired or stale (>5 s) PPS leaves
timestamp zero, so the FC guard falls through to SENS_GPS*_DELAY.
PB2 has no timer alternate function on the F412, so declare
PPS_CAPTURE_GPIO for the EXTI path, enable CONFIG_DRIVERS_PPS_CAPTURE, and
start pps_capture from rc.board_sensors.
When PPS_CAPTURE_GPIO is defined, init() configures the pin directly with
px4_arch_gpiosetevent and skips io_timer, so CAN nodes (no PWM outputs, no
timer AF on the pin) can capture PPS over EXTI. FMU boards keep the
unchanged io_timer path.
Map Fix2.timestamp into HRT with the clock-offset estimator and subtract
the node-reported processing delay (timestamp - gnss_timestamp) to set
timestamp_sample. Nodes that leave timestamp zero or non-UTC fail the
guard and fall through to the SENS_GPS*_DELAY path.
Estimates the offset between a remote node clock and FC HRT by tracking
the minimum of (local - remote), then maps remote timestamps into HRT;
residual bias is the minimum observed transport latency. Unit-tested for
convergence, jitter hold, and clock-discontinuity reset.
