Every robot, every sensor, every environment is different. PILGRIMS monitors your robot's performance, diagnoses problems when they occur, and solves them — without a human in the loop.
The hardest problem in robotics software is not perception or planning. It is the fact that every robot, every sensor, and every environment is different — and that things go wrong in ways nobody anticipated. The question is whether your system can recover on its own, or whether it needs a person.
In 2026, even small changes in the robot's environment can lead to catastrophic mistakes. Robot has no concept of its own performance: it cannot distinguish between working correctly and working incorrectly, it just blindly executes until halt.
The result is that engineering teams become the recovery layer. They monitor, they debug, they retune. Every deployment is a bespoke effort. The knowledge of what went wrong and how to fix it lives in people, not in the system itself.
PILGRIMS adds three capabilities that most robotic stacks lack entirely. It sits alongside your existing code — you write adapters for your sensors and models, and the framework does the rest.
Continuously evaluates whether each component in the pipeline is performing within expected bounds. Not just "is the sensor on" but "is the output trustworthy right now, given what we know about how it should behave."
When the monitor flags degradation, the system isolates why. A confidence drop in an object detector might trace to a lighting change, a novel object, or a model that has drifted. The diagnosis determines the recovery path.
Executes the appropriate repair: recalibrate an instrument, switch to a different model, adjust a control parameter, retry with a modified approach. The robot resumes. No ticket filed, no engineer paged.
Every failure and every recovery is written to a structured log — what was detected, what caused it, what was tried, what worked. This matters for two reasons. First, your team can audit exactly what happened during any run. Second, and more importantly, this log is the training data for a system that gets better over time. Each problem solved makes the next occurrence faster to resolve, and eventually, preventable.
Anywhere a robot operates in conditions that aren't perfectly controlled — which is to say, anywhere that matters — PILGRIMS applies.
PILGRIMS turns instrument errors and protocol failures into self-correcting events, keeping experiments running and data clean.
Seal and dispense drift, plate misalignment, reader calibration shift, transport faults, thermal variation
PILGRIMS detects the shift in the environmental conditions and adapts the system before production is affected.
Perception degradation, part variation, gripper wear, sensor occlusion, environmental lighting change
Warehouse robots navigate a world that changes with every shift and warehouse shape. Recovery from these situations shouldn't require a remote operator.
Path obstruction, map drift, localisation error, floor surface change, fleet coordination failure
Vision-based inspection is only as good as its last calibration. Over weeks and months, models drift, cameras degrade, and reference standards shift. PILGRIMS catches these changes before they corrupt your data.
Model drift, reference shift, camera degradation, false positive accumulation, lighting inconsistency
The monitor-diagnose-solve pipeline, the structured log, and the adapter SDK. Any team can integrate this with their stack and contribute adapters for their own hardware.
The part that turns logs into intelligence. Learns from every recorded failure to make recovery faster, and eventually, to prevent problems before they occur.
Recovery speed vs. fixed-threshold approaches
Detection to resolution, on device
Changes to your existing codebase
PhD, Imperial College London. Former Google Research. ARIA Fellow at the University of Cambridge, working on embodied intelligence and human-machine systems.
DPhil, University of Oxford. Research in continual learning and adaptive systems — how machines can learn incrementally without forgetting what they already know.
If you run a robotics operation where failures are expensive and recovery is manual, we'd like to build with you. Not a pilot. A real integration, with a team that cares about getting this right.
Or write to us directly: hello@usepilgrims.com
