Unmanned Systems Technology 042 | Mayflower Autonomous Ship | Embedded Computing | ElevonX Sierra VTOL | UUVs insight | Flygas Engineering GAS418S | Ocean Business 2021 report | Electric motors | Priva Kompano

34 Kingdom Hydrographic Office, which is the main provider of such charts. As they were originally made for human use, collaboration here has been key towards modifying them to be machine-readable for autonomous applications. Control network The Mayflower’s control system is designed around a distributed architecture, in line with the team’s design philosophy that conventional monolithic architectures centred on single CPUs or microcontrollers are inherently prone to single points of failure. The system is a high-availability cluster designed to support server applications and minimise downtime by using a series of redundant computers. “Our system allows us to be pretty agnostic in terms of the CPUs and GPUs we use, but we do tend towards having a high number of small ones, including some from Nvidia and Intel running Red Hat,” Scott explains. “Our architecture features numerous different software nodes, each of which is essentially a ‘container’ with algorithms and interfaces inside. “Each container runs independently and communicates with each other in a distributed fashion, and we use the open-source Kubernetes Cluster to spin up different containers to collectively run different aspects of the control system while maintaining high availability.” Thompson adds, “Kubernetes Cluster is a variant of the original Kubernetes that grew from the need of corporations to deal with load balance and failover in their data centres. We’ve taken a stripped-down version called K3S and implemented it on the Mayflower so that instead of having a rigid hardware-and- software architecture, it’s more of an amorphous, shifting ‘blob’ so to speak. “So, all onboard system and subsystem applications can be run on any of the computers that aren’t being tasked with anything else. This all arose from a trial where we lost main power, and that motivated us to decouple applications from the hardware, eventually even decentralising and fully automating the decision-making process that determines which computer takes on which task at any given moment. That allows us to deal with failover very resiliently.” This emphasis on aiding failover – the ability to fluidly move functions to standby computer systems upon failure – is critical to the success of the AI Captain. As Scott notes, autonomy means not merely intelligence but also an expectation of survival: the more systems packed on a ship, the more there is to fail, so decoupling the critical systems from specific dedicated hardware modules is vital to creating a truly autonomous ship. “We’ve done that mostly using tried- and-tested enterprise software deployed successfully in other domains, for safety purposes as much for reducing our r&d workload – there’s no sense in reinventing the wheel here,” Scott muses. “Also, a number of different networks are installed. For example, the main information network is Gigabit Ethernet using unmanaged switches for all the different devices to communicate with each other. On the lower level, our propulsion network for the e-motors, controllers and batteries is all CAN, with dual redundant buses between each device. “We maintain clearly defined layers between networks, from the lower-level ‘action’ system networks using Wago PLCs from RS Automotive, Piktronik microcontrollers, and similar, to the higher- February/March 2022 | Unmanned Systems Technology Dossier | Mayflower Autonomous Ship Our system allows us to be pretty agnostic in terms of the CPUs and GPUs we use, but we do tend towards having a lot of small ones The lower-level networks use PLCs from RS Automotive and microcontrollers from Piktronik (pictured), while the higher-level network uses Nvidia Jetson AGXs and some other systems