ClawMetry
Integration notes
Inside the ClawMetry and BluPe robot observability pilot
The early BluPe pilot, explained through its actual interface, recorded evidence, and an instructive warm-up failure.
The question behind the pilot
What should a visitor see when they give a remote robot a task? The camera matters, but it cannot explain the whole chain. Which instruction did the application accept? Which model was selected? Did a proposed action reach the controller? Is the image current? Did the object end up where the task required?
ClawMetry's ongoing pilot with BluPe explores those questions around robot arms accessed through a browser. The work follows conversations with BluPe founder Andrew Lyubovsky and development against the project's public code. It is an early integration effort, with a hosted ClawMetry playground used during testing. This article records that work. It is not a general hardware-compatibility announcement.
Keep the robot interface familiar
BluPe provides a browser playground and public robotics resources. Its repository, originally named blupe-remote-yam, now redirects to blupe-remote-bots. Keeping track of the upstream project matters because a fork can otherwise drift into a different product while still looking familiar.
Our integration approach adds an optional ClawMetry evidence panel alongside the existing experience. The robot camera, task entry, queue, and supported controls belong to the host application. The observer should help a visitor understand a run without becoming a second console that competes for attention.
Four kinds of evidence, four different claims
The panel distinguishes the task, published model notes, requested actions, and execution feedback. A published note is text that the application exposes. It is not access to a model's private reasoning. A requested trajectory is a proposed action. A packet receipt shows that an interface accepted a packet, not that an object moved successfully.
Station feedback needs its own identity and time. A robot station can report a recent joint state independently of the visitor's run. Associating that report with a run without checking the relationship would manufacture a stronger story than the data supports. The same applies to cameras: a live station view is useful context, but it is not automatically evidence of a particular command's execution.
A captured failure is still a useful test
One archived October 25 test gives a concrete example. Its saved receipt lists 808 captured events, matching the daemon's DuckDB record, with contiguous sequences and zero reported drops. The corresponding screenshot shows a model warm-up note, a stopped run, and zero submitted or accepted trajectory packets. We have published a minimal summary of those receipt fields alongside this article.
That result supports a narrow claim: the test captured the available run evidence into the local store. It does not establish successful robot action. Most of those events were observations, so the event total is not a measure of useful physical work. Describing the capture result precisely helps diagnose the failure rather than hiding it behind an impressive count.
Sharing needs a boundary too
The optional widget's source contract requires explicit sharing attestation before publishing task text or model events. Owner-only interactions and credentials do not belong in the public projection. Browser history is also described as browser history. Database persistence needs a separate recorder receipt and verification.
This is central to a public robot demo. A visitor should be able to understand the evidence being shared, while the operator retains control of private information. More verbose telemetry is not automatically better observability if it exposes material the visitor never agreed to publish.
What would make the next result stronger
The next milestone is a fresh, supervised task with a complete record. It needs an accepted instruction, attributed model request, controller receipt, fresh feedback, and visible outcome. The report should also cover a deliberate interruption or lost observation and explain what could no longer be confirmed.
The pilot remains a work in progress. The archived screenshots demonstrate the historical interface and its evidence labels, not today's availability of every provider or robot. We will update the integration story when a reproducible run establishes more. If you operate a robot playground, we would like to compare the evidence your application already exposes with the questions your users actually ask.
Sources and evidence
External sources support the attributed background. Integration accounts describe historical project evidence. Guidance and proposed tests are identified in the article.