IC470 Software Engineering

 

Autonomous Underwater Vehicle (AUV) Simulator Requirements

 

 Introduction: The Association for Unmanned Vehicle Systems International (AUVSI) and the U.S. Office of Naval Research (ONR) jointly hold an annual “International Autonomous Underwater Vehicle Competition”.  The goal of this competition is to advance the state-of-the-art of Autonomous Underwater Vehicles (AUVs) by challenging a new generation of engineers and computer scientists to accomplish realistic missions in the underwater environment.  Many applications for AUVs require measuring or mapping the bathymetry of the seafloor, and identifying the shallowest item in an array of man-made objects.  Additionally, numerous operational missions require finding and recovering objects on the seabed. The AUVSI-ONR organizers expect these fundamental capabilities to be the foundation for future Competition scenarios, with the degree of difficulty increasing each year proportionate to the degree of entrant proficiency. Note that divers are in the water with the AUV systems to observe the submersibles behavior and intercede (by pulling a kill cord) if the AUV attempts a hazardous maneuver. More complete details on the AUVSI-ONR competitions can be found at: at: http://www.auvsi.org/

 

Background: Each year a team of interdisciplinary midshipmen builds an AUV and enters the AUVSI competition.  Previously, teams have included midshipmen from Systems Engineering, Computer Science, Physics, and Oceanography.   They competed with teams from MIT, URI, a Canadian team (from the same university that developed the Space Shuttle’s robotic arm), and a French team.  Each year the midshipmen run into a similar problem: The AUV is physically constructed in the spring semester.  The team spends a great deal of time connecting wires together for the sonar and navigation systems, measuring power requirements, etc, and generally runs out of time to fully develop the multi-threaded software system that controls the AUV.   As your team-oriented software development project, your team will develop a simulator for the AUV controller for the upcoming Spring AUV competition, with a mind towards producing a software architecture that lends itself to subsequent modification so as to meet the needs of USNA’s entry in the AUV competition for years to come.

 

 

Project Overview:  The software system your team develops will be implemented in Java and will simulate controlling an AUV.  For purposes of simulation, all input will come from text files (rather than from actual serial port connections as occurs in the spring competition), and all output will be written either to text files or an appropriate Graphical User Interface (GUI) screen.  The software developed is to be concise, robust, well documented with meaningful comments, and is to utilize a descriptive naming convention. For classes, capitalize the beginning letter of each word in the class name (ie., ClassName). For constants, capitalize all letters, and put underscores between interior words (ie., DEFAULT_TIME_SLICE). For objects/variables, capitalize only the first letter of interior words (ie., currentHeading). Note that crhd would NOT be considered a descriptive variable name to represent the current heading.   The system shall include the following subsystems:

 

·       Subsystem 1: Mission Planning

·       Subsystem 2: Mission Status

·       Subsystem 3: Manual Mission

·       Subsystem 4: System Controller 

·       Subsystem 5: Dead Reckoning (DR) Navigation

 

 

5 Major Subsystems

Functionality of

indicated subsystem

1. Mission Planning

Provide a Graphical User Interface (GUI) with pull down menu that allows user to select the desired Mission Phases.  The use of a pull down menu (JComboBox) allows additional phases to be readily added during maintenance.

 

Mission Phases include:

  • Initialization/Setup (open files, and any startup activity that needs to occur before a mission can be run)
  • DR Navigation (Allows user to enter a filename of a textfile that provides the dead reckoning navigation settings as described below.  Defaults to a filename of deadReckon.dat, and informs the user via a dialog box if the user does not enter a filename)
  • Search/Track Towards an Acoustic Bearing (Allows user to specify Acoustic Frequency to search for/track towards)
  • Mission Complete (Close log files, shutdown motors, AUV is positively buoyant, so it surfaces on its own)

 

The user may select missions that involve initialization/setup,  DR Navigation (if selected), then   Search/Track Towards Acoustical Bearing (if selected), and then execute Mission Complete.

 

Provide Buttons that allow user to:

  • Run Autonomous Mission.    This button will have no effect in the course project simulation.
  • Run Simulated Mission. When this button is pushed, the Mission Status Window appears and the mission selected via the Mission Planning GUI Window is run based on input/output to/from the text files that simulate the actual system hardware. 
  • Run Tethered (Manual) Mission. When this button is pushed, the Manual Mission GUI Window appears and allows the user to manually control the AUV’s motors. The Mission Status GUI Window also appears.  

2. Mission Status

Provide a GUI with fields that display:

  • Current Mission Phase
  • Current
    • Depth (in meters)
    • Heading (in degrees true)
    •  
  • Targeted
    • Depth (in meters)
    • Heading (in degrees true)
    •  
  • Analog Motor Power Setting
    • Bow
    • Stern
    • Port
    • Starboard
  • Acoustic Bearing
    • Targeted Frequency (in Hertz)
    • Current Acoustical Bearing (in degrees true)
    • Last Known Acoustical Bearing (in degrees true)

 

3. Manual Mission

Provide a GUI that allows user to manually input power settings to control the Port, Starboard, Bow and Stern motors.  The Mission Status GUI Window also appears when the Manual Mission is run and shows the direction/speed settings of the AUV motors in response to manual control input. 

4. System Controller    (no GUI):

Simulated Mission, creates:

·       Threads that receive input from the text files that simulate the compass, acoustical signals (sonar), the altimeter, and dead reckoning navigation commands.

 

·       A thread that writes (once per second) Navigation and Acoustical data a file called missionlog.dat to include time, current compass data, altimeter, current acoustical bearing, last known acoustical bearing, and the current power setting for each motor.

 

·       The Mission Status GUI Window also appears when the Simulated Mission is run

 

·       DR portion of Mission (if selected): Mission Status Window that allows user to observe system behavior as AUV performs DR navigation.

 

·       Search/Track Towards Acoustic Bearing portion of Mission (if selected):

-        Read Acoustic Bearing information from a file called “acousticbearing.dat” located in the same directory from which the Java code is being executed.

-        This file is to be read once every second

-        Each line of this file is a single string of data (e.g. F1200B187.9) that must be parsed, and represents the frequency and bearing of any acoustic contact detected by the acoustic suite.  Note that fields are not of fixed length.  The fields in the example are Frequency 1200 Hz, Bearing 187.9 degrees.

-        If the signal detected matches the frequency the user has set in the search for/track towards portion of the Mission Planning GUI, then the bearing to the signal becomes the “targeted” heading, and the AUV is turned to the bearing of the acoustic contact using differential thrust (half-speed forward and half-speed reverse on the Port and Starboard Analog Motors as appropriate to turn in the shortest direction towards the acoustic bearing).  Note that since a file simulates the Electronic Compass, the heading will not actually change due to the motor commands in this simulation, but the desire of the AUV to turn should be observable upon inspection of the analog motor power settings.

-        If signal is lost (simulated via the textfile data), bear towards the last known direction of signal

-        If signal has not yet been detected, proceed on random heading, changing heading at least 20 degrees every 60 seconds. Again, note that since a file simulates the Electronic Compass, the heading will not actually change due to the motor commands in this simulation, but the desire of the AUV to turn should be observable upon inspection of the analog motor power settings..

-        When the end of file is reached, the system should continue to the next portion of the simulated mission.

-        If the file does not exist, the system should so inform the user via a dialog box, and then continue to the next portion of the simulated mission.

 

Manual Mission, creates:

-        Threads that take input from the user via the Manual Mission GUI inputs, and sends power setting commands to the Analog Motors as appropriate.  Each input entered by the user is to be logged into a file called “manualmission.dat”

 

5. Dead Reckoning (DR) Navigation

·       DR portion of Mission (if selected by mission planning subsystem):

-        Read requested analog motor power setting commands from a file (filename is as described in Mission Planning above).

-        This file is to be read once every second

-        Each line of this file is a single string of data (e.g. Bow-0.4Stern-0.4Port2.3009Starboard-2.3) that must be parsed, and represents the commanded power setting for each analog motor. Note that the fields are not of fixed length.  The fields in the example are Bow motor reverse at 0.4 power setting, Stern motor reverse at 0.4 power setting, Port motor forward at 2.3009 power setting, Starboard motor reverse at 2.3 power setting.

-        When the end of file is reached, the system should continue to the next portion of the simulated mission.

-        If the file does not exist, or contains improperly formatted data, the system should inform the user via a dialog box, and then continue to the next portion of the simulated mission.

 

 

Simulated AUV Hardware:

 

  • Electronic Compass:

-        Simulated by a textfile called “compass.dat” located in the same directory from which the Java code is being executed.

-        This file is to be read once every second.

-        Each line of this file is a single string of data (e.g. "C187.9P1.2R0.8"), which must be parsed.  Note that fields are not of fixed length.  The fields in the example are heading (187.9 degrees true), pitch (1.2 degrees), roll (0.8 degrees).  The values provided by the compass for pitch and roll will be ignored by the simulator.

-        If the file does not exist, contains improperly formatted data, or the end of file is reached, the system should so inform the user via a dialog box.

 

  • Analog motors:

-        There are 4 analog motors; Bow, Stern, Port, and Starboard, each of which are sent a power setting consisting of floating point numbers that range between –5.0..5.0 volts. 

-        Negative power setting commands call for reverse (relative to the motor) thrust of varying intensity with –5.0 being maximum reverse thrust.

-        Positive power setting commands call for forward thrust of varying intensity with 5.0 being maximum forward thrust.     

-        If a power setting greater than 5.0 or less than –5.0 is requested, the system shall provide only a setting of 5.0 or –5.0 respectively.

 

  • Altimeter:

-        Simulated by a textfile called “altimeter.dat” located in the same directory from which the Java code is being executed.

-        This file is to be read once every second.

-        Each line of this file contains a single floating-point number, which provides the depth of the unit in meters.

-        If the file does not exist, contains improperly formatted data, or the end of file is reached, the system should so inform the user via a dialog box.

 

  • Acoustic Suite:

-        Simulated by a textfile called “acousticbearing.dat” located in the same directory from which the Java code is being executed.

-        This file is to be read once every second.

-        Each line of this file is a single string of data (e.g. F1200B187.9) that must be parsed, and represents the frequency and bearing of any acoustic contact.  Note that fields are not of fixed length.  The fields in the example are Frequency 1200 Hz, Bearing 187.9 degrees.

-        If the file does not exist, contains improperly formatted data, or the end of file is reached, the system should so inform the user via a dialog box.

 

Notes:

  1. All textfiles are to be accessed via their own separate user-defined wrapper-classes to facilitate the connection of the system to serial ports in the spring.  The role of a wrapper class is to provide a common abstraction between the software system and the system’s hardware.  The software system interacts only with the wrapper class, and the system hardware likewise only interacts with the wrapper class.  Thus, any change to either the system’s software or hardware only needs to be reconciled with the wrapper class.
  2. Everywhere in the above where something is to occur “once per second”, it is sufficient that, in the case of a thread, the thread sleep(1000) and then continue.