Transmission of images by unmanned underwater vehicles

Abstract

As an acoustic communications medium, water is characterized by frequency dependent attenuation, short range, very low bandwidth, scattering, and multi-path. It is generally difficult to acoustically communicate even terse messages underwater much less images. For the naval mine counter-measures mission, there is value in transmitting images of mine-like objects, acquired by side-scan sonar on-board unmanned underwater vehicles, to the above-water operator for review. The contribution of this paper is a methodology and implementation, based on vector quantization, to compress and transmit snippets of side-scan sonar images from underway unmanned underwater vehicles to an operator. The work has been validated through controlled indoor tank tests and several at-sea trials. The fidelity of the received images is such that trained operators can recognize targets in the received images as well as they would have in the original images. Future work investigates machine learning to improve the compression basis and psycho-visual studies for the specialized skill of feature recognition in sonar images.

Appendix

1.1 Implementation as ROS nodes

ROS (robotic operating system) is a widely supported open source middleware for robotic systems (Purvis 2017). It provides operating system services, including hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management. It also provides tools and libraries to build, write, and run code across multiple platforms. It is light weight enough that it is widely applied in embedded systems. ROS works as a publish-subscribe architecture.

ROS is used by Defence R&D Canada (DRDC) as a middleware for its IVER3 UUVs’ on-board autonomy. Implementation of the compression and transmit algorithm as ROS nodes facilitates rapid integration into this autonomy.

Fig. 16

Interconnection of nodes on the transmit (UUV) unit

There are nodes on the transmit (UUV) side and the receive (operator) side. On the transmit (UUV) side, the compression algorithm consists of 3 ROS nodes described next and illustrated as a ROS rqt_graph in Fig. 16.

• talker Tasked with publishing the path of the images to compress on the dedicated topic imgToCompress. Initially, it simulated the ATD algorithm detecting MLO images from the sonar data stream. Later, it was directly integrated with the ATD

• compressor Subscribes to the topic imgToCompress. Each time it receives a new image path it compresses the image and publishes the encoded image on the topic imgToDecompress.

• uuvModem This node subscribes to the topic imgToDecompress. It is connected to the acoustic modem through a serial port. For each encoded image it receives, it sends it through the underwater acoustic link using the appropriate messages.

Fig. 17

Interconnection of nodes on the receive (operator) unit

Fig. 18

Example of a message in an acoustic packet as formed by ModemUUV node

On the receive (operator) side (Fig. 17) are two nodes:

• opModem This node is connected to the receiving acoustic modem through a serial port. It ‘listens’ to all messages sent by the UUV’s modem to find the packet that contains the encoded image. When that message is found, it extracts the content of the message and publishes it on the topic imgToDecompress.

• decompressor This node subscribes to the topic imgToDecompress and when a new encoded image is received, it decodes it and saves the reconstructed image to the / out folder.

1.2 Underwater acoustic communications

The acoustic modems can transmit/receive at several discrete rates that vary with packet size. For the initial in-laboratory tests, rate 4 (Table 1) was chosen so an encoded image could fit into the minimum number of packets of one frame each.This makes it easier to perform the nodes’ algorithmic proof-of-principle tests at the higher risk of losing packets. Losing the occasional packet was not a primary concern for these tests. Packet loss will be addressed in the at-sea tests. The proof-of -principle tests were performed in an indoor water tank where the transmit and receive acoustic modems were 2–3 m apart which limits packet loss. The final at-sea implementation will be performed at rate 1 which is more reliable albeit at a cost of smaller packets which means an image would be transmitted over multiple frames. This will be explained in a later section. The maximum size of a frame at rate 4, is 256 bytes so an encoded image could be transmitted over two packets. This means half of one encoded image, at a time, would be published on the topic imgToDecompress. As shown in Fig. 18, the message published contains a header with the first character identifying whether the packet contains the top or bottom half of an image followed by the image identifier coded on four characters to recognize the origin of the half image. The rest of the message is half of the encoded image.

The uuvModem node is connected to the acoustic modem through a serial port, which was configured in write-only mode. At initialization, it gives the acoustic modem an identifier to send messages in the later stages. The syntax to set the identifier to ‘2’ is:

$$\begin{aligned} {\$}{\mathrm{CCCFG, SRC}}, 2\backslash {\mathrm{r}}\backslash {\mathrm{n}} . \end{aligned}$$

(1)

Then, when a message is published on the topic it writes the following instruction to the serial port:

$$\begin{aligned} {\$}{\mathrm{CCCYC,0,2,1,4,0,1}}\backslash {\mathrm{r}}\backslash {\mathrm{n}} . \end{aligned}$$

(2)

This informs the acoustic modem that a packet will be sent from modem number 2 to modem number 1 with acoustic modem rate 4 containing 1 frame. The modem then replies with a query for the packet to send with:

(3)

The user then provides the hex-encoded message to the modem:

(4)

On the operator side (Fig. 17), the ModemOp node configures the connection with the modem through the serial port to read and write mode. At initialization of the node, it will set the identifier for the operator’s modem to ‘1’ using a command similar to (1) above. Then, the node listens to the modem output through the serial port. If it reads a CARXD message it means a packet was received. The content of that packet is read and published on the topic imgToDecompress.

The decompressor node is subscribing (listening) to the topic imgToDecompress. When a message is published on that topic, this node will identify (1) whether it is for the top or bottom half of an image and (2) its unique identifier from the message header. If it previously received the other half of the image, it will concatenate the two and decompress the image using functions from the VQScheme class. But, if the other half came from a different image, then the older packet will be decompressed after zero padding its missing half. The last packet received will be stored to wait for its other half for decompression. If no other half was received, the node will wait for the next packet for decompression.