bvrtoverfitprimes cd900a8973 fix(mavlink): reject unsupported params in commands and missions (#27541)
* 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>
2026-07-02 10:11:56 +12:00
2026-07-01 13:06:45 +00:00

PX4 Autopilot

The autopilot stack the industry builds on.

Release DOI Discord

OpenSSF Best Practices LFX Health Score LFX Contributors LFX Active Contributors


About

PX4 is an open-source autopilot stack for drones and unmanned vehicles. It supports multirotors, fixed-wing, VTOL, rovers, and many more experimental platforms from racing quads to industrial survey aircraft. It runs on NuttX, Linux, and macOS. Licensed under BSD 3-Clause.

Why PX4

Modular architecture. PX4 is built around uORB, a DDS-compatible publish/subscribe middleware. Modules are fully parallelized and thread safe. You can build custom configurations and trim what you don't need.

Wide hardware support. PX4 runs on a wide range of autopilot boards and supports an extensive set of sensors, telemetry radios, and actuators through the Pixhawk ecosystem.

Developer friendly. First-class support for MAVLink and DDS / ROS 2 integration. Comprehensive SITL simulation, hardware-in-the-loop testing, and log analysis tools. An active developer community on Discord and the weekly dev call.

Vendor neutral governance. PX4 is hosted under the Dronecode Foundation, part of the Linux Foundation. Business-friendly BSD-3 license. No single vendor controls the roadmap.

Supported Vehicles

Multicopter
Multicopter
Fixed Wing
Fixed Wing
VTOL
VTOL
Rover
Rover

…and many more: helicopters, autogyros, airships, submarines, boats, and other experimental platforms. These frames have basic support but are not part of the regular flight-test program. See the full airframe reference.

Try PX4

Run PX4 in simulation with a single command. No build tools, no dependencies beyond Docker:

docker run --rm -it -p 14550:14550/udp px4io/px4-sitl:latest

Open QGroundControl and fly. See PX4 Simulation Quickstart for more options.

Build from Source

git clone https://github.com/PX4/PX4-Autopilot.git --recursive
cd PX4-Autopilot
make px4_sitl

Note

See the Development Guide for toolchain setup and build options.

Documentation & Resources

Resource Description
User Guide Build, configure, and fly with PX4
Developer Guide Modify the flight stack, add peripherals, port to new hardware
Airframe Reference Full list of supported frames
Autopilot Hardware Compatible flight controllers
Release Notes What's new in each release
Contribution Guide How to contribute to PX4

Community

Contributing

We welcome contributions of all kinds — bug reports, documentation, new features, and code reviews. Please read the Contribution Guide to get started.

Citation

If you use PX4 in academic work, please cite it. BibTeX:

@software{px4_autopilot,
  author    = {Meier, Lorenz and {The PX4 Contributors}},
  title     = {{PX4 Autopilot}},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.595432},
  url       = {https://px4.io}
}

The DOI above is a Zenodo concept DOI that always resolves to the latest release. For a version-pinned citation, see the Zenodo record or our CITATION.cff.

Governance

The PX4 Autopilot project is hosted by the Dronecode Foundation, a Linux Foundation Collaborative Project. Dronecode holds all PX4 trademarks and serves as the project's legal guardian, ensuring vendor-neutral stewardship — no single company owns the name or controls the roadmap. The source code is licensed under the BSD 3-Clause license, so you are free to use, modify, and distribute it in your own projects.

Dronecode Logo

Languages
C++ 51.2%
C 37.6%
CMake 4.6%
Python 4.2%
Shell 1.4%
Other 0.8%