Communications Architecture of the Liquid Robotics Wave Glider

Communications Architecture of the Liquid Robotics Wave Glider Robert A. Olson* *Liquid Robotics, Inc., Sunnyvale, CA 94089 USA (Tel: 408-636-4235; e-mail: [email protected])

Abstract: This paper describes the data communications architecture for the Liquid Robotics Wave Glider and some of the motivations for the design as well as how the architecture evolved over time. Keywords: Autonomous surface vehicles, communication channels, communication networks, Wave Glider. 1. INTRODUCTION The Liquid Robotics Inc. (LRI) Wave Glider is a wave-andsolar powered autonomous surface vehicle (ASV) designed for long duration open ocean deployment. The Wave Glider is used for a wide variety of applications, including environmental monitoring, acoustic data collection, communications gateway for subsurface systems, meteorological observation, fisheries management and more. Satisfying the needs of the many mission profiles, sensor suites and customer types has resulted in a rich and very flexible architecture for internal, Wave Glider-to-operator and Wave Glider-to-Wave Glider communications. This paper describes some of those mission requirements and how we addressed them. It concludes with some observations about remaining challenges. 2. THE WAVE GLIDER As shown in Figure 1, a Wave Glider is a two part vehicle with an optional towfish. The Glider (subsurface wave propulsion unit) provides thrust by converting the up and down motion of the Float into forward thrust. An electrically operated rudder on the Glider provides steering authority. The Glider is connected to the Float via an umbilical that provides a mechanical and electrical connection between the two. The towfish shown in the illustration is optional. If present, it communicates through the umbilical with Floatbased electronics modules. The Float hosts a core electronics module, solar power panels, optional mission specific payloads and an antenna deck. The Float itself is a fiberglass body covering foam. It has one dedicated bay for the core electronics module and two customer-specific payload bays.

Fig. 1. Wave Glider configured for oil and gas application The core electronics module manages basic system services, including navigation, route management, power, safety and an Iridium 9602 Short Burst Data modem. The processor for the core module is an Atmel ATMega microcontroller running a custom control system. Custom logic manages batteries, GPS and similar services. The core electronics module consumes 1.5 to 3.5 watts depending on telemetry rates and how actively navigation and safety related sensors are used. The core electronics module is not user programmable. Its feature set is limited to those required to help the Wave Glider survive under dire power conditions. With a few exceptions, sensors are managed by C++, Java or Lua software running on a Sensor Management Computer (SMC) which is co-located with customer electronics in separate payload bays. The processor for the SMC is a TI DM3730 running OpenEmbedded Linux. It provides eight UARTs, Ethernet, USB 2.0, CANBUS, four switched 13.4 volt power connections and a microSD card-based file system. Excluding Ethernet and USB, the SMC consumes between 0.5 and 2 watts depending on workload. Obviously, sensors and other attached devices are incremental to that

power consumption. The SMC is intended to be user programmable and supports the usual set of programming languages and libraries. An important consideration is that, by policy, the SMC can be turned off if dictated by power considerations. 2. TYPICAL MISSION TYPES The typical mission parameters drive requirements for bandwidth, response time, and power budget and constrain the available communications transports. Very broadly, missions can be grouped into four categories: Survey – the use of one or more Wave Gliders in a coordinated fashion to intensively study a particular patch of ocean. Surveys sometimes are done in combination with other assets such as aircraft, AUVs and manned surface craft. Examples include fisheries surveys, chemical and biological activity surveys and bathymetry. Monitoring for events – the detection and reporting of an anomalous situation in real-time, such as the detection of a ship, a tsunami warning from a bottom sensor or a patch of oil on the surface. Surveys (described above) often include event detection via on-board data analysis to classify events as that allows the investigator to alter the survey plan to examine dynamic changes. A key design requirement is that users be able to implement mission-specific autonomous behaviors on board (following a front-seat/back-seat autonomy model), on shore, or even in another Wave Glider or autonomous vehicle. An important example of event reporting is the delivery of ship Automatic Identification System (AIS) transponder information and environmental data from the Wave Glider to the collision avoidance software in support of autonomous evasion. Buoy replacement – An important use for the Wave Glider is as an anchorless buoy replacement. Many customers experience a dramatic reduction in logistics costs since launch and recovery can be done from low-cost near shore assets, including piers. Examples include service as weather buoys and radio communications relays.

requirements imposed by high value sensor suites and mission types. 3.1 Range While our ability to operate far offshore for long periods of time is a unique attribute of the Wave Glider, the system also often is used in littoral applications. Examples include extensive support for oil and gas applications in the Gulf of Mexico, North Sea and other offshore oil locations. Much fisheries support happens within a few miles of the coast. This led to a requirement for on-demand cellular data network support. Figure 2 shows the coverage map of the Gulf of Mexico for Broadpoint, LLC as an example.

Fig. 2 Broadpoint LLC GoM cellular coverage map An interesting requirement is the ability to communicate in a local area network at sea. This is useful in flotilla and fleet operations involving multiple coordinated Wave Gliders and on occasion manned surface vessels. Our experiments with 802.11 at 5.8 GHz on a 2 meter mast resulted in consistent data rates above 25Mbps at a range of 1.5km. We plan to test designs that may allow similar performance at much greater range. 3.2 Latency (timeliness of data delivery)

Communications gateway – Since the Wave Glider can have both a surface and sub-surface communications expression, it is natural for it to serve as a relay between acoustic communications underwater and radio communications on the surface. Many customers take advantage of the mobility of the Wave Glider to service multiple undersea devices. Examples include AUV communications and seafloormounted oil and gas instrumentation.

We identified four types of latency requirements for our applications:

3. DERIVED REQUIREMENTS

Opportunistic – There are data collection operations where the size of the data block to be transferred argues for low cost or high bandwidth communications. These should be queued until such a network connection becomes available, for example by swimming in range of a cellular data base station.

The initial implementation of the Wave Glider focused on long duration operation far offshore with very conservative power management. That led to a communications design reliant on the Iridium Short Burst Data satellite transport. Experience with the platform demonstrated that we needed to broaden the suite of communications options to meet the

Immediate – Such as ship detections in a marine protected area. Scheduled – These can be small uploads such as vehicle engineering data or larger batches, such as bathymetry or ADCP profiles.

Streaming – Applications such as security cameras and certain sensor suites work best if the data can be streamed to shore for immediate operator interpretation.

3.3 Service multiple concurrent clients The Wave Glider can carry multiple sensor suites and operate missions for multiple independent users. The communications architecture must allow those users to share the communications infrastructure with a minimum of coordination. In particular, piloting and customer applications can communicate over the same communications channels. However, there is no requirement that they share channels if there is an operational reason to keep them separate. 3.4 Power

Data as the sole communications channel for an operational vehicle. Commands are sent from the Wave Glider Management System (WGMS), the native piloting interface, to the Packet Reflector. The Packet Reflector manages the details of the messaging protocol with the Wave Glider. For example, encryption and decryption happens in the Packet Reflector using a dynamically generated session key. Commands are processed by software in the Wave Glider’s C&C module. Telemetry and results of commands are returned via Iridium to the Packet Reflector, which handles the protocol and forwards the contents of the messages to the WGMS kernel processes.

As with all long-duration vehicles, it is important to carefully manage power consumption. Radios, especially high bandwidth communications, can consume more power than the sensor suites they support. This led to a requirement that we be able to duty cycle communications hardware. The communications architecture assumes that communications are generally initiated from the Wave Glider, as the shore cannot assume that the Wave Glider’s radio is on. Another derived requirement is that the Wave Glider be able to receive commands from shore even when the available power is very low or the vehicle is far from shore. In practice this has meant that Iridium SBD is available as a backup communications channel on all Wave Gliders. 3.5 Privacy, Security and Authentication The Wave Glider communicates over the public Internet, with multiple concurrent data streams sharing the communications channels. We require that all such communications be authenticated and encrypted. 3.6 Modularity and Generality Customers have expressed interest in a wide variety of communications technologies, including Iridium SBD, Iridium RUDICS, cellular data, 802.11, BGAN, wired Ethernet (for shore-based applications) and more. We have tried to make the details of the communications channel transparent to most users, although of course there are times when the differences are important. The interfaces are also designed to allow non-LRI developers to integrate their own communications technologies. 4. COMMUNICATIONS ARCHITECTURE The communications architecture is best understood through stepwise refinement. This description roughly parallels the historical development of the capability. Many details have been left out for clarity of exposition. 4.1 Basic Command and Control As illustrated in Figure 3, Basic Command and Control Architecture, the simplest version of the Wave Glider communications scheme depends on Iridium Short Burst

Fig. 3. Basic Command and Control Architecture The messaging protocol itself follows a fairly conventional stateless design and assumes that commands and responses may be lost, delayed or processed out of order. With a few exceptions, individual commands, responses and telemetry are constrained to fit in a single Iridium SBD packet. 4.2 Payload-based Autonomy The next evolutionary step was to give payloads the ability to control the C&C. This allows a payload based application the ability to implement application-specific behaviors – i.e., autonomous actions based on the application’s sensor data and priorities – following the front-seat/back-seat autonomy model. See Figure 4, Basic Architecture Extended for Payload Autonomy. The C&C cycles through the various payload and communications interfaces looking for commands. When it receives a command, it executes it and sends the response to the same interface. Any payload can send essentially all of the commands available to shore-based software. Payloads also can request status information from the C&C, such as power availability, and can send messages to other payloads.

4.4 Merged and Generalized Communications The final step was to generalize the communications management software on the payload computer such that the same communications path could be used for communicating with a Packet Reflector and with software running on other computers, as illustrated in Figure 6. An example use case is the delivery of files or streaming webcam data over a TCP/IP link to a customer’s server while simultaneously handling commands and telemetry between the C&C and WGMS.

Fig. 4. Basic Architecture Extended for Payload Autonomy 4.3 Alternate Communications Channels The third step, illustrated in Figure 5, was to allow software running in a payload to serve as an intermediary between a Packet Reflector and a C&C. The LRI Sensor Management Computer (SMC) is a standard ARM-based Linux computer and consequently has available to it a large library of drivers and communications software. We created a wrapper protocol for messages between the payload and the Packet Reflector, which we call the Virtual Relay Protocol. The effect of the protocol is to encapsulate the details of the communications channel, such as providing authentication to a cellular phone service provider. The SMC-resident software uses the same interface with the C&C as was used for payload-based autonomy. That is, the C&C is indifferent to whether the decision that led to the command(s) was made on-shore or on-board.

Fig. 6. Generalized Communications Architecture It should be noted that this architecture is not limited to LRIsupplied payload computers nor to just the listed communications channels. For example, we use the same mechanism with wired Ethernet when doing on-shore development. In addition, customers have developed their own shore-based piloting systems. It should be a straight-forward software project to extend them to operate through the Virtual Relay protocol as well. 4.5 Future Considerations

Fig. 5. Generalized C&C Communications Architecture Note that a side effect of this design is that commands also can be sent over a local area network that might include other Wave Gliders or other autonomous systems. It would be straightforward to support “back seat drivers” using acoustic and other communications technologies with this model.

A capability we hope to add is to give an application a way to delegate the choice of communications channels to a communications manager that will follow criteria set by the application. For example, something like “connect if a cellular data connection using my preferred carrier is available, but not otherwise” would allow relatively low cost upload of bulk data on an opportunistic basis. Similarly, the communications manager could post an event when a connection is made over a particular transport, leaving it to the recipients of the event to decide if they want to use that channel. A challenge posed by our communications architecture is that the C&C can be commanded from multiple interfaces which may themselves not coordinate. In this architecture, the C&C executes the commands presented to it on its interfaces. There is no guaranteed sequence to the execution order of the commands, and no interface has precedence. The only

guarantee is that a command will be completed before the next command is accepted. A specific consequence is that the shore-side piloting system may have an incomplete view of the state of the C&C. We think that in practice this will not be a problem if pilots are aware that the Wave Glider may take autonomous action. AUV operators are already familiar with this problem. 5. CONCLUSION Although we have not fully exercised all the possible variants of the Wave Glider communications architecture, in general we are pleased by the ease with which we have been able to add support for new communications technologies. Abstracting away most of the details simplifies the development of novel applications. A specific benefit is that some autonomy capabilities can be developed on shore where there is a better debugging environment and then be migrated to on-board operation, with minimal changes. 6. ACKNOWLEDGEMENTS Many people contributed to the design of the Wave Glider communications architecture over several years. Key designers included Graham Hine, Mike Cookson, Jim Kirklin, Ehud Pardo, David Walker, and many more.