ardupilot_wiki is the source and build pipeline behind the ArduPilot docs

The repository is the source, not a copy

The README is short and it makes the relationship clear. The first line points to the wiki site for the human-friendly view, and the repository title is ArduPilot Documentation Source Files.

So the published site is generated from this tree, and the repository holds the reStructuredText, the Sphinx configuration, the build scripts and the JavaScript that adds the offline reading feature. The top level entries make the structure plain: ardupilot/, blimp/, copter/, plane/, rover/, mavproxy/, sub/ and planner2/ are the documentation sections, common/ holds shared content, and frontend/ holds the browser-side code.

Two entries at the root are worth noticing because they explain what the build does. update.py and update.sh are the build entry points, and build_parameters.py with rst_table.py is the parameter table generator, which pulls the parameter metadata out of the ArduPilot source and renders it as documentation tables. The tables you see in the published parameter documentation are not hand written, and the fact that they are generated is why they lag the code by days.

The Dockerfile, the Makefile, the Vagrantfile, Sphinxsetup.sh and Sphinxsetup.bat, and the requirements.txt and package.json together form the build environment, and the presence of a Vagrantfile suggests a local VM path for contributors who do not want to set the environment up by hand.

The last push was on 2026-10-22 and the repository is not archived. The licence is recorded as a custom one that GitHub cannot classify, so the LICENSE file at the root is the authoritative text.

How the site gets rebuilt

The README states the cadence plainly: the wiki site is updated every ~24 hours, and updated parameter tables are generated every 2-3 days.

Those two intervals are different on purpose, and they tell you how the pipeline is prioritised. The prose documentation is rebuilt daily, so a documentation fix appears on the site within a day. The parameter tables wait two or three days because generating them means cloning and parsing the ArduPilot source tree, which the Dockerfile makes explicit with a build argument named PARAMVERSIONING that controls whether the parameter versioning directories are populated at image build time.

The requirements file shows the toolchain. Sphinx is pinned per Python version, sphinx==7.1.2 for Python 3.8 and sphinx==7.2.6 for anything newer, with a comment that the docutils version is there for correct bullet point rendering and can be rolled forward once the theme is updated. The theme itself is a git reference pinned to a specific commit of the ArduPilot sphinx_rtd_theme repository, described as a squash-merged pull request whose offline hooks the conf.py requests whenever the installed theme declares them. There are also the sphinxcontrib-youtube plugin, beautifulsoup4 for pulling posts from the Discourse forum into the front end, lxml for parameter parsing, and Pillow for the video stills and the lossless PNG pass, with the comment that both are no-ops without it.

The Python tooling is Ruff, configured in pyproject.toml with a line length of 127, a py310 target, and a select list that enables refurb, isort, an avoidable escaped quote check, and two printf and f-string upgrade rules. Codespell is configured alongside it with a custom ignore list for the domain vocabulary of the project, including sitl, parm and extint, and it skips the ARCHIVED directory, the LICENSE, and the ai, pdf and svg files.

The offline reading feature, and the tests around it

The most interesting engineering in this repository is the offline reading feature, and the package.json exists to test it.

The description of the npm package is explicit about the division of labour: Test suites for the offline reading feature, service worker, offline page, exporter. The wiki is built by update.py, and npm is needed only to run these tests. So node is not part of the documentation build, it is the test harness for the browser-side code.

The scripts show what is covered:

    "test:worker": "node scripts/tests/test_offline_worker.js",
    "test:panel": "node scripts/tests/test_offline_page.js",
    "test:export": "node scripts/tests/test_offline_export.js",
    "test:archives": "python3 scripts/tests/test_offline_archives.py",
    "test:browsers": "node scripts/tests/test_offline_browsers.js",
    "serve": "node scripts/tests/serve_wiki_tree.js 8000",
    "test:images": "python3 scripts/tests/test_optimise_images.py"

The full test script chains a good deal together, running the offline page, worker and export tests, the PWA video test, several Python test modules for archives, lazy YouTube, raw iframes, image resizing and image optimisation, and a unittest for the image cache wiring in the update build. The export test takes an optional set of documentation trees as arguments, and there is a full variant that raises the Node heap to 8192 megabytes with --max-old-space-size, which is a tell that the exporter is memory hungry on the larger sections.

The dev dependencies are jsdom at 29.1.1 and playwright at 1.62.1. Playwright drives a real browser, which is the only honest way to test a service worker, and jsdom covers the parts that do not need a browser.

The serve script, node scripts/tests/serve_wiki_tree.js 8000, serves the wiki tree locally, which is how a contributor checks the offline behaviour without deploying.

How to report a documentation problem

The README spends more words on process than on technology, and the process is unusually strict for a documentation repository.

Known missing, incorrect, or outdated content goes to the Issues tracker, and if the problem is not already listed you submit a new issue. But support questions are explicitly not welcome there, and the instruction is that they will be immediately closed. The alternative is to chat on Discord or post on the Discuss forum, and both links are given.

Pull requests are for improvements that are in progress, and the guidance splits them by size. Review existing pull requests if you are familiar with the topics being documented. Submit new pull requests for quick fixes and to resolve issues, following the wiki editing guide for how to make changes including environment setup.

The issue linkage convention is worth knowing because it is mechanical. Include Resolves #ISSUE_NUMBER in the pull request description if you are fixing a listed issue, which automatically closes the issue when the pull request is merged. If you are not fully resolving an issue, include Relevant to #ISSUE_NUMBER instead.

And then the part that sets expectations: pull requests get reviewed by wiki maintainers before they can be accepted, and you should be prepared to discuss and make updates.

The quick fixes are linked separately in the README, which is a hint that the project wants small contributions to be easy to make while larger documentation work is expected to be discussed first. There is a pre-commit configuration in the repository root, and the requirements file describes pre-commit as the tool used to run rapid tools like linters, spellcheckers and formatters, so the formatting gate runs before the review rather than after it.

The container build, and the parameter versioning trick

The Dockerfile is where the build environment is pinned, and it has two details worth understanding.

The base is python:3.12-slim-trixie with a noninteractive frontend, and the image creates an ardupilot user with uid and gid 1000 and gives that user passwordless sudo through a sudoers file, which is the usual arrangement for a build container that needs to install system packages. The Sphinxsetup.sh script and requirements.txt are bind-mounted into the build, and the script is run to install the documentation dependencies.

The second detail is the parameter versioning. The Dockerfile takes a build argument named PARAMVERSIONING, defaulting to 0. When it is 1, the build clones the ArduPilot repository, creates new_params_mversion and old_params_mversion directories, and symlinks /new_params_mversion and /old_params_mversion into place. When it is anything else, the build prints Not building paramversionning and moves on.

That switch exists because building the parameter documentation requires the ArduPilot source tree, and for most documentation work that is a large clone that is not needed. So the expensive part is opt-in at image build time, and the parameter tables that appear on the site are built from a pinned source state rather than from whatever is on the branch at that moment. The two directories, new and old, are the mechanism by which a parameter's history is rendered.

The repository also has a docker_update_py.sh script and a .dockerignore, and a dev/ directory for development tooling, plus copter/, plane/, rover/, blimp/ and sub/ directories for the vehicle-specific documentation.

Where ardupilot_wiki fits, and where it stops

The comparison worth making is with the alternatives for getting ArduPilot documentation offline or into a different format.

Against the website itself, this repository is strictly more capable in one direction and less in another. More capable because the offline reading feature, the service worker and the exporter exist only here, and because a fork can be built with your own content, your own theme and your own parameter versioning. Less capable because the live site is what most people want, and it is updated daily with the same content plus the search index and the forum integration.

Against a generated PDF manual, the difference is that this pipeline does not produce one. The output is a website with a service worker, an offline page and an exporter for the documentation tree. A team that needs a printable manual or a single file to hand to a technician is not served by this repository

The limits are structural and they are visible in the tooling. The parameter tables are generated from the ArduPilot source tree and are therefore two to three days behind the code, so a parameter added in a commit today is not in the tables yet. The build depends on a pinned git commit of a theme repository, a pinned Sphinx version per Python version, and a docutils version held below 0.19 for bullet rendering, with the comment that it can be rolled forward once the theme is updated. Those pins are what make the build reproducible, and they are also what a maintainer has to move when upstream moves.

The contribution path is the other limit. Documentation fixes are reviewed by maintainers and may require discussion, support questions are closed on sight, and the everyday path for a user with a question is Discord or the forum rather than the issue tracker. That is a deliberate separation, and it is the one thing a contributor should internalise before opening an issue.

For a project the size of ArduPilot, with documentation that has to work for people on a field laptop with no connectivity, the offline machinery here is the part that earns the repository its place.

Editorial conclusion

ardupilot_wiki suits an ArduPilot user who needs the documentation offline or in a bundled form, since the service worker, the offline page and the exporter are built and tested here, and it suits a developer who wants to fix or extend the docs rather than only read them. It is the wrong repository if you are looking for the ArduPilot source code itself, and the wrong tool if you want a static PDF manual, because the pipeline's output is the website. Before contributing, read the wiki editing guide linked from the README, and note the release cadence: the site is updated roughly every 24 hours and the parameter tables every two to three days.

Frequently asked questions

Official sources

1. ArduPilot/ardupilot_wiki on GitHub
2. Issues
3. README