<< Previous

Page (2/3)

Next >>

Rapid development required a quick and easy way to finely tune variables for our classes. We also wanted to have a way for enabling or disabling parts of the software without recompiling everything. A configuration file format was created to address these issues. The configuration file is globally accessed and components can specify a section in the configuration file that their options should be placed. A typical configuration file has a format as follows:

				[SECTION] = SOCKET
					activate = 1
					max_retries = 10
					keepalive = 1
					cycletime = 25
					
				

We have created a messaging system that allows a lower-level component to send data to a higher level component without having direct access to that class. A message is created by a lower-level component and passed into a message router, which places it into a priority queue. The upper-level component checks its message box (the queue) periodically for new messages and acts upon them. (Figure 1) depicts this relationship. Data can be passed with the message, or the message can identify the data that needs to be accessed in the class that created it. Messages can also originate from the debugger via TCP sockets.

 

The lowest level of the software on Seawolf I, directly above the hardware API, is the device level. This level provides interfaces for all of the sensors used for navigation (DVL, IMU and Altimeter) as well as motor and servo controllers.

All of the device classes were designed with the desire to modularize the entire system. This design choice greatly aided our migration of our original analog-controlled thrusterd to our current I2C controlled thrusters. Because of our loosely-coupled architectuyre, none of the upper level control systems required new code to use the different thrusters

Since the DVL and IMU are constantly streaming serial data, we use separate execution threads to retrieve data from them. We can poll the voltage on the altimeter’s analog channel to determine our altitude with a simple equation.

A health monitoring class uses the analog inputs on the PC/104’s onboard DAQ to monitor temperature, voltage and current sensors in the electronics tube. If the system management class measures a sensor that is out of its tolerances, it would report the problem to the mission controller (Tier III) which would decide what to do.

 

The majority of work is performed in the second tier. We divided the vehicle’s functions into four subsystems. Each subsystem runs in a separate thread and the software framework provides data/event logging and messaging to each subsystem.

A vehicle subsystem performs device initialization and shutdown, as well as some miscellaneous monitoring information over the low level devices. An acoustics subsystem collects heading information from the DSP. An image processing subsystem interfaces with the framegrabber and performs machine vision algorithms. Finally, a control subsystem uses fuzzy logic to calculate all of our movement solutions given different waypoints and desired conditions.

 

The highest level of control over the vehicle is located in the mission controller. Mission control has a pre-defined mission to follow and delegates commands to the lower subsystems. Mission control does not need to know details of how goals are accomplished, only that they are accomplished in a particular order.

The mission controller can setup each subsystem with different tasks and react to messages sent from the lower level upon goal completion. For instance, mission control may want to find a particular shape and move towards it. For each subsystem, mission control sets the conditions. Controls might be asked to perform a sweep search pattern. Imaging would be asked to find the desired shape and alert mission control when it found a positive match via the event messaging system.

A global logger allows any part of Seawolf I to log data and events in a central location, instead of its individual log file. The socket connection uses two threads for sending and receiving data. The control subsystem combines fuzzy logic controllers with kinematics equations based on our thruster geometry to produce closed-loop thrust-angle calculations. The control subsystem has to use separate controllers for translating, rotating (yaw), stabilizing (roll and pitch), z-stability (maintaining a depth or altitude) and stopping (maintaining a zero speed in xy directions). The fuzzy logic controllers read position/velocity data from the DVL, IMU, and altimeter, and output force and torque vectors which are then fed into the kinematics equations which determine optimal thrust/angle solutions for each thruster. We decided to create a simple fuzzy logic evaluation engine using C++ macros for our controls system . A set of macros enabled us to mimic FCL (Fuzzy Control Language) and English rules. The following is a sample rule written with our fuzzy logic syntax:

				rule[0] = If(Temperature) is(Cold) then 
					output[0] = High; 
				end
			

Rules can contain fuzzy logical ands and ors. We can also describe fuzzy membership sets with simple macros. We have the basic set shapes—triangle, sigmoids, trapezoids and singletons. We were able to describe fuzzy controllers with upwards of 64 rules and 8 sets using our fuzzy macro language.

 

From the debugger, the controls subsystem can be put into different modes which alter the level of control we have over the vehicle. We can choose to directly control each thruster’s angle and thrust independently, request open-loop movements by directly manipulating the inputs of the kinematics equations, or provide destination waypoints or desired velocities to test closed-loop control. The run mode is divided into speed-major movements—movements where we’re concerned with our current speed only, or translation-major movements—movements where we’re concerned with how far we’ve moved.

 

<< Previous

Page (2/3)

Next >>