austin capital factory
Click to listen on Apple Podcasts or Overcast.
For a menu of other apps, click “Subscribe” above. You won't have to subscribe to listen. Or just listen via the player above.
An unedited transcript is below.
Joshua Baer:
(silence). Is it my turn to power on? Hello. Hey, can everybody come on and take your seats? We're going to get started. It's a great turnout. I hope everyone had an awesome Thanksgiving, I did. It feels like we should just be on vacation for the rest of the year, doesn't it? I think so already. I tend to start a company every winter vacation, that's my ... Set me aside and give me nothing to do for a while. Also, welcome everyone. I'm Josh Baer. I'm the founder of Capital Factory. My pleasure to welcome you all here tonight. Who's here for the first time? Awesome, a bunch of you. Well, welcome.
Capital Factory is the center of gravity for entrepreneurs in Texas and here in Austin. We have four floors of this building. All day long and all night, there's entrepreneurs and technologists and investors and other people here meeting at places like this and meeting each other and working. And then we do a lot of work. We have a big team of about 100 people that work with them to help connect them to the, typically the people they need most, which is money, customers and other people talent that they need to hire.
It's been really awesome as the Army Futures Command came here in particular and it brought some other real interesting partners like BAE and FAST Labs. That's the customer's side of this. They can serve some couple of different parts. One, they're big companies, they can buy stuff. But a lot of them are also channels to whole bunches of other customers and can help take products to market and help startups scale. That's been really exciting to watch happen. BAE and FAST Labs has been, actually one of the best partners in that. They were one of the first to come here onsite when Army Futures Command. They're actually working with a lot of the real startups here. There's things happening between them. That's why they're here tonight, at events like this is actually to meet people and innovators that are working on real things that they can plug in.
We're really glad to have him here. I think this is the third event like this that they've so far. I know we'll keep doing more. But it's always great to see it bring in, again, a lot of new faces and people that maybe hadn't been here before, so glad to welcome you. I'm going to turn it over to Beau Duarte who runs FAST Labs here in Austin. He's going to kick it off for the rest of the night. So let me hit it off the boat.
Beau Duarte:
Thanks, Josh. All right. I'll give a quick intro. I want to welcome the folks who have maybe not come to a one of our events before. We're a little bit leery about the Monday after Thanksgiving. We considered bringing in a leftover turkey, but we didn't have any within the company, but thanks for coming out here. As Josh mentioned, our series is titled defense innovation at startup speed. So what we are trying to do here is to educate you a little bit about what's going on at BAE Systems, identify some opportunities for a startup, so universities in the crowd that might have interest in one of the technologies that we're talking about and have some conversations that could lead to further collaboration or introductions.
Also, really just to contribute to the defense innovation ecosystem here in Austin, which we are proud to help support. We all play a part here in identifying the opportunities, working with the customer. Really we all serve the same multiple customer, the men and women in uniform. So, we're very proud to do our part for that. Before we get started, just a show of hands for folks in the audience who come from big companies. All right, a handful. Small companies startups, all right. A little bit more. From the government sector. All right, a handful of guys. University students or professors. All right, outstanding. Veterans in the audience. All right, thanks for your service. Just out of curiosity, air force, Navy.
Audience:
Me, Navy.
Beau Duarte:
Marine Core.
Audience:
Here.
Beau Duarte:
All right, handful. Army.
Audience:
[inaudible 00:05:08].
Beau Duarte:
All right, I'll try to speak slowly tonight for the army folks in the room. All right. Tonight we're going to talk about autonomy. We've brought in some experts from around the country who were able to fly in amazingly enough with all the weather going on around the country. We've got an initial presentation from Dr. Matt Henry, who is part of our autonomy controls and estimation group just north of Austin. He has been working as a principal investigator on a couple of DARPA projects. He is interested in autonomous applications, where maybe you don't have the full story, you don't have complete data. It's in a very challenging and demanding environment. Today he's going to talk to you about one of his projects in particular that I think you will find of interest.
Once he's done talking, we're going to have a panel of four folks. I brought in my friend, the ringer from California, Ali Tabibian, who has done a lot of work with venture capital and startups and folks who are interested in autonomy, mostly from a commercial application viewpoint. So, he will help tease out some great discussion points. We've got representatives from BAE Systems, from the army and from the academia world at UT Austin here. He'll introduce the full panel a little bit. But without any further ado, I'd like to hand this over to Dr. Matt Henry from BAE Systems. [inaudible 00:06:36].
Matt Henry:
Matt Henry from, I'm actually working at Arlington Virginia. I'm one of a number of chief scientists in the group that we call atomic controls estimation. Just to give you an overview of what the group does, BAE System is largely an aerospace company for those of you who aren't familiar with the company. I mean, literally aerospace mostly aeronautical relates, it's mostly aircraft. So most of the work we do in autonomy was geared towards aircraft with our manned or unmanned aircraft. Autonomy is both geared towards literally making the aircraft, conduct missions, fly routes and so forth that take into account different kinds of threat and other circumstances that might need to weigh in on how it conducts a mission.
It also governs how onboard systems operate. So things like sensors, fusion systems, sensors that can be managed and potentially observe pointed out, if you like, different kinds of objects of interest, different sensors of different platforms, aircraft themselves or coordination, autonomy as well. Is a wide range of things that we consider to be under the umbrella of autonomy. Of course, autonomy as a discipline or as a capability is largely, it controls enterprise, I'm a control's engineer myself. I mean, as long as the controls through extension of control systems, which encompasses itself estimation theory, other kinds of sense-making technology areas that really allow the system then to understand the environment in which it's operating and make decisions that are really appropriate for those circumstances and also the missions that it's conducting.
My job here tonight is to try to talk to you guys about some projects we're working on to get some excitement going on in your group about working with my company. Also, to get you guys thinking about solutions to a really hard problem that I'm currently working in. So the problem we're working in particularly has to do with our ground systems. As I mentioned before, we are largely an aerospace company. I think to a large extent, autonomy, at least in the defense industry has largely been deployed in the aircraft or aerospace domain more than any other domain. You can make an argument that enabled demand is starting to catch up a little bit.
But the ground domain is one domain which autonomy really hasn't made a lot of progress because a lot of complicated attributes to the ground mission space that make autonomy difficult because there's a lot of nuance in the environment that you're operating or nuance in agent on agent interactions with those are friendly agents or not so friendly agents, nuance in the environment, nuance in state and the mission that you're executing. They make it difficult to really make a system fully autonomous.
I wanted to talk about a few of those attributes and this is a hard problem for us. Solicit ideas from the group here, either through me or through Beau and his colleagues that are down here in Austin, to help us maybe help make this problem more tractable. So I'll come back to this example, probably in two minutes. Right now, to a large extent, I'm sure most of you know, with effective ground vehicles, autonomy or really if you like systems that don't have a person driving them really are remote or totally operated remote controlled. That is still largely true for these systems. There's no real autonomy here, it's really just about a system that's going to go out and conduct a mission. In this case, it's an IED electric, I suppose we've addressed explosive ordnance disposal robot that goes out and interrogates an IED or some other explosives that it's found. Tries to help the, in this case, IED technician understand what is going on with that particular payload.
But it's largely a remote operated paradigm in terms of just how the systems are working with people. The very best systems right now are really limited largely to way point volleying. To a large extent, the ones that are most successful are the ones, this is how largely how commercial companies are doing also, the ones for which cost maps have been pre-computed. What I mean by that is that the systems have taken advantage of many, many gigabytes, terabytes of data that describe the environments, which they're going to operate, describes the features of those environments.
And then the onboard sensors then allow the system to discriminate between those features, which are there persistently, those features, they're different to help them understand what's new about the environment, what needs to reason about and so forth. So way point following is the state of the art in the sense that it is the best that we can do reliably. I would say the very best of the best are systems that are able to compute weight of these so-called cost maps on the fly. Those are pretty unusual, it's hard to do. Even when that's done, it's done slowly so these vehicles can drive fairly, not very fast. Also, the only reason about environments with certain degrees of complexity. So even solving this problem of having a vehicle traverse a terrain to conduct a mission in an environment that is not well known is difficult.
Note this vehicles not driving on a road, so there's a lot of things about this environment that make it difficult. One of their course is just that the surface composition, which makes it difficult. But that's a fairly straight forward thing to do. But the harder parts have to do with obstacles, having to do with negative obstacles, understanding whether a puddle is actually covering a very large crater or hole, or is reversible or not, or if there's non-traversable obstacles behind shrubbery. All the other kinds of things there including the visibility of obstacles and things like that that make it difficult to reversus this kind of terrain.
I would say the state of the research is such that we have the capacity now to precompute mission components that we can string together to allow these machines to operate well with infantry. In this case, this is an exercise out at Twentynine Palms, which are Marines that are entering a facility or a mock building. It's difficult to see, but in the lower right hand corner of the photograph here, there's actually one of the small UTVs that is operating in conjunction with the Marines to provide some ISR support to their operation. So this vehicle is falling way points, although it's actually computing some way points along the way. But what it's really doing, it's more interesting, is it is executing behaviors that have been given to it and eventually as I mentioned, playing out.
In this case, the vehicle is driving in a pattern that was determined to be advantageous to this particular operation and choosing what pattern to execute based on where it is, where the Marines are and where the threat is, if it's detecting any threats. What we want to do though, even that degree of have much autonomy where it's able to follow way points or follow some pre plan mission segments, doesn't really allow for very natural intuitive teaming between people and machines. The reason is that all of that stuff, and understanding of the mission of the environments, of the tasks have to be given to the system before it starts the mission. So, it's very brittle in that sense. It doesn't allow the machine to really have any understanding of why it's doing what it's doing.
The Holy Grail, so to speak, is one in which the machine can really understand from a set of hollow objectives and constraints what is it that's supposed to be doing. That includes understanding where other machines are, where it's friendly human partners are and where threats are, whether those threats are well known or hypothesize or suspected. But understanding how to interact with other agents, other machines in the environment is as important as understanding what the mission objectives are.
There's an element of this kind of autonomy that has to do with, not only carry out the mission objectives, but understanding how to preserve oneself, how to keep itself safe from threatening fire, from other kinds of danger. So, being able to balance, for example, a mission objectives with self preservation or difficult thing to really help the machine understand. The ways in which it should preserve itself, it's difficult. But understanding how to interact with the other agents in the environment, understanding how that presents an overall mission space and understanding the state of mission at any one time and how it should proceed in accordance with mission objectives and self preservation objectives, is really the way we would want to go eventually.
A big part of this is really understanding the mission, understanding where every element of the mission it is, whether that's other agents, whether it's conditions of the environment, whether it's conditions of mission objectives, wherever those things are. So part of it is organic sensor to be able to see various attributes of the environment, see various attributes of the mission. Be able to understand then also from other external sources of intelligence what the state of the world is at any one time. Synthesizing that state of the world in such a way that can understand what it needs to do next based on what's going on now. So be able to do that naturally, although even in a small unit formation like this, you still have a hierarchy where a fire team leader or squad leader or platoon leader is going to tell his Marines what to do given the situation. There's brazen to carry out those tasks based on the circumstances that they're faced with.
Machines don't do that naturally. Machines follow instructions naturally. So having them understand what the situation is and what they should be doing based on the situation and based on what their partners are doing, which can change as circumstances change, that's really the difficult part of this problem that we want to address. Another part of this discussion is there are different ways in which machines and people can work together. Currently the way we think about this is we have machine groups largely working independent of their human counterparts. Networks as well because machines don't always understand exactly what human's intent is or where a person is, sometimes even if the person's not well observed.
But intent is where the hard part for the machine to understand if, for example, if you're a fire team and you're coming up to a danger zone and you need your fire team or your squad to cross a great danger zone and establish security in the far side. Understanding the way in which those Marines or soldiers are going to carry out that providing near and far security across the danger zone, the way in which they're going to take position on the near and far side is difficult to infer only from the soldiers and Marines position. Maybe you can defer some of that from the tempo of the mission, maybe you can defer some of that from the locations of the Marines or soldiers. But it's difficult for a machine to interpret the intent. Part of the reason is that machines don't understand signals very well.
Marines when they do this, they actually signal each other with bumps or other kinds of low audible signals, allow the other team members of the team to understand what they're going to do, is they understand how to execute that part of mission. So, machines don't understand that. Sometimes it's better for them to operate separately because they can communicate with each other in a way that allows them to understand what their tactic is going to be, how they would execute that part of their mission. That's dangerous in some ways because then the machines are often left to defend themselves. Often they don't understand how to take cover or how to prevent themselves from being observed by the enemy. So it can be advantageous then for the machines to be working in close collaboration with the soldiers or Marines. So, that introduces more complication, but also offer some benefits.
Part of the study that we're engaged in in understanding what the real trade offs are in terms of operating separately or as part of the close form units and what the perception requirements are, the understanding requirements are and how the machines, they could be used to execute those mission elements with that limited degree of understanding. We can measure this in a variety of ways as we make progress. What the army and the Marine Corps are really interested though is enabling machines to act as a force multiplier for their fire teams or squads platoons in terms of enabling those Marines or soldiers to have a great control in the battle space, be able to understand about what's going on.
Being able to provide granted situational awareness to call an indirect fires, for example, is a big part of how soldiers and Marines operate when they are dealing with enemy forces, they are not immediately within their range of weapons. Those are measures effective that you could use to evaluate how well the systems are working. Capabilities is one of the other ways to measure this. But those are all ways of measuring how well the system is working.
The challenge is we need to work on, in terms of understanding what technologies we brought to bear to enable these kinds of capabilities have to do with perception. As I mentioned before, mobility is one that's given a lot of attention, but is not a solved problem. We work in the space largely of maneuver autonomy and mission management in the sense that we tend to treat platforms as being contained units. We want to more operate on the level of telling those platforms where to go and what to do without so much how to do those things they're being asked to do. So, the trade off between the platform level autonomy and the mission level autonomy is one we work with often.
The other part of this that we need to be concerned about is understanding how the soldiers or Marines are interacting with the systems and how much load we can expect those soldiers or Marines to really take on themselves recognizing that other people will intuitively understand how the communication should be interpreted in terms of carry out a mission. A machine doesn't always have the same level understanding of what this mission is and how it was going to be carried out and what a signal might mean in that context. So, providing a mechanism that allows a soldier or a Marine to communicate with machines in a natural way, so the machines can understand the context and the interpretation of a signal is a big part of this problem space.
Really as technology developers, our goal was not to prescribe how the systems will be used. Our goal is to provide the systems with capability they can be used in different ways by the war fighter because the war fighter will always find new ways in which to use any system. So we want to provide as much flexibility as we can in terms of their utility. I'll close with this example scenario. You can see here all the landscape clearly, we tend to use red and blue to correspond to enemy and friendly forces respectively. We have a variety of different kinds of platforms in this environment, different kinds of sensors and so forth. We have also a mix of actors, we have human actors and machine actors. The problem here is we want to really provide a force application to this platoon, this company or whatever sound unit this is without forcing one of those soldiers and Marines to act as a babysitter for these set of systems.
The systems have to be able to not only understand what the mission is and how to carry out the mission, they need to be able to construct and understand the mission as the mission proceeds. That includes things like be able to estimate where the threat is, which is pretty straight forward, that's pretty straight forward. What's less straight forward is being able to anticipate where the threat might materialize based on historical information, based on some notion of intuition that machine might have in terms of where the threat has been, what threat is likely to go based on the threats, the assumed threats objectives and the possibilities that are open to the threats. In other words, viewing the world a set of opportunities and constraint. That allows the machine to have a better understanding of what the situation really is, allow them to gain an understanding of what the threat is likely to materialize, and then decide what to do in that context.
But we also want to use the machines to take the load off the people in terms of some of the more mundane tasks. A recent study we did indicated that something on the order of one half of the firepower of a Marine squad is used on a daily basis to resupply the squad, which is an obscene amount of firepower that's wasted in terms of just plotting resupply or over watch for the resupply mission. So being able to allow these machines to conduct those kinds of missions, these now new missions, to allow the fire team or squad platoon to operate at twice effective level, be a huge multiplication factor for that small unit.
Really understanding how we can gain like benefits that really have a large multiplicative factor is our goal. It's a matter of really then of getting these systems the ability to understand how they can contribute in a way that allows them to carry out these tasks without having to be told what to do and how to adjust to changing circumstances, whether in terms of their mission extrusion, but also in terms of understanding how they can protect themselves from being damaged or otherwise disabled. I guess it, yet.
Beau Duarte:
All right, great. Thanks, Matt. Thank you. We're going to save the questions either for Matt or the panelists until the end. At this point, I'd like the panelists to come on up here and have a seat. Hopefully, you know who you are panelists. That's a joke. I will introduce a little bit more in depth, our panel moderator is Mr. Ali Tabibian, who is a Stanford classmate of mine who has been working in finance in Silicon Valley for about 25 years for direct principal investment as well as M&A.
Also, he's got a keen interest in the intersection of hardware and software in innovative ways, especially for robotics and autonomous vehicles. He produces a podcast called Tech. Cars. Machines. He's got a lot of interaction with companies in the commercial space that are investigating autonomous technologies. I thought he would be a great moderator for the panel to do some crosstalk with defense applications. I think we stand to learn both sides from what has been done in the other sectors. So, I will turn the mic over to Ali and let him introduce the rest of the panel. Thanks.
Ali Tabibian:
Great. Thank you very much, Beau. One of the fun facts I always tell about our firm is that two of my partners and I were in the same freshmen dorm together, and this is going back in the matter of decades. Sophomore year, we lived in a dorm where Beau Duarte happened to be a resident. Years and years later, I was watching one of the presidents make a speech and he was standing in front of an aircraft, which said, Captain Beau Duarte, on it. I thought, wait a minute, I know this guy. So I found him. About two years later, Beau was kind enough, when he was the program manager for the Navy's autonomous drone program, he was kind enough to speak at our conference, which is a similar event in Palo Alto. I'm very happy to be able to reciprocate.
Hopefully we'll have both intellectually interesting conversation for you here. But given the mix of the [inaudible 00:27:00] crowd, I do want to try to as much as possible really bring home the commercial opportunity of everything that we're going to discuss here to our participants here. Why don't I go ahead and make a very brief introduction of everyone, and then instead of having you introduce yourselves, we can just actually go into some of what you'd like to discuss here?
At the far corner, we have a Dr. Paul Decker, who's the deputy chief roboticist of the U.S. Army. He joins us from Michigan. Did I get anything wrong there? No, so far, so good, okay. All right. We're off to a good start folks. We have Dr. Jerry Wohletz, who's the vice president and general manager of FAST Labs. So you're based here in Austin. Jerry, is that correct?
Jerry Wohletz:
Boston.
Ali Tabibian:
In Boston, okay. Close enough. All right, great. Dr. Ufuk Topcu, who's an assistant professor in the department of aerospace engineering and engineering mechanics at the University of Texas at Austin. I'm hoping you're in Austin. Is that correct, Dr ... Great, great. Thank you very much. I'm going to start with Jerry. Jerry, I'm going to ask you if you'd like to tell us a little bit more about FAST Labs. If you think the audience is already aware of it, that's okay, we can skip it. But in particular, I'd like you to discuss the scouting function. That's one of the two key functions of FAST Labs. What experience and success have you had in the past in terms of how you've integrated some of the people like those present into the audience into your programs and ultimately into a commercial environment at BAE?
Jerry Wohletz:
Yeah, let's see. [inaudible 00:28:36]. There we go, it's green. All right. First off, thanks for having us here tonight. It's a great event. FAST Labs, it's relatively a new name. We rebranded how we do R&D and BAE Systems a year and a half ago to signal our pivot as we've transformed to a commercial CTO model. So FAST Labs today is more representative of what you would find at a Procter & Gamble and Johnson & Johnson in the historical aerospace and defense company. Just a little story about FAST Labs. Each of the letters represents companies that have been acquired that forms a single unified R&D organization and BAE Systems today. So the T in the FAST represents Trey Core, which is a heritage Austin. I think we are the largest defense employer here in Austin for a private company.
A little bit about our approach, consistent with taking a look at where the money is. U.S. government today accounts for about 8% of the R&D investment in the U.S. and 3% in the other world. But most of the aerospace and defense industry is stuck in a cold war space race mentality, where the belief is that the U.S. government is the dominant R&D investor. So recognizing that and the need to go faster with innovation is that we have a completely dedicated team that is searching for dual-use technologies that map to our technology strategy. We have, again, like a Cisco and a commercial company, we have a tech strategy that looks at the different markets and customers we serve. We need to be one step ahead of all of our businesses. In doing so, we are very deliberate in determining what we need to acquire because of the dual-use opportunity or given the custom military nature or something that we have to still do within the national defense infrastructure.
With that, on the acquire side, we come to venues like this. We're very active here in Austin, we're very active actually across the U.S. working with large accelerators. We basically bring them our problems. We talk to them about the challenges we have. We look for the technology that maps to what's in our portfolio of needs. Based upon that, we provide subject matter experts and we essentially will help validate a channel to market for which venture capitalists and private equity investors can then apply funds, mature the technology, use it for the commercial, use it for the military and we'll put it into high volume production at any of our worldwide factories that we have. So that's the basic model that we've pivoted to.
The tech scouting group, Beau, representing here in Austin. Dr. Francesca Scire-Scappuzzo is our head scouting. She's based out of Boston and very active in the ecosystem there. This is core to the business that we're going to. So we're about two years into this experiment. As it stands today, we're probably working with the better part of 500 companies. Some of them, we fund at a very small level. But our desire and our means is to connect them with people who've got a lot more money than we do with a desire to very rapidly mature that technology and at the end of the day, bring it to the war fighter as quick as possible.
Ali Tabibian:
Great, thank you very much. If you could pass the microphone to Paul, my next question is for Paul. Paul, two things I'd like you to touch on, and then we'll come back and expand on them, one is, what goes on in Michigan where you work in your particular unit? If you could, at the end, just list the key enabling technologies and central challenges of the unit that you are a deputy chief scientist for.
Paul Decker:
Okay, all right. Good evening. It's a pleasure to be here. It's first time ever being to the Capitol Factory, so it's a great venue. okay. Up in Michigan, formerly known as TARDEC under the Army Futures Command, we're now known as GVSC. So it's AFC CCDC, GVC. You guys all got that? Nice and short. We're formally known as TARDEC. Now we're the Ground Vehicle Systems Center. Our focus is on research and development of military ground vehicles. We also get involved from time to time in small UAS kinds of activities, but it's focused on research and development of military vehicles. Anything from small PackBot size robots that are ... how many of you are familiar with PackBots? Most of you.
Talons going up, SMets, where you're tracking the ... what's going on with SMets most of you? I know the BAE folks are, but the other folks, small businesses, are you guys tracking SMets or CVS, does any of those mean anything to you? Robotic combat vehicle? No. Optionally man fighting vehicle? [inaudible 00:33:29]. The exciting thing about army robotics now, for quite a while, we are stuck in OODA loop where there were not requirements to generated, there was no requirements, there's no program of record, no funding equity, where the big money is an acquisition programs. So I think we've finally broken that, it's taken a while.
My boss, Bob Sadowsky, I don't if you know of him, but he was really key in helping break some of that and working a lot with archaic R&D, the army requirements folks. I'm happy with Army Futures Command, I think it's going to continue to accelerate that. We'll have the requirement in the robotics area. Over the last 10 years or so, a big focus for us has been in the leader follower technology. I think you'll see that a lot in the news. Really what we're looking to do there is entry point, I'll say, into other more autonomous activities. If you can have a well-defined mission, if you can have clear goals in a limited space of what you're operating in and you can continue to build upon all the center integration activities, all the data fusion, et cetera, sorts of activities.
We also work a lot with dual-use technologies up in Michigan. So we work with the automotive folks quite a bit. We've got joint activities in the robotics space four General Motors in particular. We also work with some of the off-road, of course, we work with defense contractors. But in the other dual-use space, we work a lot with the John Deeres and the Caterpillars and the Case New Holland of the world who are working on some of the off-road autonomy areas. So we run the gamut from little tiny robots up to large robotic tank kinds of things. There's less programs of record, of course, the larger up you get. We can talk about that in the panel. A lot of that has to do with safety releases and things like that as you add autonomy to systems.
Ali Tabibian:
Great. Some key technologies or key challenges-
Paul Decker:
Yeah, key challenges-
Ali Tabibian:
... just list them please, and we'll come back to them.
Paul Decker:
I'm not going to go through all the key challenges, but some of the big focus areas we have ... The automotive folks are working a lot on road vehicles where you've gotten nice well-defined ... you've got nice roads, they're well-marked. Notice that the automotive folks tend to have demos and nice sunny places that don't have snow and things like that covering the lines. They're focused largely on the on-road area. Again, you've got nice Google maps, you've got nice situational awareness. We're focusing more and more on the off-road area. Those challenges were laid out well by the previous speaker. So, that's a big one. Another thing we're going to be more and more focused on, I think is the collaborative behaviors between small UAS, vehicle launched UAS and autonomous vehicles.
Ali Tabibian:
I imagine where you are working on pure autonomy your AI rather than intro device collaboration. A key pursuit of your division is data, more data to train the systems. That really tends to be the Holy Grail and probably some of the most expensive and some of the most challenging areas for training any system to be autonomous. That's why I think what Professor Topcu is doing is really quite interesting and can potentially remove some of the constraints or help solve some of the constraints that relate to the availability of data. Hopefully I described some of the work correctly, please take us away with what you're up to and what you're doing.
Ufuk Topcu:
All right. I wish I knew where to take it. Yes, there's quite a bit of hype-
Ali Tabibian:
Is that microphone off, is it working?
Ufuk Topcu:
It is working, I can hear you, yeah. There's quite a bit of hype behind artificial intelligence, which is essentially using data for figuring out what an autonomous system or any other system that needs to use the artificial intelligence, but let's talk about the autonomous systems. In a good number of things I have written, there is no defense system that can actually supply the data for us to train an artificial intelligence piece of equipment. So we have been working on an area of artificial intelligence that is called reinforcement learning. So the system tries and fails and then tries to learn from that.
If you look at even toy problems that requires billions of steps, billions of trials and errors to figure out something. There is no defense system, there is no physical system that's going to give you that many chances to try and fail and learn from that. It doesn't even have to be a defense system. There's no physically embodied system as opposed to what Google or Facebook deals with, or just merely a vision system deals with. There is no physically embodied system that is going to be working in a dynamic environment against an adversary. There's not going to be an adversary that's going to say, you know what, let's play. And then you fail. Let's play again, let's play again. The adversity is going to probably kill you.
The way there to go is that the current artificial intelligence training methods merely rely on data and that's not going to work out. There is no reason to learn from scratch. If we have any domain knowledge, physical knowledge, knowledge that we have, we ought to be able to use knowledge and data hand to hands. Those techniques do not exist at this point. It might look stupid, but it is what it is out there. Algorithms that can leverage data and knowledge altogether, doesn't exist.
Ali Tabibian:
Great, thank you. I'm going to go to Paul and then Jerry in that order. I'm going to play a little bit of a devil's advocate here. If you look in the world of automotive autonomy, the bloom is off the rose a little bit, if that's the right expression, in the sense that what seemed to be just around the corner, no pun intended, keeps getting pushed out into the future in terms of the capabilities of these systems to actually drive themselves, just as an example. As you mentioned, Paul, those are in environments where the rules are defined, there's a map, there's all sorts of constraints, if you will, helpful constraints. How are you defining the problem in the army in a way that both you and folks like Jerry at BAE Systems can actually deliver a solution in the immediate term? If that's really not the objective, what is the horizon at which you're looking to develop solutions for?
Paul Decker:
Okay. Regarding automotive hype, I'm not going to mention specific companies, it seems like in a lot of us in our community have talked about this, it seems like there were some folks who got out in front with the press and said, "Hey, we're going to have autonomous vehicles fleets in a year, kind of thing." That's what took a lot of industry hype. And then you had other folks jumping in saying, "Hey, us too, we're going to have level five autonomous vehicles in 2021 or 2020." We're scratching our head like, why are they saying this? It's not true? We're like oh, it must be stock prices. They're trying to get their hype out there. Not to say that there's not good advances going in automotive, but I think the hype definitely jumped ahead. A lot of that hype had to do with predictions of things being here sooner than they thought it was.
A lot of that had to do with these things I talked about earlier, where if you've got in the real world, you've got all kinds of environmental conditions. Do you have vehicles that can handle all those environmental conditions or are you on a nice sunny place where there's no rain, snow fog, dirt, et cetera? So I think that was your first question. Was there second question?
Ali Tabibian:
How are you constraining down the problem that you're facing, which seems to be a lot broader than what automotive company is facing, so that you have some progress that you can report in a reasonable timeframe?
Paul Decker:
Yeah. We're taking, I'd say, a more of an incremental approach having to do with the leader follower technology, the estimate where it's following way point it's remote control. It's operating at slow speeds around soldiers making sure that that's safe. For those of you not familiar with the estimate, it's roughly the size of a Volkswagen beetle size with a flat top that is meant for squads to throw all their backpacks on so the robot can take that 80 to 100 pounds off each soldier and they can go along with them. So we're taking incremental steps and more, I'd say, specific narrowly defined use cases trying to build towards getting into robotic combat vehicles and stuff, but it's an incremental approach.
Ali Tabibian:
Great, thank you. Jerry, if you don't mind, pick up that thread, please. From your position as a prime contractor, where is the opportunity for yourself and certainly for the vendors and maybe the academic community that works with you to make a difference in autonomy on both the defense and commercial environments?
Jerry Wohletz:
Yeah, so-
Ali Tabibian:
Where's the money in the near term?
Jerry Wohletz:
Yeah. To give a little bit of a history here. BAE Systems has been doing autonomy for DOD for 20 years. The first contract awarded for multi vehicle cooperative control was in 2001. The first publication for doing this was in 2001, fully decentralized onboard, no leader follower over a really poor networks. What problem space was that? That was for the unmanned combat air vehicle program. BAE Systems has been a provider to that for those types of applications. One of the areas is that you do have to figure out. So this doesn't do takeoff and recovery, it doesn't shoot off of a CV and recover off of the CV. But up and away, and you're in a bad land country and they're shooting at you and you're shooting back, that technology is pretty darn mature today. TRL Level 8 for dozens of assets.
It does not use artificial intelligence, it uses control and estimation theory. So it uses physics-based models because there is no verification validation that you can do with artificial intelligence and you don't need data sets, but you do need engineering models of how your sensors work, how your vehicle flies. Those are very well characterized because is using a flight control paradigm. As we fast forward now and providing this for air power, which one would say, eight miles a minute and every degree matters of every deflection. That's a challenging environment, but it's not as challenging as the ground environment. Ground environment, the terrain, the unpredictability up and away 30, above 35,000 feet, you get pretty consistent environment. You do not have that on the ground, everywhere in the world is different. The lighting conditions, to name, the obstacles, the debris, you name it.
The other thing is that when we started this, we could close our loop. We call this the observe, orient, decide and act, the OODA loop. We could solve it much faster than any of our adversaries, but you can't take that for granted today. So the notions of game theory have to come into these problems. We have no solution for a game theoretic solution. We can handle three dozen assets, highly complex, sophisticated assets today, we can't handle hundreds or thousands. So if you take a look at anything that pushes the edge with game theory, and it doesn't matter. All the game theory problems today are toy problems that can be solved, or you've got what we did for chess and go in those types of problems. But there was a lot of training data, as we said, the adversary is not going to provide us the training data.
If you train on the last war, we know what the outcome is. So this notion of we need real time game theoretic solutions based upon the actual situation, there's a big need. Anything that allows the algorithms to further scale, that's another big need. It's all going to have to be cyber resilient. So these are all very data intensive, they're model intensive. They're going to have to be resilient to someone trying to get inside your algorithms because at the end of the day, if it's combat vehicle, that combat vehicle has sensors, it also has ammo. We've got to make sure that that's not used against the blue forces as well. So anything in that area.
Dual-use wise, if you take a look at this game theory ... I haven't spent a lot of non-military thoughts about game theory. It's a fascinating field. A lot of people have ruined their careers trying to solve close forums solutions for that. There's great textbooks on the theory. I'm sure if people in the stock market would love to come up with a real time trading algorithm for game theory and how people are going to do it, but we're looking for any of those types of technologies, scale the problem, make it more cyber resilient. I think there's a lot to do with formal methods to reduce the amount of flight testing we have to do for verification and validation because we're using a very traditional aerospace and defense. Predict a hypothesis, put it in the air, [inaudible 00:46:53] the flight results meet model, if so, have confidence in your models and keep expanding. It's too expensive for the complexity that we need to go. So any of those areas.
Ali Tabibian:
Please go ahead, Paul.
Paul Decker:
Okay. The unmanned air side has been, I think leading the unmanned ground side, I'll say, in terms of its fielding, in terms of its widespread up adoption. With that said, especially the small UAS, the vehicle period UAS technologies, I think is a really promising space because that technology is also booming. I think that offers some unique ways to work in coordination with ground systems, whether it be for intelligence surveillance, recoin, situational awareness, even protection of systems, potentially as long as ... We protect them to make sure they're not easily shut down. But I think that it opens up a lot of opportunities for how vehicle paired UAS could enable future developments and ground systems.
Ali Tabibian:
Great. Thank you, Paul. Dr. Topcu, I noticed that Jerry was frequently looking at you when he was talking about a number of things that he was talking about, especially when ... it sounded to me when a system is going to autonomously make decision around lethality, it needs to be operating off of something that's provably correct as opposed to a model that's run on a historical set of data sets. Would you mind expanding on that for us? I think your work relates to that. It seems to be quite interesting.
Ufuk Topcu:
Let me try. First of all, everything Jerry said was just music to my ears from the rights. Thanks a lot. My group works on everything maths, for example, introduced. We probably are competitors in all those programs maths because we're on the same team perhaps, but we happen to be competitors. The niche that we have is how we can [inaudible 00:48:58] affordable develop verifiable autonomous systems. Verifiability to probably is well understood that how we will certify these things, how we will trust them. But the affordable part is that the current technology or just the approach for having verifiable or trustworthy systems is testing, testing, testing, testing, testing.
An autonomous system in a dynamic environment, there's just not enough amount of tests that you can run. I don't know what the right technical term for it is, but it is not practical. Therefore, we have to now insert modeling into this process for, it could be for simulation purposes, but the approaches we take are how we can model something and then go in and run an automated algorithm to figure out vulnerabilities of a system. If you cannot find any vulnerabilities, if you can argue that the system, it is not going to pose any safety critical behavior in the field, that is the type of approaches that we try to develop, and it is not going to happen.
If somebody develops an autonomous system and hands it to you and asks you, "Go and please verify this thing that's not going to pose any issues for you." That's just impossible because human imagination and human creativity is so much beyond what we can algorithmically or in an automated manner achieve. This verifiability issue has to come early on in design flow. From the first step on, I'm doing these things. At every step, I almost need to curb my enthusiasm and creativity so that I create something that I can later on verify and trust on. That's one thing. One example that I like using is that I got involved a little bit with the DARPA Urban Challenge in the Caltech team. Roughly 60 undergrads developed that [inaudible 00:50:50] over a period of nine months or so.
It ran for a few 100 miles. But at the end of this nine months, nobody had any smallest idea of how this vehicle was going to behave. It was just running. That can not be the way that we develop autonomous systems. We curve ourselves and we discipline ourselves from the first point on, so that at every step, we know exactly what each of these components fit to. That's what am going to say.
Ali Tabibian:
That was very good. Thank you. As anybody in the software business now is saying pretty much what you pointed to the cost of software is more in the testing frequently than actually the coding of the software. With artificial intelligence systems, you actually have to add a training cost to all of that as well, just looking at it from the financial perspective. So when I ran into Paul a little earlier, we started having a conversation about simulation. A little bit of a lateral move here, but Paul, you made me think that you had a lot of good stuff you wanted to talk about on the subject of simulation. Did I read you correctly?
Paul Decker:
So-
Ali Tabibian:
The challenge that we talked about, by the way, is that if the challenges are corner cases, then there's a little bit of a chicken and egg problem, is to what extent is your simulation going to be helpful in capturing a corner case if fundamentally a corner case is something you haven't thought of?
Paul Decker:
Right. There's the idea of if you could run a million simulations, you run all kinds of edge cases. By edge cases is some unique world situation, example could be, you're driving in a vehicle and there's an earthquake and you're on an overpass. The road in front of you gives out, it's no longer there. How does the autonomous vehicle handle that? So if you're a human driver and you encounter that, hopefully you stop. What does the autonomous vehicle do? Does it freeze up? Does it know to stop? Those are examples.
We're wrestling with how much simulation ... where do we use simulation versus real world miles? We're not a Google where we can run millions of miles and you got vehicles all over the U.S. just running constantly. We try to make as much use as we can of, we use a lot of national guard bases where we can have access to air spaces for this vehicle period UAS thing I mentioned, but also, so that we can run miles in a controlled area that's not around others, that's not going to interfere with others. So the pendulum, I think, has swung more towards ... how do I say it? Away from simulation a bit in terms of what we're doing, but I think because of the cost and hopefully the technology continues to get better as you got better computational power, better software algorithms that are used on these computers that we can simulate things better with more use cases.
But I think if you're going to really take advantage of AI, you've got to figure out that training data. I think simulation has to play a key role in that training data. The simulation, I think has got to be pretty darn good though because a lot depends on it, especially when you deal with large combat vehicles.
Ali Tabibian:
Great. Thank you. Excuse me, Jerry, you work in an organization where the bottom line matters. So maybe you can touch on what some of the things you're doing, which are designed to, borrowing from what Paul and Dr. Topcu said, to constrain the cost, constrained the effort associated with delivering a viable system.
Paul Decker:
Yeah. I'm going to pick up on the modeling thread here. The famous mathematician control scientist, Bellman, I believe it was in the late '50s, coined the term of curse of dimensionality. These are for, I apologize for geeking out here, non-polynomial hard problems. For what you can confirm, there is no solution, even if you had a solution, you cannot confirm that it's optimal. Basically what it says is that these problems, the more dimensions you try to include, it grows exponentially. So every element of state that you add to this problem across exponentially. What a lot of people forget is that Bellman at the same time, also coined the curse of modeling.
You can't model yourself out of this problem because you will run out of resources. There is no computers that can run it, there's no humans that can program it. You will spend all your time modeling and actually doing nothing. So the analogy we have is that you got to be very diligent on what elements you model and what you're going to simulate. Truth be told, the aircraft that all this fly in has never been tested for all the turbulence conditions that it experiences in flight. Never has, never will because it's an infinite number of turbulence conditions that exist in the world.
It would be impossible to model all the turbulence. It'd be impossible to test all the turbulence. I think the biggest missing link that I would suggest we have today is we still have a void in the fundamental theory behind autonomy. What stability means, what robust stability means. These are something that the aerospace sciences have evolved to. If you go to a nuclear reactor, we've understand that. Automobiles, the engines, they understand this. We are still have a void in the theory today to do such things. Therefore, in the absence of that, and only time will solve this, is that you have no choice, but you got to apply a lot of subject matter experts. You're going to have to pick keenly what are the important first order drivers to this notion of, is this system just going to a small perturbation tip over that inverted pendulum problem that could cause harm to any infinite number of dimensions? Or small perturbation, you're going to get a dramatic outcome that affects the overall performance.
May not hurt someone, but could dramatically alter the mission effectiveness that you're going after. So like it or not right now, it's subject matter expert driven and trial and error. That's the only thing that we have today, there's not a lot of tools that can guide us in this area.
Ali Tabibian:
Great. Thank you. Paul, you wanted to add to-
Ufuk Topcu:
I have quick things to say, sorry. Okay. This whole area of accurate physics-based models of sensors is an interesting one on the ground vehicle side. So as you're dealing with LIDAR, LIDAR Camera, LIDAR, et cetera, as you need for autonomous vehicles, do we really have good physics-based models of all those? I don't think we do. I think that's also an area of some opportunity.
Another thing I wanted to mention for simulation is we've done some interesting things with these things called virtual soldier experiments. Where you brought soldiers in, typically right from theater and we're looking at new TTPs and how some of these systems can be used, should be used. Some of the decisions they make, some of the things they want to see. It's often counter intuitive to what the engineers and stuff that are developing these systems will choose or will do, or how they'd use these systems. So, being able to have a virtual representations of these, and it's some war gaming models, that the soldiers can play, can ...
We even do some things with gaming where we give them a certain amount of money, virtual money. They have to pick some of the characteristics they want on these platforms. They've got a limited amount of money and they have to make some decisions. Some of those decisions are often counterintuitive to what program managers or engineers on these programs would choose. So, this whole area of virtual soldier experimentation is an interesting area for simulation also.
Ali Tabibian:
Great. Thank you. I'm going to change the subject a little bit actually for the benefit of our systems level people here. One of the things that everybody talks about in the world of autonomy, especially autonomy as, I would say, a subfield of AI is the decisions around the edge and the core. Where does your intelligence sit? How much intelligence do you put close to the sensors and how much intelligence do you leave for whatever happens at the core in your data center?
What seems to be really fascinating, just looking at some of the displays there, preparing for this panel is that in the military context, your core is often mobile as well. In other words, that if you're operating halfway around the world, the concept of what's at the edge and what's at the core and the criticality of latency and all that means that you probably have actually a more complex architecture than a commercial system can frequently live with. Why don't I have either Paul or Jerry, you take that and then I'll call back. Actually Dr. Topcu, would you like to comment on that in the beginning or no?
Ufuk Topcu:
[crosstalk 00:59:46].
Ali Tabibian:
Okay. I have another one for you at the end, and then we'll go to questions. Great, thank you.
Jerry Wohletz:
Yeah. For our applications, we have to have the technology that supports whatever CONOPs or TPP our customer wants to implement. Customers would prefer to go back to core if they have the pipes to do it, if it's feasible. But the reality is that it's most often not. Our philosophy as a company is we always want to start off with the hardest problem. The hardest problem is to put it at the edge where you have limited processing, you have no comms to limited comms to very poor comms that could be intermittent. If you can solve that where you don't have the processing power, where you have limited communications, you've got partial information, if you can solve that problem, you can solve the core one a lot easier.
Taking a central, we call them centralized controllers that have near perfect information, that's non-latent and taking that to the edge, very, very different problem than the reverse. But we have customers and we have customers that want it all at the edge. We got customers that want to be able to, during the mission, to switch. To some customers that they are, because of what's at stake, they want it purely core because of the repercussions of something going wrong. So to our perspective, we do all. But we start off with the hardest problem of the most constrained processing with the worst information, with the worst communications and we have to solve that fully decentralized problem recognizing that we may be in communications that period of times, and without communications for a very, very long time, but we still have to cooperate and achieve a mission effect.
Ali Tabibian:
Great, thank you. Paul, any comments on that on the issue of architects?
Paul Decker:
I'll just say from the automotive perspective, there's two things going on. There's tremendous advancements going competing at the edge with GPS and developments in Nvidia and others have come up with ... that's really driving a lot of great advancements in the automotive autonomy area. Some more of the, let's say that the Japanese manufacturers are looking at more cloud computing and connecting to the cloud and having interrogation from, I think they call it interrogation from the cloud, where if you run into an issue, you reach to the cloud and say, what do I do? There's command centers or customers, whatever they're called that guide the vehicle of how to handle that situation.
There's programs that we're involved with DARPA, code is one, Sesue is another one that are looking at what happens if, these are the exact same challenge here, if your communications go down, if you're in a GPS denied area, if you don't have access to the network like you need to connect the vehicle like the UAS or unmanned ground vehicle makes some decisions on its own based upon that. They're running real time simulations of somewhat ifs. Some of those applications, it's pretty exciting. So I think we're hoping and we're trying to do more computing at the tactical edge as best we can because we may or may not always have access to the cloud like we want.
Ali Tabibian:
Great, thank you. Dr. Topcu, all this stuff could be counterproductive if it's not secure. If there isn't some mechanism to validate that these autonomous systems are going to perform in a wide variety of use cases. Talk to us about those two issues, please.
Ufuk Topcu:
The two, issue security and-
Ali Tabibian:
Security and-
Ufuk Topcu:
... and the use cases.
Ali Tabibian:
... and the use cases, which to my mind is almost ... there's an overlap in those two issues. One use cases where it's under cyber attack, that the system needs to be secure in that use case.
Ufuk Topcu:
Yeah. I honestly don't know much about the security, but I can share my two sense on that. Yes, it is a real challenge. Somebody coming and tapping on your network or communication and starting to feed false information or just ear dropping, all those things could have a significant consequences. But I think even the doubt that merely somebody sitting at some corner and watching how your vehicle is operating, might carry quite a bit of information without using any high technology and might be able to infer a mission or safety information that you want to protect. I think about these problems, security related problems on the physical side without dealing with communication.
I agree, those are extremely challenging problems. Some of them might be solvable at the middle of the communication or competing level. Some of them might have to look into the physical embodiment of what you are doing and how you're operating. The acknowledgement of that they are hard problems, the only insight that they can offer. If anybody tells you that they can offer more, they're probably not being honest with you. That acknowledgement, the second case was the use cases.
With that, you're increasing already the tremendous large design space or the possibilities that you would have to figure out that, or ensure that your system is going to operate safely or properly. You're adding to it and it is a larger space. We talked about curse of dimensionality, there just that dimension has just grown. It has not only grown with that in a naive manner, but also in these new dimensions. There's possibly a very smart, clever malicious actor that is trying to intentionally fool you rather than just the disturbance that you might get from outside that may affect your operation, but may not be acting or playing against you as in the game theoretic manner as Jerry mentioned. Unfortunately yes, it is a challenge. Unfortunately, yes, it tremendously grows the amount of use cases that we have to deal with. That's all I can say. These are open problems.
Ali Tabibian:
Sounds like plenty of money to be made. That's all good news.
Ufuk Topcu:
Plenty of money, yes. I noticed that you did not ask me the question where the money is, that was a wise choice there-
Jerry Wohletz:
You just told us, thank you. Great. Should we turn it over for questions from the audience? Please, sir, go ahead. I'll repeat the question.
Audience:
It would appear to be when you look at the simulation and modeling and then you look at safety reinforced learning. Just to say the art today is having subject experts kind of trial and error that. It would appear to me that there isn't a very good bridge between those two rounds. What I'm saying, it's difficult to take what you have and in module to simulate in a real world platform learn from that, take that learning code back over into your simulation model. Is that a fair assumption that that bridge will be necessary or will be nice to have is a difficult thing right now?
Ali Tabibian:
The question is essentially the feedback loop between simulation and field learning.
Paul Decker:
If you're talking AI machine learning, that field is really in its infancy, as it relates to, let's say military systems, especially and I think, automotive too. There's a lot of things to be worked out, including that bridge that you had mentioned. I mean, that's definitely a gap and something to work through and get in the field in its infancy. If we have this conversation in a year, I'm confident that it'll get better, but I'd still look big gap.
Matt Henry:
You have to list of priorities. Would that be higher on that list or would it be down, how would it [inaudible 01:08:33] on the list?
Paul Decker:
I'll say it's fairly high. It's fairly high because people see that there's a lot of opportunities. There's a lot of attention focused on artificial intelligence as well as how modeling and simulation can help. So I'd say it's pretty high on that list. I don't know that it's number one on the list, but it's pretty high.
Jerry Wohletz:
I'm going to rewind the clock here, go back to about the year 2000 [inaudible 01:09:02] program. They started off with the expert system in that program. In the '80s, there was a pilot associate program. In the '90s, there was a rotor pilot associate program, both were expert systems. So they started off, they had four aircraft, 12 threats in a geographic area the size of Austin, Texas. They asked the experts, enumerate all the potential tactics that those four aircraft would potentially employ against a dozen threats.
The truth of the matter is they came back and they said, "That's impossible because of all the different random environmental conditions and what the adversary can do, it's an Unbound countable problem." So this becomes the challenge is that if you try to do the reinforced learning and the training, you're already starting off with an unbound potential outcome set. This is where this becomes extremely difficult to use and apply those type of approaches. You let alone to bring it back to modeling and simulation to replicate that because in some instances, they want to use the simulation to generate training data and vice versa. You'll end up in this dual loop where you'll never end. You will continuously try to ... Someone will come up with a new tactic because they saw something. And then you got to go implement that. And then you got to go train that. The whole premise of that its unbounded.
The analogy I would have is for the commercial industry, by the way, there is a subset of the commercial industry that is using AI based approaches for autonomous cars. But there is a portion of the industry that's using control theory. What you hear on the news is the AI based. The control theorist are relatively quiet about their approaches. But there's a company called I believe the name is Mighty AI. Their job is that they put out a request for people, and I'll use the example that they showed me, they want pictures of parking cones. They want parking pictures of parking cones from all over the world. So a parking cone in Bangalore, India looks different than a parking cone in Austin, Texas because of the sky. And then a parking cone next to a potted plant looks different than that of a parking cone against a barrier and on it goes. There's an infinite number of images of parking cones to try to train your AI algorithm. Don't hit parking cone and it never ends.
Matt Henry:
Yeah. You had mentioned that you need to pick wisely what you module, what you put in your model. So, it's not an attempt to go down this infinite loop and you [inaudible 01:11:50] you got to stop at some point. But how do you intelligently know when to put it in a module?
Jerry Wohletz:
Yeah. I would suggest the following is that if I just wanted an autonomous car to go up and down I35, I would go to the state of Texas and ask them, please use a standard parking cone. Only use this parking cone. If you guarantee me that you will only use that parking cone on I35, I'm confident I could probably chair in my algorithm not to hit that parking cone. It goes both ways, but that's what we call a cooperative problem. The challenge you have is that in the art of war, the other side is not cooperating.
Ali Tabibian:
Great, thank you. Any other questions? Yes, sir. Over here.
Matt Henry:
[inaudible 01:12:42] is making a full simulation over the environment [inaudible 01:12:45]. What about in parts of leaving the knowledge [inaudible 01:12:50] in a higher system [inaudible 01:12:51]. It might be able to take the chunk out. We were doing this on the [inaudible 01:13:18]
Ufuk Topcu:
May I jump in?
Ali Tabibian:
Please do. If you could just paraphrase the question for the online audience.
Ufuk Topcu:
Oh really?
Ali Tabibian:
That's why am having you do it, it went over my head.
Ufuk Topcu:
Would you like to do the honors of-
Ali Tabibian:
No, just said it went over my head.
Ufuk Topcu:
All right. I believe the question is, could we extract and represent knowledge at a higher level of abstraction and take advantage of that in all of these things that we are discussing? Yeah, I'm not a CCML guy. You mentioned the CCML. I actually get nervous when I see those things. I actually agree with you on that. If you look at reinforcement learning used in whatever successful applications they have and try to apply it in autonomous driving setting, what it boils down to is actually you are learning everything from scratch. Every time you do something you are even learning the driving rules from scratch. Leave alone the CCML and modeling or complicated modeling, it will be great to capture the knowledge in driving rules and just embed that into whatever you want to do.
With that, you would probably be able to even get quite a bit of coverage prune out of design space quite a bit to the amount of learning that you have to do would be much smaller. We have air force project on that. It's just essentially, we want to be able to learn because an aircraft and unmanned vehicle going through a catastrophic event, everything changes, just the model changes. Nobody had even flown that thing ever and nobody's going to ever fly that thing in that configuration again, but some learning has to take place.
The only thing that you have is just this one flight extremely outside that paradigm of current reinforcement learning algorithms. In that case, we believe that the underlying physics based knowledge that task bates is the mission knowledge that you have should be able to use to prune the amount of learning that you have to do. I completely believe that our knowledge in what ever favorite form that you have to represent knowledge has to be taking advantage in all these systems, yeah.
Jerry Wohletz:
We're trying to capture some of these experts decisions and some of the approaches we're taking with [inaudible 01:16:12], the militarized version of Ross. This thing, we have an autonomy stack that we've been developing that captures a lot of the knowledge from program to program. We also have this thing called the RTK, Robotic Technology Kernel that is supposed to be a sort of a collaborative space per lessons learned, so you're not having to recreate from scratch every time. So we're trying to take a multi-pronged approach to try to do that. I don't know, hopefully we're successful. I think things are going well, but it's a good point.
Ali Tabibian:
Do we have time for another question? Anybody have a question? Back there sir.
Matt Henry:
My question [inaudible 01:17:35]. I was wondering in regards to autonomy, [inaudible 01:17:36]?
Ali Tabibian:
The question is, is there a local flavor to the various teams that are geographically dispersed around the country as far as autonomy is concerned? Go ahead professor.
Ufuk Topcu:
This is a great way to open the discussion to the audience. Honestly, I just don't know. I did not even know that there was a difference between Kendall Square and Palo Alto. Who are the players of autonomy here in Austin? Aren't you guys the players? I am a poor faculty member, it's [inaudible 01:18:23].
Ali Tabibian:
I'll provide one insight into that from the Silicon Valley perspective, I think a limitation of the approach from Silicon Valley is people there tend to view everything as a software problem. And that the software can resolve all issues associated with any shortcomings from the sensor on up. In fact, I sold a couple of robotics companies to Google in a few years ago when they bought a batch of five on the same day, et cetera. What they try to do is essentially make the processing in the core compensate for all the usual techniques like sensor fusion, et cetera, that everybody else was pursuing. They did that with their own original autonomous vehicle. Remember the Prius's that only had a LIDAR on top? That approach has turned out to be essentially ineffective. So that's one approach. I think the software will solve everything that approaches. I know it's offensive running the Silicon Valley DNA. I don't know if it's different to maybe in Michigan, the DNA is a little different.
Paul Decker:
I think I see a lot of automotive world, maybe it's also geographic. But I definitely see group thing going on in industries, whether you talk about say the folks that make buses, the people who make passenger vehicles, the folks who do agriculture, mining. From my perspective, you see some market leaders and then some group thing that goes along with that. I think different areas tend to have different risk aversion too. I don't want to stereotype necessarily, but in Michigan, the automotive folks tend to be a little bit more risk averse unless they're pushed. If you've got folks from Silicon Valley pushing them, then they start trying to ... if they see potential for market share loss and things like that. I think some of that could drive some behaviors. But I think you definitely see group think by industry related to autonomous stuff.
Jerry Wohletz:
The one thing I'd offer is that if you take a look at the different companies that have cropped up to do the autonomous cars today for the commercial applications, it's amazing to see how many of them trace their roots back to the DARPA Grand Challenge and those events. So if you trace what Cornell's was at the time and the graduates from Cornell behold, their technology is very similar to what they studied at Cornell. The same thing goes to the MIT team, the same thing goes to the Stanford team. So, the autonomy is from MIT. Therefore, there was a very hierarchical more control theory based approach versus the Stanford approach.
To me, that's where I always will do is I'll follow go back to the Grand Challenge and I had even references here as well. To me, that's what drives the flavor. It actually went back to DARPA and those grand challenges they did and what research institute they came from and what was the flavor of focus at those institutes.
Ali Tabibian:
Great. Thank you. Two of our panelists have come a long way to be with you. We have a local representative. Let's give them all a good hand because they really gave us some very good concepts.
Beau Duarte:
I'd just like to thank Ali as well for coming out from California. We've got a ton of wings and Mac and cheese and salad over there, don't make us take it home. Please, we've got the space till 8:00. The panel should be able to hang around for a little bit for individual questions, so you can come talk to us. Thank you for coming. Enjoy the rest of your evening.