Gray Matters
Mission Matters Podcast
πŸŽ™οΈ Ep 8 - Seasats: Scaling Persistent Maritime Autonomy
0:00
-59:11

πŸŽ™οΈ Ep 8 - Seasats: Scaling Persistent Maritime Autonomy

Encounters with Chinese destroyers, how maritime autonomy differs from Waymos, and more...

Why don't we see autonomous boats sailing around San Francisco Bay the way we see Waymos (and soon, Robotaxis) all over SF? In the latest episode of the Mission Matters podcast, Matt Kaplan and I sat down with Mike Flanigan, the CEO of Seasats, to discuss the current state of maritime autonomy (and why the tech is harder to build than a Waymo!)

We cover:
πŸ›₯️ Open technical challenges in building autonomous boats (computer vision, power management, "long tail challenges," and more)
πŸ‡¨πŸ‡³ The asymmetric advantage small, cheap USVs provide the US Navy compared to large aircraft carriers and destroyers (like the $1B Chinese destroyer a Seasats Lightfish encountered on a mission last month...photo below)
πŸ‡ΊπŸ‡¦ The role USVs have played in the Russia-Ukraine conflict
⚑ And much more...

You can listen to the podcast on Spotify, Apple, the Shield Capital website, or right here on Substack.

As always, please let us know your thoughts, and please reach out if you or anyone you know is building in the national security domain.


Maggie (00:04): In this episode, we're joined by Mike Flanigan, the CEO of Seasats, a startup building the future of autonomous systems for the ocean. I'll say Seasats is definitely one of my favorite portfolio companies, in part because I think it's one of the easiest of our portfolio companies to explain to people who work outside of this industry. They're building some super cool stuff. In short, Seasats builds solar-powered autonomous drone boats that sail themselves thousands of miles across the ocean.

Matt (01:06): Yes, and the Navy has decided it needs a lot of autonomous boats. One thing that struck me learning about this space is that the unmanned surface vessel industry isn't actually new. I mean, you can go all the way back to World War Two, where several major powers used USVs for offensive operations, minesweeping, and even dummy practice targeting. And then 80 years later, you have this operation in the Black Sea in 2022 where the Ukrainians used remotely controlled drone boats to sink part of the Russian Black Sea Fleet, and it's considered this watershed moment in maritime autonomy. And now Congress, the U.S. Congress, is planning to allocate nearly $2 billion for USVs. So I think there's this important question of why now? What about future conflicts makes these platforms so important? And why haven't cheap, unmanned, and autonomous vessels been adopted at a large scale before? Thankfully, today we have Mike on the show to explain this unique moment in maritime history, both technically and geopolitically, and what it all means. Seasats is one of the leaders in maritime technology, so we're super lucky to have Mike here today. Mike, thanks for being here.

Mike: Absolutely, thanks for having me on.

Matt: Let's start there. The USV industry isn't new. So why is there so much momentum for the industry today, both technically and strategically? Why was the Ukraine war the first time that cheap USVs were used for such an important strategic effect?

Mike (02:41): Good questions. Yeah, as you pointed out, Matt, the USV industry has actually been burgeoning or growing for a long time. It's kind of been this building momentum, or maybe tension, of like, okay, the commercial market value has always been there. It's very expensive to do anything on the ocean, which we can get into later. But the technology tipping point, I would say, has been held back. And then one of the interesting things about the Ukraine-Russia war is that full-scale conflict releases some of the rules of engagement. And that actually suddenly crossed us over the point where unmanned systems become incredibly effective and revolutionary, game-changing overnight. I think when the very first videos were hitting Twitter of USVs sinking Russian ships, it was like, okay, the next day at conferences in D.C. and San Diego and California and really around the world, people are talking about this. They're like, okay, we need to change what we're talking about because everything has changed for maritime. So I think that is really what led to the tipping point, kind of unleashing it.

Maggie (03:48): Mike, maybe could you differentiate? I think we have both USVs, unmanned surface vessels, but then also ASVs, autonomous surface vessels. So where actually is the tech today? What's actually being used on the battlefield, and where are we heading?

Mike (04:06): Yeah, that's a good one too, Maggie. So USVs has been the traditional term, particularly for the Navy. They've gone with unmanned surface vehicles or vesselsβ€”it changes a little bit. We like to use ASVs to distinguish the autonomy. It's like, hey, you don't always need a human in the loop. I mean, some things are really bad. A human in the loop would be someone needing to take active controls just to continue the mission. Imagine someone who's holding down the go stickβ€”that's a human in the loop. Human on the loop would be someone monitoring to make sure that it's doing the right thing, and that would be a USV. And an ASV would be like, okay, maybe the ASV is conducting its own mission, potentially without communications, and then it's pinging back information and asking for decision-making input. So really, an autonomous system, as far as we knowβ€”particularly some of the kinetic USVs that have been usedβ€”would probably be properly termed USVs. They're using video feeds to conduct targeting where an operator is watching that feed, directing the vessel, and conducting final guidance maneuvers. And that's both in the Black Sea with Ukraine as well as in the Red Sea with the Houthis, as far as we can tell.

Maggie (05:20): And why move towards ASVs rather than just stick with these remotely piloted USVs?

Mike (05:27): Yeah, so on that one, it's interesting. Ukraine-Russia is totally the modern lab in terms of warfare and what's changing incredibly rapidly. One of the open pieces of contention is people saying, like, hey, don't over-learn from Ukraine. I would say that there'sβ€”I'm more usually in the camp of, hey, those people are usually in a traditional camp and have something to lose if things change and everyone wakes up to that. But one example where that's probably accurate is, okay, for a real near-peer competitor, let's say a global threat like China, really you're probably going to be dealing with very sophisticated systems like intensive jamming, intensive electronic warfare. So a USV might not be appropriate because those links are very easy to pick up on in maritime and to cut and to sever and to disrupt. So you might need the autonomy. And I would say in terms of getting toβ€”the second reason for needing autonomy is for persistence. If you think about it, you have this scaling problem. At Seasats, we build these very long-duration, very long-range platforms. If we put out 1,000 USVs or ASVs, sorry, and they're out there for months at a time, well, it's very unscalable to then have a whole bunch of human operators watching. You really want someone doing that command-level intelligence.

Maggie (06:54): So what is the state of techβ€”I guess first I'll askβ€”of our adversaries? I know you mentioned China, you mentioned Russia. I know the Ukrainians are using some of these more remotely piloted systems. Where are our adversaries in both developing and then deploying maritime autonomy today?

Mike (07:12): Well, one thing's for sure: definitely China is the manufacturing leader of the world, like it or not. And so, particularly if you look online, the number of USV systems that are getting proliferated by China is actually massive and at incredibly cheap price points. They're not allβ€”or the majority of them don't seem like very sophisticated or useful products. But at the same time, it's kind of like there is a quality to quantity, if there's just thousands of really kind of crappy systems. Well, you do need to contend with those. I think that's one of the things that the U.S. in particular has learned. If we're talking about the state of technology and affairs, we'll go fromβ€”let's say we just touched on China, which I'd say is mass manufacturing. In the Red Sea, the Houthis are launching relatively cheap drones, like missiles, and then also USVs, and some really interesting USVs in their attacks onβ€”you know, terror attacks on global shipping. But if you look at them, it's like these are very much like maritime IEDs, like improvised explosive devices. You've got fishing boats loaded with explosives with decoy things in the front to look like a human driver, to create confusion and uncertainty. Unfortunately, even such crude systems need to be countered by usually more sophisticated systems. So the U.S. ended up in this very difficult cost equation where it's like using expensive missiles to shoot down very cheap drones. So that's a problem.

In Ukraine, I would say that they're at a little bit more of a sophisticated level with their maritime technology, where, despite them being remote, they've shown definitely the world's leading implementation of USVs. I mean, they're launching 10 drones at a time to go do things. They're swarming Russian ships, taking out propulsion first, and then striking critical equipment second, and doing follow-on strikes. As well as now, Ukraine has again kind of opened up the history books and made everyone look because they then mounted aerial vehicles and are launching long-range USV missions with aerial strikes at the end into Crimea. And then taking that even further is kind of like, what is the logical counter to USVs? Typically aerial vehicles, and really helicopters are able to match speed and probably have the best gunnery and perspective advantage to stop USVs. Well, then the Ukrainians added surface-to-air missiles and even, I think maybe an FPVβ€”but I might be wrong on thatβ€”but at least a surface-to-air missile and took down a helicopter and then took down a fighter jet. So now it's like, okay, even those counters don't make a lot of sense. So definitely, the pace is changing extremely quickly. I would say Ukraine is definitively the leader in this space, even if what they need to do due to their ongoing war is maybe not what the U.S. needs to focus on.

Maggie (10:02): So then, where is the U.S. Navy in this whole ecosystem, in terms of actually adopting USVs and/or ASVs at scale?

Mike (10:14): Yeah, well, there's certainly a lot going on. The U.S. Navy has a lot of folks, a lot of logistical power, and a lot of budget to be spent on trying to solve problems. I would say it's been fractured and very spread out between many different groups, whether that's Service Warfare Centers, autonomy-specific groups, innovation-specific groups like DIUβ€”you name it. It's kind of like this was getting worked on in a ton of different areas. There have been recent big bets with the Replicator program by DIU and Hellscape. I would say that one of the common threads is everyone's aware that it needs to move faster.

And one of the things that I definitely see from the Seasats perspective, because we actually work with a large number of the different Navy groups, both through their exercises, through combatant commands, and through field operationsβ€”one of the things that I would say is a common thing that a lot of the folks within these groups know, the service members, is like, oh, we need to be testing in more realistic ways. The whole innovation cycleβ€”the DoD is very focused on solicitations and big bids. Unfortunately, that lends itself really well to lobbying and marketing clout and the fanciest proposal winning, and it does not lend itself well to effective, cost-effective, and mission-success-based products. So when we do see the DoD do kind of testing, I think sometimes the results are surprising. We can't talk about them all right here, but one or two of our customers, more in the special operations side of things, we've seen do straight-up competitions and end up with some very interesting results that are not always the biggest names who have raised the most money.

Matt (11:59): Super interesting. I want to kind of pivot to the platforms that Seasats builds. To your point, Mike, on some of the customers you work with and the platforms that Seasats builds, and what use cases you guys are focused on. So yeah, we've all seen in the news recently that Seasats successfully sailed a Lightfish from California to Japan autonomously, and then separately, I saw you guys released a photo that was a high-resolution image of a Chinese destroyer in the South China Sea. Those seem like a big deal to us who are outside the companies and the government organizations that are working on these problems. But can you contextualize that a bit for us? Are these things that every company is doing, and what do these announcements tell us about Seasats' capabilities and what you guys are designing your platforms for, and why?

Mike (12:53): Yeah, thanks, Matt. It definitely, I would say, is a big deal. It's pretty exciting. Our company was excited, tons of our customers were excited, and tons of people who just follow the industry were excited. I think one of the reasons that this is a big deal is if we look historically at what programs have been able to do cross-ocean missions, they're all large. We're talking about 200 to 300-foot ships, typically. That's the amount of material and resources required to cross multiple thousands of miles.

It's an interesting problem because for the Navy in general, these oceans are both historically a great protector of the United States and any country that has big oceans. It's like, okay, someone has to cross that whole ocean. In the investment world, we use the word "moat" to indicate a very small ring of water around a castle or a defensive piece of technology. It's like, if you have an ocean protecting you, someone has to cross entire oceans to get there, and they need a way to get across. You need heavy equipment to be moved. So typically it's required massive ships and equipment.

I think what was very important and kind of contextually relevant for the Seasats cross-ocean mission was, hey, we're showing that very small vessels can do this. And in today's day and age, with satellite technology, RF sensing, et cetera, big things are very visible. The world's never been so transparent, and so ships that it used to be that aircraft carriers could go hide in the ocean. You know, in the war in the Pacific, Japan and the US were going around and didn't know where each other's ships were. We had to send out scouting planes to spot the fleet and then go engage. Now that's changed. With the proliferation of low Earth orbit satellites and the intelligence agencies getting very good at their jobs, everyone kind of knows where the big ships are. They even know where the bases are. This is becoming a massive problem for the DoD in general.

So for small things to be able to do these missions is very important, because we're showing hey, small things that cannot be tracked are very hard to disrupt and are very inexpensive to build. So the cost equations on our side can be very, very relevant to today's missions, because you can cross entire oceans. You can go put them within a couple feet of a key area with great precision. So it's certainly kind of changing the understanding of what is possible.

Matt (15:19): So it seems like, from what you're saying, the unique value proposition of Seasats is doing these long-range, high-endurance missions that are typically reserved for orders of magnitude more expensive and significantly more visible ships. Really, that's kind of the key advantage you guys have built. Is that fair to say? And are these the types of use cases you'll stick to in the future, or do you plan to expand the technology and product suite to other parts of the maritime domain as well?

Mike (15:53): Yeah, I would say maybe I'll answer the future expansion second. But I think the first part you hit is really good there. It's like, okay, things that were typically much larger and more expensive. So you asked about the Chinese destroyer that we had this 20-minute encounter with on the Pacific Ocean journey. Well, typically, a destroyer like that, once a carrier strike group goes out to sea, they're not going to encounter anything except for other large vessels, maybe occasionally long-distance ocean-going commercial shipping traffic. But it's kind of an empty world, except for these other large capital assets. No ships out to sea are, frankly, as low cost as a Seasats Lightfish.

So the fact that we're able to be out there and say, like, hey, you have to contend now with the fact that you don't just have to have your watch on high alert when you're within 100 miles of coastline. It's like anywhere in the ocean, we can proliferate ASVs and both deliver high-quality, high-resolution, near real-time intelligence, and potentially also layer in offensive effects if necessary. So really, it kind of changes the dynamic. Just looking at that one specific one, a Chinese Type 055 destroyer that costs nearly a billion dollars to buildβ€”it's like $930 million. A Lightfish sells for $250,000, so it's actually less than that. But really, the asymmetry there is very remarkable.

Matt (17:26): So on what you guys are sensing in the ocean side, one example is sensing and being able to detect and characterize a Chinese destroyer. What are the other use cases for having this proliferated constellation of really cheap, low-visibility ASVs that you guys make?

Mike (17:53): Yeah, one of the fun things is we started the company very much in the commercial space, and so we've done work from subsea mapping, which is important for construction of offshore oil and gas, offshore wind, for monitoring pipelines. We've done work for the fishing industry, like shellfish monitoring, monitoring water quality. Unfortunately, every year someone gets poisoned by shellfish that have toxic water in them. And so being able to monitor those things in real time is very impactful.

We've talked about industries that drive the maritime economy. There's a whole range of these things. It's a pretty exciting and interesting world. People, particularly on the security aspect, has gone up a lot in recent years. You know, it used to be that folks would build things in the ocean, and then it's like, well, it's safe just because it's in the ocean. Like you lay down an internet cable or a pipeline or build a dam, and it's like, well, no one's gonna mess with this. It's all the way out there. That has certainly changed. There's a lot of gray zone conflict of people sabotaging equipment. And so now we're getting a lot of outreach from commercial companies asking us to do what is essentially very routine security jobs. It's like, hey, we just want data analysis and very timely warnings so that we can protect what ends up being many hundreds of millions of dollars worth of critical nation-state infrastructure.

On that side, it's very fun because we're definitely in the lead in terms of commercially viable technology. Unlike US Navy technology, there's a lot of stuff that's focused on pointy, full-on warfare. However, most of those products don't have the safety systems, the liabilities, or just the commercial viability to be at all relevant to the commercial industry. Many of them talk about dual use, but realistically, we don't see a single sale that they can point to in the commercial space. And that makes sense, because the commercial world is much more sensitive to ROI and actual stuff just making practical sense to a layperson, rather than the harder mission, but a very different mission, of delivering ordnance on a target.

Maggie (19:54): Yeah, Mike, speaking of those commercial use cases, I mean, I think about the autonomous vehicle industry in San Francisco. Matt and I both live in SF. I know we both take Waymos all over the place, and from a non-expert's perspective, this seems like a harder problemβ€”getting cars driving on the streets of San Francisco, where they might hit somebody walking in the middle of the street, or where there's gonna be random U-Hauls just parked in the middle of the street or whatever. The open ocean seems like it would be an easierβ€”which I put in quotesβ€”problem, or technical problem. So I guess, why are we seeing the maritime space sort of lagging behind the ground vehicle space when it comes to deploying autonomy? Is this a regulatory thing? Is it actually a technical thing? Is it just a market-based question? What's your perspective on that?

Mike (20:48): So I would say, to answer that in two different lights, the hardware problem on a lot of the different things, I would put open ocean maritime robotics closer to the space industry, like satellites and such, rather than the autonomous car industry. But I do think the autonomy is directly related to the autonomous car industry. So let's talk about that first.

I think that something that was interesting that we saw with the autonomous car industry is everyone kind of thought that it was gonna be pretty easyβ€”that was like, oh, we can solve this right now, in maybe the 2018 timeframe, kind of the breakout of some of the new machine learning models. It's like, wow, computer vision is so much better, neural netsβ€”we're just gonna smash this. And there's a huge surge of funding and companies, and then, really, none of them solved it. And the only ones we have left are Waymo and Tesla, who are actively duking it out in relatively confined rollouts. You know, Waymo is kind of like a very progressive, building chunk by chunk very reliably, and Tesla is kind of still this big unknown of like, are they suddenly going to unlock full vision-based, incredibly affordable autonomous driving? We'll see.

In the maritime space, we have the same problem. What held them up, what killed all those companies, I would say this is a long tail problem. So the problem is that 99% of the driving is easy and solvable, and they probably all did solve it quite well, but that 1% chance of like, okay, kid runs out from behind a car, and a human driver is incredibly good at identifying in milliseconds and then jamming on the brakes, and we come to expect that out of autonomous systems. We don't want to let an autonomous system out on the road that is just a terrible driver in these really important moments.

Maritime has the same long tail problem. Okay, a kayaker comes up, a jet ski comes up, a tanker is crossing on a windy day through a tight canal, and there's a sailboat coming, and it's like the rules of the road say that one should give way to the other, but a captain or a mariner or pilot needs to make a tough judgment call to say, like, ooh, I would rather let us bump than cause the situation like the Suez Canal or the Ever Given that got stuck. You name these massive maritime disastersβ€”they're really tricky. They're basically these maritime situations that still have really high, critical, important moments, but now it's actually much harder, because instead of having a massive bulk of training data to get through the bulk of this, there's very little. It's very low volume, and it's a false sense of security. Like you can go out and operate for months and say, oh, we have COLREG-compliant software. And it's like, no, they probably don't. They just had very few interactions. And anytime someone gets nervous, they switch on a Starlink and just watch the cameras and do a little nudging if they need to. So I think that long tail problem is the tricky thing that's holding up maritime.

Maggie: Mike, what’s a COLREG?

Mike: COLREGβ€”thanksβ€”the collision regulations. These are a set of guidelines about how vessels on the ocean should interact with each other, and it's the International Maritime Organization, or IMO, that published them, jointly with a bunch of different nations, I don't know, maybe 50 years ago or something. And yeah, ASVs have been struggling with them ever since.

Matt (24:08): Yeah, going a bit deeper on the tech stack, I want to better understand where Seasats comes into this. You talked about being the only company in the military maritime space that also has a commercializable product. You said you started commercial, have commercial customers, and then that would seemingly give you a lot of technical differentiation in the intelligence and surveillance and reconnaissance ISR missions, right? Could you talk a little bit more about what differentiates Seasats technically from other companies in the maritime space or from legacy ship companies, and what are the hardest parts of that tech stack you guys have built? What are the hardest challenges you've had to solve?

Mike (24:58): So I'll start with the traditional companies and then move towards some of the newer companies. I would say the traditional differentiation is that in maritime, to build these ASVs, and I'm going to keep it focused on the offshore, so offshore and longer endurance missions where you need to be out for more than one day, greater than 24 hours, and operating at least a mile offshore. When you do that, you go from hundreds of competitors down to just a handful that say they can do it, and even fewer that have proven they can do it. We're probably talking about a single hand's worth of companies. The field thins dramatically.

Why is that the case? It's because you need to solve a wide array of problems and you need to be competent, or even expert, at all of them. You can't just be good at one or the other. So there are a lot of boat building companies that say they can build autonomous boats, but if they don't have modern software, they don't have great electrical engineers, they don't have the full expertise that these autonomous systems require, then they just don't succeed. It's a good looking boat, but it doesn't actually do what they need.

There are other companies, like in San Francisco, where I've seen some startups that pop up and say we know software and we're going to build a sweet autonomous boat because boats are easy, and it demos really well. But you see 8020 aluminum, which is a very common prototyping aluminum, like rickety stuff bolted together, ripping around for demos in the bay, and that's essentially irrelevant to the real mission. Until those companies recognize that they need to hire really good mechanical engineers, really good naval architects, and even really good electronics and electrical engineers, they won't succeed.

You can't just find off-the-shelf solutions. If you just buy a Jetson, like an NVIDIA Jetson, that typically sucks five to twelve watts. Doesn't sound like a lot, but most PhDs in autonomy have not considered power consumption being a problem. If you're out for days and days and days, you need to manage your power budget. You need to switch things on and off. You need to handle different communications networks. Just the number of problems you need to solve is massive.

Even just communications, which I just mentioned there, if you just run Starlink all the time, it's 60 watts. Now maybe you're having to run a gas generator. But guess what, if you run any type of internal combustion engine like gas or diesel, you typically have a person service those every couple hundred hours to change the oil and change the seals. Even our cars do not run close to that long, even though automotive is one of the highest reliability industries in the world, and they need a lot of servicing.

So I think the problem here, technically, is that there are a lot of things to solve, and it's very easy to start, but it's really hard to finish. It's just another one of these long tail problems. It's really hard to get to the last couple percent, and those end up mattering in the ocean industry.

Matt (27:42): Yeah, I think that's a super interesting point about how to build autonomy. From what you're saying, what I'm taking away is that to build autonomy, it's not just a software problem, but especially in maritime, it's a hardware problem as well. But I feel like we see companies in the space who are saying, "Hey, we know how to build boats. There are a lot of people out there who know how to build boats. We don't need to reinvent the wheel. We're just going to build the software that retrofits those boats, or maybe we make some slight modifications to handle the power, the comms, or the other problems you just talked about. But we're not going to have a proprietary design for our vessel, because people know how to build boats." So could you talk more about why it's really important to be the ones building the boats yourself? Why not just retrofit boats with software kits and maybe a few other things that help you monitor and manage things like power and comms?

Mike (28:41): Yeah, that's a good question. And you know, if we could buy boats off the shelf that did the missions that we needed, we absolutely would. We joke all the time that we would love to outsource more. We wish we could outsource more.

One of the things that Seasats started with was these man-portable boats. Some of our very first government customers were special operations, and they had these hard requirements of, "Hey, we need to be able to show up to a location and with just people, get this thing into the water and start the mission, and do that without lining up a crane or a forklift." So that immediately puts a very hard requirement in terms of how much weight is acceptable.

And so for us, we end up very much in this composite, very compact space, trying to build these really long range, really capable stealth platforms. And they have that weight and size limit. Now because of that, we have to pack all this stuff in and do all this design work. And really, we have to own the entire solution. It's not okay to throw it over the wall and say, "Well, someone else will hopefully solve that," and then have a vendor send it back and it's a little bit too heavy.

That has led us to a point where we're now winning sole source awards, and where our customers tell us, "Yeah, you know, there's nothing else out there that is that size, that capable, with that range and has proven performance. It just doesn't exist." You can look at the trade space, and there are dozens and dozens of companies, and they make big things, they make fast things, they make short range things or small things, but nothing that hits both of those requirements.

The cool thing is, I didn't realize, and I don't think we realized, just how helpful this would be for commercial market growth, because it turns out that shipping around the world is a huge pain. And if you can make something small and portable and very capable, then you can also ship it really affordably. So we get a lot of contracts where they say, "Hey, we need to do this thing in this other country, and we have six weeks to do it." And there just are not many options for what you can actually commercially air ship around the world. We're right at the limits. We already have to have people who are really experts in shipping, logistics, going through customs, doing all this stuff.

So yeah, it turns out the size and weight, I kind of like to think about this like cell phones or computers. You know, it used to be that you had giant computing rooms, and then it was like, "Hey, now it's only the size of a fridge." Then it's like, "Oh, now it's the size of a refrigerator or a microwave," and now it's in our phone. And it's like, okay, if it's smaller, you can scale it better and faster. So really, everyone would do everything as small as possible if they could. Typically, you go bigger if you have to. So the smaller the better. It's just that it requires a lot more engineering.

Matt (31:18): Yeah, I imagine on the US government side, there would be a lot of contested logistics interest in a platform that can not only be shipped overseas easily, but in some cases, can ship itself overseas easily. Is that something that your customers have gotten excited about?

Mike (31:35): Yeah, I think that's a cool one. Because in contested logistics, okay, how do we maintain a fighting force, or standing force when we've got conflict with an adversary and where supply lines are not as easy? You know, you can't just fly a big cargo plane in or send a big boat. It's going to be a target.

Well, the cool thing about the stuff that we're doing, if it's really long range and small, is we can change its logistics balance, both in terms of maintenance. You know, it's like, "Oh hey, that might be difficult to maintain, right?" Well, what if you only have to maintain it twice a year? If you maintain it twice a year, it's like, well now, I mean maintenance every six months, sure, just stockpile a tiny pallet, and you're good for multiple years. So you totally delete this problem by making the things be very, very long endurance and self-reliant.

And then the second one, like you mentioned, is they can just go super far. So it's like, great, you can basically get into contested areas, and the smaller, the better. I think signature management is a huge thing that people are learning in terms of unmanned systems.

Matt (32:33): Yeah, I wanted to ask just another quick question about how you're designing for persistence. The Trans Pacific mission, what was the one where you went from California to Japan? What was the hardest thing to get right technically to make that mission successful, and from a design standpoint, what did you learn from it?

Mike (32:58): Here's the thing about all these challenges - there are the problems you don't want to solve, and those are probably the ones that are most important. You could build the boat lighter, or you could build the boat faster, but you really need it to work day in and day out, so you have to respect those constraints and requirements.

Our vessel is actually a hybrid vessel. Not many people know that. People either think it's an electric motor that's battery powered and forget that all the solar panels actually harvest an enormous amount of energy when you're very efficient with your power budget. For many months, you need solar power. But it's also hybrid - it uses a fuel cell, and that's really important because it has the ability to work for weeks even if it's very cloudy with big storms. For other applications that are carrying high power, high draw payloads like electronic warfare payloads, they require hundreds of watts. You can only do that and then recharge quickly if you have a hybrid system.

That required a lot of engineering. When we did our first prototypes, it was not hybrid - it was pure solar electric. We realized from doing missions that we needed to tackle this hybrid challenge, and we invested in it. It took a ton of engineering. Some of the cross ocean missions actually unveiled things about those hybrid systems that you're only going to learn when you have boats out in massive storms and huge waves. You have to decide how to choose the right level of simplicity versus complexity. If you make the design decision to add some actuator to close some air vents, that adds configuration management, extra parts to build, and extra failure modes. You need to carefully weigh the decisions to add those things. Those open ocean missions are really where we prove that stuff out, where we validate our design and share it with the world so that people know what the status of this technology is.

Maggie (34:53): How do you guys go about actually building some of the machine learning models and tools that you deploy on these systems? I know you mentioned, and we've heard from others, that there is a big shortage of maritime data to train something like a computer vision algorithm. There's only so much real world testing you can do. What does that pipeline look like, from data preparation to training to testing, simulation, and evaluation?

Mike (35:21): Well, I think we're fortunate that the machine learning world as a whole has moved forward massively. We leverage open source models. We take the best in class, and then we have our own data libraries that we've built up. Then we fine tune and train to a maritime perspective that's relevant to our boats, because it's all about matching data distributions. If you take the best Tesla model and then ask it to do something random in your house that it's never seen before, it's probably going to do poorly because it just hasn't actually seen that type of data before. Having on-target data is really important.

Maggie (35:56): Is that just data that you guys have collected, or are you using simulation or synthetic data?

Mike (36:01): Yeah, typically for us right now, we've evaluated synthetic data, but currently we have this advantage where we have boats all over the world, and they've been out there for years. In some cases, we have a lot of data, and we're getting more every day. Our amount of data is accelerating. Currently, the best data is real data. I anticipate eventually we're going to use synthetic data to replicate certain specific things that are really hard to see variety in. But right now, we're sitting on a very good host of data, and we're even doing some data collection contracts for other folks in the industry because they say, "Hey, we don't have a way of getting this affordably." So right now, we're putting out a lot of data.

Maggie (36:41): And then are you doing all real world testing, or are you also doing testing in simulation?

Mike (36:46): We do a ton of simulation, as well as accelerated hardware-in-the-loop testing. That's very common in automotive and aerospace. I will say, with some pride and joy, that back when I was writing software at Seasats in the very early days, one of the things I contributed was writing our simulation engine - our first simulators. That allows us to test a huge amount of our code without the software ever knowing that it's not actually out in the real world. You can simulate sensors, you can simulate comms jamming, you can simulate a lot of things. Then we pair that with real world validation, because certain things like comms degradation - there are tools to simulate them, but a lot of times they're not quite accurate to the real world.

Matt (37:27): You mentioned that you now are actually selling some of these data sets to other customers who want to use it to train their maritime autonomy stacks. To me, that seems like something that can serve the whole industry and potentially be a large part of what your company does itself, just because of the unique data quality and quantity that you're collecting out on the ocean. How do you see that in terms of being part of your product offerings in the future? Is that a big part of it? And secondly, are you planning to deploy missions for the express purpose of collecting data that you can sell, or is this just downstream of having a bunch of Seasats out there conducting missions that you're able to sell the data from?

Mike (38:14): It started as the second, where it was a downstream effect of already having the boats out there doing something, but it's definitely moving towards the first, which is specific missions tailored towards getting specific data and then being able to sell that data stream.

When we started the company, our name - the abbreviation is Seasats, but the long form is C Satellites, C Satellites Inc. We were in a space-based accelerator, Tech Stars, and we had early investors and advisors who were all out of the space industry. They really saw what I fully believe in, which is that this is going to transition to the point where these USVs are very much treated like satellites. We have fleets of them out off coasts, off Economic Exclusion Zones, able to provide continuous, affordable, high resolution data.

The people that need it - Coast Guard, Border Patrol, DEA, mapping services, fishing industries - they subscribe to that data and say, "I need to know when someone crosses into this area." We become the contractor that keeps the satellites working. We maintain the boats, we improve the autonomy, we handle collision avoidance, liability, all these different things, and we just provide uptime. We've done that pretty successfully for the US Navy and for a couple of commercial customers in a few different cases, and they've always been really happy, and we've always been really happy because it's a great business model.

Maggie (39:36): Mike, have you all had to go through the process of actually integrating some of your systems with DoD systems or with Navy systems and some of their data feeds? I know we've heard - we just did a podcast earlier with some technical leaders in the Navy - and they said integration is one of the number one challenges that they see startups and honestly primes alike manage. I'd just love to hear about how you all have gone through that integration process.

Mike (40:04): Yeah, I listened to that episode with Justin and Artem, and I totally agree. The integration problem is super key. Luckily for us, we knew this industryβ€”we'd been in the space for about five to ten years specifically before starting Seasats. And so integration was something we took seriously from the beginning. One way to solve that is making sure that you have very open APIs at the endpoints where they need to be met. So we spend a lot of time writing software to integrate with systems like Minotaur Lattice, L3Harris systems, Copiers, AFSβ€”you name it, all these different common operating and common intelligence or collaborative autonomy systems. And we've integrated with close to ten at this point, and it's always pretty easy for us. We use standards that are well known, government developed, and are easy to work with.

You know, I also really enjoyed that part of the podcast, which asked the question about just how hard it is to get onto Navy ships, or how hard it is to integrate with operational units. And I think one of the things that was recommended on thereβ€”I forget whether it was Justin or Artem that recommended itβ€”was to initially go for standalone systems, because it's easier to get the paperwork approved, and then later move to fully mature, super tightly integrated systems. That's the route that we went, and it has been successful. We've managed to get Seasats onto grey hull Navy ships in important parts of the world. And it's always done because, basically, people realize the critical need. They realize the capability that a Seasats system can offer. They look at its size and say, "You know what? We can slap that in this area, have minimal approvals necessary, operate it slightly in parallel, and it offers the military a unique capability." And so that's how we've gone about integration. And then now that we're at the phase of larger sole source contracts, we are bridging some of those tight integration efforts where the government invests in saying, "You know what, this can be something we're gonna have for five to ten years, and we need to wrap it in tighter."

Maggie (42:02): Speaking of some of these government developed standards, I know one buzzword that I hear a lot is MOSAβ€”Modular Open Systems Architecture. I'm curiousβ€”I've heard maybe mixed things, both positive and negative about it. I'm curious, is that real? Is that going into effect? Is that something you all are working with? Do you have any thoughts on it?

Mike (42:20): MOSA and UMAA get tossed around a lot. What's UMAA? UMAA isβ€”I'm gonna mess this up a little bitβ€”Unmanned Maritime Architecture, something like that. But I would say MOSA is the closer of the two to being a good, realistic thing. I would say MOSA in intent is excellent. We try to be accurate with our stuff, so we say that we're a MOSA-designed system, because they want to know that it's modular, open systems architecture, and absolutely Seasatsβ€”we design everything around that. We've carried probably forty different mission payloads from unique different companies doing unique effects. It's probably higher than that now. I wouldn't be surprised if we're over fifty, but every one of those requiresβ€”if you haven't designed in a modular, open way, every one of those is a custom engineering project. I mean, I've had folks from Navy Information Warfare Center say, "Oh yeah, typical sensor integration could be a million dollars and take half a year to a year." We do it in a day or two, and sometimes we don't even charge because, you know what? We just want our library to grow. If it's a mission value-add sensor, we want to add it to our platform. We're just gonna do this as fast as possible. So MOSA is important. UMAA is important. I would say sometimes in the technical details, those things kind of miss the mark. They get a little overwritten, a little over-prescribed, but the intent is correct.

Maggie (43:43): Another technical question that I had was, how are you all seeing LLMs and transformers play a role in maritime autonomy? Are you all actively experimenting with this, and where do you see the most promise for this technology?

Mike (44:02): Yeah, we definitely do experiments because there are certain parts of the autonomy perception stack that we have done LLM-style, or these new large transformer models. And you know, the initial results are super promising. Because this is a long tail problem, they're not quite there where we've deployed them to vessels where it's like, "Okay, we're gonna have to invest some time to get that right." I'm super excited on the LLM side, in particular, because we spend so much timeβ€”we get a lot of compliments, we don't advertise a lot about our user interface, but we get a lot of compliments from customers saying, "Oh wow, this is super intuitive. This is one of the best things in the industry." I mean, I've heard this from competitors as well. They say, "Oh man, how'd you guys get that so clean?" I think the future of UX is gonna be LLM-basedβ€”you're just gonna talk to this tablet the same way you'd talk to a person. You'll be like, "Hey, it's getting dark. Should you change anything in your sensor behaviors?" And rather than trying to make this intuitive through traditional interfaces, it's just gonna prompt you with the correct settings, or it's like, "Hey, enter a stealthy observation mode. Hey, we're entering a contested area. Set yourself up properly." And I think that will be totally enabled by LLMs. And I'm super excited to see that workflow improve.

Matt (45:17): I want to ask about price and cost. We talked earlier about the Ukrainian drone boats and sinking the Russian Black Sea Fleet. The cost asymmetry there is enormous, and those boats cost around two hundred thousand dollars or something like that. And then, you know, I was reading a Reuters article the other week that was talking about some of the challenges that the DOD has been facing with our own small USV industry. And it was saying that those platforms cost a million to two million dollars, and it very starkly drew the contrast between those costs and the cost of the Ukrainian platforms. Why is there that cost asymmetry between what Ukraine is spending versus what the DOD is spending? Why can't we pay one-tenth the cost that we're paying now and buy ten times the vessels? And then also, just curious, how do you think about the right way to price these platforms more broadly?

Mike (46:14): Yeah. So, you know, I think that Ukraine is in a unique scenario, because they're in an active warβ€”every dollar, every round, every life matters. So they need to make really conscious decisions. They don't have the luxury of time or space to potentially get something overpriced, to invest in something that doesn't have an effect. It's that "a bird in the hand versus two birds in the bush" thingβ€”they're taking birds in hand all day. And so, you know, it's interestingβ€”when they put out their open source, crowdfunded initiative for, I think, the Magura platform, which was the very effective USV for driving back the Russian fleet. According to open source, available information, they're releasing those at two hundred and fifty thousand dollars, I believe. And so it's like, okay, that's a pretty good analog. They wouldn't post that number if they thought that was wildly overpriced, because they're opening up to the world being like, "Hey, help us fund these things." It's not like they're soaking up huge profit margins there. They're trying to drive ahead in a war. So I think that's a good reference point to recognize that maritime is hard. You need a lot of these systems to work. You need waterproofing on almost everything, which drives down the volume and increases human touch time. So maritime is expensive. Ukraine is probably a bottom priceβ€”that's probably the simplest systems that you can make, even though, to their credit, they're the most sophisticated in the world in terms of effectiveness.

In terms of the US, you know, I think that article quotes a Saildrone platform at maybe two million dollarsβ€”I'm just quoting what they put out there. I think there's some challenges here where it's like, okay, the US DOD is very used to asking for very high-end capability, so it's gonna be more expensive, and they're preparing for very high-end conflict. So it's like, okay, you need really sophisticated systems. They're definitely gonna be more expensive than the cheapest possible systems on the market, which let's just call Ukraine or China. So it's some price between two hundred and fifty thousand dollars and we don't know what the upper end isβ€”maybe it's two million dollars.

How we think about pricing is from a commercial value stance. It's like, okay, could we realistically just replace this boat with people and contractors and go do the mission? And if you're in the millions of dollars range, it gets hard to justify. You can do that really effectively with just commercial solutions. And frankly, yeah, I think that also becomes a crutch. If you think about the liabilityβ€”I don't know who the CFO is at Saildrone, but if you tell the CFO at Seasats or Saildrone, "Hey, we're going to be driving around a two million dollar asset offshore, unattended. It's just gonna be floating out there for days," they're gonna be like, "Ooh, what's our financial risk liability position on this?" And suddenly it's like, "Well, how about we have a couple hundred dollars a day chase boat out there with a crew to attend it." And now, once you got this chase boat out there, then it's like, "Well, we can also have a backup comm system. We can do all these things." You end up in a totally false, fake, basically testing environment, because you always have someone there to baby the system and to bring it home. You don't need to get good at navigating remotely through channels and difficult things, because you basically have a human to kind of watch it. So I think that's a problem with these really expensive systemsβ€”they get expensive, and then they get babied during testing.

So we were really aggressive about keeping our price low. And right from the start, we were doing fully unsupported test missions, and we could only do that when we were bootstrapping and starting this off of extremely small amounts of angel funding. We couldn't put out a multi-hundred-thousand-dollar system because we didn't have hundreds of thousands of dollars. We had to be confident in our equipment at very low price points.

Matt (49:55): Do you think that the fact that the US is looking for boats that have more autonomy capability on the software side is making their platforms more expensive? Or are there parts of the technology stack that are more sophisticated than what the Ukrainians are using that make it necessarily more expensive?

Mike (50:15): More sophisticated? Probably yes. Whether that's more mission effective is the open question. It's like, okay, who can complete missions better? Which is what you need at the end of the day. If you just want a nicer car, then you can always go up. You can be like, "All right, I want a Porsche or a Ferrari or McLaren"β€”you can spend more money if you've got more money to spend, and if you want nicer things to buy. I don't think inherently the software needs to be that expensive. Yeah, it's not a very hard computer vision problem, so I don't think it needs to be as expensive as it is. I think the prices will come down, and that will put pressure on companies to find viable price points and viable dual-use solutions, or to go out of business or have down rounds. We'll see what happens.

Matt (51:00): Last question on the lessons from Ukraine. You talked earlier about how you balance learning and not over-learning. Are there lessons from Ukraine in the maritime space that you think don't apply, specifically don't apply to a US future conflict, or how the DOD thinks about its posture and maritime autonomy?

Mike (51:25): Yes, absolutely. I think that a lot of folks saw the Ukraine very successful defense and offense with their USVs and said, "Ooh, we need exactly that." I would say it's very worth rememberingβ€”Ukraine was a defensive nation fighting a war against a much larger aggressor, and in an all-out war scenario. I like to consider this back to wars in the Middle East, like Iraq and Afghanistan, with roadside IEDs or improvised explosive devices. The IED problem was a massive problem to US forces. But there were not a dozen IED startups that were like, "Hey, we should be building IEDs for the US." It's like, noβ€”cheap defensive weapons are not what the US invests in. We typically are investing in precision strike missiles, aerial systems, et cetera, that also have really advanced safety systems, for morality purposes, like last-minute aborts and things, which drives up the cost.

So I'd say now the US is in the unfortunate situation of potentially facing near-peer conflict where it's like, okay, we can't have as exquisite systemsβ€”economics are a real factor. But at the same time, I don't think water-borne IEDs, super cheap, kinetic solutions are really the right place for the US to invest in. I think we need to look at those lessons and build new ones, or build more appropriate things to integrate into US doctrine.

Matt (52:53): Transitioning now to some rapid-fire questions as we get close to closing out here, what's been the biggest surprise building Seasats?

Mike (53:03): Maybe just the number of places and the number of needs and things we'd get involved in. I think Elad Gill's startup handbook, or whatever that book is, talks about not realizing just how big the world is. And that is totally true. There are so many people who reach out to us on literal cold inbound sales, and I'm like, "I did not know they would need autonomous boats."

Maggie (53:25): What's the most surprising one of those, if you can share?

Mike (53:28): Jellyfish detector. We didn't know if this was a joke or not, but it turns out that nuclear power plants are typically by water sources, and they have big water grates. And if you get a big plume of jellyfish that float along on currents, then they'll clog the grate, and suddenly you'll have everyone panicking about a nuclear meltdown because they can't cool the plant fast enough. And so these folks building power plants were very seriously contacting us in the early days, and doing presentations around using fleets of Seasats to provide early warning for underwater jellyfish swarms. And we were like, "Wait, really?" Yeah, we thought it was a joke at first. That's definitely the weirdest.

Maggie (54:04): What's your hottest take about the current state of defense tech or maritime autonomy?

Mike (54:11): Ooh, there's so many hot takes. Okay, here's one. I think that there should be way more testing. Everyone is excitedβ€”I think what has really happened, why are defense companies clustering and racing to Ukraine? Besides protecting democracy and helping a nation protect their sovereign borders and stuff, it's because they've become the de facto testing lab for the world in terms of defense systems. What's the big shame to me is that the US has so many regulations that we have failed to create effective test environments in the US. And I've talked to folks in the government about this, and folks who are trying to reshape things, and my conclusion is often like, "Gosh, we should probably raise some money and just purchase some private land, or purchase some areas and just run a commercial testing facility." Because it's crazy that we're so bad at this. I mean, I love looking at Zipline drones. They couldn't get FAA permission to do early UAV stuff in the States, and so they just went overseas to do testing, delivering important medical supplies, where they could do it.

Maggie (55:15): How far out do you think we are from being able to take an autonomous cruise ship?

Mike (55:20): Oh, I love this question. I can't say never, because that surely is wrong, but I'm gonna go fifty-plus years. Oh man, I know that might sound like I'm a pessimist. It's not for technology reasons. It's just like airplanesβ€”commercial airliners have been able to automate the entire flight, the takeoff and the landing, for a long time. But we need pilots for liability, for responsibilityβ€”there's so many reasons that humans are so good and versatile. When you're talking about big cruise ships, it kind of just doesn't make sense. Someone's telling me they're gonna get rid of the final crew on these super tankers, and it's like, really? There's only fifteen people on there, and they're transportingβ€”what?

Maggie (56:03): What about a whale watching boat, like there's ten of us on here, sort of thing?

Mike (56:08): Okay, okay. We have toyed about offering around Mission Bay beer cruises, where our autonomous boat just tows people around with tubes and coolers full of beer, because we've done that for ourselves, right? This was kind of a fun gimmickβ€”we should have people get toured around for romantic cruises with no driver. That might be sooner. We could do that kind of whenever you want, if you want to Venmo us, we could probably do it once illegally.

Matt (56:27): Specifically in the USV space, what's the most commonly misunderstood viewpoint about the industry?

Mike (56:39): I think the oneβ€”this is just like, over and over, I beat this pointβ€”but I would say just that the demos are done on days when everyone wants to go to the water. It's sunny, it's nice. If it rains, it pours, there's bad weather, and then everyone doesn't do it, and it's like, "Oh, that doesn't make sense." And so often the tests are scripted. It's like, "Okay, and now the bad guy is gonna come and we're all gonna point the cameras, point the weapons, and report our duties." It's just totally fake. And so the combatant commands are actually really the point of the spear, in my opinion, on this, because they're out there doing missions in the world, oftentimes that are not scripted. It's like, okay, trying to stop smugglers, trying to stop conflicts and being in kind of more contested zones, even. I saw an article where someone was like, "Hey, we should be using this as a more aggressive testing environment, because we're trying to stop smugglers." And it's kind of separated from adversaries. That makes total sense to me. Anything that can make it more real is critical.

Maggie (57:39): What advice do you have for other founders looking at starting a company in the national security space?

Mike (57:44): Find amazing investors and teammates and advisors who get how long it's gonna take and how hard it is, because maritime defense is a problem where you can't just be good at one thing. You need to be kind of amazing at one thing, which is what gets you your differentiationβ€”that classic startup ten-times improvement, to get people to try it. But then you really can't suck at anything else. It's like, if you're bad at contracting, if you're bad at legal, or if you're bad at some core competency in your technology stack, then it's just kind of doomed for failure. You'll never get all the way there because you basically need to be good enough at everything. And I think the only way to do that is to have a good team, and that counts all the way to the investor network, which, you know, Shield Capital is a phenomenal investor. Nice plug for any startups looking for capital.

Maggie (58:37): Well, on that note, Mike, thank you so much for coming on the podcast. I definitely learned a lot about the world of maritime autonomy, and really appreciate your time.

Mike (58:46): Totally. Thanks for having me on, Maggie and Matt. This is a lot of fun. Glad to be on here and glad to get to share a little bit about what's happening.

Share

Leave a comment

Discussion about this episode

User's avatar