ClawMetry
Event preview
ClawMetry at Leukerbad Robotics Hackathon 2026: what we plan to test
Confirmed selection and a concrete test plan for November 14 to 16. An event preview, with results to follow after the hackathon.
From an Amsterdam worktable to Leukerbad
I have been selected to participate in the Leukerbad Robotics Hackathon 2026. The event is scheduled for November 14 to 16 in Leukerbad, Switzerland. As of this article's November 7 publication date, it is still ahead of us. This is a preparation note about what we want to learn, rather than a report of completed demonstrations or results.
The starting point is our SO-101 work at La Machine and the ongoing BluPe integration effort. Both show why a robot demonstration needs a clear record. It must connect the instruction, the machine's response, and the limits of the observer.
Why this event is relevant to observability
The organizers describe a hardware-focused hackathon spanning robotics, artificial intelligence, and XR, with applications connected to everyday urban settings. Their program gives us a useful setting for conversations with builders who have different machines, controllers, and operating constraints. The official event pages are the source for the schedule and available resources.
Our interest is in the operational questions that travel across those differences. How does a person know a task is active? How do they recognize an old camera image? Who is responsible when a task needs a handover? What evidence survives after a demonstration ends? We want to learn which of these questions teams already answer well and where an independent observer would help.
Choose one task with a visible finish
A good hackathon test begins with a narrow workflow. Agree what completion looks like before the run: for example, an object reaches a designated surface and remains there. Record who authorized the task and which environment was used. If the task changes midway, keep that change in the history.
We do not need to connect every available robot to learn something useful. One supported interface, one supervised task, and a reviewable record would be a stronger result than a long list of logos. The available hardware and permitted access will determine the scope.
Test the gaps as carefully as the happy path
A demonstration can look convincing while its recording tells a different story. We want to inspect source timestamps, observation gaps, rejected requests, and the difference between a controller acknowledgement and a measured response. Where feasible, a deliberate software disconnect can test whether the observer clearly reports that its view has stopped updating.
Any interruption test needs to be agreed with the hardware owner and run through the supported interface. The goal is to evaluate the observer's account of events, not to improvise a new control path. Machine-specific local procedures remain the basis for physical operation.
Bring back a compatibility report
After the event, the report should name the machine and software tested. It should describe the task, available data, and observed outcome. A simulator run should be labeled as simulation. If an interface cannot report measured motion or confirm a stop, that limitation belongs in the report.
We also want to preserve the human part of the review. Could another participant understand the timeline? Did the recording help find a problem? Which screen answered the operator's question fastest? These are questions a prototype can investigate without pretending to have established broad deployment readiness.
Meet us around a real workflow
If you are attending and building a robot application, bring one task you would like to make easier to inspect. Show us the controller or SDK you use and the evidence it can expose. Explain what a person needs to decide during a run.
This preview will remain a dated account of the plan. A separate post-event report should carry the actual results, photographs from Leukerbad, and any reproducible example. The cover is organizer artwork from the event listing. It does not depict results from the upcoming event.
Sources and evidence
External sources support the attributed background. Integration accounts describe historical project evidence. Guidance and proposed tests are identified in the article.