Authoring Autonomy
Interview with Brian Ringley – Boston Dynamics
Ahead of his keynote presentation at CDFAM in DC this year, Brian Ringley, Distinguished Product Manager and HRI Designer at Boston Dynamics discusses his path from computational design and digital fabrication to his current work on the data collection and task authoring systems behind Atlas.
We all know who Boston Dynamics are, and some of what the company has publicly released, but your path from computational design and digital fabrication to your current role there is perhaps less well known. Can you walk us through that trajectory and what you’re focused on now?
As a student, I was interested in how emerging technologies reduce the latency between design intent and finished product. When a designer understands the affordances of a given material plied by some tool, or of a given machine’s “understanding” of some 3D modeling software language, you’re able to offload computation from the digital design model onto downstream manufacturing processes and material properties.
Think of the complex patterns that emerge from the geometric Booleans of plywood strata and CNC ball mills, that Baroque intersection of material striation and cusp artifacts. Later I would learn that there’s a term for this: Design for Manufacturing.
I applied DFM and file-to-factory thinking later in my career when I worked in architecture on problems ranging from facade modeling to prefabricated, modular systems for office space. The more time I spent on construction sites, the more it was evident that not all downstream intelligence was captured in the digital model. Tradespeople on site routinely make many helpful edits and adjustments that add up to significant deviations between intent and reality. Construction is effectively an open-loop process ignorant of this intelligence, and I became obsessed with reality capture as a means of closing the loop.
But how do you digitize buildings at-scale? The answer seemed to lay in autonomous reality capture made possible by advances in robotic mobility. Only the emerging breed of legged robots coming out of Boston Dynamics were capable of traversing stairs, gaps, ground clutter, and the various other moments of chaos common to construction environments. This was my first major project at Boston Dynamics, and these construction efforts have since been passed on to partners such as FieldAI.
I turned my attention to the critical mass of Spot robots in industrial environments, and the realization that these robots, while endlessly fascinating, are merely a means to an end of preventative maintenance and uptime, which in turn contribute toward the dream of the fully automated factory. As a product manager for Boston Dynamics Orbit (the software interface for our factory solutions empowered by fleets of our robots), I drove change from a robot-centric to a factory-centric user experience. The focus shifted from measuring environments with robots to leveraging emerging generative models in order to have conversations with the factory itself, mediated by our mobile robots and their sensor data.
This shift from world-measuring to world-understanding is very relevant for Atlas, our humanoid robot, and today I’m focused on the data collection and task authoring systems that enable Atlas to do real work.
Can you give us an overview of what you’ll be presenting at CDFAM DC?
I’ll discuss what it means to be a designer of these authoring systems. I’ll touch on the hardware of course, such as the key industrial and HRI design decisions that have informed Atlas’s signature look, but I’ll also make it clear that hardware alone will not revolutionize automation. You’ll need to harness the reasoning power of agentic AI to understand the task environment and do the right thing.
It’s important to realize that the level of automation we’re looking to achieve with Atlas was possible before with task-specific industrial automation; it simply wasn’t economically viable. What will make it viable now is the combination of generally capable robots with generalist behavior systems, as well as the agentic programming systems that are capable of reliably producing those generalist behaviors. And then ultimately embedding all of that into industrial software applications, factory production systems, and factory-scale digital twins. In other words, putting this technology into its operational context.
Large Behavior Models and Atlas Find New Footing | Boston Dynamics
When I personally think about robot autonomy, I think of setting a task and letting the system determine how to execute it, with as little micro-managing as possible. How have you approached training robotic systems to operate at that level of abstraction?
Totally! Barring a machine’s ability to develop desire and self-determination and some will to task itself, the objective is to train robots as naturally as we train one another.
We’re certainly not there yet. The focus now is to build up a library of skills with physically demonstrated data and other data sources, and combine that with generative models that allow robots to correlate their task environments with the natural language instructions they’re receiving.
As we’ve seen with large language models, the more data with which you train a model, the more generalization you’ll get, and the less you’ll be “micro-managing.” You certainly won’t be subject to the tedium of programming individual waypoints and toolpaths anymore.
There’s a tendency to treat autonomy as primarily a software and AI problem, but robots are physical objects navigating physical space under the constraints of physics. How do you ensure the hardware continues to be optimized alongside the software, and how does sensor data from a given robot generation feed back into the design process?
At Boston Dynamics we eat, sleep, and breathe hardware.
High-performance, reliable, and generally capable hardware is the basis for anything we do. And how capable is any form of AI without a physical body that enables it to act on the world, anyway? So naturally we’ll keep pace with hardware optimization in order to be successful.
Sensor data is important, but at the end of the day you need engineers and customers putting robots to work, identifying where they fail in the real world, and subsequently improving your designs. AI and process automation play a role in this, of course, but it’s still a fundamentally human design and engineering activity. Our mantra is “build it, break it, fix it.”
Thought experiment: the year is 21XX, and a fleet of Atlas descendants has been dispatched to Mars to explore, extract, and return maximum value to Earth, with no humans in the loop. What framework, infrastructure, or capabilities would need to exist for that mission to be executable autonomously at that scale?
I’ve always been interested in the idea of a “helper class” of robots, the way you need a drone ship to catch an autonomously landing rocket, or the way an observational drone needs a visit from a refueling drone to stay operating in the sky.
We will need to invent so many layers of physical autonomous systems between the humans-in-the-loop and the autonomous agents performing the task, especially if we’re talking about hostile environments like space or deep-sea exploration. What those are exactly, I couldn’t begin to say haha.
Finally, what do you hope to take away from participating at CDFAM, and what is the one thing you would like the audience to leave with from your presentation?
I’m always excited to learn from other disciplines who are dealing with the same paradigm shifts in computational design, particularly fields steeped in advanced manufacturing like automotive, aerospace, and maritime.
I hope to convey to my audience that everything has changed about software programming and interfaces. It’s time we learned how to speak to machines.
These shifts are surfacing across engineering, software, simulation, AI, bio-mechanics, architecture, and advanced manufacturing, but the people working through them are rarely in the same room.
Join Brian and others exploring the space at CDFAM DC. Register to attend and connect.
