The interview transcript below has been edited for length and clarity.
John Healy: You cannot wait for a robot to sense danger and then think about how it sends the information back to the cloud to then get an instruction to make a change before it, it adapts to that change, and particularly in an environment of safety. You need to run more of that responsive computing on the device.
Sam Witteveen: Today we've got a really interesting conversation with John Healy, who's the vice president and general manager of Industrial and Robotics at Intel. So many things are going on with physical AI. It's not just all ChatGPT nowadays. John is here to basically tell us a little bit about what's going on and clear up some of the things that we've been seeing at VentureBeat as well.
John, welcome to the conversation.
John Healy: Sam, it's great to be here. I'm delighted to have the opportunity to chat with you today.
Sam Witteveen: Your recent research found that 67% of leaders are confident that they'll manage a mixed sort of robot workforce in the future, but only 40% of them feel like they're prepared.
So what are the missing factors that people are leaving out here?
John Healy: Yeah, it's a really interesting piece of insight we gained, Sam, as we conducted a survey across some 800 representatives across multiple regions and multiple industries, and what was clear was the ambition to deploy more robots was very high But their s- readiness to deploy at that scale was actually quite low, and that was the 40% number, those who had an actual strategy written down, a real strategy that they were pursuing for a robot and human workforce integration.
And so as we distilled that insight, we really boiled it down to five areas. Having a strategy in the first place that comprehends what will it take to integrate automation or forms of robotics with my workforce? Have I thought through the implications of that in a more structured way? The other was the area of skills.
Do I have the skills internally in my organization to address the needs of deploying robots at scale? And that's really interesting because it starts to create not just new skills required and new roles required, but also the modification of some of the, the roles that already exist when you want to integrate automation with what is workforce management or operational management.
Then there was the area of safety, ensuring that robots are going to be safe in deployment, and that's quite an interesting subject in and of itself, I think we'll return to. And then there was shape, or we might-- some might call form factor of the robot, really thinking about what does it take to deploy robotics if I'm automating a particular function, and do I want a humanoid?
Do I want a, a mobile robot like an AMR, an automated mobile platform, or is it some manipulator that's going to be some combination of both? Really thinking that through so that the robot's deployment is one that's best tuned to the need of the application. And then the last was really a comment around scale.
Oftentimes people are saying, "Hey, I'm ready to deploy. I want to deploy at scale, but I have five robots working today. How do I deploy 50 or 100? And what does it take for the industry to support that level of scale deployment?" So those five S's we narrowed down to being the areas that represented the distillation of what we call the deployment gap.
Sam Witteveen: So that, that's fascinating. Can you walk us through a deployment? Like I think for those who are old enough, we tend to think of The Jetsons or something, along those lines. What does a deployment actually look like for people who are getting this right nowadays?
John Healy: Maybe I'll start with an example of a, a robot that's acting in a collaborative way.
We call those cobots, collaborative robots, because they get deployed with a human operator doing some work. And let's say it's a precision engineering role, just for the argument of an example, 'cause we have cases of customers we've supported in doing that. That robot may be handing parts or holding parts while the human is doing some of the assembly work.
So think of somebody putting together a circuit board where that has precision components to be populated on that board. The robot, the cobot, is holding, maybe holding the platform or the board while the human is putting parts in place, and then it takes the finished product and puts it to one side.
At the robot, both the sensors are managing i- its ability to understand its environment, and it's making some decisions, which we call inference, on the robot to respond to those decisions. So sitting at the robot is intelligence, a form of computing that's allowing the robot to respond and adapt as things are changing.
Then right behind the robot, somewhere within the premise, is the next stage of the deployment, which typically is some form of management and supervisory server or computing platform that's supporting that robot and maybe many others in their deployment within that environment. We call that fleet management.
So you have a local server managing the fleet of robots that's deployed, and it's also allowing the data that's being captured on the robot to be gathered and stored So that during oftentimes the night when the operation is slowed down or stopped, that local server will fine-tune the models that run on those robots to ensure that the next day they've learned even more based on the experiences of the robots in that day.
So you have the robot, now you've got a local server that's supplying some of that support. Then typically behind that is the work that happens in the cloud, where training of the original model is occurring and large data sets are used to tune that model to become more foundational in the kinds of applications it can support.
That's typically what we see in, in, in an implementation today.
Sam Witteveen: You brought up this whole idea of sort of inference versus training, right? And I think this is something that people don't, give enough thought to. W- how does the model break down when people, perhaps the company is looking at how much do we allocate towards inference, how much do we allocate towards training?
John Healy: There are actually two maybe major considerations when you're considering a deployment. So let's just use a humanoid for the fun of it. A humanoid has multiple different functionalities that it needs to be capable of supporting, from movement to articulation, to understanding its environment, to, avoiding issues, to having a safety protocol.
All of those are differing functions that will all coexist in a humanoid. The model that is trained initially looks to comprehend all of those functions and many more. That's the or- initial stage of building a foundational model for humanoid-like deployments. That will typically happen where le- we often ti- type to think of it as where computing resources are unlimited, as in the cloud.
So that's why we see so much build-out of data center infrastructure to support AI model training. That's typically a cloud-based activity. But the ma- major consideration for deployment is the round trip delay or latency that you can afford when you're running the robot, how quickly the robot can respond to a change in its environment.
You cannot wait for a robot to sense danger and then think about how it sends the information back to the cloud to then get an instruction to make a change before it adapts to that change, particularly in an environment of safety. That will dictate that you need to run more of that responsive computing on the device, and we call that inference.
So inference is running the model on the deployment, on the de- deployed device or the robot locally, and that's the big split that occurs. So you have a practical implementation of where you can run compute based on the need of the application, and that's typically latency or time-dependent. But there's a second consideration, which is one of cost.
What we see happening in some of the early deployments is that there's a heavy dependence on cloud and less infrastructure build-out locally. And so as they move, as vendors or as customers move from the first few that they tested in the lab environment with a heavy dependence on cloud, and they look to move to the many when they're deploying tens and one hundreds, they need to build more infrastructure locally to support that, which includes what they build on premise, the servers that are doing that fleet management and coordination, and on the robots themselves.
And one of the things we've seen is the ability to manage differing forms of application need on the robot is becoming increasingly possible. In our case, the investments we've made and the applications we see with our Core Ultra processor is an example of that, where you have heterogeneity in the robot.
You can do real-time control, you can do inference, which is the AI manipulation, and motion and management of the articulation of the robot all in the same platform. That's a big cost advantage for somebody moving into scale deployment of their robots.
Sam Witteveen: You've brought up the concept of humanoids, or you've talked about humanoids multiple times, right?
Is that the right thing that people, that, organizations should be looking for? It seems to me that there's probably a lot of use cases where while a humanoid might be the best, it might look like, very impressive and stuff like that, it's probably not the most reliable thing for various use cases.
John Healy: Yeah, it's a very interesting discussion, and that form factor does push the boundaries of a lot of the technology. If we can solve it on a humanoid, all of the other types of implementations, other form factors, whether that's a manipulator on a fixed base or a manipulation, a single arm on a wheeled base, those become easier for us to solve.
What's more likely and more maybe important is to think about how does the form factor of the robot evolve in support of the work that it's going to do. So if you think about the needs in a warehouse or the needs in a hospital or the needs in a retail store, the shape of the robot should be designed around and supportive of the application that it services.
So why two arms if five are better? Why not an octopus if you want to hold multiple things and you want to be capable of manipulating and working at the same time? Two arms is a human limit. Four arms is a robot. So that's one example. It could be also that you're better to have a more manipulative top end on a more stable base, like an AMR base.
That means a manipulator sits on top of a stable base that can afford to have a larger battery pack, so more power. It's much less likely to tip over based on the payload that it carries, but it benefits from the dexterity of what we might have naturally associated with a humanoid form factor, and that's much more likely, Sam, the direction the market will take, is that we will combine the differing functionalities and shapes to support the needs of our application.
Somebody mentioned to me recently, why have two cameras where the eyes would normally be on a humanoid if you're actually better to have a camera on the end of each appendage of the grasp? So now you have a highly de- detailed view, three-dimensional view of the device you're working on, and it makes a ton of sense.
So it's much more likely robotics will evolve toward the need of the application than some specific form factor that we like because it looks better and it's more in our own likeness. I'll give you another example that I think is very real, and we actually use it ourselves in Intel, is the quadruped, which is more dog-like, four legs or maybe six legs, depending on its design.
Those can be very effective for navigating the perimeter for both a security or a, a surveillance sort of a role, where it may be reading sensors or indicators and can navigate over terrain that is both inside and outside. A walking device is much better than a wheel device for that kind of environment, so it's a very practical implementation.
But it's not deployed because it looked like a dog. It's deployed because it actually can navigate the terrain really well and still do the job that it was designed to go do.
Sam Witteveen: John, everyone thinks of, Intel probably as hardware but really you and your team have been working a lot on the software side and the software layer.
Can you tell us a little bit about, Intel's robotics AI suite? How does that help teams that, and organizations that are just getting into this, and how does it help them to get to the deployments that you've talked about?
John Healy: Yeah. Really our goal is to re- reduce the time to implementation and remove friction in the development flow from early model training all the way to deployment at scale.
And so with a set of assets like our robotics AI suite, we're really bringing together the modular componentry for the foundation layers of what makes a robot function. Adding libraries that'll enable you to accelerate those functions so you can meet the strict requirements of the deployment.
I mentioned the timeliness and the latency management, so we have libraries to enable that. And then the tools that allow the developers of the applications to seamlessly train and fine-tune their model. So within the suite, we have an asset called the Physical AI Studio. That allows somebody who really doesn't need to understand how the model works to tune and fine-tune the behavior of the robot based on the work they want it to do.
So imagine somebody who wants to train a robot to fold the sheets in a hotel. They can do the folding and the robot is watching what they're doing and learning the technique, and the studio allows the model that's running on the robot to be fine-tuned to better imitate what the operator or what the human being was doing.
We call that imitation learning. And so that allows for the robot's model to be fine-tuned without understanding how to manipulate the model itself. And then the other asset we've built into the Robotics AI Suite is a physical AI framework, which is accelerated with OpenVINO, which has a long history of enabling, computer vision and v- and video-based analytics to be accelerated and v- and produce very high performance applications running on our underlying hardware.
And what the framework provides for is the integration of that fine-tuned model that comes from the studio with the remaining subsystems that exist within a robot. What our framework provides for is an easy way to intergrow, integrate all of them together by writing very short number, a short number of code scripts to pull those in d- different blocks within that framework.
That's a path to reducing the time to implementation to allow the developers to focus on what they really do best, which is innovating in their applications.
Sam Witteveen: John we've come to t- time. What's the best way that people can actually find out more about what you and your team are doing, about Intel's Robotics AI Suite?
John Healy: Yeah, all of this is available on intel.com, and we'll be able to share a link for people to go and look, and they'll see examples of the products, they'll see examples of the applications in market, and some contact follow-up information if they want to even pursue m- more insight.
Sam Witteveen: John, fascinating conversation.