Intel Corporation (INTC) Earnings Call Transcript & Summary

[Presentation] Welcome to the Intel web press conference. I'm here in the Mobileye garage in Israel where we are working on the future of mobility. And I can't wait to tell you what we have been up to. You may ask why Mobileye is giving the Intel press conference. First, it's because Mobileye is a growth engine for the company, and Intel is fully committed to the business. Later today, you'll hear more from Gregory Bryant where he gives his perspective on the power of computing. I thought it might be interesting to have an outside perspective on what the Mobileye news means for the industry. So I have invited Ed Niedermeyer to join me on stage to help unpack the news. Many of you know Ed from his Autonocast podcast as well as being the head of communications at PAVE, Partners for Automated Vehicle Education. Welcome, Ed. Thank you for joining me today.

Thank you so much for having me. I'm really looking forward to getting the chance to talk.

I've really been enjoying some of the videos that Mobileye has been putting out from the testing that you're doing in Jerusalem. It's really impressive to see what can be done with cameras. But it sounds like you're starting to test elsewhere. Could you tell me about that?

Sure. When you think about scale of testing, this is what enables us to test in different geographies, there are 2 factors. One factor is now its how general or transferable is your driving policy algorithm. So driving policy is all about decision-making about the car merging into traffic. So if you are overfitting to many, many driving data, lots of driving data, then you'll need lots of drives in your location, and that will limit your scalability. The second point is how fast can you build a high-definition map of the new area that you want to test. And if building the high-definition map requires lots of manual labor, that also limits scalability. So on both fronts, we made huge progress. On the driving policy, we are by embedding our RSS into the algorithms of driving policy. We're able to kind of obstruct the problem in a way that is no longer data-driven and is really Ocham's razor. It's generalized and transferable. So we believe we can go from territory to territory without testing. Second is our RAM technology. This is crowd-sourced idea of using driving-assist cameras in production vehicles, sending out snippets of data to the cloud. And in the cloud, we build high-definition maps. After kind of development of 5 years, we have passed a threshold in which we today can build high-definition maps at scale. No manual labor, data coming from production vehicles. We have hundreds of thousands of production vehicles sending us data. And we are basically mapping the world, all automatically, everything done in the cloud. And then came the COVID-19. So the pre-COVID-19 era, if we want now to build a new site, we would send 20, 30 of our best engineers to the new site, but travel is impossible there today. So in Munich, we have 2 people. They are not even engineers. They are field support employees to support our driving-assist products with our customers in Germany. So we were able, in 2 weeks, to ship a vehicle, test it. The mapping is already automatically. We have now about 20,000 kilometers of data just in Munich already, already mapped. In 2 weeks, set it up and start demonstrating to our OEM partners in Germany. Hundreds of drives already. We have been doing those demonstrations and tens of thousands of kilometers of driving data just to see how things are going in 2 weeks. So this gave us this feeling that now we can scale. So we're planning China, in Shanghai, Tokyo, Paris, Detroit. And if we figure out how to get the regulation with the New York City, with the New York State, we'll also plan to deploy in New York, all in the matter of the next few months because those 2 factors of scalability are practically solved in our development.

Unless you're really familiar with the AV development, you may not understand like what a dramatic thing that is to be able to do so much in -- go to a new area and in 2 weeks with 2 employees to be able to do that. And I think for driver assistance, that idea of a camera-based system is really widely accepted. Again, it's the most common form of driver assistance but -- or advanced driver assistance. But when it comes to autonomy, people are a little bit more skeptical, I think, that a camera can really do so much on its own. Can you help explain sort of what is that relationship between sort of the ADAS that Mobileye already has a huge business in and the autonomy piece where you're headed? How do those 2, yes, interact.

I think it's a great question because it really separates us for most of the crowd. So I believe that camera first, camera first is crucial, both from a technological point of view but also from a business point of view. And business also matters, right? So let's start from technology. The question we ask ourselves is, what is an acceptable failure rate of the perception system if we want to deploy a Level 4 car? Now we measure failure rate in terms of hours of driving. So let's do a back-of-the-envelope calculation to understand what are the human statistics. So if we Google, we'll find out that there are about 3.2 trillion miles a year in the U.S. being traveled by cars. And there are about 6 million crashes a year. So divide one by another, you get every 500,000 miles on average, there is a crash. And let's assume that 50%, it's your fault in the crash, so let's make this 1 million. And let's divide this by, say, 20 miles per hour on average, so we get about once every 50,000 hours of driving, we will have a crash. So now let's assume we -- let's assume that we have reached that level of performance using a robotic machine, and we deploy 50,000 cars. Now 50,000 cars is not a big number, right, if you want to build a business. So it means that every hour on average will have an accident, which is our fault because it's a failure of the perception system. Now this is -- from a business perspective, this is not sustainable. And also, from a society perspective, I don't see regulators approving something like this. Even though it matches human statistics, you have to be 1,000x better than these statistics, right? So this is where redundancy helps us. So we tell ourselves, look, if we build a camera-only system with the mean time between failure of a square root of what we need, say we are targeting 10 to the power of 8, 100 million hours. So have a camera system where the mean time between failure of 10 to the power of 4, 10,000 hours, right? And then radars and LiDARs will be a redundant add-on to -- for the remaining square root, for the remaining 10 to the power of 4. It's like I have an IOS smartphone and an Android smartphone in my pocket, and I ask what is the probability that both of them crash at the same time. Clearly, it's a product of the probabilities because you're talking about different modalities here, radars, LiDARs, cameras. So this is why it's, from a technological point of view, so crucial to do really the hard work is not combine all the sensors at the beginning and do a kind of a low-level fusion, which is easy to do. It is -- forget about the radars and LiDARs, solve the difficult problem of doing an end-to-end stand-alone, self-contained camera-only system. And then add the radars and LiDARs as a redundant add-on. So this is from the technology. Now from the business perspective -- now if you are building a technology which is good only for Level 4, then you really need to wait for a time in which Level 4 autonomy is prevalent, is ubiquitous. Say 5% of all new cars would be Level 4 autonomy. Now this could be -- this could take a decade. Now during that time, during that decade, you'll have 0 revenues. Now it's not sustainable unless it's a government-funded project. It's a national project. So you really need to think about the business if you want to sustain for the long run. And it's not just a science project, right? You want to build a business. Now it turns out that if you do this redundancy, the camera-only subsystem is ideal for pushing the envelope of driving assist for Level 2 systems, right? This is exactly what we did with winning the design project with Geely in China. So September next year, this car is being productized at volume production in China for Level 2. So the idea is that you have this camera subsystem. Now since it's camera-based, it's at a consumer price level. So now you have a scalable thinking. And this scalable thinking is really the cure for sustaining such a long time until Level 4 becomes ubiquitous. Now business matters because if you don't have the oxygen for a marathon run, then at some point, you'll fall, right? So it turns out that it's ideal from a technological point of view but also ideal from a business point of view.

To me, it's refreshing to hear sort of one of the leaders, if not the leader, in sort of camera-based automated driving sort of emphasizing that even though you can do so much with the camera that getting that sort of safety critical level of reliability does require on other kinds of sensors, the LiDAR and the radar. And in fact, one of the pieces of recent news for Mobileye is that -- and Intel is that you're going into LiDAR business to an extent. Could you explain sort of what the thinking is behind that?

Yes. So the way we're thinking about it is that consumer AV will take some time. We believe it's going to be 2025 time frame. Therefore, if we want to start practicing, we need to start with Robotaxi because the Robotaxis are less price-sensitive in terms of this cost of a self-driving system in a car. And then we can build this LiDAR -- radar-LiDAR subsystem in parallel to the camera subsystem. So our first-generation of Robotaxis are going to be based on the Luminar LiDARs and also a cocoon of radars around the car. And we have a separate vehicle. You don't see it here, but we have a separate vehicle. Luminar LiDARs, few radars, no cameras at all, no cameras at all, that has the same performance level of our camera-only subsystem. And then at the end of development, a moment before we launch, we put the 2 subsystems together. Now in parallel, we are also building second generation, the 2025 time frame. Because, as I said before, it's a marathon run, right? You can't think just 2 years ahead. And there, we are looking at the next generation, the technological leap in LiDARs and radars. So in LiDARs, it's called FMCW, frequency modulation coherent wave. So it's a completely different principle. It's a kind of a Doppler principle rather than a Time-to-Flight principle. And it turns out that Intel has a huge advantage over everyone else. Intel has a silicon photonics, both in terms of fabs and production and in terms of IP, where you can put active and passive laser elements on chip. And we have a team that has been working for quite a long time in building the next-generation LiDARs. That is kind of where we're targeting this 2024, 2025 time frame. On the radar side, we are targeting imaging radars. So these are radars that have a much, much higher resolution than today's radars. This is why they are called imaging. It looks like an image. But the twist here, it's going to be software-defined. So rather than analog-defined, you simply sample the entire scene, and then through software, you do all the modulations. So this gives you lots and lots of flexibility. And we believe that by 2025, one front-facing LiDAR would be sufficient, and a cocoon of imaging radars and one front-facing LiDAR would be sufficient for this radar-LiDAR subsystem. And that will bring us to a cost level, together with the camera subsystem, which is good enough for consumer AV, for Level 4 consumer.

I think that's -- sort of one of the things that also sets to you apart is that you are in a position to say, this -- we're not just developing Robotaxis.

Yes.

We're going to build a truly autonomous vehicle that you as the consumer are going to be able to afford by a certain time. That's really kind of incredible. That's what a lot of people seem to want, isn't it?

I think Robotaxi would be somewhat of a game change when they'll be ubiquitous. Because removing the driver from the equation could reduce the cost of transportation considerably, even rival the cost of public transportation. But having a consumer AV, that is completely disruptive. That's completely game-changing. And I believe that 2025, we'll start seeing it. It will be at the cost level of the consumer AV. We'll have a number of years of practicing from a regulatory point of view because regulation is critical here, right? It's -- and it's sometimes -- it's difficult to leap directly to a consumer level from a regulatory point of view. Going through a regulation of a fleet is much easier from a regulatory point of view than regulating a consumer. So going through the phase of Robotaxi is very, very useful also to practice the regulatory front at relatively low volume before you go and jump into the cold water, high-volume Level 4 and then hell's -- hell breaks loose.

And I think the RSS framework that you pioneered is being adopted by a number of automakers, I think -- or players in the space. It's one of the sort of ways forward with that, right? Is that sort of the idea that this could be sort of a template that potentially maybe regulators might look at?

Yes, I believe the RSS, the Responsibility Sensitive Safety, framework that we built is one of our most important achievements. I would say this is our top achievement, more than anything else that we have done. Because back in 2017, we realized that the mean time between failure of the perception system, even if it's very, very high, it's not sufficient because there is a decision-making of the car. What happens if the robotic agent has a lapse of judgment? Humans have tons of lapse of judgments. This is why accidents occur. Now society will not accept a lapse of judgment of a computer. So what do we do about this? Because we are going to deploy an AV car amongst other human drivers. So it needs to behave accordingly, right? It needs to have the values. It needs to have -- it needs to behave according to human judgment because it's going to drive amongst humans. Now how do you go about it? Is this going to be probabilistic? Are we going to drive zillions of miles showing that we have 0 accidents, and then we'll convince society that we can put this machine on the road? So we understood that we have a problem. And then when we looked at the space, we understood that traffic laws -- and those traffic laws, there isn't much judgment there. Now you have the red light, you need to stop. If there's a solid line, you should not cross it, right? But then there is this duty of being careful. You are told you need to be careful. You are told that even if you have the right-of-way and the other guy doesn't respect your right-of-way, you should yield, right. Right-of-way is given, not taken, right? So this idea of being careful is not mathematically defined because a computer needs a precise and crisp definition, right? Now it's not just by selecting lots and lots of data, you'll be able to figure out what does it mean to drive carefully. Now we can go and define it mathematically. And this is what we did with RSS. The RSS defines mathematically what it means to be careful. It understands that humans make assumptions. So we replicated those assumptions in a mathematical way that has parameters, so that we can start engaging with regulatory bodies about the values of those parameters. And then once we have set those assumptions, the framework takes the worst case. That means I don't need to predict what the other guy is going to do because I'm taking the worst case under the assumptions that have already been agreed with, with the regulator. So this gave us kind of the Asimov rules, the 3 Asimov robotic rules. So it's a rule-based kind of thinking how do you define what is reckless and what is careful. Once you defined this, you know where the border, where the dividing line is, and you simply don't cross it. And then if the other guy puts you in a dangerous situation, you have kind of proper actions how to get out of it without causing an accident. So we built this theory, and it was clear to us, it has to be transparent, no hidden equations, no hidden sauce. It has to be fully transparent, so that we can communicate with regulatory bodies. We can convince also industry actors to take this as a basis, so that we can, together, work with regulatory bodies in order to standardize it. Because safety cannot be a secret sauce of an agent, of an actor because society will not accept it in the long run. RSS is -- I think is one of our crown jewels of achievement, and we deliberately made it transparent. And I believe that eventually, it will be standardized. One form of it or another, will be completely standardized.

I want to shift gears a little bit to sort of one of the other pieces you mentioned as being a key enabler of this rapid scaling that you're sort of embarking on. And that's the REM piece, the mapping piece. My understanding is that -- and you already described sort of what it's enabled in terms of getting the Munich operations up and running with 2 people in 2 weeks, which is amazing. But for those who aren't -- and I'm surprised that people aren't as familiar with REM. Could you sort of explain it, but then also maybe explain why -- decided to use that huge data to map rather than maybe to focus on things like using that for training data?

Again, it's a great question because when you think about collecting data from a car, you can think of 2 uses. The first use that comes in mind, the most natural use is to do event recording. So kind of find corner cases, cases where, say, the driver intervened, took action or through other measurements like the braking profile, decide that there is an event and simply record everything from your cameras. And then when you are connected to WiFi, send it to the cloud. And then in this way, you can have kind of a very scalable way of collecting events and use that to improve your system. It sounds reasonable, but actually, it's a brute force way of going about things. So I kind of deploy a crappy system and then in a brute force way, kind of call it beta. And then in a brute force way, kind of improve and improve and improve. Eventually, you will kind of get into a glass ceiling. Another way of looking about collecting data is to understand what is the source of problems in building a perception system. So on building a perception system, there are 2 things that you need to perceive. One are objects, road users, vehicles, pedestrians, buses, cyclists and so forth. The amount of data that you need to train a deep network to recognize these object is not huge. Years ago, we -- at Mobileye, we surpassed human capability of detecting cars and pedestrians and the data that we had years ago, right? So this is not a bottleneck. What is a bottleneck is all the rest. Understanding the semantics of the road. Where are the drivable paths? What is the relevancy of drivable path and traffic lights? Where do you stop in order to wait in a 4-stop kind of intersection or in an unprotected turn? What are the priorities? Is my path a priority compared to another path, so I need to yield or the other guy needs to yield? There are lots of -- tons of semantic data in a road. The limiters, where are the kind of the limiters that I -- places I cannot drive into, like J curves and things like that. It's so detailed that the probability of not making a mistake in a single pass, so kind of an online, the probability of being perfect. Again, we want to reach a mean time between failures of thousands or tens of thousands of hours, is almost unachievable. And then we told ourselves, well, crowd sourcing, it's not a single pass. I can have zillions of cars passing through a complicated area and by piecing all the information from those zillions of cars that pass through, I can do something that a single car would never be able to do, no matter how good my perception is. So this -- which the idea is we don't need data for event recording. We need data to build those maps. Let's call them map. So they're not really maps. It's not a navigational map. It's what's out there in the scene that is not a road user. Everything, I want to know everything about the scene, all the semantic information at great detail and great accuracy. I want to know where this lane is at a centimeter-level accuracy, okay? So the switch of the mind was that we need to build technology that will take information, data collection from cars, what has to be very, very low bandwidth because if it's not low bandwidth, we'll not be able to convince our carmakers to cooperate with us and send the high-bandwidth data to the cloud because it costs a lot of money, right? So we're talking about 10 kilobytes per kilometer. It's really nothing from a cost of -- it's $1 a year on an average kind of a mileage. And then do the really hard work. And as I said at the opening, it took us 5 years. We announced REM 2015. Only half a year ago, we reached the point in which we can truly, without a single manual labor, just automatically, take all those pieces of data going to the cloud and build this high-definition map at the required details to power our autonomous fleet. So this is -- from our point of view, this is the real use of data collection from cars. It's not event recording. It is being able to build the scene to an accuracy level that no single car can do. This is the beauty of it.

Yes. I think anytime someone hears map, they think navigation. And they don't understand that, as you said, this is about limiting the complexity that your probabilistic system has to solve for, right, if you know what's established in the landscape. So actually, I did want to clarify one thing that you had said. You mentioned that zillions of vehicles. I'm guessing that's not the official figure. I just wanted to get a sense of sort of what is the scale of REM. What kind of -- how many vehicles, yes, today?

So today, we have many hundreds of thousands, I think, even approaching 1 million vehicles sending data over 6 OEMs, 6 carmakers. Next year, it's going to be more than double than that. As of half a year ago, we got about 8 million kilometers of data every day. Now it's much more than that. And we have worldwide coverage. We are talking about something that's truly scalable, truly global because you can drive everywhere. And Roadbook is the enabler. It's not going city by city. It's the entire planet all at once.

Yes. So this is really fascinating. I just kind of want to take a step back for a moment here and just sort of get your thoughts about sort of about putting all these pieces that we've been talking about together. And then sort of comparing it to the competitive space.

I'll try to summarize what are the key distinctions separating us from all the rest. And it's a small number of distinctions. Everyone is -- each one of them is deep, but it's a small number. First is the REM technology. Geographic scalability all at once. The second is this idea of redundancy. Camera subsystem, radar-LiDAR subsystem. Next one is our driving policy, which allows us to really be transferable from territory to territory.

Yes. And if you look at the problems that each one of those things are solving, they are so fundamental to making this technology work in the real world and particularly at a scalable level. And I think both what you've shown in Munich and just your plans going forward, all of the different -- so I mean, this seems to be the most ambitious sort of scaling plan for a Level 4-focused Robotaxi company in by -- in such a short term. And so to me, I mean, that certainly seems like you must be able to do something that others aren't able to do.

Now we have a legacy of 2 decades. So now it matters.

Yes, I think that's oftentimes lost sight of new technology, everyone's focused on the novel. And 20 years of experience of computer vision is nothing to sneeze at. This has been just an absolutely fascinating discussion. Thank you so much for taking the time to speak with me today.

Thank you, Ed. It was great. It was a real pleasure. Thank you.