AUVish: An Application-Based Language for Cooperating ... - CiteSeerX

AUVish: An Application-Based Language for Cooperating AUVs Andrew Rajala, Michael O’Rourke, Dean B. Edwards Center for Intelligent Systems Research, University of Idaho, Moscow, ID 83844-1024 Abstract - AUVish is an application-based language for Autonomous Underwater Vehicles (AUVs), designed to facilitate cooperative behaviors needed for complete coverage in underwater mine countermeasures (MCM). Initially, AUVish was developed to support the computer simulation of replacing lost vehicles. Additional cooperative tasks were added to the simulations and AUVish was modified to handle the complications that arose. The syntax, semantics, and pragmatics of AUVish are explored, along with the processing and application of AUVish messages. A comparison with existing AUV languages concludes the essay.

as the broadcasts. Each vehicle sends a two second navigation ping, and vehicles cannot communicate during these pings. AUVish is based on different aspects of existing AUV languages, and it is designed specifically for the problem of maintaining complete coverage in underwater MCM. The AUV formation, shown in Fig 1, engages in underwater MCM by searching for mines in a lawnmower search pattern. A hierarchical command and control structure is used, where the leader receives information from the swimmers and followers and sends out commands.

I. INTRODUCTION Follower 1 (F1)

Swimmer 1 (S1) Swimmer 2 (S2)

Fig. 1: AUV Formation in Underwater MCM AUVish was first developed to handle the problem of replacing a lost vehicle [2]. If an AUV is lost and the formation does not compensate, there will be gaps in the coverage. The Navy requires complete coverage and the gaps in Fig. 2would need to be covered in some fashion, perhaps by a second group of AUVs. Gap 1000

950

900

y position [yd]

AUVish is a language developed for cooperating AUVs in underwater MCM that involve locating, classifying, and neutralizing underwater mines. The motivation for cooperating AUVs is the U.S. Navy’s desire for complete inspection of large areas for mines. To cover large areas in a realistic time, multiple vehicles will need to be deployed. Given the dynamic and unpredictable nature of the ocean environment, problems can and do arise that cause gaps in the coverage, and cooperation among the formation’s AUVs is needed to handle these problems. For AUVs to cooperate, they must share information and make requests, and this requires a communication system and a language. On the surface, AUVs can use radio frequency (RF), but are limited to acoustic communication while underwater. Several languages have been developed for cooperating AUVs, and these are generally command and control languages designed to respect the limited bandwidth of underwater communication. Cooperating AUVs are communicative agents that must deal with high error rates, limited bandwidth, and a shared resource. The underwater channel is notoriously bad for communication, with propagation effects such as ray bending and multipath. Data rates are restricted because acoustic energy is absorbed by water as the frequency increases. The current approach to error in underwater communication involves building redundancy into the code and large amounts of error correction processing into the receiving end [1]. We are currently using the Woods Hole Oceanographic Institute (WHOI) Acoustic Micro Modem on the University of Idaho Low Cost Vehicle Platform. With the WHOI modem, vehicles transmissions are restricted because the underwater channel is shared among all broadcasts and navigation pings. The modems operate on the same frequency since many of the messages are intended for all the vehicles in the formation; the possibility of interference prevents vehicles from transmitting at the same time. In addition, the WHOI modem is used for active LBL navigation, which operates on the same frequency

Leader (L)

850

Gaps

800

750

700

650

0

100

200

300

400 500 x position [yd]

600

700

800

900

Fig. 2: Gaps in search pattern caused a disabled AUV New problems were considered, and AUVish was modified to handle them. Cooperative behaviors investigated include replacing a lost vehicle [2], dealing with lost communication [3], inspecting mine like objects (MLOs) [4], and building a map into each of the vehicles [4]. This paper presents the language developed to accomplish these tasks and explains the syntax, semantics, and pragmatics of AUVish. II. BACKGROUND Several groups have worked on or are currently working on

AUV languages for AUV-operator and AUV-AUV communication, and the U.S. Navy has made a push to develop a universal AUV language so that all the vehicles in a fleet can communicate with each other. This section supplies an extensive overview of existing AUV languages. The Marine Systems Engineering Laboratory (MSEL) was one of the first groups, designing Conceptual Language for AUVs (COLA) for the Experimental Autonomous Vehicle (EAVE) system. COLA uses the natural language concepts syntax, semantics, and speech acts to deal with the limitations of underwater communication. Messages are treated as speech acts, performed in support of the sender’s goals. Speech acts are used to classify message types since they indicate sender intention and appropriate response. Request and Inform are the two basic speech acts [5]. Syntax is used to conserve bandwidth and support error detection. Bandwidth is conserved by embedding information in message structure. If a message contains an error, it will have an illegal structure and the parse will fail. The semantics consist in look-up rules involving the vehicle’s lexicon. The semantics are also used to detect incorrect messages that have legal syntactic structures. Errors are found by comparing message values with constraints placed on the vehicle [6]. The Ocean SAmpling Mobile Network (SAMON) is an ONR-sponsored project investigating heterogeneous AUV missions and advanced autonomous agent design. The SAMON project’s AUV language has been modified over the years and given several different titles: Generic Behavior Message Passing Language (GBML), Common Control Language (CCL), and Robotalk. GBML was the first, and it supplied a framework for a common language allowing cooperation of heterogeneous AUVs. Some of the guidelines set forth were arbitrary execution of behaviors, extensibility to new vehicles, and allowance for additional messages [7]. CCL emerge as a tactical command and control language for multi-vehicle, semi-autonomous data collection systems. CCL has a hierarchical command structure with a tactical coordinator (TC), supervisor AUVs, and subordinates. Mission directives are initialized in CCL and expressed as scripts for the TC. The scripts may be initiated by a human operator or a dynamic event and transmitted down the chain of command to the supervisor AUVs. For the subordinates, the messages are broken into primitive behaviors and each behavior invokes a strict protocol. The subordinates collect information and pass it back up the chain of command [8]. Emerging from CCL, Robotalk moves from strict hierarchy to dynamic organization. In dynamic organization, vehicles change the communication structure in response to environmental changes and uncontrollable events. A group structure is used to allow dynamic clustering of devices that can be modified during the run through group declarations [9]. Compact Control Language is a communication protocol designed to allow multiple AUVs to communicate with a central point and each other. This protocol is designed around the WHOI Utility Acoustic Modem and the WHOI Micro Modem. It was developed for low bandwidth acoustic communication and all the messages fit into 32-byte packets.

The language does not have error detection because it is handled in the transport layer of the WHOI acoustic modem, and there is no slot for the source and destination since it is available separately from the data content [10]. The Solar AUV project has developed another language called Common Control Language (CCL). This CCL allows AUVs and the operator to communicate a common set of commands as well as information for monitoring and control. It is constrained around a few bits, but unlike the Compact Control Language, it is not restricted to a packet size. CCL is behavior-based, so the directives are structured to express the basic AUV behaviors. When the CCL interpreter receives a message, the planner uses the kΩ-optimization search method to look for the optimal sequence of basic behaviors to accomplish the received tasks, and the vehicle chooses how the behaviors are executed (e.g., parallel, sequential, general choice, cost choice) [11]. III. SIMULATION The Autonomous Littoral Warfare Systems EvaluatorMonte Carlo (ALWSE-MC) is used to simulate the underwater, AUV environment. ALWSE-MC is a kinematic, statistical AUV mission simulator developed and maintained by the Naval Surface Warfare Center in Panama City. The AUVs are simulated by point masses with defined sensor packages. For the simulations, the logic for generating and processing messages was developed for the leader, swimmers, and followers. This logic is incorporated through Matlab scripts that run every second. Communication is modeled in ALWSE-MC with an internal communication module. Based on the size of the message, the module calculates the transmission and travel time; and then waits the calculated time before putting the message into the receiving vehicles’ inbox. This model assumes (a) turn taking, where no two vehicles can talk at the same time, (b) use of a spherical transducer, enabling all vehicles to hear communicated messages, and (c) use of a WHOI acoustic Micro Modem. A 32-byte message packet was used because at the time it was the smallest message packet available on the WHOI Acoustic Micro Modem. The communication module calculates 3.2s for transmission and .04s for travel. Since the Matlab scripts run every second, the AUVs communicate on 5s intervals. This had the incoming message placed in the receiving vehicle’s inbox at 4 seconds, and gave the receiving vehicle one more second to process the message before generating its own message. Therefore, the time between transmissions for a single vehicle is 5s*(number of vehicles). Work has begun using the 13-bit micro packet available on the modem to reduce the time delay between vehicle transmissions. IV. LANGUAGE AUVish was originally developed with the strict syntax of COLA for message parsing and the communication structure of SAMON-CCL. It is unique since it is application specific and has been thoroughly simulated. In this section, we develop

the syntax, semantics, and pragmatics of AUVish. We take syntax to concern the well-formed expressions of the language and the rules for combining those expressions, semantics to concern the literal meaning of the expressions regardless of the context in which they are used, and pragmatics to concern the meaning that arises from the combination of the expression produced and the context of that production [12]. A. Syntax The syntax of AUVish is constrained by the physical limitations of our modem. All messages are the same size and consist of six slots. The first two slots of the message identify the transmitting vehicle. The third slot identifies the message type, and the last three are for message content. The syntactic structure of the language, with the six slots, is listed below.

B. Semantics The positional syntax simplifies AUVish semantics considerably. AUVish is not compositional. A given signal will have six parts, and each part is best understood as expressing a proposition; that is, each slot is interpreted as a sentence, implying that the message as a whole is more akin to a paragraph. To illustrate this, we give two examples of a message received and how one would read it. 3 S1 I 0 UnkObj 175 35 “3” – Vehicle 3 is transmitting “S1” – Vehicle 3 is in the Swimmer 1 position “I” – This message is an Inform “0” – It is intended for all the vehicles in the formation “UnkObj” – Vehicle 3 has found an Unknown Object (Possible Mine). “175,035” – The Unknown Object is in cell (175,35)

1. Transmitting Vehicle Number: Vehicle serial number • 1-10 2. Transmitting Vehicle Status: Vehicle’s formation position • Leader • Swimmer 1-10 • Follower 1-10 • Deactivated 3. Message Type: Indicates the type of message to come. This is used for sorting messages and error detection. • Request • Inform 4. Message Target: Vehicle number of the intended recipient of the message. If a zero is used, then the message is intended for all the vehicles in the formation. • 0-10 5. Message: Can be a request or inform. A request requires an action by the receiving vehicle and an inform simply shares information. The superscript is used to refer to the message latter in the paper and is not part of the message. • Requests: Request Action: Replace Swimmer a Reconfigure Pattern b Become Follower c Become Swimmer d Inspect Unknown Object e Request Information: Request Vehicle Position f

C. Pragmatics To date, we have investigated two pragmatic aspects of AUVish. First, given that each slot corresponds to a sentence, each message comprises several speech acts. Each slot corresponds to a separate speech act: slot five can be a request or inform, while the other slots correspond to informs. These different speech acts, however, combine to form two larger communicative acts. In particular, any given message is one of two types, classified according to these larger communicative acts: (Inform[Transmitting Vehicle Status], Inform[New or Requested Information]) or (Inform[Transmitting Vehicle Status], Request[Action or Information]). The first illustration in the Semantics section is an instance of the former and the second an instance of the latter.

• Inform: Inform Requested Information: Vehicle is in Swimmer g Vehicle is in Follower h Vehicle is Disabled i Inform New Information: Unknown Object j Object is a Rock k Object is a Mine l Vehicle is at Cell m 6. Additional Information: This slot contains a pair of numbers. There are five possibilities depending on the content of the preceding message. Zero means the number is not used. • : a • : b, c, d, g, h • : f • : e, j, k, l, m • : i

• Inform[Transmitting Vehicle Status]: This communicative act is associated with the first two slots and accomplishes three tasks: (1) it informs other vehicles that the transmitting vehicle is still there via its vehicle number, (2) it indicates what formation position the vehicle occupies, and (3) it provides feedback on whether or not a task is executed. The formation must be able to tell when a vehicle is lost if they are to replace it. This is currently done by requiring periodic updates from all vehicles. Each vehicle stores the formation positions occupied by the other vehicles in memory. If the formation does not receive updates from a vehicle, the leader infers that the vehicle is lost and replaces it by sending another AUV to the formation position occupied by the lost vehicle. The leader does not know if the message was received and executed until the dispatched vehicle broadcasts its formation position; thus, this speech act

1 L R 6 RepSwm 002 125 “1” – Vehicle 1 is transmitting “L” – Vehicle 1 is in the Leader position “R” – This message is a Request “6” – It is intended for vehicle 6 “RepSwm” – Vehicle 6 replace a Swimmer “002,125” – Swimmer 2 is to be replaced, proceed to waypoint 125

provides feedback to the leader about whether the change of position request was successfully executed. • Inform[New Information]: This communicative act is associated with the third, fourth, fifth, and sixth slots and supplies mission critical information to other vehicles, including mine locations and coverage areas. This type of message can come from any vehicle in the formation. • Inform[Requested Information]: This is a response by the leader to a request for information associated with the third through sixth slots. Currently, this focuses on the formation position of a vehicle. • Request[Information]: This is a request to a vehicle for specific information, delivered via the third through sixth slots. A vehicle generates this message if it receives a message that does not agree with the information in its memory. Presently, only the swimmers and followers request information from the leader. • Request[Action]: Also associated with the third through sixth slots, this speech act requests that the target vehicle perform a certain action. At the moment, only the leader requests an action from another vehicle. Second, several contextual factors affect the pragmatics of the messages, viz., the formation position of the receiving vehicle, vehicle memory, and the current situation. Communicative success depends on sender/receiver synchronization of these factors. If they are not synchronized, the intended result of the message will not be achieved; however, when this sort of failure occurs, the language and vehicle logics trigger a dialogue designed to synchronize all affected AUVs.

The message’s second communicative act is then processed. The language has been designed so that the message slot (i.e., the fifth slot) determines which module the vehicle runs. In each script, the leader makes decisions, updates its memory, and generates outgoing commands. When the leader gets to the end, it loops back around and performs the same operation for each vehicle in the formation. Enter From Leader Logic

Check Inbox For all the vehicles

If update clock