Title: Autonomous Instrumentation for Oceanography

Power and Electronics for AUV Maya

The choice of power source for the AUV was Lithium Polymer cells that offer a high energy to weight ratio of 182 Wh/kg. The AUV is powered by one battery bank dedicated to the electronics (24V/18Ah) and another bank for the thruster (96V/ 9Ah) . It carries a total of 1296 Whr, weighing a mere 7.62 kg to achieve an endurance of 6 hours. The vehicles propulsion was achieved with a single brushless DC motor capable of delivering a maximum thrust of 4.0 kgf at a bus voltage of 96V. At this operating point, the vehicle cruises at an average speed of 1.5 m/s.

Electronics and battery bin

Battery Monitoring node

A PIC16F876 based microcontroller circuit with CAN 2.0B support constitutes the battery node. It monitors the battery bank, and powers ON/OFF the various sensors and electronics in an orderly manner using solid state relays. The battery node is configured to send battery data over the CAN bus using a Standard CAN data frame every 1 second and bears id $7d3 in the CAN network as shown below.

Various safety features are incorporated in the battery node to ensure that the vehicle does not go astray in the event of a failure. 

A centralized power distribution architecture is adopted to ensure clean power to all the subsystems of the AUV. Small and efficient DC to DC converters are used to generate 12 and 5 volts. The two battery banks, battery monitoring nodes and the power conditioners are all placed in close proximity, to facilitate easy and safe interconnection of different loads at the front and rear.

Power flow diagram for AUV

MZ-104 – Small micro computer for AUV 

The AUV electronics consist of the main controller based on an MZ-104 running Linux, Sensors such as the AHRS, GPS, DVL and PPTR, Actuator nodes such as the Thruster node, the Fin node and the Rudder node, and finally the Battery monitoring node(s). These nodes are connected to the MZ-104 using a CAN 2.0B network. The AUV connects to a shore/ship based PC through a wire-less modem. This is accomplished by establishing a PPP link between the two, and communication between the MZ-104 and the PC take place via TCP/IP sockets with the MZ-104 as the server and the GUI on the PC acting as a client.

Software Model

The MZ-104 have two programs executing on it full time. These are:

1) The “auv_server” program is a TCP/IP server which enables the GUI client to connect to itself and do various tasks like:

i) Issue direct commands to actuator nodes/controllers.

ii) Update status information on the GUI

iii) Configure Controllers on the AUV.

iv) Upload/Download and Execute missions.

v) Upload data files to the GUI.

vi) Perform sensor calibration (AHRS).

2) The “auv_controller” program contains configurable digital PID controllers for Heading, Speed, Pitch and Depth control. It also acquires data from all the sensors i.e. GPS, AHRS, DVL and PPTR using either RS-232 or CAN depending upon the type of interface it has with them. It also runs the navigation and guidance algorithms. It sends PID outputs to the various actuator nodes via CAN. It also periodically updates itself with battery power information from the battery monitoring nodes via CAN.

These two programs can send data to each other by two methods, namely by using “Shared Memory” which allows for high-speed data transfers between the two programs for online data exchange or by using “Secondary Storage Devices” such as Flash drives or a hard-disk for offline data transfer (mainly in the form of log-files or data/mission files).

Distributed can networks on AUV

Two options of either using a centralized or distributed scheme were considered when designing the software and hardware architectures of AUV. The centralized design is simpler but lacks modularity, and usually involves more powerful hardware which is capable of performing tasks at high speeds, reliably and with support for multi-threading or multi-processing program execution. In a distributed design processing scheme, power can be lower since various smaller and dedicated processors handle smaller and dedicated tasks. This obviously results in dependence upon one or more means of communication networks between these distributed computers or nodes in the system. Hence a proper choice of a reliable network is very essential. Several distributed network namely Ethernet, RS-422 and CAN were compared with the underlying consideration that the use of a network should allow
relatively easy interfaces with low cost micro-controllers. Without going into the comparison of networks, we settled for the Controller Area Network 2.0B standard [CAN] as being a viable option for a modular ASV architecture. CAN networks have been tested extensively in industrial environments and are a well proven technology that is widely used in the automobile industry [5]. CAN offers the following properties.

a) Network nodes allow modular expansion, and redundancy of hardware if needed
b) Simplicity in debugging software
c) Prioritization of messages
d) Guarantee of latency times
e) Multicast reception with time synchronization
f) System wide data consistency
g) Multi-master configurations possible
h) Error detection and error signaling
i) Automatic retransmission of corrupted messages as soon as the bus is idle again
j) Distinction between temporary errors and permanent failures of nodes and autonomous switching off of defect nodes.

The small-message based protocol is ideal for communication between nodes in the ASV since all control messages required for it are smaller than 8 bytes. Multicast messages with time synchronization enable multiple nodes receiving consistent data simultaneously. A reliable method of arbitration ensures that important messages take control of the bus. Moreover, nodes that are unreliable are automatically put off the CAN bus. A block diagram of the architecture adopted is shown in Figure 4.