19d669e542
* 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>
5.7 KiB
Flight Controller Porting Guide
This topic is for developers who want to port PX4 to work with new flight controller hardware.
PX4 Architecture
PX4 consists of two main layers: The board support and middleware layer on top of the host OS (NuttX, Linux or any other POSIX platform like Mac OS), and the applications (Flight Stack in src/modules). Please reference the PX4 Architectural Overview for more information.
This guide is focused only on the host OS and middleware as the applications/flight stack will run on any board target.
Flight Controller Configuration File Layout
Board startup and configuration files are located under /boards in each board's vendor-specific directory (i.e. boards/VENDOR/MODEL/).
For example, for FMUv5:
- (All) Board-specific files: /boards/px4/fmu-v5.
- Build configuration: /boards/px4/fmu-v5/default.px4board.
- Board-specific initialisation file: /boards/px4/fmu-v5/init/rc.board_defaults
- A board-specific initialisation file is automatically included in startup scripts if found under the boards directory at init/rc.board.
- The file is used to start sensors (and other things) that only exist on a particular board. It may also be used to set a board's default parameters, UART mappings, and any other special cases.
- For FMUv5 you can see all the Pixhawk 4 sensors being started, and it also sets a larger LOGGER_BUF.
Host Operating System Configuration
This section describes the purpose and location of the configuration files required for each supported host operating system to port them to new flight controller hardware.
NuttX
See NuttX Board Porting Guide.
Linux
Linux boards do not include the OS and kernel configuration. These are already provided by the Linux image available for the board (which needs to support the inertial sensors out of the box).
- boards/px4/raspberrypi/default.px4board - RPi cross-compilation.
Middleware Components and Configuration
This section describes the various middleware components, and the configuration file updates needed to port them to new flight controller hardware.
QuRT / Hexagon
- The start script is located in posix-configs/.
- The OS configuration is part of the default Linux image (TODO: Provide location of LINUX IMAGE and flash instructions).
- The PX4 middleware configuration is located in src/boards. TODO: ADD BUS CONFIG
RC UART Wiring Recommendations
It is generally recommended to connect RC via separate RX and TX pins to the microcontroller. If however RX and TX are connected together, the UART has to be put into singlewire mode to prevent any contention. This is done via board config and manifest files. One example is px4fmu-v5.
Getting Your Board Supported
This page covers the technical work of porting PX4 to new hardware. The process for getting that port reviewed, merged, and listed on the PX4 website, including board IDs, USB VID/PID, flight-test evidence, and maintenance expectations, is documented separately:
In short: build your own firmware target based on PX4, demonstrate stable flight on the current release, and open a pull request with your board support code, documentation, and flight logs. The board support guide explains each step.
The PX4 project supports and maintains the FMU standard reference hardware and any boards compatible with the standard, including the Pixhawk series (see the full list of supported hardware). Boards merged into PX4 benefit from a port in the repository, firmware builds accessible from QGroundControl, compatibility with the rest of the ecosystem, and automated CI checks.
:::tip The cost of maintaining a port is proportional to how far it diverges from the standard. Consider that cost before deviating: staying close to the reference design lets you benefit from day-to-day PX4 development with minimal maintenance burden. :::
Manufacturers are responsible for keeping their port up to date and working across PX4 releases. The PX4 project reserves the right to refuse or remove ports that do not meet the project's requirements, and all contributors are expected to follow the Code of Conduct.
Related Information
- Device Drivers - How to support new peripheral hardware (device drivers)
- Building the Code - How to build source and upload firmware
- Supported Flight Controllers:
- Autopilot Hardware
- Supported boards list (Github) - Boards for which PX4-Autopilot has specific code
- Supported Peripherals