Skip to main content

Contributing to ARES

Welcome to the ARES project! We're happy that you are interested in contributing. Developed at the Air Force Research Laboratory (AFRL), ARES relies on an open community of researchers and developers to accelerate the pace of scientific discovery through closed-loop autonomous experimentation.

Whether you are a scientist looking to integrate an experimental setup or a developer aiming to improve the core orchestration engine, your contributions are welcome.

The ARES Ecosystem​

ARES is highly modular. Before contributing, it is helpful to know which part of the ecosystem you are working with:

  • ARES OS: The core orchestration engine. Written in C#/.NET with a Blazor frontend, it handles the registration of devices, planners, and analyzers as well as workflow execution.
  • ARES Launcher: The desktop management hub that simplifies installation, version management, and database management.
  • PyAres: Our official Python library, designed to make scientific integration as seamless as possible for researchers.
  • Educational ARES: A specialized, low-cost version of ARES for educational environments, built around autonomous 3D printing (e.g., Prusa MK4S).
  • ARES-Datamodel: The source of truth for communication. It contains the Protobuf and gRPC definitions that power our language-agnostic plugin architecture.

Contribution Pathways​

Depending on what you are building, the process for sharing your work with the community looks a bit different.

1. Plugins (Device Drivers, Planners, Analyzers)​

Because ARES uses a highly decoupled, "Plugin-First" architecture, custom hardware drivers, AI planners, and data analysis routines do not need to be merged into the core ARES repositories. You can develop and host these tools entirely on your own.

If you have built a device driver, planner, or analyzer that you believe would be valuable to the wider ARES community, you don't need to submit a pull qequest. Instead, we want to feature it! Please email a member of our team (see Contact & Support below) to discuss adding your plugin to our official list of supported ARES tools.

2. Core Development (ARES OS, PyAres, Datamodel)​

If you are fixing a bug, adding a core feature to the orchestration engine, updating the Python library, or modifying the datamodel, you will follow a standard open-source GitHub workflow. You will fork the relevant repository, test your changes locally, and submit a Pull Request (see the Submitting Core Contributions section below).

Opening Issues​

If you find a bug, have a feature request, or need to discuss a major change before starting work, please open an issue in the relevant repository!

Before creating a new issue, please search existing issues to see if your topic has already been reported or requested. This helps avoid duplicates and keeps discussions centralized.

When opening an issue, please include the following depending on your context:

  • Bug Reports: Provide detailed steps to reproduce the issue, the expected behavior versus the actual behavior, and details about your environment (OS, ARES version, relevant hardware, Python/.NET versions). Include error logs if applicable.
  • Feature Requests: Give a clear description of the requested feature, the specific scientific or technical use case it solves (as allowed), and any proposed implementation details.
  • Architecture Discussions: If you are planning a major refactor or a significant new plugin, open an issue first to discuss it with the maintainers. This ensures your work aligns with the project's roadmap and prevents wasted development effort.

Getting Started​

Depending on the repository you are contributing to, you will need slightly different local setups.

Prerequisites​

  • For ARES OS & Plugins: .NET 10 SDK and an IDE like Visual Studio, JetBrains Rider, or VS Code.
  • For PyAres: Python 3.10+ and your preferred Python environment manager.
  • For Datamodel Changes: Ensure you have the Protocol Buffer Compiler (protoc) installed if you are generating custom gRPC classes manually.
  • Git: For version control.

Local Setup​

  1. Fork the relevant repository from the AFRL-ARES GitHub Organization.
  2. Clone your fork locally: 
    git clone [https://github.com/YOUR-USERNAME/REPOSITORY-NAME.git](https://github.com/YOUR-USERNAME/REPOSITORY-NAME.git)
    cd REPOSITORY-NAME
  3. Follow the repository-specific README for instructions on building and running the project locally.

Development Philosophy​

ARES is built with a "Plugin-First" philosophy.

  • Keep it Modular: New hardware integrations, planners, or analysis tools should be developed as plugins rather than tightly coupled into ARES OS.
  • gRPC & Protobuf: We leverage gRPC for high-performance, scalable communication. If your contribution requires changes to how plugins communicate with the core OS, those changes must start in the ARES-datamodel repository.
  • Language-Agnostic Design: Remember that ARES connects C#/.NET environments with Python data science stacks. Maintain clean, standardized API contracts.

Submitting Core Contributions​

We use a standard GitHub Pull Request (PR) workflow.

  1. Create a Feature Branch: Always branch off of main for your work. Use descriptive names like feat/add-modbus-driver or fix/exeuction-ui-bug. 
    git checkout -b feat/your-feature-name
  2. Write Clean, Documented Code: Ensure your code follows the style conventions of the respective language (e.g., PEP 8 for Python, standard C# naming conventions).
  3. Commit your Changes: Write clear, concise commit messages.
  4. Push to your Fork: 
    git push origin feat/your-feature-name
  5. Open a Pull Request: Open a PR against the main branch of the original AFRL-ARES repository.

Pull Request Guidelines​

  • Describe the Change: Clearly explain what the PR does, it's neccessity, and how it was tested.
  • Link Issues: If your PR resolves an open issue, link it (e.g., "Resolves #42").
  • Be Patient: Our maintainers will review your PR as soon as possible. We may suggest some tweaks or ask for additional tests before merging.

Licensing​

ARES is open-source and primarily licensed under the MIT License. By contributing to this project, you agree that your contributions will be licensed under the project's standard MIT License. Please check individual repositories if specific license terms apply.

Clearance​

ARES Clearance: Distribution A. Approved for public release: distribution unlimited. AFRL-2025-5329
PyAres Clearance: Distribution A. Approved for public release: distribution unlimited. AFRL-2025-5332.

Contact & Support​

If you have questions before you start building, we are happy to help!