Ground Robots Are Arriving on the Front Lines

Welcome to the Cogs of War podcast. I'm Jonathan Panter, Executive Editor of the Cogs of War Vertical, brought to you by War on the Rocks and Booz Allen Hamilton. Our episode today is about ground autonomy and air-ground teaming. I am joined in the studio by Ryan Hartman, Chief Executive Officer of Ondas Sentinel, and Scott Phillips, Chief Innovation Officer of Forterra. Ondas Sentinel is a defense division of Ondas, a publicly traded company that provides autonomous solutions across security, safety, industrial, and other markets. Forterra, founded in 2002, is a leading provider of autonomy hardware and software for ground vehicles. Ryan and Scott, thank you for joining the show. Thanks for having us. Great to be here. I'd like to start by just asking each of you what your company does and what brought you there. Well, Ondas is a very interesting company. We were founded in 2014, but our focus in 2014 was secure networks for critical infrastructure. So providing communications capabilities for things like mass transit systems and things like that. We quickly learned that drones were an important element of critical infrastructure communications and security. And that started us on a pathway to become the company we are today, which has everything from ground robotics to stratospheric balloons. I think we're the only company in the world that can say that we work in ground robotics all the way into stratospheric solutions. All of it enabled through autonomy. And what in your career brought you to Ondas specifically? Ondas is, if anyone who follows Ondas will see that we are a prolific acquirer of businesses. So prior to running Ondas Sentinel, I was CEO of Worldview that did stratospheric balloons. And so I am a product of my company being acquired by Ondas and forming Ondas Sentinel, where I'm happy to be the CEO of a pretty large company. And I'm very proud to be the CEO of a pretty large company. And I'm very proud to be the CEO of a pretty impressive portfolio of really interesting technologies. For Terra, dates back almost 20 years now, our leadership team competed in the first DARPA Grand Challenge. And so we've been focused on research and development around autonomous ground systems for decades now, developing some kind of initial ideas and early technology leadership. And about four or five years ago, we decided that the technology was moving from the research phase into now this is actually mature, this is ready to be fielded. And so we took outside capital for the first time in the company's history about four years ago, and decided to scale up and say, can this technology we've been incubating actually make an impact on the battlefield? And since then, it's been a rapid growth and explosion. We have about 100 autonomous vehicles deployed to Ukraine right now, running daily resupply missions to the front. We can talk about that. We also are on the road to the next step, which is to develop an autonomous vehicle. We also are on the only ground autonomy program of record for the US Marine Corps, the Rogue program, where we're fielding autonomous anti-ship ballistic missiles into Okinawa. Personally, I've been in the kind of artificial intelligence space for kind of 20 years as well, that the Navy funded my PhD in AI many years back before AI particularly worked well. Was an early employee at Palantir and kind of touched a lot of the defense technology space in AI. And what drew me to Forterra is people think a lot about chatbots and AI nowadays, but physical AI is really having a moment right now. And how do we transfer all this learning around AI into making intelligent technology on the battlefield that can take soldiers out of harm's way and put an artificial bot in there to enable less casualties on the battlefield? And so you mentioned this distinction between AI operating in software and then physical AI. And it's always been my understanding that with ground autonomy, some of the physical and engineering challenges have really been the primary bottleneck. You mentioned that it was about five years ago that Forterra decided you were ready to sort of leave the lab and bring those solutions into actual operational use. Were you there when that decision was made? I was not, but I know the team that was, and I've been watching them and working from afar. Nowadays, it's easier than ever to get to a demo of an autonomous vehicle. The models exist. You could, like a high school science project, could throw together some actuators on a car and throw AI onto a vehicle that can run an impressive demo and that can make some really cool videos that you can post online. The gap between that and being able to have a safety-certified vehicle that you can produce at scale and that you trust to be around people and they're not going to run over those people is where the gap really was and really is. And so we spent a lot of our time investing in, how do I make this vehicle manufacturable? How do I make sure that we can meet safety standards so that the army and the military trust this to be around their soldiers? Because the ultimate goal is to remove people from the battlefield and save lives. You want to make sure that you're fielding something that's safe and can run safety-critical operations. It's interesting because when I think a lot of people think about autonomous air operations, ground operations, surface operations at sea, they tend to see these as disparate and separate domains, which these are different domains. But I'm trying to think about parallels between what ONDAS does and what Forterra does, and immediately what comes to mind when you bring up this basic safety issue, ensuring that the vehicles themselves don't endanger civilian populations and that there's not interference with civilian applications. It seems like that's probably a huge issue that you have to deal with at ONDAS, given the proliferation of drones in the civilian market. Yeah, absolutely. I started my career in autonomous systems at Raytheon. When you think about just aircraft operating, there's a lot of stuff that you have to deal with. You have to deal with aircraft operating as an unmanned system, an uncrewed system. The first hurdle that we had to overcome is test, and testing them in the national airspace, testing them in areas where there were manned aircraft, there were people on the ground. Fast forward 20 years, and we still struggle with the same thing. For ONDAS, with the portfolio that we have, we have systems in theater, we have systems supporting Israeli efforts and clearing tunnels. One of the key elements for us is integrating those domains, not just from a capability point of view of being able to task a ground robot to go clear an area, but also to keep that system safe. There are still civilian populations that we have to navigate around. There are still infrastructure that we have to stay clear of. When you team a drone with a ground robot, you create a more wholesome picture of the mission that the ground robot is executing. It's obviously very effective from a mission objective point of view, but it's just as effective in keeping the robot safe, keeping people safe, and ensuring that it does what we need it to do. Both of your companies have capabilities that are actively employed right now in combat zones. You mentioned assisting the Israelis in Gaza. You mentioned, of course, Ukraine. Does ONDAS also have presence in Ukraine? We do not. When you're looking at the data that's come out of those ongoing conflicts, what have been some of the greatest lessons learned that have helped you iterate on your next evolutions or products? There are several things, and one of them is just the robustness of the solutions. Scott mentioned earlier going from a test environment to an operational environment. It's very different. I mean, it is the ultimate test when you're putting a system into harm's way. You're learning of additional vulnerabilities of the system. You're learning of things that worked well in the lab, things that worked well in a test environment that don't work so well in a combat environment. When we talk about putting systems into harm's way, our number one job is mission assurance, not just quality assurance. It's mission assurance. Mission assurance encapsulates so much more than just the quality of the product. It is, does it do what it is designed to do? From our point of view, especially on ground robotics, the terrain is so variable in where you're maneuvering systems. Ultimately, it requires a family of systems, from ground robotics that walk versus tracked robotics, the types of sensors that they have, and then the connection to other systems. A ground robot on its own, we can design it with integrated autonomy and AI, but it's so much more effective when you connect the domains. And that's one of the things that we've learned, not just with the work that we're doing in Israel, in Gaza with ground robotics, but I go back to my days when I led another company called Insitu, and learned that a single domain, operating as a single domain, is nowhere near as effective when you start connecting these domains. I can talk about our experience in Ukraine. We have over a hundred vehicles deployed running daily missions on the front lines of Ukraine right now. And my biggest lesson learned is kind of the almost cliched saying that amateurs think strategy, professionals think logistics. Logistics is an incredibly difficult problem for the Ukrainians right now because of the air threat. And the front lines are a no-man's land due to the FPV threat. And so you don't want to be sending people. There are soldiers sitting in foxholes right on the front lines that have been there for days, and they need food, they need water, they need ammunition, they need to pull casualties back from the front. And so that logistics problem becomes a nightmare when you think about the air threat. And so being able to team aerial drones that are providing your overhead surveillance for potential threats and then be able to take the people that would be running these resupply missions out of that harm's way and be able to move that I think we've moved a million pounds of material forward and have pulled back 100 casualties. And that, I think, is really motivating at our company in that those are 100 lives that have actually been saved because you were able to get an autonomous robot in and out. Now it's a terribly difficult environment to work with. You're constantly facing a jammed environment, both with your comm systems and your navigation systems, GPS denial, and you've got the threat from overhead. And so the lessons learned are not, when we went in there, it was, oh, I ran a bunch of test cases on ranges here in the United States on what GPS jamming looks like. But they're constantly, like, the Russians are constantly changing their techniques. And so my kind of big lesson learned is, is you can't wait for perfection. You get in there and you go, oh, I have this problem. It's distinct. There, a really, you know, small but interesting problem that we found was the Russians were using GPS jamming and actually presenting a timed clock. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. It was 20 years into the future. So what? We detected it as false, but all our certs on our vehicles expired because they thought it was 20 years in the future and we couldn't log into our vehicles anymore. And it's just those, like, small little things that you just have to learn in contact that you can bring back and iterate. And that doesn't cause us a problem anymore, but it's because you just kind of learned, like, incrementally learning lessons that by fielding rather than, I think, kind of a more traditional approach of, like, learn all the lessons in the lab when it's perfect. Send it out. And that's kind of the big mindset shift that I'm seeing. Yeah, I'm taking a few things away from this. One is that the image that most people have when it comes to ground autonomy, which I believe is wrongfully focuses on kinetic missions, the idea of, like, you know, a missile launcher or some sort of a weapon system on the ground vehicles is not really true in terms of the actual use cases. Sounds like you're applying it mostly to logistics. And then the other question is that these aren't really remote controlled in as much as in these GPS denied environments, rather. They have to have some means. So, like, you know, you have to have some means of getting from the rear area to the forward area to deliver those supplies, food, possibly blood and things like that. How do your systems navigate autonomously? How are they doing that in the absence of an actual, you know, precision navigation and timing? There's not a single answer to that. The defense in depth is kind of how I think about GPS denial. It's not, oh, I'm going to have this magical sensor that tells me where I am. You have GPS when it's available. You run a number of constellation satellites. But you also do visualization. You also have a variety of other sensors that you're trying to use. And I like to say they can jam some of your sensors some of the time, but not all of your sensors all of the time. And so you have to have fallback methods for fallback methods for fallback methods. And then you also have to, I tend to think about deploying something is not solely about the technology. It's about the con op or the concept of operation. And so how do you employ the technology matters as much as what the technology is. And so we use a range of different attachments. Sometimes you're tele-oping where a remote soldier is remotely controlling the vehicle in the rear. Other times you're saying clear to go, go by yourself, make this decision. Sometimes you're in like a convoy mode where you have a manned vehicle where you're behind that vehicle and the autonomous vehicle is following the one manned vehicle. And the key is, is that you want as many tools in your toolbox as you possibly can, such that when you make contact, you go, OK, I'm falling back to this other mode or I'm switching it up and I'm going to do this other thing. And the goal is. And the goal is to be adaptable, not have the silver bullet. Maybe you said slightly a different way and how the way we think about it is, you know, being able to gracefully degrade with the environment. There is a perfect environment. You know, you start finding situations where GPS is denied. You know, other modes might be denied. You have to be able to gracefully degrade with the with the environment. And, you know, we do a lot of very similar things, you know, to include tethered or fiber optic control just to maintain the ability to remote control of a ground. And then also just do very short comms links between drones and ground robotics so that you can maintain contact and you can continue to control it. And again, this is like one of the primary reasons we start to connect domains that when you start to connect the domains, you can gracefully degrade with the environment and still provide a warfighting effect. This is a little bit how I think about the difference between the air and the ground domain is is the air is running your mission. It's running a set overhead sensing mission or it's running. Running an attack mission. There's a lot of different missions that you can run in the air, but air is constantly worried about size, weight and power. I can only stay aloft with so much weight, with so much power for so long. And the nice thing about ground is that's the logistics. That's where you bring in your heavy infrastructure, your larger sensors, your larger weapon systems, your larger counter UAF systems. They are going to naturally sit on the ground because they require more power. They require more weight. And so being able to team air to ground air is providing the overhead. Pitcher, they're providing the bird's eye view. Ground is providing kind of ground processing, ground compute. It's providing, you know, long range fires. It's providing a comms relay to be able to relay out of a potentially jammed environment. And so when you start to compose these things together, each domain has some strengths and weaknesses. And when you put them together, they can actually, like, cover each other in interesting ways. One of the things I worry about, though, the more you connect systems is the cybersecurity issue, the jamming issue. the over-reliance, the question of vulnerability of making one system or one domain too dependent on the other. How do you guys think about this? I think it's very much in alignment with what we were just talking about. You know, you cannot rely on the perfect environment and that everything is going to work. And so, you know, each domain has to be able to operate independently and continue to provide a, you know, some level of mission readiness or, you know, some level of capability. For ground robotics or, you know, the tier one drones or even some of the larger systems, you know, they have a primary mission that is a single domain capability. It's just more effective when they're able to stay connected. But this is where autonomy becomes really important and being able to have, you know, platform autonomy and the ability to operate in an environment where it's alone, it doesn't have, you know, connectivity to, you know, other systems, it doesn't have the comm relay. You still have to be able to deliver on some level of mission effectiveness. And so, you know, that's why everything we do, it has a basic set or basic autonomy capability so that it continue to execute a mission. You know, a great example of this is, you know, the ground robotics that we put into tunnels in Gaza. It can't be connected to another domain and it has a very important job to do. And so the autonomy that's integrated into those systems, you know, it can sense its environment, it understands what it's supposed to do, and it can do that job very well. And if you take it out of the tunnel, all those same capabilities enable it to go, you know, clear an area, do a resupply mission, you know, carry out casualties as a sole domain. So just to clarify, those robots that are operating in those tunnels, they're not tethered at all, or they're not using VHFs for line of sight? It's either/or, right? So, you know, in some environments, we have to do tethering. It's just, it's too noisy. You know, the nice thing, you know, in operating in tunnels today is there's not jamming, there's not a threat environment that there was before, you know, but tethering, it makes it, you know, far more reliable to be able to execute its mission. Just to pivot on that, a lot of emphasis nowadays is on the autonomy, and that's very interesting. We have an autonomy team, but we have a separate team that we call Distributed Warfare Team, which is, you know, you're going to end up, I like to call this the internet of battlefield things. You're going to have many autonomous systems, you're going to have many sensors, you're going to have air systems, you're going to have sensors, you're going to have shooters, you're going to have counter UAS systems, and they're all going to be operating in a denied environment from a communications perspective. And so, how do you think about these things coordinating and collaborating together? Because to achieve a mission, you can't just have one system do one thing. It's about the sensors, it's about the shooters, it's about the counter UAS, it's about the defense, it's about the offense. So, you know, I don't think that's going to be a piece of the puzzle, but it's going to be one that's going to be useful for a lot of us, and I think that's going to be a big part of what we're going to be doing in the future. And so, you know, I don't think that's going to be a piece of the puzzle, but it's going to be one that's going to be useful for a lot of us, and I think that's going to be a big part of what we're going to be doing in the future. on that part of the problem. Well, what I'm taking away is something that may therefore clash a little bit with the conventional view of what the next high-end fight will be. There's a lot of talk about we're going to be operating completely denied conditions. Autonomy will be everything. The aircraft, the ground vehicles, the unmanned service vessels are going to operate on their own. What both of you are telling me, it seems as if the resilience, the redundancy, the diversity of comms architecture suggests that the conditions under which we would require true autonomy, that is no communications whatsoever with the human handlers, are going to be vanishingly rare. Am I understanding that correctly? I think you are. And when we think about current conflict and future conflict, there is a system of systems architecture that has to exist. And that system of systems architecture has to be able to operate in an environment where you do have redundancy. You do have fallbacks on primary communication. You have to be able to operate on primary communication paths and find yourself operating in secondary communication paths. And as Scott pointed out, all of your systems can't be jammed at the same time, right? And you have to be resilient. You have to be adaptable to the environment. And I think systems that are being designed today take that into consideration. Even the unmanned aircraft we fly, whether it be a stratospheric balloon or a Group 5 UAV, we have five different comms paths on those systems. Because you have to be able to operate on those systems. You have to be able to operate on those systems. Because you know that at any given time, one or several of them are going to be unavailable to you. And you just have to be able to quickly detect and know when one is not available to you and transition to another path. I think about it as a single system maybe can achieve a tactical objective. But if you want to achieve an operational or strategic objective, you're talking about multiple systems working together, a sensor, a shooter, like eyes in the sky. And so if you want to achieve anything great. You're going to have to find a way to coordinate. I think the key insight is that we can't assume like we did in counterterrorism that we're sitting home in D.C. watching the full motion video feed of every drone flying over Afghanistan. That's just not the world we're going to be living in. These things are going to be offline, they're going to be coming up and down. Maybe I can get a comms link to the local tactical soldier in the field, but not back to Honolulu. And so you have to just. Resiliency is the name. It's the name of the game. And we're fighting these two competing things is, well, I can coordinate really well if I put all of my infrastructure in a central command post and I have a command post where I'm running the mission. If you centralize in a modern fight, you're a target on the battlefield. And so you can't centralize because precision strike is being proliferated. We don't have a monopoly on precision strike anymore. And so coordination gets really easy when you centralize in a command post, but we can't do that anymore. So now we've got to decentralize. You've got the other challenge of like, how do I maintain communications and networking and talking to one another so I can coordinate for a larger effect? And I just think about it as tools in the toolbox. We can't centralize anymore. Your precision strike does not allow that. So we're going to decentralize. How do I have as many tools in the toolbox so that when the network goes offline, I can follow commander's intent and I can keep going on my part of the mission. But if I get intermittent comms or like small status updates, I can re-vector based on some world understanding. That's not something that just got shared across the network. And so it's really about designing resilient architectures, not just assuming one robot in the middle of the woods, knowing nothing other than its initial mission. Well, I'm glad you bring up the GWAT era because it's very useful for us to at least to exploit the lessons learned from that very difficult 20 years. And I certainly agree that we no longer have the assured command and control that we might have enjoyed fighting against that adversary in the future fight. Another thing comes to mind though. When looking at the era, the difference between where we are with air autonomy, unmanned aerial systems and with ground autonomy. And that is the quality of the data that we have existing from the era and how much it's been able to inform our models. We have millions and millions and millions of hours of feed and actual real world operations of unmanned aerial vehicles from 2000, actually earlier than that, but 2000 through, let's say to the modern day. Whereas I think one of the major holdups must be, and please correct me if I'm wrong, but I'm curious to hear. What is the difference between the data that we have in the past and the data that we have in the future? And what is the difference between the data that we have in the future and the data that we have in the future? And what is the difference between the data that we have in the future? to put a Waymo out into Ukraine right now, it would fail miserably. Very mature technology, TRL level nine technology would fail out there because there's a new crater every day we pass this road and there is no pre-mapping. And so being able to like field, see that, understand, "Hey, I need to adapt to new craters every day. I need a model that can detect crater," is incredibly important. GWAT, we collected a lot of data. I'm sure it's useful, probably less on the ground domain because ground wasn't as mature back then. Yeah, I think Scott's got it exactly right. Operating in some of the environments that we operate in, there's reference data and we have models trained on the reference data, but you have to retrain the models constantly. There were roads that no longer exist, tunnels that maybe existed and now there's blockages in the tunnels. All models have to be retrained. And I think that's part of the beauty of ground robotics is you're collecting much higher fidelity data. And as long as you're capturing that data and training the models on that data that you're capturing, you get much higher fidelity models as a result. Why is it higher fidelity data with ground autonomy? Because it's in the environment in real time and it's sensing new things that you didn't have before. You cannot be relying on aerial assets doing mapping, as an example, on a daily basis. And in operational environments, ground robotics are just an additional source of data that I think is really important to maintaining a situational awareness of the area that you're operating within. This is the key distinction, I think, and I mentioned this earlier, in that aerial has limited size, weight, power, can only stay aloft for so long, and you can only pipe so much of that data home. And the nice thing about ground is very large hard drives to store lots of data. And you have sensors and you can put in much higher fidelity sensors. You can put in a lot more weight. And this is where I really think about ground as the infrastructure layer of the autonomous fight. It's got compute, it's got power, it's got comms, it's got all the heavy lift things, and it's got the on-station time. You can position that forward and keep it there for very long periods of time. And so the hard part is it's a more difficult autonomy problem. You have to move around much more difficult terrain and you have to be able to deal with obstacles and complex environments in a way that you don't in the air. But boy, we have an easier swap problem than he does. Well, it occurs to me, though, with all the fascinating engineering you're both invoking, continuously updating models and exquisite sensors and communication suites that are robust to different kinds of jamming and degradation, that over time, cost balloon, these systems are becoming more valuable, in some ways harder to build, or the payloads are getting larger. And yet the way we began this whole discussion is this question of intradability. That part of the reason we're fielding these systems is to save the lives of troops in contact, at least for, in the case, logistics mission, or with the recognition that given the contested airspace we're likely to see in future combats, maneuverable ground units are going to face a lot of fires from above. How do you guys understand that trade-off between you're trying to build the best product there is, that is the most resilient so that it doesn't get knocked out overnight through all the threats we've discussed, but you're trying to build the best product there is, that is the most resilient so that it doesn't get knocked out overnight through all the threats we've discussed, but you're trying to keep the costs at a reasonable level enough so that the vehicle can be considered a tradable? I think there's a couple different areas that are worthy of a discussion here. I'm a classical trained engineer and spent a lot of time in the 90s and early 2000s designing systems, and value engineering was something that was really important. And I feel like in the early 2010s, that started to go away. But now with a requirement, to put scaled mass in theater, attritability is incredibly important. And so we spent a lot of time inside ONDOS doing value engineering. I'd also say the whole idea of attritability, it's a spectrum. We live by the ethos of bots before boots in the environment where you're going to take a person out of harm's way. If you're going to do that, I don't think it's the cost or the price of the system that's important. It's how many lives are you saving by not putting them in harm's way. The same is true for aerial assets. I mean, if you look at the proliferation of unmanned aircraft in some of the more recent conflicts, and if you look at what the Department of War is doing in South Com, where we have an entire ISR infrastructure that is entirely unmanned, from surface vessels to Group 1, Group 2, Group 3 UAVs, now Group 5 UAVs, and it includes the stratosphere now. All of it based on the idea that these are attritable assets, and it's not the same threat environment as the epic Fury or Ukraine, but we're still putting systems in harm's way and we're learning a lot in South Com with what the Department of War is doing there and an entire architecture that's built out on unmanned systems and a lot of that was leveraged in Epic Fury. There's a lot of talk about the number of MQ-9s that were lost in Epic Fury, 40 plus systems lost. Obviously that's disappointing and that's at least more than 40 lives that were saved by putting those assets in harm's way and I don't think anybody is going to complain that we lost 40 MQ-9s compared to the saving of lives and those systems delivered a very important capability in that conflict. We tend to think attributable, not attributable and those are the two binary categories. At least our experience out in Ukraine is the Ukraine's divided the front into three zones. They have the very front, they have the kind of zero to one kilometers depth, then they have the very front, they have the kind of zero to one kilometers depth, then they have the one kilometers to say 10 or 20 and then they have like 20 to 40 kilometers back. And you want a different class of system at each of those layers. At the very front, they're taking these very small bots and they're just driving them into Russian foxholes and that's not even attributable, that's consumable. And then between one kilometers and 10 kilometers, it's a slightly larger class. You're bringing kind of the last mile logistics type things happening to bring kind of resupply into the front. And then, you know, 40 kilometers back up until 10 or 20 kilometers back, that's where your heavy lift, you're bringing on all the heavy payloads and so you have a larger, maybe more expensive class of vehicles. And there's advantages and disadvantages to all. And as you go down, you decrease the capability cheaper. And so you're taking on more risk, but you got to run a hundred resupply missions or you can go up and you can get it all done in one shot and that maybe saves you rolling the dice 50 times. And so there's not a singular answer to, should it be attributable? Should it be more expensive? It's more of a, you're going to have a different class of system depending upon the problem you're trying to exercise. Well, I appreciate that both of you have really added a lot of nuance here and dispensed with some of the false binaries in what is a very emerging area. So it's not all defense observers are entirely familiar with unmanned ground vehicles. I think just to conclude, I'd like to ask each of you, is there anything that everyone believes in this space right now? That you think that we'll look back on as wrong? I've been wrong a lot in 27 years in the industry. I think one of the things that we're going to look back and say we got wrong is actually the discussion we just had. That there is this binary approach to attributable versus non-attributable. It has to be a family of systems. We have to have a family of systems that include low cost, consumable, attributable systems. We cannot get away from attributable. We cannot get away from exquisite systems. The exquisite systems are the marquee of the US defense industrial complex. We build amazing war fighting systems and we need them. But we also need to have a mindset that lower cost consumable and or attributable systems have to be part of the solution. And I worry that right now we're going too far to the one side where we think that too many systems have to have this classification of attributable. We'll lose capability if we go too far down that path. Maybe my controversial take here is that I think we're maybe hunting down the wrong path when it comes to JADC2 in that I think we are still thinking about a war where we fight from a centralized command post. And all the data, we're trying to integrate all the systems so that all the data comes back to the commander and the commander can be directing the war like Ender's game. And I don't think the modern fight is going to look like that. It's going to look like disconnected systems. It's going to look like systems where you're pushing decision making down echelon. And what's going to happen is you want all interoperability. Don't get I'm a very strong proponent of interoperability. But you have to assume that at your centralized command post, you are not going to be directing the war. You're going to be sending out commander's intent. And you're going to have to trust not just autonomous systems, but down echelon soldiers to be able to carry that out, having intermittent connections to systems. And so we really aren't yet got our minds around that. And the fact that it is going to be a distributed fight and not a centralized fight, I tend to agree with you. And I appreciate ending on a controversial note, gentlemen, thank you for joining cogs of war. Thank you. Thank you for listening to cogs of war. Don't forget to sign up for our free newsletter that comes out every other week, warntherocks.com/cogs-of-war. Keep reading, keep thinking and stay healthy.