Hi Stefanie! I am working on trash pick up as a part of my PostDoc fellowship. We are partnered up with MediMRF an early stage startup that sorts trash in hospitals. As you mention, we work with very little compute.
Hi Stefanie! Love this article. I had very little compute and presented my research at CoRL this week. Agreed with all your points, especially around Sutton recently clarifying his point on the bitter lesson. There are a ton of problems in this space that more efficient algorithms and clever engineering can address, e.g. Supermimic was a great robotics paper of a very simple model (3 layer MLP world model).
Trash pickup is a fantastic soft body problem because if a failure occurs, it's not catastrophic. I also think it has great applications in both industry and nonprofit work, e.g. cleaning up polluted rivers and oceans (that video from Chris is very cool).
Dyna Robotics was a major hit at CoRL and I think one of the reasons they're successful is the problem they've chose to work on, i.e. towel/laundry folding. It makes closed loop evaluation easier than more critical use cases (e.g. industrial parts assembly, which really have to ensure the 9s of reliability because failures are costly).
As someone going back to grad school next year for CS/robotics, this article felt very aligned with the research I'm thinking of tackling next + my own approach to research.
The $600 million round for Bedrock Robotics landed with no disclosed machine counts, intervention rates or cost per cubic yard, which on my read is the gap your post comes at from the other direction. Capital and compute are scaling faster than anyone's proving what they buy, while you're proposing to run a POMDP on a laptop and a Spot.
Your FastSLAM-to-POMDP plan is a good way to test that. If the AI-generated probabilistic program tracks uncertainty as well as you expect in the gridworld, the question is whether that advantage holds once it meets real sensor noise on Spot, rather than whether more compute would have gotten there faster. Does the transfer expose a different bottleneck than compute?
I like the push to find questions that fit the hardware already on hand. The best antidote to compute envy may be a robot that still needs someone to make it pick up the trash.
Hi Stefanie! I am working on trash pick up as a part of my PostDoc fellowship. We are partnered up with MediMRF an early stage startup that sorts trash in hospitals. As you mention, we work with very little compute.
Claude's feedback on this post was that the trash paragraph was weaker than the other two, but it was WRONG!
Hi Stefanie! Love this article. I had very little compute and presented my research at CoRL this week. Agreed with all your points, especially around Sutton recently clarifying his point on the bitter lesson. There are a ton of problems in this space that more efficient algorithms and clever engineering can address, e.g. Supermimic was a great robotics paper of a very simple model (3 layer MLP world model).
Trash pickup is a fantastic soft body problem because if a failure occurs, it's not catastrophic. I also think it has great applications in both industry and nonprofit work, e.g. cleaning up polluted rivers and oceans (that video from Chris is very cool).
Dyna Robotics was a major hit at CoRL and I think one of the reasons they're successful is the problem they've chose to work on, i.e. towel/laundry folding. It makes closed loop evaluation easier than more critical use cases (e.g. industrial parts assembly, which really have to ensure the 9s of reliability because failures are costly).
As someone going back to grad school next year for CS/robotics, this article felt very aligned with the research I'm thinking of tackling next + my own approach to research.
The $600 million round for Bedrock Robotics landed with no disclosed machine counts, intervention rates or cost per cubic yard, which on my read is the gap your post comes at from the other direction. Capital and compute are scaling faster than anyone's proving what they buy, while you're proposing to run a POMDP on a laptop and a Spot.
Your FastSLAM-to-POMDP plan is a good way to test that. If the AI-generated probabilistic program tracks uncertainty as well as you expect in the gridworld, the question is whether that advantage holds once it meets real sensor noise on Spot, rather than whether more compute would have gotten there faster. Does the transfer expose a different bottleneck than compute?
I like the push to find questions that fit the hardware already on hand. The best antidote to compute envy may be a robot that still needs someone to make it pick up the trash.