1 May 2007

Sensing in shallow water

Educators prove advantages of wireless platform for environmental data acquisition in shallow water areas

Fast Forward

  • Temperature, pH, conductivity, and dissolved oxygen sensors for water quality measurements have not made the grade at city, state, and government agencies, especially in shallow waters.
  • A NASA-funded project helps relieve time-consuming data collection in South Texas Coastal waters.
  • Researchers report success of a remote-control, shallow-draft vehicle that wirelessly transmits data in real time.
By Rafic Bachnak, Wien Lohachit, Marc Mendez, Alex Sadovsky, and Jack Esparza

City, state, and government agencies concerned with water quality measurements have used temperature, pH, conductivity, and dissolved oxygen sensors in the past, but with limited success, especially in shallow waters. Water quality data collection in shallow water areas can be a challenge because it normally requires setting up sensors in several places, plus it is redundant and time consuming. Performing the task manually also has a high chance of disturbing the test area. Large territories and inaccessible areas present difficulties due to a soft bottom or contamination. There is a high probability of disturbing the test area while placing the sensors. In the San Joaquin River Basin in California, for instance, a real-time water quality forecasting model helped improve the management of saline agricultural and wetland drainage to meet water quality objectives. To help alleviate some of the challenges in the South Texas Coastal waters, the instrumentation and software systems of a NASA-funded project led to development of a remotely-controlled, shallow-draft vehicle. The system wirelessly transmits environmental data to a docking and control station in real time.

Investigators in the Division of Nearshore Research (DNR) of the Center for Coastal Studies of Texas A&M University-Corpus Christi collect water quality data in areas with water 3 feet or deeper by a human-controlled boat. Also, a number of research centers have autonomous boats that require course planning prior to deployment. In these cases, it is not easy to chance the pre-planned course once the boat is in the water. A team of computer scientists, engineers, and mathematicians developed a remotely controlled shallow-draft vehicle that continuously and efficiently determines water quality in shallow water areas (6 in to 3 ft), rather than using fixed-position sensors to acquire water-quality parameters. The boat is small (7ft in length and 3 ft in width), has a shallow draft, and is easy to steer to collect data in real time. The prototype collects salinity and other environmental data and is equipped with onboard computers, water quality instruments, a global positioning system (GPS), a digital compass, a remote control receiver, and a receiver/transmitter radio. It will eventually have the ability to intelligently maneuver around obstacles. Acquired data transmits wirelessly via a radio to a remote control station in real time, and data logs to a PC for later processing. 

System design

While designing the boat, we considered the following operational requirements:

a. The boat was to have remote control within the operator's line of sight.
b. It should be small and easy to transport in the back of a truck without extra towing equipment.
c. It should be stable enough to resist waves and wind.
d. It should have the ability to travel through areas with a draft as small as 6 inches.
e. It should have sensors to detect objects from all directions (front, sides, back, and bottom).
f. It should transmit data wirelessly to a docking and control station in real time. and control station in real time.

Motor, steering

We chose an electric trolling motor to propel the prototype. This motor is rated for salt-water operations and can propel a boat as heavy as 1,500 lbs. It has hand-controlled steering with five forward speeds and two reverse speeds. The motor was easy to modify for remote control. We accomplished the remote control function via a six-channel FM radio. It uses only two channels; one controls the steering via a high-torque servo and pushrod that connects to the shaft of the motor, and the other controls forward and reverse speed via a remote-control switch. The control switch in-cludes two relays, opening and closing according to the pulse signal of the receiver. This simple configuration worked well for tests of the concept in the lab; however, we needed another arrangement prior to sea trials since the original equipment servo harness was plastic and easily breakable. Also, the remote-control switch did not allow variable speed control. It could only provide one speed forward and one speed reverse. We corrected the first problem by replacing the servo harness with a 12 VDC steering motor that drives a built-in worm gear in combination with a remote-control switch to control the direction, left or right. We solved the second problem, varying the speed of the motor, using electronic control, which would allow varying the speed in forward and reverse. The speed of the motor is simply a function of the position of the radio controller joystick.

The onboard PC consists of a stack of PC/104 modules, called the Cube, with analog-to-digital conversion capabilities and serial port interfaces. The Cube acts as a central control unit and interfaces with the radio and all onboard sensors, including the GPS and digital compass.


Water quality sensor

The water quality sensor is for use in fresh, salt, or polluted water. It is useful in shallow water areas since the sensor does not have to be immersed in water. This instrument measures several parameters of environmental data simultaneously including conductivity, temperature, pH, dissolved oxygen, and salinity. We can preset the water quality parameters through the program the manufacturer supplied. The sensor connects to the Cube via a serial interface and is set to collect data in RS-232 mode. We collect sensor data using a serial port program, which a scheduler periodically calls and writes as a shell script. The sensor data collects outputs as ASCII text. Data storage on a compact flash disk transmits through the radio to the target laptop for the data presentation program to process and display the information for the researcher or operator.
A GPS unit with a sounder interface involves a transducer that detects depth data. This sensor also connects to the Cube via a serial port interface in RS-232 mode. These components help to identify the position of the collected data. The GPS system gives the x and y coordinates that are longitude and latitude of a physical point, while the depth sensor gives its z coordinate.

Remote control station

The control station consists of a six-channel remote controller and a laptop. The remote controller manages the movement of the boat, and the laptop keeps a log of the data transmitted by way of the radio from the boat. The remote controller steers the boat and controls its speed. There are two analog control sticks on the remote controller. The right stick controls the left-right direction of the boat, and the left stick controls the speed in both forward and reverse direction. The remote controller is operated independently from the laptop computer.

The laptop stores and processes the received data and displays the status of major systems and onboard sensors. The laptop display serves as a guide to assist the operator with navigation if he detects objects around or under the boat. The operator is able to direct the boat to investigate areas of interest. Once the laptop receives the data, it checks errors to make sure the data it receives is the same as the data transmitted. Error-checking detects any errors in the communication between the two radios. The receiver/transmitter radio will retrans-mit data when an error has occurred between the two radios. The laptop connects to the wireless radio via a serial port. The received data stores in an ASCII format, and the data presentation software uses this data for information display and plotting.

The Cube collects data and transmits it to the laptop on shore at regular intervals over a wireless radio connection. The laptop computer also displays the remaining system battery voltage. An operator gathers water-quality data in near-real time and directs the boat to investigate areas of interest. The transmitted data stores on the PC for processing.

The data acquisition program displays the transmitted data for the laptop on shore. It also keeps a log of the sensor data, GPS information, and all the system information, such as battery voltage and system power. The system plots data points on a graph generated by GDI+ namespace. The plot displays the GPS and depth information. Collected time offers a synchronization point of depth in- formation and GPS coordinates.

System software

DNR has developed a Linux-based platform as part of the Texas Coastal Ocean Observation Network. A footprint version of the Linux platform runs on the Cube. Since the boat data acquisition needs a serial connection, we use a serial module along with a serial-polling (serpoll) program. Currently, DNR uses the cron utility (UNIX system daemon) to run the serpoll once per minute for its stations.

Cron is a module that enables Linux users to execute commands or scripts automatically at a specified time/date, once we set the configuration file parameters in shell scripts. The serpoll program polls serial port information according to the configuration files and returns the result to a specified folder on compact flash disk.

The remote controlled system requires data in intervals of seconds. Therefore, the serpoll program must run from a different utility. The serial port devices (the GPS and sensor) output data at 15-second intervals. For this reason, we wrote a bash script, hydgps.sh, to call the serpoll program every 15 seconds. This provides four sets of data from the GPS and sensor within one minute. The Linux shell scripts that operate from the Linux cron utility handle data collection for each sensor. After the script executes, acquired data from the sensor and GPS store on the flash disk in the directory. The script initializes when the Cube boots by defining it on the crontab, the Linux system utility that calls the program to run at the beginning of each minute.

Evaluation, results

We performed several tests on the Cube data acquisition and control computer to ensure the connections between onboard computer, data acquisition script, and sensors. Once the onboard Cube data acquisition was working properly, we integrated the receiver/ transmitter radios with the onshore laptop. This test concentrated on the accuracy of received data on the laptop. The data from the Cube traveled simultaneously to the laptop every 15 seconds. Selected data shows data from the Cube is the same as data from the laptop.

Sensor, GPS measurements

                                                   Reading From laptop
                                                   Time collected: 10:56:10 
       Salinity                                 22.1%       
       Temperature                         27.01 0C
       Battery                                 12.2 V

        Latitude                               2742.9763 N
        Longitude                            09719.2846 W
        Depth level                          3.9 F


Although the boat was fully functional, it could not track against the wind and waves and had difficulty executing a controlled turn or making subtle course adjustments. The control system, based on remote-control servo/transmitter technologies, is subject to the inherent limitations of these technologies. Also, the design did not allow programmatic control of the vessel. As a result, the operator must observe all details about the boat's state (speed, position, and heading) visually, rather than receiving recorded information. So we developed a second prototype that addresses these limitations and offers additional features. The only similarity in the design of the two prototypes is they both use the same trolling motor for propulsion. The second prototype, a remotely operated vessel (ROV), has a cylindrical hull, along with a pontoon on each side of the hull, and makes up the body of the boat. This ROV also incorporates a new control system that helps overcome limitations of the initial boat.

In the network communication paths, all control and data signals travel to and from instruments via the controllers. We use a standalone platform to develop the ROV software, which means it does not need a Windows-based system on which to operate.

Testing the ROV

We've successfully tested the ROV software, and its handling is straightforward. To determine the accuracy of the depth sensor, we compared manual measurements at several physical points to the measurements reported by the depth sensor.

Future work

With the controller in place, the ROV can have on-board programs that guide its navigation. A programmed interface can guide the vehicle on a path based on a grid and various tests in order to limit and/or control distance traveled, degree of turn at set points, and similar distance travel for return. Although exterior factors play a major role in the vehicle's ability to actually operate on a set path autonomously, various obstacles can have a dramatic effect on accurate execution of programming parameters by the vehicle, including water current, failure of communication connection, loss of power, actual obstacles that may be underwater and impossible to see, and other objects in the water. A major consideration is to have the craft become autonomous to the point that it maneuvers independently using visual cues or sensors.

We're adding real-time video to the ROV. The system consists of a compact vision system and two cameras. A major aim of the project is to develop functionality that allows the ROV to navigate on its own when given a destination or a series of destinations (waypoints). As this new, programmatically driven control system becomes more mature, and the boat chassis in which it is embedded becomes more reliable, autopilot functionality becomes more of a possibility.

About the Authors

Rafic Bachnak is a professor of electrical engineering at Texas A&M University-Corpus Christi (rbachnak@falcon.tamucc. edu). Wien Lohachit is a Texas A&M graduate, with a Masters Degree in Com-puter Science, Alex Sadovsky is professor of Mathematics, Jack Esparza is an undergraduate research assistant in Mechanical Engineering Technology, and Marc Mendez is an electronic engineer at Base Line Data, Inc., a corrosion survey company in Portland, Tex.