00:05:09 · Ty Morse, Olaf Hichwa
[00:05:09] S0: What like trade offs did you make on the design of Archer so that you could actually ship it in a fast, rapid pace and scale your production quickly? [00:05:16] S1: Reality is a very powerful thing, right? When your engineering project is in simulations or in low volume demonstrators or in demo mode, you get to have a lot of control over the world and things are pretty perfect. When you build things that serve a, you know, critical national security objective and are made in massive volume and are used by people whose lives depend on them in volume, you don't have very many luxuries. And you're kind of forced like the... Kinda... I've I've noticed the Elon algorithm is kind of forced upon you. The insane deletion isn't really like a a luxury. It's like a... No, you will fail. You will not deliver anything. Your volumes will be tiny. Your timelines will slip, you have to be vicious in the deletion. Every requirement gets questioned to shit. We push back on all of them. You know, you want picture perfect drone swarms that like, you know, operate like in thousands of units and behave like a wild animal swarm, like a fish swarm, you don't actually get that requirement. That's a demo requirement. And you have to be much more real. You have to think like, what do the users want? What has worked when we deployed? What can we manufacture? And those kind of realities are just hammered into the engineers that work on on Neros products.
00:06:40 · Ty Morse
[00:06:40] S0: A lot of people talk about like autonomous weapon systems now, but you guys very specifically from the beginning are basically trying to focus on trade... Creating the best possible thing for an operator. Yep. And now you're like moving into slightly more autonomous systems, but mainly still focused on the operator. Why did you do that? Why didn't you just go straight to autonomy?
00:06:56 · Olaf Hichwa, Ty Morse
[00:06:56] S1: We gotta look about how the first Archer ever was designed. You know, Soren showed up at my office and was like, I know some Ukrainians from Twitter. Just get on a call with me and they will give us some good feedback on what we need to do. So it immediately was like user obsession from day one. And then what did the users want? They didn't ask for a AI powered drone swarm with a thousand units. They asked for how do I set off the bomb? How do I make the radio not get jammed? How do I go longer range? And so it started there. Right? And then we we we really believe in getting something that works to get feedback. Because if you spend too long just designing in a vacuum, when you have that contact with reality, everything falls apart. Your assumptions are wrong. So we generally focus really heavily in getting something to the field quickly to iterate on. With that being said, you can't just continuously operate on those six week engineering timelines. We touched on it last time. You need a little bit of time to have breathing room. And we we do that by first usually deploying like an initial system, getting feedback, and understanding what the true pain points are. Some of the true pain points we've noticed is is like operator burden is a big deal. If a user has to look at the drone and carefully babysit it for the full like thirty minute strike, you know, you take off and you're commuting for twenty five, thirty minutes, and then going for that... [00:08:17] S0: Is there something like a loss of focus?
00:08:19 · Olaf Hichwa
[00:08:19] S1: There's a loss of focus. And you know, you you gotta take care of your buddy. You gotta watch your surroundings. You have to monitor maybe another drone. We we start to learn what breaks with a full manual solution, and we fix the parts that break. And I think it's like people assume autonomy is like a switch. They go straight from no autonomy to, you know, thousand unit AI swarm, and things fall apart so quickly. Those swarms are so finicky, and they just do not survive first contact with reality. They're they're so, you know, perfectly designed for demo environments with GNSS, with other like unrealistic features. Like they they they assume that your targets won't be moving. They assume your targets won't be occluded. And they assume they won't have like destructive patterns or all these like edge cases of battle aren't considered. So generally, when we're working on products, we're we're focused on what gives America an edge in the fight, and that is usually things like extreme manual precision and things that decrease the operator burden. This has been like one of the big design philosophies behind Archer AI. This is the this is the product here and this is actually a product we're launching today as part of this. So Archer AI is an Archer with an autonomy stack. So in the front of Archer, we've got a computer vision system that can use AI to lock on to a target and fly itself into the target once you get jammed or go over the RF horizon. This is a very like high user load part of the equation. Right? And it allows the user to just command a drone to go into the target. The user can take over. It uses our same industry leading anti jam radio solution. The user can readjust where the AI thinks the target is in real time. If the AI messes up, if, you know, there's something, some countermeasure that the enemy has figured out, the user can readjust. But the drone will go into the target even if you lose comms, even if you're GPS denied. And I think this is like a a really big step forward for what works. Like really regularly, like, let's say you wanted to, you know, go use Archer against an enemy in the battlefield. One of the first things people run into is you go over the RF horizon. Right? If you try and go for the strike, there'll be trees or a mountain or something in the way, and then the radio won't go through that.
00:10:38 · Olaf Hichwa, Ty Morse
Archer AI gets around that because once you, you know, once you know... You find your target from up high, you could tell the drone to go strike even if it doesn't have communications back to the user, so you can dip below that radio horizon. But these kinds of kind of decisions on what we build are always really informed by what the user really needs and really works. They're not often informed by like what, you know, certain folks in the government that maybe don't understand the users really well want in a demo, or what Congress wants in in something. We're we're much more focused on just like build something that works for the users, and then let the users be your salespeople. [00:11:18] S0: Okay. This was actually something that you talked about earlier. You don't necessarily want to listen to government because the government doesn't know what to build. Yeah. How do you how do you build something you sell to government when the government doesn't know what it wants [00:11:30] S1: to buy? We want to build something that the users really, really, really want. And of course, like, it is a massive generalization to say the government doesn't know anything about what they want. There are exceptions to this rule, but generally... [00:11:46] S0: They're like directionally correct?
00:11:48 · Olaf Hichwa
[00:11:48] S1: They're well intentioned. They're well intentioned. I'll say that. Yeah. Very well intentioned. And there are smart people in the government that are directionally and actually correct. We find it most useful to do the digging ourselves. We we go to Ukraine. We meet with users. We reach out to users. We respond to every customer support ticket very publicly. We have feedback sessions every month with that team. And then we tell the government what they want whenever they'll listen to us. And we'll say like, hey, this worked in Ukraine. This is going to be deployed in Ukraine. This is already working in Ukraine. Here is our library of videos of the system working in Ukraine. You know, we have hundreds and hundreds of successful missions flown on Archer today. There's very few companies that can say that. I'm not aware of another defense tech startup that can say that period, at least at this this magnitude. So our people in the government listen to that. They go, oh, well, they did the user study. You know, don't trust don't trust, you know, any one company. Go talk to the Ukrainian users. We'll make an introduction. And the Ukrainian users will be like, yeah, check it out. I'll show you my video of of this thing working. And the government, the smart people in the government will like, maybe that holds some weight. Maybe we should set the requirements around what they're talking about and allow for some open competition from there. So I I'd say folks are really well intentioned. They just might not have the resources to run like the user studies that we run and the the trials that we run.