pith. sign in

arxiv: 2604.03440 · v1 · submitted 2026-04-03 · 💻 cs.CE

ARES OS 2.0: An Orchestration Software Suite for Autonomous Experimentation Systems and Self-Driving Labs

Arthur W. N. Sloan , Robert W. Waelder , Morgen L. Smith , Nicholas Kleiner , Arnas Babeckis , Jason Wheeler , Daylond Hooper , Benji Maruyama This is my paper

Pith reviewed 2026-05-13 18:20 UTC · model grok-4.3

classification 💻 cs.CE
keywords autonomous experimentationself-driving labslaboratory automationorchestration softwareclosed-loop systemsservice-oriented architecturelab equipment integration
0
0 comments X

The pith

ARES OS 2.0 orchestrates lab hardware, analysis, and planning through a central service-oriented core that accepts user-written modules over protobuf and gRPC.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

ARES OS 2.0 is an open-source suite that coordinates actions and data flow among laboratory equipment, data-processing routines, and experimental-planning algorithms. Its core supplies central control, user-interface generation, data handling, and design tools, while external modules connect to it through a standardized protobuf-and-gRPC interface that is language-agnostic. Because the modules can be written by the researcher for any specific hardware, analysis step, or planning strategy, the framework removes the need to rebuild the entire automation stack for each new experiment. The result is that groups in materials science, chemistry, or biology can bring a closed-loop autonomous system online with less total engineering effort and can concentrate their programming on the science rather than on infrastructure.

Core claim

ARES OS 2.0 supplies a reusable orchestration layer that manages experimental actions and data handoff across arbitrary lab equipment, analysis routines, and planning modules by means of a service-oriented architecture; modules communicate with the core through protobuf and gRPC, making them language-independent and directly implementable by end users for their own hardware-control, data-processing, or experimental-design needs.

What carries the argument

The service-oriented architecture whose modules communicate with the central core via protobuf and gRPC, allowing language-agnostic, user-creatable components for hardware control, data processing, and experiment planning.

If this is right

  • New hardware can be added by writing only the module that talks to that device, without altering the rest of the automation stack.
  • Analysis routines written in any language can receive raw data and return results that immediately influence the next experimental choice.
  • Central data-management and user-interface services are supplied once, so each laboratory avoids re-implementing those layers.
  • The same core can support experimental flows across materials science, chemistry, and biology without domain-specific rewrites.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Labs without dedicated software engineers could adopt closed-loop experimentation sooner, shifting the bottleneck from infrastructure to scientific insight.
  • Standardized module interfaces might eventually allow community sharing of hardware drivers and planners, reducing duplicated effort across institutions.
  • The architecture could be extended to include remote or cloud-based planning modules that operate on data collected at multiple physical sites.

Load-bearing premise

That researchers can write and integrate their own hardware-control, data-processing, or planning modules through the protobuf-gRPC interface without substantial extra engineering or compatibility problems.

What would settle it

A timed test in which an independent researcher adds a previously unsupported piece of equipment as a new module and records the lines of code and hours required to achieve closed-loop operation.

Figures

Figures reproduced from arXiv: 2604.03440 by Arnas Babeckis, Arthur W. N. Sloan, Benji Maruyama, Daylond Hooper, Jason Wheeler, Morgen L. Smith, Nicholas Kleiner, Robert W. Waelder.

Figure 1
Figure 1. Figure 1: A closed loop, research autonomy process flow. Used with permission from [Stach et al., 2021]. Copyright [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
read the original abstract

ARES OS 2.0 (hereinafter ARES OS) is an open-source software suite to enable laboratory automation and closed-loop autonomous experimentation. Its function is to orchestrate experimental actions and data handoff between lab equipment, analysis routines, and experimental planning modules through a service-oriented architecture. ARES OS is abstracted to apply to general experimental flows common in materials science, chemistry, and biology and related disciplines. The core of ARES OS provides central control over all modules, along with the heavy lifting of UI creation, data management, and experimental design tools. ARES OS modules communicate with the core software over protobuf and gRPC, allowing them to be language-agnostic and user-creatable. This allows users to easily implement modules that control experimental hardware, process collected data , or plan experiments to meet their specific research needs. ARES OS lowers the barrier to entry for researchers to build their own self-driving labs, allowing them to focus on scientific programming for their use case and reducing the effort and time needed to bring an autonomous experimentation system online.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 1 minor

Summary. The manuscript presents ARES OS 2.0, an open-source software suite for orchestrating autonomous experimentation systems and self-driving labs. It employs a service-oriented architecture in which modules for hardware control, data processing, and experimental planning communicate with a central core via protobuf and gRPC, enabling language-agnostic, user-creatable components. The core supplies UI generation, data management, and experimental design tools, with the stated goal of lowering the barrier to entry so that researchers can focus on domain-specific scientific programming rather than infrastructure.

Significance. If the ease-of-use and time-reduction claims are substantiated with concrete implementation guidance and validation, the work could meaningfully advance autonomous experimentation by making self-driving lab setups more accessible across materials science, chemistry, and biology. The open-source release, general applicability to common experimental flows, and language-agnostic communication layer constitute clear strengths that would support broader adoption if demonstrated.

major comments (1)
  1. [Abstract] Abstract: The central claim that the protobuf/gRPC service architecture 'allows users to easily implement modules' and 'reduc[es] the effort and time needed to bring an autonomous experimentation system online' is load-bearing for the paper's contribution yet is unsupported by any .proto definitions, server-stub examples, registration procedures, measured development effort, or compatibility discussion (e.g., schema evolution or dependency management). Without these, the asserted reduction in barrier to entry remains unverified.
minor comments (1)
  1. [Abstract] Abstract: Typographical spacing error in 'process collected data , or plan experiments'.

Simulated Author's Rebuttal

1 responses · 1 unresolved

We thank the referee for their constructive and detailed review of our manuscript on ARES OS 2.0. We have carefully considered the major comment and provide a point-by-point response below, indicating the revisions we will incorporate.

read point-by-point responses

  1. Referee: [Abstract] Abstract: The central claim that the protobuf/gRPC service architecture 'allows users to easily implement modules' and 'reduc[es] the effort and time needed to bring an autonomous experimentation system online' is load-bearing for the paper's contribution yet is unsupported by any .proto definitions, server-stub examples, registration procedures, measured development effort, or compatibility discussion (e.g., schema evolution or dependency management). Without these, the asserted reduction in barrier to entry remains unverified.

    Authors: We agree that the abstract's claims would be strengthened by explicit supporting material. In the revised manuscript we will add a new subsection (Implementation Details) that includes: (1) complete example .proto definitions for a representative hardware-control module and a data-analysis module; (2) minimal gRPC server-stub code snippets in Python (with a note on language-agnostic generation for C++ and Go); (3) the exact registration procedure used by the core to discover and load user modules via service descriptors; and (4) a short discussion of compatibility practices, including protobuf field numbering for schema evolution and dependency pinning via gRPC versioning. For the effort-reduction claim we will supply qualitative evidence drawn from our internal development logs and deployment in two self-driving-lab workflows, showing the reduction in boilerplate relative to a pure custom gRPC implementation. We cannot, however, provide quantitative user-study metrics of development time, as no controlled external evaluation was performed. revision: partial

standing simulated objections not resolved
  • Quantitative measurement of development-effort reduction (no controlled user studies were conducted).

Circularity Check

0 steps flagged

No circularity: software description contains no derivations or self-referential reductions

full rationale

The manuscript is a descriptive overview of an open-source software suite with a service-oriented architecture. It states that modules communicate via protobuf and gRPC to allow user-created, language-agnostic components for hardware control, data processing, and planning, and claims this lowers the barrier to entry. No equations, fitted parameters, uniqueness theorems, or derivation chains appear anywhere in the text. The central claim is presented as a direct consequence of the described design rather than derived from prior results via self-citation or ansatz. No load-bearing step reduces to its own inputs by construction, satisfying the criteria for a score of 0.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

This is a descriptive software paper with no mathematical models, data fitting, or physical postulates. No free parameters, axioms, or invented entities are introduced.

pith-pipeline@v0.9.0 · 5523 in / 1113 out tokens · 32134 ms · 2026-05-13T18:20:49.696537+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

9 extracted references · 9 canonical work pages

  1. [1]

    Nature Synthesis , author =

    ISSN 2731-0582. doi:10.1038/s44160-022-00231-0. Pavel Nikolaev, Daylond Hooper, Frederick Webber, Rahul Rao, Kevin Decker, Michael Krein, Jason Poleski, Rick Barto, and Benji Maruyama. Autonomy in Materials Research: A Case Study in Carbon Nanotube Growth.npj Computational Materials, 2:16031, October

    work page doi:10.1038/s44160-022-00231-0

  2. [2]

    frugal twin

    ISSN 2057-3960. doi:10/gf6r2r. Stanley Lo, Sterling G. Baird, Joshua Schrier, Ben Blaiszik, Nessa Carson, Ian Foster, Andrés Aguilar-Granda, Sergei V . Kalinin, Benji Maruyama, Maria Politi, Helen Tran, Taylor D. Sparks, and Alán Aspuru-Guzik. Review of low-cost self-driving laboratories in chemistry and materials science: The “frugal twin” concept.Digita...

    work page 2057

  3. [3]

    Martin Seifrid, Robert Pollice, Andrés Aguilar-Granda, Zamyla Morgan Chan, Kazuhiro Hotta, Cher Tian Ser, Jenya Vestfrid, Tony C

    doi:10.1039/D3DD00223C. Martin Seifrid, Robert Pollice, Andrés Aguilar-Granda, Zamyla Morgan Chan, Kazuhiro Hotta, Cher Tian Ser, Jenya Vestfrid, Tony C. Wu, and Alán Aspuru-Guzik. Autonomous Chemical Experiments: Challenges and Perspectives on Establishing a Self-Driving Lab.Accounts of Chemical Research, 55(17):2454–2466, September

    work page doi:10.1039/d3dd00223c

  4. [4]

    Accounts of Chemical Research , author =

    ISSN 0001-4842. doi:10.1021/acs.accounts.2c00220. AFRL-ARES. Pyares, 2026a. URLhttps://github.com/AFRL-ARES/PyAres. Self-Driving-Laboratories at Argonne. Madsci,

    work page doi:10.1021/acs.accounts.2c00220

  5. [5]

    doi:10.1016/j.matt.2024.04.022

    ISSN 2590-2393, 2590-2385. doi:10.1016/j.matt.2024.04.022. URL https: //www.cell.com/matter/abstract/S2590-2385(24)00195-4. 3 ARES OS 2.0A PREPRINT Mohammad Zaki, Carsten Prinz, and Bastian Ruehle. A Self-Driving Lab for Nano- and Advanced Materials Synthesis. 19(9):9029–9041,

    work page doi:10.1016/j.matt.2024.04.022 2024

  6. [6]

    ACS Nano , author =

    ISSN 1936-0851. doi:10.1021/acsnano.4c17504. URL https://doi.org/10.1021/ acsnano.4c17504. AFRL-ARES. Ares-launcher, 2026b. URLhttps://github.com/AFRL-ARES/ARES-Launcher. Robert Waelder, Chiwoo Park, Arthur Sloan, Jennifer Carpena-Núñez, Josh Yoho, Stephane Gorsse, Rahul Rao, and Benji Maruyama. Improved understanding of carbon nanotube growth via autonom...

    work page doi:10.1021/acsnano.4c17504 1936

  7. [7]

    doi:10.1016/j.carbon.2024.119356

    ISSN 0008-6223. doi:10.1016/j.carbon.2024.119356. John S. Bulmer, Arthur W. N. Sloan, Michael Glerum, Jennifer Carpena-Núñez, Robert Waelder, Jefford Humes, Adam M. Boies, Matteo Pasquali, Rahul Rao, and Benji Maruyama. Forecasting carbon nanotube diame- ter in floating catalyst chemical vapor deposition.Carbon, 201:719–733, January

    work page doi:10.1016/j.carbon.2024.119356 2024

  8. [8]

    doi:10.1016/j.carbon.2022.08.001

    ISSN 0008-6223. doi:10.1016/j.carbon.2022.08.001. James R. Deneault, Jorge Chang, Jay Myung, Daylond Hooper, Andrew Armstrong, Mark Pitt, and Benji Maruyama. Toward autonomous additive manufacturing: Bayesian optimization on a 3D printer.MRS Bulletin, 46(7):566–575, July

    work page doi:10.1016/j.carbon.2022.08.001 2022

  9. [9]

    doi:10/gmnwx7

    ISSN 1938-1425. doi:10/gmnwx7. 4

    work page 1938