Skip to main content
ADOS is developed in public repositories and contributions are welcome: bug reports, fixes, features, documentation and translations. There is no contributor licence agreement; your contribution is licensed under the repository’s own licence. See Open source for the repositories and their licences.

Kinds of contribution

Bug reports. Open a GitHub issue in the repository the bug affects. Include steps to reproduce, what you expected, what happened, and your environment (OS, browser, flight controller firmware, agent version, board). Logs and screenshots help. Fixes. Small fixes can go straight to a pull request. For larger fixes, open an issue first to agree on the approach. Features. Open an issue first so the approach can be discussed before you write code. Split large features into smaller pull requests. Documentation. Pull requests to this site, READMEs and code comments are welcome. Translations. Mission Control ships 16 languages. See Translations.

Set up a repository

For how the code in each repository is organized, see Project structure. For step-by-step code changes (adding a panel, a decoder, a board), see Code recipes.
Needs Node.js 20 or later with npm, Git, and a Chromium-based browser for WebSerial.
npm run demo starts the app at http://localhost:4000 with simulated drones; npm run dev starts it without demo data. Before you open a pull request:
ADOSExtensions holds the first-party extensions. Bug reports there are welcome; to build and publish your own extension, start with Your first plugin.

Pull requests

  1. Fork the repository and create a branch from main.
  2. Keep each pull request to one feature or fix.
  3. Add or update tests for new behaviour, and run the repository’s checks listed above.
  4. Describe what changed, why, and how you tested it. Add screenshots or a recording for UI changes.
  5. Do not bump version numbers; maintainers handle releases.
Mission Control changes that touch the protocol layer, calibration or pre-arm checks need testing on real hardware as well as in demo mode.

Branch names

Each repository’s own CONTRIBUTING.md sets its branch scheme:

Code style

  • Mission Control: TypeScript strict mode with no any; Zustand for shared state, one store per domain; Tailwind tokens instead of arbitrary values; every component correct on the dark theme. Flight controller access goes through the DroneProtocol interface only.
  • Drone Agent: Ruff for linting, mypy for types, Google-style docstrings.
  • Android GCS: the official Kotlin style, 4-space indentation, no wildcard imports, lines up to 120 characters.

Translations

Mission Control’s translation files live at locales/<code>.json in the ADOSMissionControl repository. locales/en.json is the reference. To improve a language, compare its file with locales/en.json, translate missing or placeholder values, and open a pull request. Use the terms pilots in that language actually use, keep labels short, and never translate parameter names such as MOT_SPIN_ARM. To add a language, copy locales/en.json to locales/<code>.json, translate it, and add the code to locales and localeNames in src/i18n.ts.

Report a security issue

Do not open a public issue for a vulnerability. Email team@altnautica.com with the details, and we will work with you on a fix and coordinated disclosure.

Code of conduct

Be respectful, constructive and specific. Harassment, discrimination and personal attacks are not tolerated. Report problems to team@altnautica.com.

Next steps

Project structure

How each repository is laid out.

Code recipes

Step-by-step recipes for common code changes.

System overview

How the parts fit together before you change them.

Community

Ask questions on Discord.
Last modified on October 11, 2026