A Control System for OFDM Networked Autonomous Underwater Vehicles

Transcription

1 A Control System for OFDM Networked Autonomous Underwater Vehicles Michael Zuba, Carlos Villa, Alexandria Byrd, Chris Fedge,SonLe, Haining Mo, Zheng Peng, Jiaxing Che and Jun-Hong Cui Computer Science and Engineering Department, University of Connecticut, Storrs, Connecticut Mechanical Engineering Department, University of Connecticut, Storrs, Connecticut {zuba, carlos.villa, alexandria.byrd, chris.fedge, sonle, haining.mo, zhengpeng, jiaxing.che, Abstract Autonomous Underwater Vehicle (AUV) networks are becoming increasingly popular in scientific, commercial, and military applications. AUVs are used in undersea exploration and environmental monitoring for tasks such as detection of oilfields and marine life, distributed tactical surveillance for offshore and seaport defense and mine reconnaissance. AUV networks are also becoming an important interest in an effort to enhance the capabilities of underwater sensor networks (UWSNs). In this paper we propose a control system for networked autonomous underwater vehicles that includes both hardware and software modules. The system integrates various communication and sensor devices, such as an IMU and an OFDM acoustic modem and contains a graphical user interface for optional manual remote control and monitoring of AUVs in the network from a base station. Index Terms Autonomous Underwater Vehicles, Underwater Sensor Networks, Control System, OFDM from the ability to have large amounts of small sensors that are able to collectively cooperate, by using acoustic communication, to achieve similar tasks as AUVs [1]. However, these sensors can be computationally limited and have even more rigid power constraints. When compared with these sensors, AUVs are more powerful as they can provide significantly higher computational power and communication range. AUVs can be integrated with UWSNs to form hybrid networks and act as gateway nodes, which can relay data faster and farther, or as data mules to alleviate some of the burdens on smaller constrained sensors. A hybrid network architecture can be seen in Figure 1. However, most AUVs available today are not ready to be integrated into networks or are being built to consider networking operations. I. INTRODUCTION Autonomous Underwater Vehicles (AUVs) belong to a group of unmanned robots that are used to perform a variety of underwater tasks focused on surveying and monitoring of underwater environments for scientific exploration, commercial exploitation, and attack protection. Specific applications include sea life detection, offshore oil platform monitoring, sea floor mapping, deep sea archeology and mine counter measures [1] [6]. AUVs are generally categorized by the following technologies: autonomy, energy, navigation, sensors and communication. The ideas for these machines came from the need for more efficient and cost effective ways to survey and monitor the ocean other than direct use of ships or submarines. For instance, AUVs do not have to be manually navigated which greatly improves their usability and it is more cost effective to deploy a few smaller AUVs than to deploy larger ships. Additionally, AUVs have their own internal power source that allows them to work independently of other base stations or ships. Autonomous systems are becoming more feasible and practical as technology advances. This has allowed researchers to begin linking individual vehicles together using acoustic communication [7] to perform collaborative tasks such as path planning and sea floor mapping [8]. AUV networks are also becoming increasingly important in an effort to enhance the capabilities of underwater sensor networks (UWSNs). UWSNs are large-scale underwater networks, whose strength comes Fig. 1. Hybrid UWSN and AUV Architecture In this paper we will discuss our command and control system (CCS) that is being designed for an autonomous underwater vehicle. The AUV, that will incorporate our CCS, is being developed in parallel with the goals of being low cost and with emphasis on networking operations. Our system consists of both hardware and software modules that are integrated together to provide manual and autonomous control. The focus of the software modules is to interface with the mechanical systems of the AUV and to facilitate networking operations and integration into UWSN architectures. Our CCS consists of a main control loop, stabilization algorithms, a graphical user interface and a underwater networking protocol stack that makes use of an included orthogonal frequency-division /12/$ IEEE

2 multiplexing (OFDM) acoustic modem. The control system software is developed in an embedded Linux environment using a microcontroller and a suite of sensors and devices. This control system will be responsible for controlling and monitoring all major mechanical and electrical subsystems. It will monitor and interpret outputs from the attached sensors, such as IMU and side scan sonar devices, communication and network devices and command the AUV to act accordingly and make use of team formation techniques. The rest of the paper is organized as follows. Section II will present related work in AUV design and control systems. Section III will discuss the general design of our control system and the details regarding the hardware and software modules. Lastly, Section V will present our conclusions and future work. II. RELATED WORK AUVs have been around for quite some time, dating back to the Special Purpose Underwater Research Vehicle (SPURV) which was developed in 1957 at the University of Washington [9]. In recent years these vehicles have begun to surge in complexity and technological advancements. Many vehicle designs exist; from thruster controlled to buoyancy driven and can be equipped with a multitude of sensors that include side scan sonar, acoustic modems and hydrophone arrays. In this section we will introduce a few AUV designs and control schemes. In [10] the authors developed an adaptable software framework to control underwater vehicles. This framework consists of support for modular control systems, a complete abstraction layer, independent control systems for different vehicles, a graphical user interface and data structures for passing messages in the control system. The control system incorporates a controller configuration message that helps setup and pass the necessary information to the low level controller of the underwater vehicle. This allows for automatic and operator manipulation of parameters such as course, pitch, depth and thrusters. The user interface is used to facilitate mission planning and display important sensor data. In [11] the authors present the design and evaluation of the REMUS AUV, which is widely used today by researchers. The control system is based on the PC-104 form factor of the IBM-PC and can be connected to laptop computers for system configuration. Additionally, the REMUS makes use of long and ultra-short baseline acoustic navigation, bottom lock doppler navigation and GPS. A planar receiving array consisting of four wideband hydrophones is used to receive the acoustic signals from seafloor transponders or docking stations to help navigate the vehicle. Using these signals the vehicle will dead reckon between transponders. A user can make use of a graphical user interface to adjust parameters on the vehicle when it is docked in a station. In [12] the authors develop a control system for an AUV based on a PC-104 embedded computer. The system is partitioned into the following subsystems: navigation, propulsion, safety and data acquisition. The control unit, an Aewin PC104+, uses a AMD Geode LX800, 500MHz CPU and has low energy consumption. The operating system being used is Windows XP and the data storage system is flash. The navigation system is based on GPS, an inclinometer and a digital compass. A radio link is also used to establish real-time data collection and monitoring from a base station when the vehicle surfaces. A graphical user interface is also developed to read and write parameters from various sensors integrated with the control system. III. CONTROL SYSTEM The control system will be placed into a custom built AUV that is currently being developed in parallel. A current design can be seen in Figure 2. Fig. 2. Mock up of Autonomous Underwater Vehicle Internal Equipment The control system is the brains of our AUV. It will read the sensors of the vehicle, monitor the OFDM based acoustic modem for external communication from other AUVs or the human monitoring station, determine the appropriate actions based on this information and send commands to the actuators of the vehicle. The control system is required to provide the overall orchestration of the vehicle, determining every action. A. System Architecture The whole system will operate in a closed loop. The main control loop is written in C and runs in an Embedded Linux Fig. 3. System Architecture

3 environment on a Gumstix Verdex Pro COM microcontroller. The system architecture can be seen in Figure 3. First, the system retrieves current sensor data from the on-board sensors, as well as any incoming packets from the acoustic network. Once any commands have been parsed and the sensor data is cleaned up, the inputs are then used to determine what actions the AUV should perform. These are converted into commands for the 32-bit ARM MCU (ETT board) that controls the actuators. In addition, any information that needs to sent over the acoustic communication network is prepared for transmission. Once this is completed, the commands are sent to the MCU, the information packets are sent across the network and the system polls the sensor data. This process then starts all over again. The AUV s system operation can be broken down into three main activities: Data Acquisition, Action Determination and Output Generation. Due to the nature of the control system environment, it is possible to run these three activities concurrently as three separate processes on top of the Embedded Linux environment. We will process information sent from a navigation sensor, currently a 9 Degrees of Freedom Razor IMU and an OFDM acoustic modem by the use of RS232 ports. An STM32 ARM processor is used to generate the pulse-width modulation (PWM) signal for the motor driver and other actuator. This also communicates with the main controller through RS232. The general component diagram of the control system can be seen in Figure 4, where the ETT board and Gumstix are two types of microcontrollers. 1) Gumstix: In order to build an autonomous networked system that allows each AUV or node to perform tasks efficiently and make smart decisions based on available information we decided to use a Gumstix microcontroller as the brains of the vehicle and control system. The Gumstix Verdex Pro COM is a fifth generation ARM architecture based on Marvell PXA270 with XScale microprocessor core with 64MB RAM, 16MB flash and runs at a frequency of 400MHz. It is a single board embedded system suitable for controlling and allowing autonomous functions of the AUV. The operating system being used on our microcontroller is embedded Linux. This will allow our control system to run advanced algorithms that require more computing power but at a more reduced energy consumption. The Gumstix will perform as the main controller and will run the communication protocol stack [13] and cooperative control algorithms. We interface the Gumstix with the OFDM based acoustic modem and device microcontroller using two RS-232 serial port connections. A mini USB port is also available and used to interface with the inertial measurement unit. 2) Acoustic Modem: An OFDM based acoustic modem is integrated into the AUV. It communications with the main control loop through an RS-232 port with the Gumstix, as mentioned above. The current OFDM modem design is based on a TI DSP board which incorporates both a transmitter and receiver in efforts to support two way communications. The signal bandwidth is 6 khz, where the center frequency can vary depending upon the transducer being used. The effective throughput or data rate is dependent upon the size of the packet Fig. 4. Equipment Interfaces being sent but theoretically, from the modulation and coding point of view, the data rate at the physical layer is 3045 bps. Specific details regarding the acoustic modem, its real-time implementation and experimental results on its effective data rate are provided in [14]. 3) Inertial Measurement Unit: The inertial measurement unit (IMU) being used in the control system is a 9 Degrees of Freedom Razor IMU. This IMU makes use of three separate triple-axis sensors: a ITG-3200 gyroscope, a ADXL345 accelerometer and a HMC5883L magnetometer. The on-board system of the IMU processes the outputs from its sensors and then sends a string of data over the serial port with this information for the main control loop to parse and process. 4) Device Microcontroller: The device microcontroller (MCU) is a 32-bit ARM MCU that handles the communication between the control system and the actuators and other sensors. This communication is also performed by creating a special string using the necessary messages that need to be sent and passing them through the RS-232 connection. The main control loop sends power commands for the actuators to the device MCU and the device MCU sends sensor data and the current actuator power values back to the main control loop. B. Main Control Loop The main control loop works in the following way. The OFDM acoustic modem will receive information from the localization protocol first, which is done using the protocol stack discussed later. This message will be received as a string: ROV Location: (x-cord, Time Sent. Therefore, when the Gumstix receives this string it will parse the string and store the coordinates as integers. Additionally, the acoustic modem is constantly listening for messages and commands from the base station. These messages will be sent in the form of a string and will have a header of A0 which is used to identify the specific AUV that will use the message or command. In the case that a user is trying to move the AUV, the header will be followed by motor values for each

4 individual thruster. These values will be between 0 and 254. The final string for this type of command should look some like the following: A0:254,254,254,254, which means move AUV0 forward, full power to all 4 motors. The Gumstix will parse this string to identify if that specific AUV is required to perform the action. If it is the correct AUV the motor values are stored as unsigned characters such that the MCU can understand the message. Algorithm 1 Pseudo code for the main control loop. while (1) do read(modem) BUFFER if strtok(buffer, : )!=ROV Location then StoreLocation read(modem) BUFFER if strtok(buffer, : )!= A0 then MotorsValues MCU wait(1) read(mcu) BUFFER2 BUFFERS Sensor[0, 1], Motor[0, 1, 2, 3] read(imu) Roll, P itch, Y aw BuildMessage() Message write(modem) Message end if else write(modem) ERROR end if end while After reading in the messages, the Gumstix will write these motor values to the MCU. The MCU will use the motor driver we have developed to convert the message into voltages that are used to power the motors. Once the data is sent and the motors are powered, the MCU will send back a string of information that contains values from attached sensors and motor values. The string will look similar to the following: Sensor1, Sensor2, Motor1, Motor2, Motor3, Motor4. This information is stored in the Gumstix. At this point the Gumstix will read data from the IMU. The IMU will send a string that is ordered in the following way: (yaw, pitch, roll). These values are stored individually, each of type double. Once this process is complete, the Gumstix will create a string in the following order: A0:X, Y, Sensor1, Sensor2, Yaw, Pitch, Roll, - Motor1, Motor2, Motor3, Motor4 and write it to the acoustic modem, which is then sent over the network to the base station. The GUI will interpret and display this received data. Performing this process sequentially will affect the performance of data collection and accuracy of AUV tasks. In order to maintain effective operations using the AUV we have programmed this main control loop using threads in a multithreaded fashion. The pseudo code for the above process can be seen in Algorithm 1. C. Software Modules Since a variety of devices are being used in our control system, we have developed various software interfaces. One such interface is the communication between the Gumstix and ETT board. A bridge interface is programmed in C/C++ to convert specified voltages and placed into our own array packet header which is verified and passed between both controllers to control individual motors. Additionally, we have created a basic stabilization algorithm and built off our existing underwater networking protocol platform, Aqua-NET [13], to include more specific AUV network modifications and manual control system. 1) Aqua-Net: The main software system used for networking and communication tasks is based on a Linux implementation of Aqua-Net [13]. Aqua-Net is a generic architecture for underwater sensor networks that was developed to provide a powerful networking solution kit for underwater network researchers. It was designed to facilitate robustness for users and simplicity for protocol or application developers. The architecture is expendable, user friendly and provides a layered structure with the ability to optimize cross-layer protocols. This is an added benefit to developing networking and communication specific protocols for AUVs or for hybrid protocols in which underwater sensors communicate with AUVs. We can make use of existing medium access control (MAC) protocols, routing protocols, reliable data protocols and time synchronization and localization protocols. Further, we have evaluated this software system and proven its strength and benefits in our lake testbed system, Aqua-TUNE [15]. Currently, we make use of some existing networking and communication protocols developed in Aqua-Net and tweaked them slightly for our prototype use. We hope to develop optimized AUV specific protocols as part of our future work. 2) Stabilization Algorithms: Unlike land vehicles, underwater vehicles are greatly influenced by the platform they use. This means that the vehicle will constantly have a change in its roll, pitch and yaw. Roll is the angle when the nose of the vehicle is tilting left to right. Pitch is the angle when the nose of the vehicle is titling upward or downward. Finally, yaw is the angle of freedom when the nose of the vehicle is facing left or right. Because of these influences the AUV, when given the command to move forward, does not go perfectly straight in the water. It will move straight for a short period of time and then slowly change course based on the environment. In order to correct this a vehicle requires a stabilization function in order to make sure that the AUV stays in its intended direction. This stabilization function will be able to change the yaw and pitch of the vehicle. Roll is not a factor here because of the way our AUV is designed. It was designed to maintain itself in straight paths due to having a heavy bottom. Furthermore, because of the AUV design, if rolled, it would not be able to counteract the moment because of the way the thrusters are placed on the vehicle. For the AUV to counteract these moments in which it strays off course, specific pumps have to be turned on in order to keep itself on course. This method is similar to that which is used in Quad-Rotors [16]. In order to detect if the AUV is influenced by these moments, the IMU is used. Figure 5 shows the specific motors that must be used in order to induce

5 Fig. 5. Stabilization Example the change in that specific degree of freedom, where a the color green represents power to that specific motor. In order to counteract the moment in which the AUV is acting, an opposing force must be added. An example of that is if the AUV is diving (negative pitch) then a command can be sent to the AUV to breach (positive pitch). This applies to the yaw as well. Using this information we can create a basic stabilization function that is appropriate for our prototype design. Algorithm 2 provides the pseudo code outlining the foundation of this function. The control of these actuators has two modes of operations: individual values or keypad movement. For individual values, the user can input an actuator speed value from 0 to 254 into the text field in the upper left section of the GUI. The keypad movement allows the user to press the q, w, e, and r keys to increase the values of the first, second, third, and fourth actuator respectively. The same applies for keys a, s, d, and f to decrement the speed values respectively. The user can also use the X button to reset the values for all actuators, which also acts as a way to halt movement of the AUV. These keys are shown in blue on the GUI. In Figure 6 the top right section portrays a graphical depiction of the AUVs actuator setup. The dark circles represent each thruster and display the power values currently being sent to them. The small red dot indicates the heading of the vehicle and will move accordingly. The top left section is used to cycle through which particular AUV the user wishes to control or monitor and display data from internal sensors. In order to cycle through a different AUV the user can make use of the tabs that are labeled AUV 0, AUV 1, and AUV 2. The user can also customize the names of their AUVs. Below these tabs is where the data from internal sensors is displayed. This information includes the AUV s current (x,y) position, depth, temperature and the current power of all thrusters. On the bottom left of the GUI is a 3D graphical representation of the AUV based on raw data from the IMU, which is displayed below it. This data includes information such as yaw, pitch and roll. Algorithm 2 Pseudo code for the stabilization algorithm. if Pitch then AUV +Pitch wait(2) AUV Pitch wait(1) AUV OriginalCommand else AUV OriginalCommand end if Since the AUV will not be perfectly straight at all times we have performed some tests in a swimming pool environment to calculate a tolerance of +/- 5 degrees in the stabilization process. This tolerance is large enough to not have to constantly worry about stabilizing the AUV but small enough that it will not effect the performance of the AUV in a negative way. With the help of the IMU, the stabilization process is much easier to conduct. D. Graphical User Interface The GUI has been designed in Java for manual control of the AUV from the monitoring station using an OFDM acoustic modem, which can be seen in Figure 6. This allows a user to directly control the input values for each of the four actuators. Fig. 6. Graphical User Interface IV. CONCLUSION In this paper we propose a control system for networked autonomous underwater vehicles that includes both hardware and software modules. The system integrates various communication and sensor devices, such as an IMU and an OFDM acoustic modem and contains a graphical user interface for optional manual remote control and monitoring of AUVs in the network from a base station.

6 For future work we plan to further develop and test our AUV networking protocols for advanced localization, swarming techniques and optimized networking and communication capabilities. Additionally, we plan to test the use of genetic algorithms for more effective autonomous control and waypoint navigation. REFERENCES [1] J.-H. Cui, J. Kong, M. Gerla, and S. Zhou, Challenges: Building scalable mobile underwater wireless sensor networks for aquatic applications, IEEE Network, Special Issue on Wireless Sensor Networking, vol. 20, no. 3, pp , [2] J. Partan, J. Kurose, and B. N. Levine, A Survey of Practical Issues in Underwater Networks, in Proceedings of the 1st ACM International Workshop on Underwater Networks (WUWNet 06), 2006, pp [3] M. Zuba, Z. Shi, Z. Peng, J. Cui, and S. Zhou, Vulnerabilities of Underwater Acoustic Networks to Denial-of-Service Jamming Attacks. in Wiley Security and Communication Networks, February 2012, pp. 1 10, doi: /sec.507. [4] J. Kong, J.-H. Cui, D. Wu, and M. Gerla, Building Underwater Adhoc Networks and Sensor Networks for Large Scale Real-time Aquatic Application, Proc. of IEEE Military Communications Conference (MIL- COM 05), pp , October [5] A. Diercks, V. Asper, M. Woolsey, J. Williams, F. Cantelas, R. Camilli, P. Rona, V. Guida, and L. Macelloni, NIUST AUVs - Expanding Possibilities, Proc. of MTS/IEEE OCEANS 10, September [6] D. Mindell and B. Bingham, New Archaelogical Uses of Autonomous Underwater Vehicles, Proc. of MTS/IEEE OCEANS 01, [7] L. Liu, S. Zhou, and J.-H. Cui, Prospects and Problems of Wireless Communication for Underwater Sensor Networks, Wiley Wireless Communications and Mobile Computing, Special Issue on Underwater Sensor Networks, vol. 8, no. 8, pp , [8] B. Johnson, N. Hallin, H. Leidenfrost, M. O Rourke, and D. Edwards, Collaborative Mapping with Autonomous Underwater Vehicles in Low- Bandwidth Conditions, Proc. of IEEE/OES OCEANS 09, May [9] D. Blidberg, The Development of Autonomous Underwater Vehicles (AUV); A Brief Summary, in Proc. of the IEEE International Conference on Robotics and Automation (ICRA), May 2001, pp [10] T. Pfuetzenreuter and H. Renkewitz, ConSys - a New Software Framework for Underwater Vehicles, in Proc. of IEEE OCEANS Sydney, May [11] B. Allen, R. Stokey, T. Austin, N. Forrester, R. Goldsborough, M. Purcell, and C. von Alt, REMUS: A small, low cost AUV; System Description, Field Trials and Performance Results, in Proc. of MTS/IEEE OCEANS 97, October [12] I. Masmitja, G. Masmitja, J. Gonzalez, S. Shariat-Panahi, and S. Gomariz, Development of a Control System for an Autonomous Underwater Vehicle, in Proc. of IEEE/OES Autonomous Underwater Vehicles (AUV), September [13] Z. Peng, Z. Zhou, J.-H. Cui, and Z. Shi, Aqua-Net: An Underwater Sensor Network Architecture: Design, Implementation, and Initial Testing, in Proc. of IEEE/MTS OCEANS 09, [14] H. Yan, L. Wan, S. Zhou, J. Cui, J. Huang, and H. Zhou, Dsp based receiver implementation for ofdm acoustic modems, in Elsevier Journal on Physical Communication, [15] Z. Peng, S. Le, M. Zuba, H. Mo, Y. Zhu, L. Pu, J. Liu, and J.-H. Cui, Aqua-TUNE: A Field Testbed for Underwater Networks, in Proc. of IEEE/OES OCEANS 11 - Spain, June [16] S. A. Raza and W. Gueaib, Intelligent Flight Control of an Autonomous Quadrotor, in Proc. of the International Journal of Advanced Robotic Systems, January 2010.