MetriPlane v0.2.0: replayed workcell state → evidence bundle → regression test

Projects
, , ,
1

Hi Open Robotics community,

I released MetriPlane v0.2.0, an open-source physical-observability tool for bounded workcells.

The short version:

MetriPlane turns replayed or calibrated workcell state into physical events, incidents, Cell Truth Reports, evidence bundles, local bundle verification, and generated regression tests.

I am preparing a SoftwareX research-software paper while finishing my MSc thesis, and I am looking for external technical feedback from robotics, simulation, digital-twin, manufacturing, and research-software people.

3-minute demo

The demo shows a replayed missing-tool scenario:

missing required tool
→ physical event log
→ Cell Truth Report
→ INC-0001 evidence bundle
→ local bundle verification
→ generated regression test
→ regression PASS

Repository and archived release

Repository:

v0.2.0 release:

Zenodo archive / DOI:

External reproduction issue:

What MetriPlane is trying to solve

Robotics and manufacturing systems often have logs, cameras, simulators, and dashboards, but still lack a simple reproducible way to answer:

What physically happened?
Where did it happen?
What proves it?
Can we replay it?
Can we turn the incident into a software check?

MetriPlane v0.2.0 focuses on this narrow layer: replayable physical evidence for bounded workcells.

It is not meant to replace a robot controller, MES, safety system, simulator, or full digital-twin platform. It is an observe-only evidence layer around physical workcell state.

Main v0.2.0 workflow

The v0.2.0 demo path is camera-free and uses a deterministic assembly-cell replay.

The system generates:

  • physical event ledger
  • process deviation
  • incident INC-0001
  • Cell Truth Report
  • portable evidence bundle
  • bundle manifest and checksums
  • replay command
  • generated physical regression test
  • local verification result
  • static dashboard/report artifacts

The key idea is that an observed physical incident should not remain only a one-time log entry. It should become a reviewable and repeatable software artifact.

Why I am posting here

I would value external feedback from people who work with robotics software, ROS, simulation, digital twins, perception, manufacturing automation, or research software.

The most useful help would be a camera-free reproduction attempt through this issue:

A useful public comment would include:

OS:
Python version:

doctor: pass/fail
deterministic replay: pass/fail
Atlas assembly-cell run: pass/fail
bundle verify: pass/fail
generated regression test: pass/fail

Technical relevance:
2–5 sentences on whether this seems relevant to robotics, simulation, digital twins, manufacturing, or research software.

Main limitation:
1–2 sentences on what should be improved, bounded, or validated next.

Critical feedback is more useful than praise.

Camera-free reproduction path

The full path is in Issue #6, but the core commands are:

git clone https://github.com/Miko997/metriplane.git
cd metriplane
git checkout v0.2.0

python3 -m venv .venv
source .venv/bin/activate
pip install -e .

python -m metriplane.cli doctor

PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 python -m pytest -q

./tools/mp.sh deterministic-replay

metriplane atlas validate-pack configs/domain_packs/assembly_cell

metriplane atlas run \
  --session-jsonl datasets/demo/atlas/assembly_cell_missing_tool.jsonl \
  --pack configs/domain_packs/assembly_cell \
  --out runs/atlas/assembly_cell_missing_tool

metriplane atlas bundle verify \
  runs/atlas/assembly_cell_missing_tool/evidence_bundles/INC-0001.zip

metriplane atlas test \
  runs/atlas/assembly_cell_missing_tool/regression_tests/INC-0001.yaml

Expected high-level results:

doctor: pass
pytest: 580 passed
deterministic replay: pass=true, 0.0 cm position difference, 0 event mismatches
Atlas run: events=6, incidents=1
bundle verify: pass=true
regression test: PASS missing_tool_caused_delay_INC-0001

If you do not have time to run it, a short comment on the design, limitations, or relevance would still be useful.

Scope and non-claims

MetriPlane v0.2.0 is intentionally bounded.

It is:

observe-only
local-first
camera/replay-oriented
planar/tagged-asset scoped
research-software oriented

It does not claim:

robot or machine control
safety certification
quality-release approval
people recognition
marker-free tracking
full 3D reconstruction
production-factory validation
factory-wide deployment readiness

ROS 2, Isaac, Omniverse, Docker, and other integration paths are treated as adapter/deployment surfaces unless a specific artifact separately evidences them.

What I am especially interested in

I would appreciate feedback on:

  1. Does the evidence-bundle / regression-test loop make sense for robotics or manufacturing review workflows?
  2. Is the camera-free reproduction path clear enough?
  3. Are the observe-only boundaries clear enough?
  4. What should be validated next before this is useful beyond a deterministic demo fixture?
  5. Would this be useful around ROS/simulation/digital-twin workflows, or is the framing wrong?

Thanks for reading. I would appreciate technical criticism, reproduction attempts, and suggestions on how to make the artifact stronger before SoftwareX submission.