Adds documentation for the SITL containers and .deb packages introduced in #26495. The containers are now live on Docker Hub: [`px4io/px4-sitl:latest`](https://hub.docker.com/r/px4io/px4-sitl) and [`px4io/px4-sitl-gazebo:latest`](https://hub.docker.com/r/px4io/px4-sitl-gazebo).
The main addition is a [Try PX4 Simulation](https://docs.px4.io/main/en/dev_setup/try_px4) page that leads with a single `docker run` command and gets someone flying in under a minute. It lives in Getting Started, right after Recommended Hardware/Setup, so it's one of the first things new users see.
The existing `.deb` package reference has been moved from `packaging/px4_sitl_deb.md` to `simulation/px4_sitl.md` and expanded to cover both containers and `.deb` packages on one page. Sections are ordered by how people use them: what's available, install, configure, connect QGC/MAVSDK, connect ROS 2.
Other changes:
- README now has a "Try PX4" section with the docker one-liner above "Build from Source"
- Landing page (`index.md`) reworked to lead with "Try PX4" before "For Developers"
- Toolchain page (`dev_env.md`) gets a tip redirecting simulation-only users to pre-built packages
- `getting_started.md` and `SUMMARY.md` updated with links to the new pages
- Simulation index tip updated to mention containers alongside `.deb` packages
The SIH container image is published as `px4io/px4-sitl` (renamed from `px4io/px4-sitl-sih`) so the default lightweight option carries the simplest name. The Gazebo image remains `px4io/px4-sitl-gazebo`.
Also upgrades all GitHub Actions in the SITL workflow to Node.js 24 compatible versions (`actions/checkout@v6`, `actions/cache@v5`, `actions/upload-artifact@v7`, `actions/download-artifact@v8`, `docker/setup-buildx-action@v4`, `docker/build-push-action@v7`) to fix the Node.js 20 deprecation warning ahead of the June 2026 deadline.
---------
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Split the maintainer role into two types to make it easier to grow the
bench without asking new contributors to commit to a specific component
up front. Code Owners keep their existing scoped responsibility for a
category, while Reviewers help across the project without ownership of
any specific area. Both are full maintainers, share the @PX4/dev-team
GitHub team, and have the same write access and voting rights.
Rename the Active Maintainers table to Code Owners with no change to
the current roster. Add an empty Reviewers table so future nominations
land in their own PRs. Update the contributor docs to describe the two
types, cover both in the recruitment and onboarding flow, and note the
promotion path from Reviewer to Code Owner.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
