Why Humanoids Are the Future of Manufacturing

Hi, everyone. Thank you so much for joining us today. And thank you, Alberto, for joining me today as well. I'm Aya Durbin, and I am on our Atlas Product Team. And I lead our Humanoid Application Product Strategy. That means I decide where we'll start with this robot and what customers are looking for this robot to do over a long time horizon, so that we can make sure that we build a great strategy to get there over time. My background is in warehouse robotics. I come from a company called 6 River Systems, where we implemented AMRs in warehouse environments that we're working directly with people. It was my job to build interfaces for people to work with these robots directly, and to build out the workflows that handled all the different types of exceptions and issues that came up in these warehouse environments. I'm very excited to be here with Alberto Rodriguez, who is on our behaviour team. Alberto, I'd love if you could share a little bit more about your role, background and what your team is responsible for. Great. Yeah. So I joined BD about four years ago. Before that, I was a faculty at MIT, and I decided to step down and join BD, in part because of the excitement about Atlas wanting to get into manipulation. And now I direct the behavior team in Atlas, which basically is responsible for the development and implementation of the AI strategy. So how are we going to get Atlas to move and manipulate the things that we wanted to do and how our customers are going to do that. So Alberto's team is really responsible for figuring out how we fulfill the long-term promise of humanoid robotics being general purpose, which I think is something we hear a lot from customers that they're really excited about. I think when people see the humanoid form factor, they make a lot of assumptions about what it can and can't do. And the thing that people are most drawn to is actually the ability to have a machine that's flexible and that is adaptable to real-life environments. Do you think that the level of general purpose that's required to achieve that long-term vision is actually possible? I mean, how is your team thinking about tackling that? Yes, to give you a short answer, but I guess I'll go to the long one. When I joined BD about four years ago, one of the things that I got a chance to do was to visit many factories. One of the things that stands out after so many trips was the fact that many of the tasks are being done in factories are extremely complex, so the challenge is very high. And the other thing that stands out to me is that a lot of those tasks, even in modern factories today, they're not automated. And the reason why they're not automated is not necessarily because we don't have the technology to automate them, but it's mostly an economical reason. It just doesn't make sense to use current modern hard automation technologies apologies to solve those tasks. Just to give you an example, in car manufacturing plants, just imagine a modern car manufacturing plant, it makes about 1,000 cars a day. So extremely efficient. And then the rest of the factory is a big funnel that is responsible for bringing always the right piece at the right time, in the right place so that the people that are doing most of the assembly and assembly line, they don't have to waste a second in finding that part. They're always on the job following the cadence of the assembly line. To make that happen, so in the same assembly line, they might assemble between 5 and 10 different cars. Each car has thousands of parts and each car has, I don't know, there are five different trims with 20 different colors. So you multiply all those numbers, there's a ton of variability of the parts that need to be handled. And if you look at the assembly line, you get in a similar situation. It's full of thousands of very small tasks that are very dexterous, which involves a huge amount of variability. And all of that variability just makes it not economically feasible to use hard automation techniques like the kinds that you would design a special purpose and effectors or fixturing to reduce the uncertainty and specialized solutions. So really, the goal post for humanoids, the real value is addressing directly that variability, that generality that can unlock the ceiling of current automation techniques. Going back to your original question, is that possible? Can you actually build humanoids that can provide that degree of generality? The problem is really hard. Like, if you look at an assembly line, the real problem that we are talking about is someone fishing with its right hand into a bowl full of bolts, picking one, going with the other hand to pick up a ball driver, inserting the bolt in the bolt driver and screw it on the underside of the roof of a car, maybe while bracing with the other hand to maintain balance. It is very complex. But that is our lighthouse. That is the task that we are aiming for Atlas to do. There's fundamentally no reason why it shouldn't be possible. The hardware is capable of it. We know that. And the techniques we're using today should be able to scale to that level of complexity. So we're convinced that it is possible to get that generality. There's certain barriers or certain complexities to get there. But the technology is clear. We want a technology that is capable of that is general-purpose hardware, that is capable of ease of retasking so that we can avoid the scaling issues with complex integration for each one of the tasks, we need that technology that enables natural interfaces so that our customers can tell these robots what to do not by complex programming, but rather by directly telling them or demonstrating them what they should be doing and safety around people. Those are the core tenets, and we think we're convinced that it's possible to get there. If I had to pick up one thing that I think that we might still not have a really good solution for how to get there is the incredible degree of reliability that is necessary to deploy robots in, let's say, factory lines; how are we going to get to the 99.7% reliability that they have today. That's a fascinating challenge, where we're in a-- Very big area of research that we're going to need to keep investing in. And I think on the topic of reliability, there's three key areas that Boston Dynamics that we think about when it comes to delivering customer value, which to me on the product team is the most important thing that we can do. I'm very excited about humanoids being used for any task in the future, but in order to continue to get investment, in order to continue to prove that humanoids will reach that point, we're going to need to have milestones that show customers that humanoids can provide value today, which means we need to start getting reliable in a few different areas. We have hardware, which needs to become reliable. We have our behavior, so the robot actually doing the physical task over and over again. And then we have the application software that lives on top of this. It also needs to be reliable. We need customers to be able to know what to expect from these systems. Humanoids need to be predictable. We've learned a lot from spa and from Stretch about how we make hardware reliable, how we make this application software reliable. How do you think we're going to take our learnings from spa and Stretch into actually building out a product that is usable by our customers in the near term? Yeah, that's a great question. So I think there's tons that we are already learning from our other products. And that's one of the benefits of being in a company like BD that has already been through this trajectory before, with both Spot and Stretch. The trajectory of building a product as complex as an autonomous humanoid or autonomous quadruped, it goes in three phases. At the very beginning, at phase one, you're building the robot, you're building a machine. And most of what we do is limited by hardware reliability. Hardware reliability gets in the way of how fast we want to do development. And being able to do early deployment, sustained deployments with customers, that I would say, where all humanoids are today. The moment that you get your hardware reliable enough that you can do sustained deployments, then you go into phase II. That is where you bring your robots for a long time into your customers. And then you learned what I call the other bitter lesson. For those of you that know Rich Sutton's the bitter lesson. What is the other bitter lesson? The other bitter lesson is that the customer is always right and you were probably wrong. You've made wrong assumptions about the product you were building. Maybe the level of autonomy was wrong. Maybe your system is not handling enough exceptions. Maybe your human interfaces are wrong and in that phase you are quickly developing and evolving the software. But it also includes many other supporting capabilities that actually turn a robot into a product. Once you lock that in, once you actually learn that lesson and figure out what your customer actually wants, then you go into phase III. You can actually scale deployment and then is when hardware becomes again a liability. That is the long tail of hardware reliability that you can only work once you get to thousands or tens of thousands of robots. For reference, that's where Spot is today. Those failure modes, you only get the statistical evidence or what are the right heaters once you have tons and tons and tons of hours of operation and evolving that and solving those problems takes time. Getting hardware to be a perfect machine or close to perfect machine takes a long time, because any of those failures might involve, I don't know, change a supplier up the stream and change that part and then change your manufacturing operations. And then proving to yourself that actually that makes a difference. That can take months to do that. So I think all humanoids are still in phase I. We're working really hard and really fast to get to phase II. But I think it's very clear that we're still in that phase. So being in phase I and trying to get our hardware reliable, I'm sure lots of people are currently asking themselves the question, why would we make our hardware more complex with legs. I get this question from customers all the time. I get this question from my family all the time. So I think maybe both of us can offer our perspective on why we've come around on legs, because it's definitely been an internal debate that we feel very confident that we've landed in the right place on. But it's absolutely been a debate. And so I want to answer the question because I think it's a good one. We've talked a lot about visiting facilities. We have our engineering team visit facilities. I've certainly visited hundreds of facilities myself, exploring applications across markets and understanding where humanoids can be valuable in all different walks of life and in all different types of industrial environments and home environments and retail environments. And I can say with 100% certainty that we do not need legs in all of those places. But what I will also say is that we spent a lot of time already talking about the long-term promise of humanoids, and that's really why they're being built. People want a flexible piece of hardware that can be easily retasked and do anything in a building that a human might do. And if that's the long-term goal, then we're building a piece of hardware that helps us get to that goal. Hardware that has legs, hardware that looks like a human means that we can work in any environment where humanoid might be valuable. It means that when the software does catch up, when your team solves all of our problems that we have working towards that goal, the hardware is there and ready for us to explore all of those opportunities with customers, and we can do it at lower cost and lower complexity, because we don't need to keep building a new robot every time we want to explore a new application or a new opportunity. There absolutely will be robots that take over the job of humanoids in some places if legs don't make sense and that's OK. That's exciting. That means the robotics field is growing. We want to make sure that as we do research and as we build out our software stack, that our hardware is there to support it. And then if we have different form factors in the future, that's even better. I agree with you. From a technological perspective or from a capability perspective, I think legs actually makes sense. It used to be that the problem with legs was dynamic stability. How are we going to get robots to not fall, how much compute do you need to use to maintain that stability. But actually what we've seen in the last couple of years is that has turned out to be an easy problem today. Like that is no longer a bottleneck dynamic stability. And if you can handle it, legs gives you a certain very interesting capabilities. So from a form factor gives you a slimmer body, which allows you to go to more places in more constrained environments, which, as you know, we've seen in many factories. Legs also allow you to turn faster by enabling discrete contact changes in the support of the robot that allows to do quick turns, while if you have a wheeled robot, you have to navigate the complexities of the dynamics of stopping and turning. So I think in some way, legs, from a capability perspective, actually makes sense. Maybe if I had to pick one caveat that is still remaining is safety. Being able to certify safety in a dynamic balancing robot, it's still today something that we don't know how to do. There's no regulation. There's no process to certify a robot that is safe in a human environment. But as a company, we're working alongside other companies that are also building humanoids to create the regulation umbrella and the certificates and the tests that are necessary to be able to guarantee, certify that certain conditions are met. Ultimately, the deployment in factories will require, just like many other technologies that are deployed in factories, it will come from a combination of certifications and trust on the vendor, but also training and expectations from humans in the factory, which is a place where you can have those. How do we get to homes, for example? That's a bigger question. And that leads us into where we're going. In this conversation, I want to make sure that people walk away understanding how we're getting from where we're at now to that eventual home use, retail use and use of humanoids really around people on a regular basis. We've been talking a lot about where we're going with humanoids and what the North Star looks like that we're working towards, and all the research that we're doing to get there. I want to make sure that people walk away understanding how we're actually planning on getting there and how we go from where we are now to that long-term North Star. We want to add value to customers soon, and when we think about which applications are a good fit for us in the near term, we really think about three things. The first is we need a robot that's capable of actually performing the task. We need to actually have the behavior capability to pick the item up to work in the environment, and to do that core task that us humans take for granted. We need to do that task reliably. And maybe most importantly, we need to perform the task the exact way that the customer expects us to. These robots need to be predictable. If you've ever hired for any job, ever you know that whether you're hiring someone to do work in your home, to do work in a restaurant, or even to do work on a factory floor or in a warehouse, even if the person has five years plus experience doing the job, you're still going to train them on how they should perform the task in your specific facility home restaurant. Because in your environment, different problems come up and you want them to handle those problems in a unique way that you do it in your facility. And when it comes to adding value to customers in the near term, that's a really important component of our full solution that we need to offer if we're going to really go into building soon. And so we really are paying attention to all of the parts of the problem that need to be solved if we're going to have humanoids actually working in facilities soon. We've thought a lot about where we start, what our beachhead is going to be. There is a ton of research that needs to be done in order to fulfill that long-term goal. And even in the short term, if we want the robot to be reliable at performing these behaviors, there's a lot more research I know that your team is working on to make that happen. So picking the right beachhead was a really important decision for us, and we did a lot of visiting of customer facilities and touring of sites to make sure that we made the right choice there. You were a big part of that selection process. And of us selecting industrial manufacturing is the place that we'll start. What made you believe that really is the right place for us to start when it comes to making sure that we are still making progress on research, but also adding value to customers in the near term? The first component, which was like a necessity, is that it has scale. It has sufficient scale for it to make sense. But beyond that, I think there were two things that made it very important or we thought made it a good choice. The first one is safety. So manufacturing, because of the structureness of not just the setting itself, but the way that workflows happen in factories allow for certain concessions that gives an easier ramping of safety requirements. You can start with robots that don't get close to people, for example, or just stop the moment that people get close to them and from there ramp up to more complex situations. And then the second one, which was very close to my heart, is that manufacturing has sufficient variability to motivate the need for generality. So we're not building a special-purpose solutions manufacturing from a financial perspective makes sense to attack it from a general-purpose perspective from. After the many, many visits, it became clear that the kinds of things that people are doing in these settings, that the kinds of operations that are necessary to assemble cars or assemble many other things are extremely complex and motivate that generality. If I put my research hat on, I would say that manufacturing is almost manipulation complete. So if you get your robot to solve the complex manipulation tasks that are necessary to assemble a car, you're good to go. You can get your robot to do many, many other things outside of factories. So that manipulation, completeness, it was important to go to that selection. Manufacturing definitely offers that range of tasks that make sense in the short term, that we can build on over time to reach that long-term goal. The parts we're working with now are the same parts that they work with on the general assembly line, which is exciting because all the work we do today matters for that long-term goal to getting to manipulation complete. I'm sure very quickly. So let's get into how we actually teach the robot to do tasks. I get tons of questions from customers that want to better understand what can we do today, how do I know what we can do today, how do I learn what we can do today. When will we be able to do more, when can we do more tasks in their building, how do we train the robot to do tasks? I think in general in the media, people are hearing that AI brains and large behavior models or LBMs will be the solution to this problem. And I think this is a great forum to help clarify for people what is an AI brain, what is a large behavior model, do you believe that these are answers to some of the questions that we have about how we reach generality? Can you explain a little bit more about training. This is, I think, a great forum to help answer some of those questions for people. It's a great time to answer that question because the answer to how are we building in generality or how are we creating behavior engines. The answer to that question has changed dramatically in the last three to four years. It used to be in the good old days, just a few years ago, this is how we were teaching it in classroom. The way that you build a behavior engine is something like a pyramid. So on one hand, you have raw inputs that get into the robot. So camera, pixels, tactile feedback, encoders and on the other hand, on the other side, the output is currents or torques that you send to your actuators. And you can think of what used to be a layered system of algorithms that on one hand, they were taking the raw information that was getting into the robot and turn it into more and more abstract and complex representation of the state of the world. So getting from raw pixels to features like points, masks, lines on an image and from there get to objects with identities, and from there get to maps, where you localize things in the environment. And then downstream from that a sequence of algorithms that we're making more and more concrete decisions about what the robot should do. They're starting from, OK. The next thing the robot should do is pick up that object and move it there. Then you distill that down into, well, the robot should take a few steps and then reach to that object and then take it, grasp it, move, and then distill that into an actual trajectory, and then distill that into torques or currents to the actuators. And this is how robotic arms and AMRs are working today? This is how they're working today. This is how most robots, including humanoids, were working just a few years ago. And the problem with that you can build systems that do complex behaviors with that. But there's two key problems. One is maintenance. So that system is built out of many, many blocks that have many dependencies. And the moment you want to improve it a little bit, it's just very hard because any change you do, you have to change a million things in the system. So it's very hard to maintain or improve. And the second problem is scalability. So it's a system that is not necessarily based on accumulating knowledge or experience over time. So every time you need to do a new deployment, you still need your very experienced engineers to just tell the robot how to do the thing that you actually wanted to do. One of the things that we figured out over the last few years is that there's a much more scalable process to do that, which basically means replacing all of that internal structure of the brain or the behavior engine by a system, a neural network that is not programmed, but instead is taught to do the thing that you wanted to do through experience, in most cases through demonstration. So going back to something you just said earlier about on-the-job training. When you hire someone, when you want someone to do something, the way you want it to do that's what we call post training. So that's on-the-job training. That's the core of the basis of how to get today a robot to do something to a certain degree of performance. So basically, means you demonstrate the robot how to do something and then you demonstrate it many times, usually through teleoperation today. And at the moment that it makes a mistake, you jump in, you correct it, and then it learns over time through those corrections to be better and better at executing that job. That is thing that loop of improvement of giving the robot more experience through demonstration is the loop that we call post training, and is the loop that is necessary to do for every single task where you want to deploy a robot. Now, the problem with that is that again, it just becomes difficult to scale if that process is tedious and long. So what's the real bet here? The real bet is that you need a second system that just on the Spot, provides a good initial guess as to what that behavior should be for any task. That's what we call pre-training. And that's the massive system that accumulates knowledge over time and is capable of creating somehow common sense and generalization over what it means to do a certain task and achieve a certain goal. Now, that is one of the most interesting questions today is how are we going to build. That's the LLM equivalent in robotics, the large language model. And that's the AI brain that people are asking about? Yeah. I mean, in my head, the AI brain is both things. Both things are indispensable. So you want a system that has common sense, but you're always going to need a system that gets that common sense to actual high performance. That's on-the-job training you were saying. Like you're always going to want to tell the robot actually do it this other way because it's just I prefer it that way or you've messed it up here. So in my head, both are essential parts of that strategy. Now, how do we build that common sense? That's one of the trillion-dollar questions today. And basically, it boils down to providing enough experience and knowledge about general tasks, about general environments, and about general motions and being able to accumulate it in a way that then is accessible by the post-training engine. How do we do that? Well, you have different ways of providing demonstrations to the robot. One, the most common today is still operation. So scaling up the operation to get the robot to do hundreds of tasks, and you get one single engine to learn how to do hundreds of tasks with the hope that it will generalize over time. And then there's other ways, other means, by which you can provide demonstrations that are less close to embodying the robot like teleoperation, but are easier to scale. So you can use simulation. You can discover behaviors in simulation with reinforcement learning rather than through demonstration. Or you can directly look at how people do certain tasks and try to learn from more unstructured demonstrations, let's say from video. Accumulate all of that information in such a way that that engine at least is capable of certain things. We want Atlas to be able to know how to move gracefully with agility and with strength, and that is independent of the job that it's doing. That it has to be able to do that anyway. It has to know, for example, it needs to have enough common sense that if I'm going to apply a certain force in that direction, maybe I should change my stance to expect that I'm going to be receiving back a certain force. You want Atlas to have a certain degree of visual spatial understanding. If I'm seeing you there, I know that you are more or less at a certain distance, and that if I want to reach to that thing, I need to reach at a certain amount in a certain trajectory, with a certain velocity. All of that is also independent of the job, and it's very useful information for this large brain to contain as a general knowledge. And then things that are more specific about the environment where it's going to exist. In our case, there's no reason why Atlas has to learn about the existence of the thousands of assets and thousands of fixtures and tools that it's going to see in factories, because we know those ahead of time. So there's no reason why not to put them in that general understanding. And fourth, and maybe most important, dexterity. How do we get Atlas to actually become dextrous with its fingers to the point that it can use tools. It has a common understanding of what it means to exert sufficient force through a tool, or it has common understanding of what it means to handle reorient objects, or what it means to insert something. The feeling of clicking something in place. That's something that should become part of its general understanding that it doesn't have to learn on the job. It's interesting to think about the types of information that a robot cares about versus a traditional LLM that we're all starting to get used to. If you think about the LLMs we're using today, they're looking at data that's publicly available on the internet because that's really what it needs to answer our simple questions about how to write an email slightly more professionally. But a robot, the types of data that you're talking about needs a whole different set of inputs to be able to output what we expect it to which is, I think, definitely more clarified in this conversation already. I want to dig a little bit deeper into the teleoperation question that I get from customers. Not everyone has seen how we actually collect data via teleoperation with the robot. Can you paint a picture of what it's like to do the teleoperation process? What technology do we use? How experienced are the demonstrators and how long does it take to collect enough of this type of data to actually build a policy that allows us to do the hard type of work that we're talking about? We think teleoperation is a valuable workflow for teaching robots how to do certain tasks, and we're definitely using it. It's also a workflow that is valuable to show robots how to correct for mistakes. For example, it's unclear whether long term actually that is the right interface for our customers to use to tell our robots what to do. Probably, some more natural interface like language or just direct visual demonstration is more scalable. But for today, teleoperation has become essential and most companies rely on it. It's probably the most reliable way to teach a robot what to do. So imagine one of our demonstrators, one of our experienced demonstrators. So they put on a VR headset. So they see through Atlas eyes in three dimensions, so stereo vision. So they get a good awareness of what it means to see through Atlas eyes, which is important because we don't want demonstrators to do things in a way that later on, would be difficult for Atlas to see. We want our demonstrators to embody what it means to feel and be Atlas. Our demonstrators, they also have trackers. So these are gadgets that you put on your hands, on your torso and on your feet so that the way that they move controls Atlas in real-time life. And over time, they build a certain experience over how to get Atlas to do good motions, and what it means to get Atlas to stay in balance, what are the extents of the force that Atlas can exert. So there's certainly a learning curve of a few weeks for our experience demonstrators to get to that point. Once you get to that point, how do we build an actual one behavior? We collect in the order of five hours of-- between 5 and 10 hours of demonstrations of the same behavior. Not always exactly the same behavior, the same behavior affected by variations and potential failure cases, and see how the operators would-- demonstrators would correct for those mistakes. And all of that becomes the corpus of data that we use to train. We would use it, in this case in post-training to optimize the task to high performance. How do you envision us making it faster to train these robots to do new behaviors, from where we are today to where we need to get to? What will make it easier? Yeah, I think in some way that is probably the most important question. So it goes back all the way back to the generality and scalability question. So the amount of time you have to spend on post-training to get Atlas to do an actual job at high performance, that is the actual real cost. That is the thing that gets in the way of scaling your deployments, your integration, and the most effective way to reduce that time, the amount of demonstrations or the amount of time that we need to invest in each deployment is to invest into the large corpus of pre-training. The larger that becomes and the more general that becomes, the best. The first guess that it has about what is the actual policy that we need to run for a particular job, and then the lesser amount of time that we need to invest on-the-job training for each one of the tasks. That is what people call the flywheel. So the more times you've done that effort of building new tasks, deploying them, and those deployments are generating high-quality behaviors that is actually generating very valuable data that then you can put back into your pre-training and make that more capable. So that's what we refer to when we mentioned flywheel, the data flywheel. In general, our product philosophy is adding customer value in the near term and even from a research front, as we add that customer value, we're getting faster and faster and faster at delivering customer value, because we can train our system more quickly to do tasks almost without thinking because it has more knowledge already built into its brain. How fast do you think things are moving on the research front? We've talked a lot about the old techniques that we use to train the robot on new behaviors, and clearly there's a whole new way that we're moving forward and how we train our robot to do work. What has it felt like to be moving this quickly? What does it mean for customers to be moving this quickly? Just if you can give a little bit of insight into what it's like to be into the research world. The first thing that comes to mind is exciting. I think that it's hard to think of any other time probably doesn't exist in the past where robotics has moved this fast. It's not just the speed, but also it's much easier to get our robots to do things that were impossible before, and that's very exciting. There's certainly some underlying anxiety that I think the whole community is pressing down. We're basically betting that generality, just like with large language models, will emerge with scale. And there's lots of good reasons to believe that that will happen. But that is not something that no one has shown yet. We have the right ideas and we have the right motivation and we have the right techniques for how to get there. We need to execute that. We also have exciting results that are really proving that we can add customer value in the near term. And the conversation that we just had about how valuable that is to our long-term goals is very exciting. I think it's important for people to take away that just based on the research results we've seen already, we know that we can do early tasks in automotive manufacturing and manufacturing and industrial environments, and that is wildly exciting because it means that the investment in humanoids is going to continue, and it means that customers will really start to see value soon, which really is the goal because that's the first step on a productization journey. That's the first step to building a business. That's the first step to enabling this long-term research that we want to get to. I think it's important for everyone to keep in mind that there are many pieces to this puzzle, and there's a lot of noise in the industry right now, and everyone is so excited. And there's a lot of focus on specifically the known unknowns that we've really been diving into today. But there is a lot we do know. We know a lot about hardware reliability at Boston Dynamics. We know a lot about how to build great application software and operator interfaces, and how to make sure that even in this new world of AI, our robots are still following the rules of the road in customer facilities. So I'm excited to take our customers' experiences and our customers knowledge and pair that together with what we've learned from Spot, from Stretch, and from all of our thousands of robot deployments that we've already done, and combine that together into what the next step is for Boston Dynamics and for the world, which is humanoids. And it's all very exciting. So thank you for helping to provide some clarity on what we do definitely know and what we do definitely not know but we're working really hard to figure out in this world of noise that everyone's living in. Thank you. Yeah. I have a question for you. When are we going to get to have 1,000 robots in the hands of our customers? That's an excellent question. Or 100,000. Choose your number. We will have thousands of robots deployed in the next 5 to 10 years. That's our vision and that is what we are aiming towards. And I think just based on the conversation we've shared today, it's clear that we've made the research results that will get us there. And that's why I feel confident in saying that we will absolutely have robots in the thousands deployed over the next 5 to 10 years in industrial environments. Hundreds of thousands is definitely a larger question. I think that's actually a better question for you because your team is going to have to solve the problems to make that one happen. But yeah, we're very excited because we have thousands of Spot robots out into the wild. We know that it's possible. We know how to do it. And we've seen the research results that will get us there. I'm very comfortable with those numbers. I think that because of the experience we have from Spot and Stretch, we have an understanding of what is the process of maturing these products, building the hardware, maturing the software, maturing the customer relationships and building trust with them. And in a way, I think of Spot is leading the charge. Spot is at that sweet Spot right now, where At the sweet Spot of the hockey stick, where we have thousands of robots out there in the hands of customers, many customers that are scaling, and you can think of Stretch as being two years behind that and Atlas being two years behind Stretch. So I think I'm comfortable saying that within four to five years, we should be where Spot is today. It's exciting to be at a point where we've seen enough results to feel confident in those numbers, and we've seen from our experience that it can really happen. OK. Aya, here's another one. Also very easy. Can I buy one? Loaded question which I get all the time. I'm sure you're not surprised. From customers, from non-customers who are interested in humanoids, I think every single company in the world has a mandate from their executive team that says, what are we doing with humanoids? We need to be early. We're going to crash and burn unless we start using humanoids tomorrow. And I guess I'll say a few things on that. One, when humanoids are ready to be a product, which a product to me means it's a reliable member of your workforce. We're not there yet, but when we are there, the customers that are already using Spot Stretch today, the process of deploying a humanoid will be plug and play because especially having something like Spot that roves around your facility and does inspection enables a much faster deployment process mapping process for a robot like Atlas. And so we will be building out tools and functionality that make it very simple to drop Atlas into your facility if you're already using one of our other robots. So that's a great place to start that you can actually take action on today. That is absolutely on the path to humanoids, even if a humanoid is not physically standing in your building. That being said, we are doing work to make sure that humanoids are standing in buildings. We won't build a good product unless we do that. And so we've already started going on site with Hyundai, which is our first foray into doing on-site engagements. Now, Hyundai is a great partner to start with because we really need to be working with people in the early days that understand that this is not a hardened product yet, and Hyundai is really on that journey of eating-- they call it eating your own dog food. When you're building a product and working with us as we fail, as we succeed to build something that really works for operators in their facilities, that we can eventually leave on site, and we can call a hardened product that you can call me and buy. We're not quite there yet, and we will be getting there over the next year or two. So what is important is understanding the technological readiness of these systems, which is what the point of the conversation was today, so that customers can start to think about where realistically, is a good spot in your facility for humanoids to start, so that if you do reach out to our team and we start to have a conversation about where humanoids make sense in your facility, you're pointing us to the right places. You're pointing us to areas where you have lots of labor that is ergonomically unfriendly and just not great for a person to do, and that has more of those gross pick and place functions, because in the early days, I don't want to be asking you if we can deploy tens of thousands of robots into facilities where we're screwing screws into small spaces because that behavior is going to be a lot harder to get reliable than some of these other behaviors that we've seen in warehouses or manufacturing logistics facilities. Thank you. Thank you. So I want customers to think about, where does it make sense for humanoid to start for you so that when you do reach out because I know inevitably, we're going to have many people reach out after this conversation. We're talking about the right types of tasks, and we're talking about the right areas to start and come into that conversation with a mindset that you're not buying a product today. We're talking about a partnership to launch a product at this point. And over the next few years, as we get the product more reliable, that's when we'll actually start selling Atlas. And today, you can't just call a salesperson and buy an Atlas. You have to go through me and Alberto first. And that's where we're at in the process. Thank you, everyone for joining us today. This has been such a great conversation. I'm glad that we could shed a little bit more light into the reality of what's going on in the humanoid space. If you have more questions for us, please let our team know and we're happy to do this more often. Great. [MUSIC PLAYING] OK. So we have a lot of other questions that we got from the audience. Thank you for sticking around. We are not going to have time to answer all of them, especially after that wonderful question that you asked me. But we're excited to jump in and answer some of the most pressing things that we've been hearing from the people on the call. The first one is one that we have just started answering for the public, and that is why do we have a gripper with three fingers. And what are our plans for grippers in the future. I think people are interested in the idea of a humanoid robot having many styles of grippers to pick up glass parts or parts that clearly require something other than fingers. So how do you think about grippers? Why do we have three? And what's our plan for the evolution of the hand? Yeah, happy to answer that question. I get it many times. So basically, it boils down that we like building grippers that we need for today and that we need to do the research that we need to do today. So for the phase of the program where Atlas is, we wanted Atlas to be able to grasp many things. And building a gripper with three fingers, we deemed sufficient and we've proven that it is sufficient. It's a gripper that you can grasp almost anything that we throw at it. If you add more fingers, if you add more complexity, it always ends up you pay the price in terms of unreliability. You pay the price in terms of lower speed of development. We are definitely working on more complex gripper that will get to see in some time in the future. And they might have more fingers if we think that they're necessary. Our next milestone is dexterous manipulation, and we are building grippers that have the degree of robustness and strength that our current grippers have, but that they will also be able to use tools, they will be able to do assembly, and they will be able to grasp small objects and handle them. It's funny that you bring up dexterous manipulation because that is a question we got many times in the Q&A. We in general at Boston Dynamics are focused on adding customer value in the near term, but in order to reach our long-term goals, we need to be setting ourselves up for success in the future, which means doing research, like you said on those longer-term horizon targets that we have to achieve those goals. One of those things is doing research on dexterous manipulation. We know we're going to need to do it in order to get to general assembly. Can you tell anyone a little bit about the work that we're doing in the office today that will set us up for success to be able to do more of those dexterous tasks? Definitely dexterous manipulation is a large fraction of the research we're doing today in the office. While teleoperation is very central to building these systems, we do think that acknowledge that it has certain limitations. Dexterous manipulation is a behavior that relies on fine finger control and processing haptic sensing in a way that is difficult to expose our teleoperators to. So we have two alternative bets that we're getting good success from. The first one is reinforcement learning in simulation. Reinforcement learning is an algorithm. It's a type learning algorithm that instead of learning from demonstration, it learns from trial and error. And because it's done in simulation, it scales up much faster and much easier than teleoperation. And we're very excited about of results we're getting the new grippers we're building to do complex tasks that involve assembly and small object handling. The other bet, which is a more longer-term bet, is actually learning directly from observing how humans use their hands. If you're building hands that are not too far from the morphology of the human hand can become an effective way of at least making it easier to learn dexterous manipulation. So we talked a little bit about legs earlier in the conversation. And one of the components of that conversation that's come up in the questions is, how do legs impact the cost of the robot, how are we thinking about the cost of a humanoid. Wouldn't it be cheaper if we built a robot that had wheels instead of a robot that had legs? And so just how do we think about that in general? I'm going to answer this question from a product perspective, and I would love to answer it from an engineering perspective, too, if you can do that. When we think about cost of the robot, we're really thinking about how we offer a positive return on investment for customers. That's our main concern. The form factor of the robot is not the main point of the conversation. If we can get the form factor that we have, that can tackle all the applications that customers want us to tackle to a price point, that means that we can get customers a fast return on investment. That's what we're most interested in. That's what customers are looking for, and we are able to do that with legs and wheels. Legs, like we talked about earlier, have all different advantages. And so to me, as the product owner, I want to make sure that we're offering customers that positive return on investment and so long as we can having a product that works for the largest number of customers in the largest number of environments, and that allows us to explore, especially without having to iterate on hardware, which again, would increase cost and increase complexity. That's better for me. That's better for the customer at the end of the day. I guess what are your thoughts on cost, especially when you think about legs versus wheels? Yeah, I think from an engineering perspective it's an easy answer that's really not much of an advantage from an economical perspective in having a wheel-based robot. The number of actuators that you need to build legs, it's quite similar to the number of actuators that you need to build a mobile base that is stable and is omnidirectional. So ultimately, you might have four wheels, but each one of those wheels might need two actuators so that you can rotate the wheel. It adds up to eight. You might even want to have a z-axis to go up and down. So at the end of the day, the number of actuators doesn't make a big difference. And you also get much higher mass, which needs higher power to drive. And it doesn't make much of a difference. It might actually be the case that building legs ends up being cheaper than building stable, high-performance mobile platforms. That can reach high, they can reach low, they can go into the areas that humans can go into. And now we're back to why did we choose legs in the first place. All right. Thank you so much, everyone, for joining us today. We had such a great time talking with all of you. Keep an eye out for more. We will have more coming soon at bostondynamics.com and on our YouTube channel. channel.