Abhinav

research @uniofoxford, exploring new ideas @spc, prev @microsoft, before that @brownuniversity

[Abhinav @abhinavvsriram]

One way to make a robot better at assembly: redesign the part it has to assemble - in addition to DFM, we now have DFRA - design for robotic assembly.

@adarshkulkarni of @foundryrobotics, spoke about building adaptive finally assembly factories that make products for customers and generate the data to improve their robots. The product Foundry sells is manufacturing capacity.

The challenge becomes clearer when you look at a complete process. Adarsh gave a simple example: if a robot has a 90% chance of getting each next step right in a ten-step sequence, it completes the whole sequence correctly only about 35% of the time without retries. A convincing individual action can still leave you with an unreliable assembly process.

Then add the variety in manufacturing: different products, processes, fixtures and grippers. The system has to handle that variation while meeting requirements for speed, uptime and reliability. There is substantial work between a model demonstrating a capability and a factory being able to depend on it.

Foundry’s approach is to start with what models can do today and use technicians for the remaining work. The factory becomes a place to build products and learn how to automate more of the process.

Consider how that can work:
1. Start with assembly work a customer actually needs done.
2. Deploy models on the steps they can handle.
3. Have technicians perform the work the models cannot yet do.
4. Collect useful manufacturing data from that production.
5. Use it to improve the models and evaluate what they can take on next.

Each production run becomes an opportunity to learn from the tasks, materials and constraints that matter to the customer.

Adarsh also described helping customers make their products easier for robots to assemble. Understanding what the models and hardware can handle informs decisions about the product itself:
- Give the gripper more than one place to grab.
- Design the placement so the part helps locate itself.
- Make the relevant features easier for the robot to see.

That means you can work on both sides of the problem: improve the robot’s ability to perform the task and make the task easier to perform.

Teams that understand the model, the assembly process and the customer’s design constraints will become increasingly valuable as capabilities improve. They will know when a failure calls for more training data, a different fixture, a design change, or a person doing that step.

[Abhinav @abhinavvsriram]

I didn't know Amazon had deployed over a million robots, and even more surprisingly they manufactured most of these robots in-house!

@spaceguytye, CTO of Amazon Robotics for the last decade, spoke about how much work still begins when a robot leaves the lab. There is no getting around this even for the most experienced deployment team out there.

A system may look convincing in testing, but when it reaches the real operating environment, something is always wrong. Nothing like reality to humble you. Even today, Amazon starts in one corner of one floor of one warehouse, works through problems sequentially, and expands from there.

A million deployed robots buys you an extraordinary amount of experience (and data). It does not let you assume the operating environment will cooperate. There is substantial work available to teams that can turn improving models into fast deployment operations a customer will actually run.

Consider what has to happen after a robot performs a task successfully:
1. Someone has to connect it to an existing process.
2. Decide what happens when something goes wrong.
3. Give an operator a useful way to intervene.
4. Recover without turning a small exception into a production stoppage.
5. Then collect enough evidence to know whether the next revision helped.
Each of those decisions changes the product; and each depends on the facility and the people in it.

@rodneyabrooks made this clear in another session moderated by the excellent @rocketalignment. In an industrial deployment, there are really three customers: the corporate buyer, the facility manager and the person beside the machine. They experience the same deployment through different problems:
- The buyer wants the investment to pay off.
- The facility manager wants production to run smoothly.
- The person on the floor wants an interaction that makes sense and does not make the job frustrating.

My bet is that teams with a repeatable way to satisfy all three (and more) will become increasingly valuable as model capabilities improve. They will know which task is worth doing, which failure matters, and what the customer can tolerate while the system gets better.

This is a demanding kind of work. It requires spending time in the facility, hearing conflicting requests and deciding which problems the system must solve. It also creates an opening for companies willing to take responsibility for the full customer experience.

[Abhinav @abhinavvsriram]

@jjkaplowitz @a16z @edgarpavlovsky @nickco @barrett_io @natabr75 Would love to join, work closely with @willsentance on physical AI for manufacturing!