* 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>
