ClawMetry
Developer guide
From simulation to a real robot: an observability validation checklist
A practical path from an inspectable simulator record to one carefully documented hardware result.
Simulation lets you ask better questions first
A simulator gives a team a repeatable place to develop an observer and test event handling. The team can inspect tasks without continuous physical access. It is a useful stage in an integration workflow. The evidence it produces describes the simulated environment and the software connected to it.
MuJoCo is one example of a physics engine used in robotics research and development. A rendered arm can be driven by simulated dynamics rather than a prerecorded animation. Even then, the result does not establish how a particular physical controller, sensor, or loaded arm will behave.
Mark the environment in every recording
Store an explicit environment label with the run and display it during review. Include the model and scene versions used in simulation. On hardware, record the relevant controller, software, and calibration references. A screenshot should not force a reader to infer whether it shows real equipment.
This matters when combining records into a report. A successful simulator task and a failed hardware connection may both be genuine results. They should remain separate results. Combining their most flattering parts into one narrative would erase the gap the hardware test was supposed to investigate.
Validate the observer before the physical outcome
First check that the observer identifies a run, receives the expected event types, and preserves their order and source times where known. Exercise missing fields and interrupted streams. Confirm that reviewing the saved record does not send a command back into the simulated or physical system.
Then compare what the integration reports with a source you can independently inspect. A count of captured events is useful for completeness, but it cannot show that the task succeeded. Check the content around the requested action and terminal state as well as the count.
Move to one supervised hardware task
Choose a task with the hardware owner and agree on a visible completion condition. Verify the supported interface and local operating procedures before the run. Capture the instruction, available action requests, controller responses, and the physical evidence needed to review the result.
Expect details that the simulator did not cover. These can include camera delays, calibration context, missing sensor fields, or controller responses with narrower meanings. These are findings to document. They should not be patched over by replaying a cleaner simulated state in the same view.
Test interruption reporting within the agreed scope
An observer should make a lost source obvious. Where the owner agrees, test a recording interruption or application disconnect and inspect how the interface represents the missing information. Do the timestamps stop advancing? Does the last image keep its age? Is the outcome left unresolved when observation ends?
Physical stopping tests require their own controller-specific procedure. The observer's role is to record what was requested and what could be confirmed. A clean simulated stop and an accepted hardware API call do not establish the same physical result.
Publish a narrow, reproducible conclusion
Write the report around the exact environment and task. State which interfaces were tested, what the recording captured, how completion was judged, and which questions remain. Include a genuine photograph or screenshot with a caption that says what it depicts. Keep simulator and hardware evidence labeled throughout.
Our SO-101 experiment and BluPe pilot are useful starting points for this discipline. The next integration should leave another builder with enough context to repeat the test and enough evidence to disagree with its conclusion. That is a stronger foundation for adoption than claiming broad support from a single polished demonstration.
Sources and evidence
External sources support the attributed background. Integration accounts describe historical project evidence. Guidance and proposed tests are identified in the article.