NPK/ Unify

ROBOT ENGINEERING HISTORY

Know what changed
between robot tests.

Connect hardware, code, models, and calibration to each run—then compare successful and failed tests.

In development. Built around the needs of commercial ROS 2 manipulation teams.

Designed for the teams
bringing robot arms into production.

PickingSortingMachine tending

01 / THE PLANNED WORKFLOW

Less reconstruction.
More context to investigate.

Keep the tools you use. Build a shared record that connects configuration changes to the tests that matter.

01

Record the configuration.

Link each run to an exact snapshot of hardware, software, models, calibration, and settings. Make missing information visible.

A record you can refer back to
02

Compare the right runs.

Choose a successful baseline with comparable procedures and conditions. See recorded changes alongside their evidence.

The engineer chooses the baseline
03

Investigate together.

Bring mechanical, software, and test context into one conversation. Preserve notes and evidence for an engineer-confirmed resolution.

Differences are leads, not diagnoses

02 / SEE THE DIFFERENCE

The test failed.
Start with what changed.

This fictional example illustrates the planned comparison. It is not customer data or a working product interface.

SYNTHETIC EXAMPLE

Pick cell A / Run comparison

041 → 042

Comparable recorded conditionsPick procedure v2 · object: carton A · lighting: bench setup L1

Baseline chosen for matching recorded conditions. Unrecorded conditions may differ.

HardwareManual report · demo operator · confirmed 09:40
041 · SuccessfulGripper · G-01
042 · FailedGripper · G-02
Changed
SoftwareSynthetic Git metadata · clean working trees
041 · SuccessfulCommit · a81c9f2
042 · FailedCommit · b72d4e1
Changed
CalibrationSynthetic calibration version records
041 · SuccessfulCamera · cal-v12
042 · FailedCamera · cal-v13
Changed
ModelSame recorded model version in both snapshots
041 · Successfulpick-model-v3
042 · Failedpick-model-v3
Unchanged
Training dataLineage not recorded · sameness cannot be established
041 · SuccessfulUnknown
042 · FailedUnknown
Unknown
SettingsLatest setting not recorded · comparison unavailable
041 · SuccessfulGrip force · 30 N
042 · FailedGrip force · unknown
Incomplete

Three recorded changes. No automatic conclusion. The gripper, software, and calibration changed. The engineer still needs evidence to determine why the test failed.

About this example’s evidence

All identifiers, times, and records are fictional. Both runs are dated 2026-09-01. Run 041 references snapshot s041/r1 at 09:10; run 042 references snapshot s042/r1 at 10:05. The baseline hardware confirmation is 09:00; the later manual confirmation is 09:40, both by “demo operator.” Snapshot observations occurred at 09:10 and 10:05 and were recorded at 09:11 and 10:06 respectively. These labels do not imply physical hardware was automatically verified. Raw evidence is not attached. Unknown training-data references do not prove unchanged lineage.

03 / START WITH ONE WORKFLOW

A real regression.
A focused first step.

We’re looking to learn from engineers who have recently reconstructed a robot test failure. Start with a conversation about what happened and what the record was missing.

Share only sanitized information your team is authorized to discuss.

PROPOSED PILOT · NOT YET AVAILABLE

One test workflow.
Four weeks of learning.

Scope
Up to five robots
Focus
Configuration history + run comparison
Success
Agreed reconstruction-time baseline and usage criteria

Inputs, responsibilities, timing, and pricing would be agreed together before starting. No pilot results are claimed.

LET’S UNDERSTAND YOUR WORKFLOW

What changed
in your last regression?

Discuss a recent regression

Opens your email app. You can also copy the addresses:
2thomaskelley@gmail.com

carterness4@gmail.com

A 20-minute conversation about one recent incident.
A planned product, shaped by engineering reality.