The Institute of Marine Research Takes NI LabVIEW to the Bottom of the Ocean
"To reduce power consumption, the LabVIEW control application turns off equipment when it is not in use. It also monitors the Observer for emergency situations."
- Atle Totland, Institute of Marine Research
Detecting fish located close to the seabed with scientific echo sounders onboard research vessels.
Using NI LabVIEW system design software to control the Deadzone Observer, a highly accurate autonomous underwater vehicle that can detect fish located close to the sea bottom.
Atle Totland - Institute of Marine Research
Egil Ona - Institute of Marine Research
Geir Lasse Kaldestad - Marin - Innovasjon AS
Several large fish stocks of considerable economic importance inhabit the Barents Sea north of Norway. It is vital to the fishing industry to measure the size of these resources correctly and manage them in an optimal way. Data from scientific echo sounders and trawl catches are commonly used for this purpose. However, due to the physics of sound propagation in water, echo sounders cannot detect fish located near or on the seabed. This blind zone – normally referred to as the dead zone – increases with bottom depth. At a depth of 300 meters, the dead zone is approximately 1.5 meters, which can prevent the echo sounder from detecting bottom-dwelling species like cod and haddock.
To detect fish hidden in the dead zone, we developed the Deadzone Observer, an autonomous unit controlled by LabVIEW.
The Observer Control System
We control the Observer’s buoyancy regulation, mission execution, and communication with the mother vessel using LabVIEW. The complex LabVIEW control application running on the Observer’s internal PC also reads, uses, and stores a large variety of sensor data, including depth, bottom distance, inclination, leakage, system voltage, system current, sea temperature, internal temperature, oil pressure, and GPS position.
Upon deployment, the Observer descends to 25 meters above the seabed, with a maximum depth of 1,000 meters. LabVIEW works with an oil-filled swim bladder to control buoyancy and keep the unit at a fixed distance from the bottom. Because the Observer is so close to the seabed, its echo sounder has a dead zone of only a few centimeters, so it can detect a single fish resting on the seafloor. The Observer collects data autonomously for the duration of the dive, which is predetermined in the unit’s mission plan.
To reduce power consumption, the LabVIEW control application turns off equipment when it is not in use. It also monitors the Observer for emergency situations. If the application detects such an event – for instance, low power or a leak – the Observer surfaces and triggers an alarm on the ship. The Observer also surfaces if the control application or the Windows operating system stop. Even in the event of a main system failure, we can obtain the Observer’s geographic position from an independent ARGOS transmitter attached to the Observer’s antenna mast.
Most of the Observer’s sensors have either an RS232 serial or Ethernet interface. Due to the system’s complexity, we needed to simulate dives during the software development phase in order to verify correct code performance. Testing handled each of the data ports (COM ports and Ethernet ports) in independent program loops. We transferred data between the main program loop and the various data port loops using global variables, although shared variables in LabVIEW would also work. In test mode, one or more of the data ports loops can be disabled while a simulation program sends data to the global variables instead of the data port loops, letting us test any imaginable dive scenario in the office. We used “state machine” architecture for the control software. It was our choice of LabVIEW as the software architecture that prevented us from drowning in code complexity.
The Ship Communication Program
Once a dive is complete and the Observer returns to surface, an onboard GPS receiver is activated to send a geographic position fix, and the LabVIEW control application connects the Observer with the ship using Iridium, a two-way satellite communication system with global coverage, even in polar regions. Geographic position data, error messages, and other data are then transmitted to the ship. Using an onboard LabVIEW application, we can issue new commands or a new mission plan to the Observer, which can operate independently from the ship for up to a week at a time. Once communication is terminated, the Observer continues on its mission.
Safe operation requires that the Observer accurately receive all communication from the ship. The ship will retransmit information if the Observer does not return a verification telegram.
The Charging Program
The Observer consumes a lot of power. In order to operate for up to one week at a time, the Observer needs batteries with high energy density. An array of 430 lithium ion batteries providing a total capacity of 8.3 kWh are packed in layers.
Due to the high energy concentration, we must closely monitor discharging and charging. A circuit board monitors and stores voltages, currents, and temperatures on each layer of the battery. If something is wrong, the battery is shut down. Each circuit board has a serial line that is used during charging. An external PC is connected to the Observer, and the LabVIEW control application interacts with the built-in circuit boards on the battery to ensure correct and safe charging.
For more information, contact:
Senior Engineer, Institute of Marine Research
Post Box 1870 Nordnes
5817 Bergen, Norway
Tel: (47) 552 38 668
Fax: (47) 552 38531
Bookmark and Share
Explore the NI Developer Community
Discover and collaborate on the latest example code and tutorials with a worldwide community of engineers and scientists.
Who is National Instruments?
National Instruments provides a graphical system design platform for test, control, and embedded design applications that is transforming the way engineers and scientists design, prototype, and deploy systems.