Your expertise. A bigger ambition.

What we want to discuss

The task your software performs and its current maturity.
Hardware dependencies, existing test evidence, and deployment experience.
Ownership, open-source obligations, and rights to commercial distribution or sublicensing.
Support capacity, update responsibilities, and a defined first milestone.

How collaboration would work

A collaboration could involve a founding technical role, a software license, or a jointly scoped development project. Compensation, equity, royalties, and exclusivity are not promised here; they require a separate negotiated agreement.

Before sharing sensitive material

Start with a non-confidential overview. Do not include proprietary source code, credentials, personal records, or restricted technical information. Confidential exchanges require an appropriate agreement and channel.

The problem worth working on

Robotics has a software problem that hardware progress keeps making more obvious. A modern robot can be mechanically capable and still useless, because the gap between what it can physically do and what it knows to do is enormous. Closing that gap is currently bespoke work, repeated from scratch for each robot, each site and each task.

The result is an industry where capability does not accumulate. A team solves pick-and-place on one arm in one warehouse, and almost none of that work transfers to the next arm or the next warehouse. The engineering is real, the learning is real, and it mostly evaporates.

Where the difficulty actually sits

It is worth being specific, because vague descriptions of this problem lead to vague solutions.

Hardware heterogeneity. Two robots that look similar expose different joint limits, control rates, coordinate conventions, safety interlocks, sensor calibration and failure semantics. Abstraction that hides too much makes the robot unsafe; abstraction that hides too little does not abstract.
The perception-to-action gap. Recognising an object is not grasping it. Policies that perform well on held-out data still fail on contact dynamics, occlusion, lighting, clutter and the specific way a given gripper deforms a given material.
Sim-to-real. Simulation is the only affordable way to generate scale, and it systematically misrepresents friction, compliance, latency and sensor noise. Closing that gap is an ongoing research problem, not a solved pipeline step.
Long-horizon tasks. Chaining short skills into a multi-step job compounds error. A ninety-five percent reliable step is a coin flip across fourteen of them.
Evaluation. There is no agreed way to say a robot capability is ready. Offline metrics do not predict deployed reliability, and a demo video predicts nothing at all.
Safety envelopes. Every capability has conditions under which it must refuse to act. Encoding those conditions, and proving they hold, is harder than producing the capability.

What a shared software layer would have to provide

If capability is going to accumulate rather than evaporate, something has to carry it between robots and sites. That means more than a library.

A hardware abstraction honest enough to be safe, with the parts that cannot be abstracted exposed rather than hidden.
Capabilities packaged with their preconditions, their operating envelope and their failure behaviour, not just their weights.
An evaluation harness that produces a comparable answer to "is this ready here", on real hardware, before deployment.
Deployment with versioning and rollback, because a capability regression on a machine that moves is not the same as one on a web server.
Observability designed for physical failure: what the robot saw, what it decided, what it did, and what the discrepancy was.
A way for an improvement learned at one site to reach the others, with the provenance to know whether it should.

What we are honest about

None of this exists yet. There is no software development kit to download, no application programming interface to call, no account to create and no package to install. Nothing on this website is a release, and this page is not a developer preview.

The venture is in formation. What exists is a position about where the leverage is, and a specific view of the first integration worth attempting. Anyone who tells you the full stack above has been built already is describing something else.

Where early collaborators would have real influence

The decisions that matter most in a project like this are made early and are hard to revisit: what the capability interface looks like, what the hardware abstraction refuses to hide, how safety conditions are declared, what evaluation counts as passing, and what the licensing and attribution model is for contributed work.

Those are the questions worth arguing about now, with people who have shipped robots and have the scars to prove it. If you have strong opinions grounded in having done this, that is the conversation we want.

Backgrounds that are directly relevant

Manipulation and grasping, especially contact-rich tasks on real hardware.
Robot learning: imitation, reinforcement learning, and vision-language-action approaches.
Simulation and sim-to-real transfer, including domain randomisation and system identification.
Controls, motion planning and real-time systems.
Perception: 3D vision, state estimation, calibration.
Functional safety and risk assessment for machinery.
Developer platform engineering: software development kits, versioning, distribution, observability.
Fleet operations, where reliability is measured rather than claimed.

How to get in touch usefully

A short note about what you have actually built and what broke is worth more than a resume. Say which of the problems above you think is the real bottleneck, and where you think this framing is wrong. Disagreement from someone who has deployed hardware is more valuable than agreement.

Please keep the first exchange non-confidential. Do not send proprietary source code, credentials, unpublished research under embargo, or anything your employer would object to. Confidential discussion needs an agreement in place first.

If you are packaging a capability, start with the capability specification template.

Before scoping an integration, the facts anyone will ask you for: the integration requirements checklist.