* 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>
* Add vitepress tree
* Update existing workflows so they dont trigger on changes in the docs path
* Add nojekyll, package.json, LICENCE etc
* Add crowdin docs upload/download scripts
* Add docs flaw checker workflows
* Used docs prefix for docs workflows
* Crowdin obvious fixes
* ci: docs move to self hosted runner
runs on a beefy server for faster builds
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* ci: don't run build action for docs or ci changes
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* ci: update runners
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
* Add docs/en
* Add docs assets and scripts
* Fix up editlinks to point to PX4 sources
* Download just the translations that are supported
* Add translation sources for zh, uk, ko
* Update latest tranlsation and uorb graphs
* update vitepress to latest
---------
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Co-authored-by: Ramon Roche <mrpollo@gmail.com>
