# Software-Defined Robotics and the Physical AI Revolution

**Podcast:** Dev Interrupted
**Published:** 2026-04-28

## Transcript

Brian, just before we roll into the script, you yourself as an engineer and an engineer-minded person, what is most exciting to you right now on a personal level about how fast all the technology is moving and the things that you're experimenting with outside of intrinsic?
And are you doing anything fun outside of applying it towards robotics?
Well, I mean, I think I'm mostly working focused on robotics.
And for me, the exciting part is really just seeing that robotics is...
I feel like I've been waiting for robotics to have its moment for about 25 years.
I've been at this for a long time, mostly as an intellectual pursuit.
And now it's starting to become not only a hot topic because that wouldn't be quite enough, but it's like it's a hot topic in part for a reason because it's also becoming really, really useful.
So that to me is just, it's very satisfying.
Absolutely.
It's like transformative to see this technology that has so much potential finally be able to like, manifest it.
Robotics is something that I've always found personally interesting just in my own interest with technology and experimenting with it just as like a solo dev or just even like a teenager just trying to figure out how a breadboard works is like really complex to get into.
So it's really amazing now to see how it can become more accessible too, and I'm excited to talk about that today.
And to everyone listening, welcome back to Dev Interrupted.
Today, we're looking at the physical AI revolution.
For decades, the hardware and robotics was way ahead of the software.
We had the bodies, but they lacked the brains to handle the messy, unpredictable world that we all live in.
But our guest today has spent his career solving that gap.
Brian Gerke is the CTO of Intrinsic.
Many of you know him as a titan of the open source community.
He was a co-founder and CEO of Open Robotics and one of the primary architects of the robot operating system.
And now at Intrinsic, which just officially moved from an alphabet moonshot to an integrated core unit within Google, he's leading the charge to make robots as easy to program as web apps.
And Brian, it's so great to have you here today.
Well, thank you for inviting me, Andrew.
It's great to be here.
Absolutely.
And I want to dive right in to the breakthrough that we're all talking about and experiencing in robotics.
You feel it yourself.
You said at the top of our conversation that, you know, you feel like robotics is finally having its time in the sun and is going to be able to make huge strides.
And you're right at the forefront of that.
And a lot of that is made possible by things like artificial intelligence and new developments like LLMs.
But applying that to a heavy robot arm is...
Like an entirely different beast to tackle.
So what was the missing link from your perspective that's finally made this software-driven robotics viable for like more industrial work?
I think that's a great characterization because I think the robot hardware has been pretty capable for quite a long time.
Like if you look at the kind of applications we're tackling at an intrinsic with our customers.
We're basically using robots of a kind that have been around for a long time.
They've gotten better.
They've gotten lighter.
They've gotten smaller.
They've gotten more, you know, they're more collaborative robots that might be safe to use without having a cage around them.
So there are some improvements along the way.
But by and large, it's kind of the same hardware.
But historically, those robots have only been used in really fixed, rigid environments where we...
In order to use the robot, you engineered out all the variants so that the robot could operate in almost a blind fashion.
And it just would do the same thing again and again, pick from here, put to there.
And that's really useful in those high volume manufacturing type applications.
But there's so much more that could be done.
So we've been wanting to do that for a long time.
I think what has really been the breakthrough is the availability of better software.
And that software goes all the way from So how do we understand the world?
I've got cameras, I've got lasers, I've got other sensors that are going to help me understand, see the world and then make sense.
Now I need to make sense of it.
And then I need to decide, well, how can I act in that world in a safe way?
Can I, can I move my body so that I don't collide with the world?
And I go to the place where I want to get the object and I, and I figure out where it is.
I figure out how to, how to grasp it.
I pick it up and then I do whatever it is I'm supposed to do with it.
So that solving all the components of that.
uh, that control, like perception, planning and control problem that took us as a field just decades to get right.
Um, it's taken, I mean, I, I shouldn't say it's right yet.
We're still, it's always a work in progress, but we've made a ton of progress and, and now it's being accelerated by the advent of what, what I'll call modern AI.
Cause I've been at this long enough that AI has been a term.
I mean, it's been a term since the fifties.
When I was in school in undergrad in the 90s, I took an AI class, right?
And there are lots of techniques that are AI that now when we see AI, we mean a specific type of AI, which is these big neural networks.
We still use a lot of the older AI and the things that we do, and that's also really good.
But these big neural networks have now, they've allowed us to really solve some problems in ways that we didn't previously think was possible.
And perception is a great example.
So now we can, if we think back to like how that...
how do I get the robot to do applications where I haven't engineered out all the variants, so it's going to encounter a different situation from run to run, from job to job.
A key way to deal with that is make it smarter about how it sees the world.
And that's where the neural networks come in to handle that camera data and allow the robot to figure out what is it seeing, where is the thing that it needs to interact with, where are the obstacles.
Absolutely.
And so there's multimodality that has to be tackled with technology, with software.
There's also the reality of latency, because when you're a robot operating in the real world and you're ingesting all of this information from sensors, it immediately goes stale because you exist in a living, changing world.
And so having to tackle all these problems requires compounding, like a lot of innovation.
And that's what...
You know, LLMs and AI and neural networks and advancements in this kind of technology have really unlocked for robotics.
And it's really amazing to see how this was initially more like an experimental route into what is the future of robotics going to look like.
And now it's transitioned into something more deeply integrated, like within Google.
And so from your own perspective as a CTO, how does having access now closer to Google's frontier research and things like Gemma and I change what's possible in your mind for where Intrinsic can go with these compounding software problems?
We've taken innovations that originated in DeepMind, and we built on top of them and fine-tuned them and customized them and also hardened them, which is a topic we can talk about in some detail, to put them into production.
And so we've been working with them for years now.
Now that we are officially part of Google, we can work even better together.
So now, previously, we were two separate companies, if even under the same umbrella.
And that always adds a little bit of a barrier.
between the two teams.
And so now we've taken that away and now we've got the opportunity to work much more closely together.
We're now meeting very regularly with the leadership team over there and figuring out what's your objective, what's our objective, what's our broader strategy, and how do we bring that together in a way that's going to allow us to both do what we're trying to do here.
And I think the future is very bright there.
Absolutely.
I like how you call it that you can both do better because you're working together in that way.
And I think that becomes really key when technology companies partner so closely with more like foundational lab type environments.
Because we've had guests on the show before.
We've had Philip Schmidt from Google DeepMind, who's talked about being plugged into this virtuous cycle, this virtuous loop where you have the research that informs the development of the baseline technology that informs the innovation on top.
And then the innovation on top, you learn so much that fuels that baseline that makes everything better.
So now that intrinsic and robotics can be closer to its own virtuous loop that unlocks, like you said, a lot of upside for everybody.
like too, Brian, how you called out how we think about robotics more traditionally, like maybe like an arm or something that does something very standardized.
I imagine, or I think about when people think about like assembly lines in a factory, imagine if that robot got off by an inch or something.
Now suddenly the whole thing has to shut down because it's not an intelligent machine as much as it is an automated one.
So in this new world where those machines can become more intelligent, How do you characterize that at intrinsic, and how do you then build for that unknowable world based on these kinds of sensor inputs that you can get now?
Yeah, I think you've drawn just the right distinction there between it being what you might call an intelligent robot versus being an automated robot.
And historically, most...
And by the way, robots are very widely deployed today, right?
You can go into lots of factories.
Like you said, you can go to assembly lines and find, you know, from automotive to electronics manufacturing, you find the use of a lot of robots.
They are by and large, but I think you correctly characterized as automation.
They're very well, in a very high performance way, often designed and built.
But they are designed and built to do one specific task.
So if you look at, for example, let's take electronics manufacturing as an example.
What is common today is if I'm going to build, say, a mobile phone, then I'm going to bring up an assembly line for that phone.
And I'm going to figure out all the steps to put that phone together.
And I'm going to automate as many of them as I can because that's going to be more efficient and more productive.
And I'm going to build robot cells.
that are really specific for doing one task for that phone for the time I'm going to be making that phone.
And when I want to switch the model of the phone next year, I'm going to kind of start from scratch.
I'm going to basically take those robots.
I'm going to tear that whole thing down.
I'm going to build up a new line and I'm going to program.
I might, maybe I reuse some of the hardware, but I'm kind of starting over every time.
And that's been the journey of deploying automation kind of since the beginning is.
You tend to start over.
Each new task is kind of like it's its own bespoke snowflake, basically.
And the difference that we think, the different situation that we think we can provide now is what if that hardware, you have the same hardware and it becomes a software defined resource for you.
Like it's something where what it does is a result of the software that you put into it.
And that software gives it better capabilities because it can, for example, instead of always reaching to the same place and if the object it's going to pick up is off by one inch, as you said, it just, you know, it misses.
Instead, it looks over there and says, oh, I see where it is.
I'm going to pick it up wherever it happens to be.
I have an expectation of approximately where that is, but I'm going to go pick it up from exactly where I understand it to be.
That makes it more capable.
Also, then we can update that software over time, just like you can update software on all the other systems you interact with from your phone to your laptop to your cloud-based systems to, I mean, today your car gets software updates on a regular basis.
So if we start to think about these robots as not being single purpose, one-time programmed, bespoke resources, but rather these reusable, reconfigurable software-defined resources, we can fundamentally change how we think about using robots, even just narrowly in manufacturing.
We could talk about other domains too.
At Intrinsic, we're currently focusing on rolling out of manufacturing.
But even just within manufacturing, which is itself a big industry, we think there's a sea change that can be affected there if we can have this kind of software-defined robotics view.
Absolutely.
And it's tackling...
The hardware and the physical problem with the same mindset that an engineer is tackling a software problem using modern software engineering solutions.
The idea of modularizing it, breaking up this monolithic.
thing into smaller component parts.
And then in doing so, you're actually able to democratize the ability to create the best version of all of those individual parts.
Because in the previous world where you're creating this singular monolithic solution one-off every time, it's the equivalent of just like...
you know, one shot prompting an entire repo on your computer and then trying to use it and then hoping it works and that it does for that immediate thing and then throwing it away.
That's not a very engineering mindset to build because there's so much potential to extract from that.
And this is what's getting unlocked that you're calling out.
Software is allowing us to extract the value, the domain expertise that goes into creating that super specialized phone production line, right?
I agree with that.
And I think you're hinting at something which I think is really important to recognize about robotics as a field is that it's very interdisciplinary.
So if you talk about an engineering approach to solving a problem is to break it up into pieces.
And in robotics, you need people to be involved in the endeavor who are expert at.
mechanical engineering and electrical engineering on the hardware side, as well as, you know, user experience and human-robot interaction at the other end where you're starting to put the system to get in with people because the systems are always going to interact with people, even if you consider them to be autonomous.
In the middle, as we think about putting the software together, you need people who are experts at the cloud infrastructure and the data handling and vision.
and state estimation and planning and control and so on.
And so you need to have a software framework that allows all those people because nobody is an expert in all those things, right?
There's no like a renaissance man of robotics these days.
It's too broad.
And so you need someone, you need to be able to bring in all the people to contribute and give them a place to exercise their expertise.
Exactly.
And a lot of your work in open source and as a technologist has been focused on building tools that enable other developers to bring that domain expertise closer to the problem.
You know, where does your builder mindset come from and how does it shape what you do at Intrinsic?
I think my first experience with this was when I was in grad school.
I was at USC and I was...
pursuing a PhD in computer science in a robotics lab.
And like every robotics lab, we had some robots.
We had mobile robots.
They were small wheeled platforms that we had to work with.
And our goal as researchers, as grad students, is to do new science, right?
That's the top level objective.
You're meant to discover things.
In this case, it's kind of an experimental science.
You invent algorithms and you test them.
So the robots are like, they're part of your testing.
They're instruments for you to exercise your ideas.
And then you gather data, you report on that.
That's what you write about.
Now, in order to use the hardware, we needed software.
And we had a very common experience, which is that we bought the robots from a company that made robots for the research market.
They came with some software from the manufacturer, but it didn't do everything that we wanted.
that we wanted to make changes.
We wanted to fix bugs.
We wanted to add things, but it was proprietary software that came from the manufacturer.
We couldn't change it, but we were, you know, programmers.
So we thought, well, why don't we, we could write our own software instead of using that software.
So it was kind of like, if you imagine you get a computer, it has an operating system.
Instead of using that one, you write your own.
This is that, I mean, that a much grander version of this story is what is at the core of like, you know, the origination of, of Unix actually of BSD in particular.
So What we did is we wrote our own software and then it served our purposes in the lab.
So it was infrastructure software to use the robot, interact with all its sensors.
And then we didn't just keep it to ourselves, but we shared it.
We put it up as open source.
We put it on SourceForge, which is a, you know, that was a thing that came before GitHub, right?
This is quite a while ago.
It was like era circa 2000.
And the thing that was magic for me was when the first time after sharing it.
that we got contributions.
We got another set of grad students in another lab in another state who said, hey, I found that useful.
Here are the drivers that allow that same software to support my robot, which is a different robot that you've never seen before.
And now I'm using your software with my robot.
And that to me was just like mind blowing.
Like, wow, that's, we put this out there and then somebody picks it up and finds a way to use it in a way that we didn't even imagine.
Like that for me is where it started.
And I, since then, I've just always been dedicated to being a tool builder, putting these platforms out there, because I love to be surprised by what people do with it.
And so now, you know, fast forward several years, we worked on the project I'm alluding to there.
It was called the Player Stage Project.
That kind of what replaced it eventually was the ROS project, the robot operating system.
And now that we built that again, kind of.
With research users in mind, we were building a large wheeled human scale robot called the PR2.
You could think of it kind of like a humanoid, not unlike so.
Wheels, two arms, a head with lots of sensors.
We wanted it to come with software.
We made all that software open source.
That was ROS.
But the key thing is that it wasn't just used with the PR2.
And by now it's been used for everything from indoor robots, outdoor robots, wheeled robots, legged robots, flying robots, swimming robots, robots on the space station, like anything you can imagine.
And that's one of my very favorite things to do is to go to Roscon.
It's a developers conference that we run every year and just see the variety of applications that people make.
So like back to your question of, you know, why am I a builder?
It's because of that.
It's because if you build tools and put them out there.
And then it's like, for me, there's just nothing more satisfying than seeing what people think of to do with what you shared with them.
Absolutely.
So well said.
That's the magic of open source that you share something that you build and then you become surprised and delighted by how others find ways to innovate and build and be inspired by what you put out there.
And that's what makes open source such a great part to be a part of and to contribute back to.
Really amazing experiences in open source where I share something, where I put something out there.
And it's amazing to see what other people will do once they get a glimpse of it.
But it's even more magical, like what you were describing, to think about it extended into our world.
And the technology that you made influenced the physical world in other places in ways that you didn't even see.
You weren't even there.
And that has such a level of magic to it.
That is just something totally different than, oh, someone ran my software.
I, I will, I have to say like, I, you know, I travel a fair bit for work and I, it's not uncommon these days to get off the plane at an airport and see robots roaming around the airport.
Doing, they're doing cleaning or security or they're, you know, they're, they're a rolling kiosk that.
offering, especially in Asia, they're kind of helper robots that you can ask them questions and things.
And I always make a point to take pictures and see who's making that.
And I go look it up.
And very often, they're running ROS.
It's like, wow, that's kind of cool.
I landed at some new place in the world I've never been before.
And there's a robot in this airport, which is running some software that we created.
And that's really cool.
That is really cool.
I mean, after this now, you know, another aside, like I live in West Hollywood and in West LA, they're piloting all of these, you know, robotic delivery robots because it's an extremely walkable neighborhood.
And there's two or three that are all fleets that are always roaming around and I see them and they are tackling the problems differently.
I am always fascinated on an engineering level when one of them rolls by me.
And now I can't help but wonder if maybe they're rolling by me powered by Ross.
If it depends on the brand, there's a very good chance they are.
Very cool.
So let's talk about that.
Let's talk about the democratization of influencing that physical world.
You know, there's millions of software developers globally, but only a small fraction of them have ever really worked on a robot.
What do you think is the biggest barrier right now, keeping everyday coders out of the robotic space?
I think that historically it was a, so if we roll back, you know, I don't know, 10 years, it would have been that you needed to build and understand too much of it yourself.
You, you need it as an individual to come in to build an application.
You kind of needed to be that, um, you know, imaginary robotics, Renaissance man or woman that I mentioned earlier, like that you just, you needed to have too much in your head of like how the low level details of the robot work in order to program a robot in a useful way.
Uh, I think that.
Platforms like ROS have lowered that barrier a lot because they come with a lot of the things that you need sort of taken care of and taken care of in a way that you can kind of treat it like a black box.
You know that it works, but you don't need to know how it works.
I think in addition, it's been difficult to get hardware.
So the robot hardware has tended to be...
expensive it has long lead time to manufacture and so it's that that's been a that's also been a barrier i think what we're seeing now is that we've got we've got really good software that's available some of it's open source like what is in the ross ecosystem some of it is proprietary and maybe makes use of builds on top of things that come out of the open source ecosystem like what intrinsic is offering but both are available and they and they They both do the job of encapsulating a lot of that stuff that you need to use but don't need to understand how that works internally.
And then on the hardware side, I think there's two interesting developments.
One is just the availability of low-cost hardware.
So you look at what comes out of the robot effort.
They've got a great open-source robot arm that you can buy it from them.
You can also just download the designs and 3D print it.
And you've got a low cost robot arm that you can work with at home.
They've got some great tutorials that tie it into using machine learning models so that you can grab like, you know, one of the great open source neural networks.
You can bring that in, you can train it with your robot and you can actually play with the robot interactively.
And you can start, I mean, I would encourage people to do this.
It's actually a pretty low cost, quick and easy thing to do at home.
And an intermediate step there is simulation.
So like the, you know, one of my colleagues has long said the, The lowest cost robot you can find is the one that lives inside your computer.
So if you can have a good software simulation of a robot, then that can get you a lot of the way to exploring the idea you have for what you want the robot to do.
So you can test, you develop, iterate and simulation.
And then once you've figured out what kind of robot do I want to use, what's the application, how do I want the software to look, you can actually defer quite far going through the time and cost to get it.
onto the hardware you still need to get to the hardware right the unless you're building a a movie or a video game also which have their own value just having it in simulation is not enough right to for most what i would consider robotics applications the the value manifests itself once it gets out into the physical world so you do need to go to the hardware and you're probably going to have to make some changes versus what happened in simulation because simulation is getting better every day but it's also still not perfect um but the simulation can It gives you a big leg up.
In the simulations, as they get better, it allows you to, like you said, defer that cost, that physical investment until as late as possible.
And then when you finally do make that jump, it's as accurate as it.
as it could possibly be and and that becomes the things that you're you're tuning to on like the larger loop that then enables all of this simulated based kind of innovation inside of it because i like what you called out i think that the sim is really critical and in this kind of environment that you're talking about, where you're solving a physical problem, you need to represent it in a simulated way so that you can gather enough data to solve it effectively and quickly.
Because that's what these types of neural networks and this type of technology is actually unlocking, is your ability to rapidly iterate.
So the simulation, to me, always seems like such a key piece.
And digital twins are something that are really fascinating to me, trying to mirror the precision of the real world in that simulated way.
And along that path, there's a lot of obstacles.
And so in the robotics industry, what do you think becomes the difference between a compelling prototype and something that actually starts to deliver value rapidly?
And is the simulation what closes that gap?
Is it something else that the simulation enables?
I'm curious how you see teams bridge that gap.
The simulation helps.
Like I said, it helps a lot.
And like at Intrinsic, we take a digital-first approach.
So if you're going to sit down and try to program a robot, what we and I would prescribe is start with a digital twin.
Model it in a 3D environment.
Maybe you're using a standard CAD tool.
There are lots of different authoring tools that you could use.
The Intrinsic product flow state is a 3D.
environment that allows you to, you can author directly there.
You can also import your assets from a CAD system.
But in however you do it, first create a 3D representation of the system you want to interact with.
And then that allows you to explore like, well, which robot do I want to use?
Because different robots have different workspaces.
If it's a robot arm, they'd have different payload capacities.
Where do I want to put the sensors, right?
Those are all things that are easy to play around with in a 3D environment, much faster and much less expensively than you would with the hardware.
And then bring up the software stack, get it working, convince yourself that you've got like at least approximately the right behavior before you go to simulation.
So let's say that you get it working in simulation.
Now you get it working on the robot.
Working means different things to different people, right?
So a lot of times we see a lot of really great videos of robots doing just amazing things.
There is generally a...
pretty big gap between a video of a robot doing something in, you know, a couple of times in a reasonably controlled environment.
You don't know how many outtakes there were, right?
They don't, they don't, not everybody's good about showing the blooper reel.
So there's a difference between that, which is a, that is valuable, right?
That's a, that's a demonstration of what's possible, right?
That that's like, oh my God, we did this thing we didn't even think was feasible before.
There's still a gap from there to.
It's a product that I can convince a customer to put on, let's say their shop floor and rely on for their business, right?
Like I, there are amazing things now that we can do with robots that have like an 80% effectiveness rate, or even a 90% effective, like reliability.
Like a robot can do some amazing dexterous manipulation task 90% of the time.
That is extraordinary.
We could not do that five years ago, even one year ago.
At the same time, if I'm a customer working in a manufacturing context, a 90% reliability rate is like useless.
That is just like, I'm not going to deploy something that one time out of 10, it fails to do what I want it to do, right?
We need so much more reliability before we're willing as a, as a, as a customer who is, I like rope.
Like if I'm an end customer, maybe I like robots, maybe I'm enamored of them.
But if you, if I'm really going to use it for my business, I kind of need to, the point for me needs to be not that it's a robot.
Not that robots are cool, but that it does useful work for me and that it does it reliably enough for me.
And so on that basis, I need it to be much more reliable than 90%.
So then what does it take to get there?
One of my friends and mentors is Rod Brooks, who founded our robot.
And he has some laws of robotics, his own laws of robotics.
And one of them is that from a lab demo to something that is...
I think he says to 99.9% reliability takes 10 years.
And then every nine you want to add after that takes another 10 years.
I think technology is changing faster now than it has been historically.
So I think that that time period is probably shrinking.
It's probably, it might not always be 10 years like it has been up till now, but I would still measure it in years.
So if you're asking, like, you see a demo of a first demonstration of some compelling application of a technology, like from there till it's going to be in productive use, I still think we measure that in years and even more years depending on the domain if you're going to put it into a mission-critical application.
I think this has been the journey of...
autonomous vehicles right you look i mean this is a very recent and timely example i don't know if you've got autonomous cars driving around in la i know we've got them in northern california we we got the we got them they're awesome so and they are awesome and it's worth recognizing that you know you a lot of that work's been going on for many decades but there was a real focus of attention in um there were these darpa funded challenges that happened in the mid-2000s from like 2004 to 2008 that really showed in first off-road and then on-road conditions what was possible.
But it took another 15 years to go from there to something that is the beginning of a business that is exercising that technology.
And even 15 years, that seems so fast when you think about how many hoops that technology has to jump through.
Because like you said, that's existing in a world where 90% doesn't cut it.
That's the brutal reality of taking robotics to production is you start with as many nines on that uptime.
You start with a full 100%.
And your customers, they don't accept anything less because they're operating at scale.
Absolutely.
And it's part of...
Bringing people together to solve this problem, which we've acknowledged now needs to be modularized.
It needs to have these hyper-specific learning loops so we can take advantage of all of this new compute and ability to learn rapidly with these machines and get them specified for what we need.
Part of that is things in the intrinsic ecosystem, like embedding domain expertise and skills into things that robots can access and then apply to their environment.
What does that look like?
to you as a roboticist on our show and to our listeners too a lot as well.
When they hear skills right now, they think about how do I encode my knowledge working expertise into something like Cloud Code could use to be accurate like me.
What is the analog for that in the physical world?
It's a great question.
And so I mentioned earlier the idea of like a good software platform.
To allow you to build an application, it takes things that you need but don't need to understand how they work and it encapsulates them.
And so that's the concept of a skill for us is it takes some functionality that I need and it makes it like a function I can call, basically.
So examples in the intrinsic stack are, you know, pose estimation.
So this is the problem of I've got, I have a camera image and I have, let's say, a CAD model or some other.
way to represent the object I want to find in the scene.
Where is it in the scene?
In 3D space.
And that's a computer vision problem, which neural networks are now very good at solving.
We use neural networks almost exclusively for solving that problem.
But we can give that to you as a skill.
And that's in our catalog.
So if you go build an application, you can just drag and drop the, I think it's the estimate pose skill that you drop in and you say, Take your input from this camera, look for this object, and then it outputs a pose.
It gives you a location and an orientation in space where that thing exists.
And you don't need to know how it works inside.
And then you go from there to we've got another skill called move robot.
And that's where I can say for robot arm, for example, I want the hand to end up in this place, which might be the output of that SMA pose skill.
Like move the robot to where the object is because I want to pick it up.
And then when you say go, what happens underneath is it looks at, well, where are all the things in the environment?
It does a high degree of freedom motion planner to decide how to move through space in a safe way that respects all the constraints of the robot, doesn't collide with anything.
But again, that's a thing.
You get to take that as just a building block.
You don't need to know how it works internally.
You didn't have to implement it yourself.
Importantly, you can bring, as you mentioned, your own skills.
You can extend the platform.
by encoding your own skills.
And they could be those kind of like underlying bits of functionality, like I mentioned.
They could also be specific to an application.
Like if you're, and this is where it gets pretty interesting, like as at Intrinsic, I think we're expert at building the underlying robotics infrastructure, like perception, planning, things like that.
We're not expert in any particular application domain for robots.
So let's say you want to have a robot that is going to do welding.
And there's a lot of what's called process knowledge that goes into welding.
Like welding is not to do it well.
You have to know a lot about the materials.
You have to have a really tight feedback loop.
You have to understand like how to produce a weld of really good quality.
I had no idea how to do that.
And nor does our team.
And so we're not the ones to develop the skill for controlling the tip of a welding robot.
We can give you the bits and pieces to control a robot generally.
But if you are an expert in that area.
then what you might bring to the table is that process knowledge and we can give you a way to encode it so that you have a skill that does that task really well.
And that's the transformation that's affecting robotics, the ability now to open source and share these modularized pieces of intelligence and action so that teams can build on top of them instead of constantly reinventing the wheel.
And it sounds fundamental, but these are core unlocks that just weren't possible in a realm before recent technology advances and all of the innovations around technology and neural networks as well.
called out so much of this too is based in perception and understanding the world and the world is different everywhere so the only way to actually grow the capabilities of the robotics industry and what it can achieve is to like you said democratize it so the welders of the world can bring their process closer to the technology that they're building with.
They can create reusable, amazing machines that are highly specialized.
And then they can even share this knowledge with each other.
And this even goes back to the idea of the open source ecosystem scaling and winning in these kinds of cases.
You know, we've had a lot of software leaders on the show who have made really big bets on their open source ecosystems and making everything available on a base level for people to build and to innovate.
Because when everyone can innovate in this shared space, everyone benefits from the gains.
And this is a key flywheel for anything that involves learning.
Which, as you've rightly called out, robotics is all about extracting learning from places and embedding it into machines.
You spent over a decade leading open robots in the ROS community.
And looking back, what did the success of open source robotics teach you about tackling these complex engineering problems?
If I had to pick maybe two lessons out of the experience with Ross and what has made it now a de facto software standard for robotics globally, is one, we took a...
distributed systems approach and that this goes back to the earlier part of conversation where we talked about how do you get an interdisciplinary team to be able to contribute so we we took a an approach where we said this we're going to we're going to break down this problem into pieces and we're going to provide the tools to create applications which are made up of pieces we're not we're going to start instead of having a you could by contrast take like a monolithic application approach that might have some benefits to it if all you want to do is build one application, if you know that you want to build exactly one application, a monolithic approach, you might be able to squeeze more efficiency out of it, for example, because you don't pay the penalty.
There's always some cost of having abstractions between components.
But we said, well, yeah, but what we're trying to do here is allow a lot of people to build a lot of different applications.
So let's take a distributed systems approach where an application, when it's running, has...
multiple we call them nodes in the ross ecosystem they might be processes they might be threads they could be in the same process there's some details there but they are the the functions of that make up the application are broken up into pieces which can kind of stand alone and then what that means is that you get to come to the table with your expertise and you want to contribute you're not contributing to a big monolithic stack what you're contributing is a piece it's a package it's a node it's a process that has a well-defined interface and it can run as part of the larger application and then it it does part of that overall it solves part of that overall problem so that that's one is distributed systems let let people contribute just the part that they're good at the second thing is lower the barrier to entry to joining the ecosystem and so part of that is about The licensing, so open source, we've always chosen permissive licenses.
We used to use the BSD three-clause license.
These days we use the Apache 2 license, which is kind of the spiritual successor to the BSD license that is more aware of modern software patent law.
But let people take the software without asking for permission, without registering, and importantly give them the ability to modify it themselves and to use it commercially.
without any constraints other than like carrying forward copyright, things like that.
But that means that they can build on it with the understanding that they're going to be able to go use it in their business and that's going to give them more of an incentive to participate.
So lower their barrier to entry in that way.
Also, when you combine those two things together, if with the distributed systems approach, my contribution to Ross can be, I don't need to get a patch applied to the core.
I could.
But more often, I'm going to come to the table with a new thing.
It's a thing that isn't in the core.
It's a device driver for a new camera that just came out.
Or it's a machine learning perception system that I just built myself.
I get to share that with the community as a standalone package.
I can contribute that atom to the system rather than having to figure out how to modify the underlying core.
So I think the combination of those two things is it's just allowed people to come in.
really, really easily to the community.
And that's what's caused it to grow.
It's amazing how you describe it like that, because I know for me, when I listen to it, I know for many of our listeners as well, who, like I said, maybe are in sometimes a more traditional software engineering world, where right now with the innovations that neural networks and LLMs provide, they think about how they spend a lot of their times too, breaking big problems that used to be.
big monolithic problems down into smaller ones and then democratizing it and just handing it over.
to the stakeholder, to the domain expertise holder, to the person who sends that email every Friday and let them make the workflow with that tool you made.
And I think those are a lot of the really powerful unlocks that engineers in more generalized software engineering environments are experiencing right now.
So it's really amazing to hear how that same thing applies to robotics and beyond.
I also, I want to call out the really smart thing that you said about creating like an open source community that actually grows and becomes this like really almost like this like rich garden with like just so many things in it people want to come in they want to they want to plant their plants here they want to be in in this soil because it's rich and it's letting everybody actually own what they build and what they grow and that's what's really exciting i think about making that kind of ecosystem is everyone has a stake and in the environment and making it better and that's the really the magic of creating that virtuous environment.
So it's amazing to hear that, you know, taking so much joy and care to attention and fostering it.
I'm curious too, just from a leadership perspective, how do you think about as an ecosystem leader partnering with other ecosystem leaders?
And how do you think about like mutual growth on those kinds of levels?
Robotics is a very big space, right?
The robotics is, I wouldn't even say the robotics necessarily is a, it's not even a single ecosystem.
It's like a, it's like an ecosystem of ecosystems.
And so, There's the Ross ecosystem.
There's an NVIDIA ecosystem.
There's a lot of energy going into robotics.
I was at GTC a couple of weeks ago, and there's a ton of interest in applying NVIDIA technology to robotics.
There's a Google DeepMind ecosystem.
Likewise, a lot of interest in applying things to robotics.
There's an intrinsic ecosystem.
where we've got a particular view on applying robotics in a manufacturing context, and we've got a particular product offering.
All of these intersect with each other.
And so it's super important to understand what each ecosystem is trying to achieve, who the...
people are who are really driving those ecosystems forward, and then finding those places at intersection and figuring out, well, how do we work together?
You know, our friends in DeepMind have long been proponents of the open source simulator physics engine called Majoko.
And so, you know, to interact more effectively with them, we've been using a different physics engine historically.
We work on, well...
What if we both support the same physics engine?
Then our applications and our test suites move back and forth more easily.
We look at NVIDIA and say, okay, they've got all in on the open USD standard for representing digital twins 3D environments.
Well, let's make sure between that ecosystem and the ROS ecosystem that there's a good interchange because ROS has its own way of representing 3D environments that actually predates USD.
Let's make sure there's good interchange there.
And then, hey, maybe we'll just see where people vote with their feet and maybe USD becomes a more commonly used representation.
But I think just being aware of what's happening in each of those ecosystems and then being willing to find those areas of overlap and then figure out how to work together, that's what leads to a successful outcome for everybody.
This is really inspiring to hear you listen about how accessible robotics are now.
And I want to touch on something that I learned about Intrinsic that currently all have an AI for Industry challenge that's running right now.
Could you maybe give me some more details about it and how maybe folks that have been listening to this conversation could participate if they're curious and taking a dive into robotics?
Absolutely.
And there's a long, proud history in robotics of challenges really motivating a field.
I think it's a great...
forcing function to like get to basically put a problem in front of a group of people and say okay this is a problem that we we think it's an important one because we've drawn it from real experience also we've kind of specified it clearly so it becomes a task where we can everybody can can enter and participate and then we can measure performance against folks and hey there's there's a dollar prize associated with it along with bragging rights so in this case for that what we call the ai for industry challenge this is the first time we've done it and what we're focused on is a particular task that is incredibly relevant in electronics manufacturing and that's handling of cables so pretty much every almost every electronics device even pretty small ones end up having some cables in them and what we're working on here is at the at a kind of a macro scale if you look at servers there are lots of servers that are going into data centers these days and there are cables to be uh connected inside those servers when they're being manufactured and this is something that's been traditionally very difficult for robots to deal with uh you know when they you get up if you give give you a bit of cables they're all kind of entertaining inner you know woven they're tangled can you can you see can you pick out one cleanly from that scene using perception?
Can you decide, well, how do I pick it up?
Having picked it up, are you able to feel well enough in order to insert it and where it needs to go?
These are intellectually challenging problems for robotics.
They're also incredibly relevant for an end customer and manufacturing.
So what we did is we took that together and designed a competition where we've formulated a specific cable handling, a set of tasks you need to do.
You need to pick up a cable, you need to plug it in in a particular way.
We give you a simulation environment that you can run at home.
So there's a repo you can clone off of GitHub.
You'll get a simulator that you can run at home.
In fact, I think we even support three different simulation environments depending on which one you prefer to work in.
Our assumption is you're probably going to use a modern AI, a neural network based approach to come up with a policy in order to solve this problem.
Although, hey, if you took a classical approach and just like wrote some code to solve it in more of an imperative fashion, that's up to you.
Like a solution is a solution.
And then you can submit your solution, your policy to us and we test it and we can score it.
We've got a leaderboard.
We've already got folks up there on the leaderboard now.
And we've got a few phases to this competition.
So we're going to take the highest scoring folks out of the first phase.
We're going to get them into a second phase where they're going to start using, interacting with a cloud hosted system that intrinsic runs.
And then the people who do well there are going to progress into running on actual hardware.
Very cool.
It's like a multi-phase hackathon with all these different gates that you jump through.
And along the way, you're learning about this simulation space that we talked about today that allows folks to innovate and to build.
And it's really fun to hear you describe all the things that robots can tackle, and then here they are.
getting tripped up by a cable, you know, something that as humans, we just take for granted all the time.
We just plug it in with full accuracy, not even thinking about it.
And you could do it with your eyes closed, right?
You could, you could reach it to the bin and kind of use your fingers and pick it up and then you could kind of go wiggle it in.
It's super hard for robots.
And that's a, that's a real obstacle to manufacturing at a time where there's a lot of demand for more devices like that.
That's very cool.
So it's exciting to see y'all open up the challenge.
I know I'm going to go check it out, especially since you've packaged up a really great starting kit.
There's no reason why I can't throw a cloud code session at it and see what me and it could do.
And so I invite our listeners to definitely explore and to do the same.
And Brian, thanks so much for sitting down with me today.
Besides the hackathon as well, where can folks go to learn more about you, what you're doing at Intrinsic, and follow the latest from the challenge as well?
So I'm sure we can get a link in the notes for the challenge website.
That's where you can download.
We'll point you to the participant toolkit so you can get the code to run at home.
You can register to participate.
There's a whole community where people are starting to talk with each other about what's going on there.
More broadly, your entry point for all things related to ROS is ross.org.
That's where you'll find an entry point to that whole community, including all the discussion forums.
pointers to the documentation, the tutorials, things to get going.
I would, you know, again, suggest starting with one of those low-cost robot platforms like a robot or a TurtleBot.
If you're into mobile robots, a TurtleBot is a low-cost mobile robot that you can get to work with.
If you find any of that interesting, we do ROS meetups and developer conferences throughout the year.
Our global ROSCon that we do every year is going to be this year in Toronto in the fall.
So look that up and come join us in person and get to know some of the folks behind the ecosystem.
There'll be a bunch of folks from the broader ROS ecosystem.
There'll be a strong contingent from Intrinsic representing there as well.
Very cool.
Well, we're definitely going to share all of those notes.
I'm definitely going to be checking out Roscon.
So thank you again for joining.
And like I said, you'll be able to find all of the links and things that we talked about today in the show notes.
But don't forget to find us on LinkedIn or Substack as well, where we include this with our weekly newsletter.
You can find myself there as well as our guest.
And we would love to continue this conversation with you.
So if you have any questions or you're inspired or challenges about things in the world that we talked about today, we want to hear.
from you.
Just let us know and we're going to follow up with you.
And thanks again for joining us on Dev Interrupted, everybody.
We'll see you next time.
And Brian, thanks again for joining me today.
It was a true pleasure to have you here.
My pleasure.
Thanks, Andrew.
AI is everywhere in software engineering, but most teams still can't prove its impact.
That's where the Apex framework comes in.
Apex is a new operating model for engineering productivity designed to measure AI where it actually matters at the pull request level.
It connects AI activity to delivery outcomes, not just tool usage.
Apex is built on four pillars with AI leverage, predictability, efficiency, and developer experience.
Apex helps you increase throughput without sacrificing delivery confidence or burning out your team.
Because speed without predictability creates chaos and faster coding often shifts bottlenecks downstream.
If you want to operationalize AI the right way, Linear D and Apex gives you the system and the cadence to do it.
download the guide and start measuring what matters