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>
1.5 KiB
Community Supported & Experimental Autopilots
::: tip Are you a manufacturer who wants to get a board supported by PX4? See the Manufacturer's Board Support Guide. :::
::: tip For more information about PX4 project autopilot board support levels see: px4.io/autopilots/. :::
Experimental Autopilots
This category is for experimental autopilots (and autopilot "platforms") that are not supported by either the PX4 project team or by a manufacturer.
Boards in this category must work with at least one PX4 release for a defined vehicle type. They may not be compatible with the current PX4 release, and compatibility is not maintained by the project for future releases.
Experimental Vehicles
These are complete vehicles that have a fully integrated autopilot and other hardware (i.e. unlike the other autopilots listed, you can't use them in your own builds). They are listed in this page because from a PX4 software perspective, they are another autopilot.