AUViking Design Overview

 

Revision 1.0

 

In partial fulfillment of the requirements of

Design Project CENG499

 

By

Donovan Parks (9905396)

 

Team Members:

Mark Campbell (9805386)

Zahid Rajabali (9809247)

 

Date

April 1, 2003

 


TABLE OF CONTENTS

 

1.0 Introduction. 1

2.0 6th AUVSI International AUV Competition. 1

2.1 Competition Overview.. 1

2.2 Competition Constraints. 3

3.0 Incremental Approach to Building an AUV.. 4

4.0 AUViking Overview.. 6

4.1 Communication System.. 6

4.2 Host 7

4.3 Dockside Computer 7

4.4 Vision System.. 8

4.5 Sensor Controller 8

4.6 Sonar Controller 8

4.7 Navigation Controller 9

4.8 Motor Controller 9

4.9 Mechanical Design. 10

4.10 Propulsion System.. 10

4.11 Token Release Mechanism.. 11

4.12 Power System.. 12

5.0 AUViking in the 6th AUVSI International AUV Competition. 12

5.1 Mission Specific Algorithm.. 12

5.2 Subsystems Required for Mission Specific Algorithm.. 14

5.3 Subsystems Required for this Years Goals. 15

6.0 Conclusion. 16

 

References. 17

 

Appendix I – Progress Report #1. I

Appendix II – Progress Report #2. VI


 

LIST OF FIGURES AND TABLES

 

FIGURES

 

Figure 2.1 Competition Arena for the 6th AUVSI International AUV Competition [1] 2

Figure 2.3 Competition Decision Arrows [1] 3

Figure 2.3 Competition Targets [1] 3

Figure 4.1 Block Diagram of AUViking. 6

Figure 4.2 Rendering of AUViking (21” x 15” x 5.375”, ~32Kg) 10

Figure 4.3 Rendering of AUViking Thruster 11

Figure 4.4 Exploded View of AUViking Thruster 11

 

TABLES

 

Table 2.1 Hard Constraints Imposed by Competition Rules. 4

Table 2.2 Soft Constraints Imposed by Competition Rules. 4

Table 5.1 Timetable for Subsystems Required for this Years Goals. 15

 

 


1.0 Introduction

 

The AUVic is a team of engineering and computer science students from the University of Victoria that are actively involved in building an autonomous underwater vehicle (AUV). An AUV is a submersible robot that is able to complete intelligent tasks without aid from human operators.  The team is currently working on its second generation AUV, AUViking.

 

AUViking is being designed to compete in the 6th AUVSI International Autonomous Underwater Vehicle Competition.  The competition will be held on August 7-10 at SPAWAR TRANSDEC in San Diego, California. AUViking should fully meet the constraints specified by this competition and contain subsystems to allow it to complete at least a portion of the competition goals. 

 

The primary goal of the competition is to drop a token onto a target in the competition arena.  Completion of this goal requires an AUV capable of performing controlled maneuvers, detecting of objects, and autonomously making decisions.  Due to the difficulty of designing and implementing such an AUV, an incremental design approach is proposed that will allow generations of AUVic teams to build on the efforts of previous teams.

 

A highly modular design is being used by the AUVic to allow subsystems to be developed independently of each other.  Each of the subsystems proposed for AUViking will be examined along with a discussion of how these subsystems allow AUViking to complete the competition.  All of the systems required to complete the competition are in various stages of development, but it is expected some of them will not be completed before the competition.  This is acceptable and is a result of the incremental design approach.

 

2.0 6th AUVSI International AUV Competition

 

AUViking is designed to compete in the 6th AUVSI International AUV Competition.  The rules for this competition drive many of the specifications for AUViking making an understanding of the competition essential. A summary of the competition rules given in [1] are provided here for convenience. 

 

2.1 Competition Overview

 

The objective of the competition is to score points by completing different tasks.  The major task that must be completed is dropping a token onto the “active” target. Figure 2.1 gives an overview of the competition arena indicating a possible layout of the competition objects. Three targets will be placed in the competition arena, but only one of them will be active.  The active target will be identified by a lit lamp at the “decision point” (see Figure 2.2) as the arrow corresponding to the lit lamp will indicate the direction to the active target. 

 

Before attempting to drop a token into the active target the AUV must first pass through the validation gate.  The validation gate is made from white PVC, measured 72 inches across by 120 inches deep, and is suspended just below the surface of the water.  The validation gate is used to test that the AUV can operate in a controlled manner.  It is not necessary for the AUV to be able to autonomously search for the validation gate.  Instead, at the start of a competition run, the AUV will be pointed directly at the gate and only needs to be able to move in a reliable straight line to pass through the gate (demonstrating the AUV can operate in a controlled manner).  Passing through the validation gate is worth 250 points.

 

Figure 2.1 Competition Arena for the 6th AUVSI International AUV Competition [1]

 

Figure 2.3 Competition Decision Arrows [1]

 

Points are awarded for dropping a token into the active target.  The target is made from foamed PVC and each level is a square with sides of 1, 3, or 5 ft.   Figure 2.3 shows the layout of the targets and indicates the points that are awarded for dropping the token on different levels of the target. 

 

Figure 2.3 Competition Targets [1]

 

Points are also awarded for a number of subjective measures (craftsmanship, team website, team uniform, …) that total 350 points (a complete list of scoring for subjective measures in contained in [1]).  Each kilogram under the 100Kg limit also earns 2 points and significant points are deducted if either the AUV or tokens exceed the specified maximum dimensions or weight.  Each minute under the 15 minute time constraint set for the competition (see section 2.2) also earns the team 100 points if the competition goals are successfully completed (i.e. at least one token is dropped onto the active target).

2.2 Competition Constraints

 

Several constraints are imposed by the competition rules.  These constraints consist of hard and soft constraints which result in disqualification from the competition or heavy deduction of points, respectively.  The hard constraints are given in Table 2.1 and the soft constraints in Table 2.2.

 

Hard Constraints

 

AUV must be completely autonomous and operate only with equipment physically contained on the AUV (no off board computers, GPS, or remote control)

 

AUV must be positively buoyant by 0.5% of their mass

 

AUV must contain a visible ”kill” switch that disconnects all batteries from the propulsion system

Table 2.1 Hard Constraints Imposed by Competition Rules

 

Soft Constraints

 

Maximum weight of AUV is 100Kg in air (to be reduced to 32Kg for the 2004 competition)

 

Maximum dimensions of  AUV is 72in x 36in x 36in

 

Maximum dimension of token is 6in x 1.5in x 1.5in

 

Maximum weight of token is 1.5lbs in air

 

Competition must be completed within 15 minutes

 

Capable of diving to 38 feet (maximum depth of competition arena)

Table 2.2 Soft Constraints Imposed by Competition Rules

 

It is obviously necessary to meet the hard constraints in order to be able to compete in the competition, but it is equally important to meet the soft constraints if a competitive AUV.  AUViking has been designed to meet all of the hard and soft constraints.  This including the reduced weight constraint for the 2004 competition as it is hoped the hull, propulsion system, and many of the electrical system can be used for the next few years.

 

3.0 Incremental Approach to Building an AUV

 

The AUVic currently consists of 14 undergraduate students, 1 former University of Victoria student, 2 faculty advisors, and 1 industry advisor.  The team members are dedicated to realizing a competitive and well designed AUV, but all members have additional commitments that significantly reduce the number of man-hours that can be put into AUViking.  It is felt that the AUVic team does not have enough resources in terms of time, money, or expertise to building an AUV capable of completing the 6th AUVSI International AUV Competition.

 

It is believed that by focusing on a subset of the competition a well-designed AUV (although lacking some subsystems) can be built that can be extended by future teams.  It is hoped that a future team will maintain this philosophy of providing quality subsystems for future teams.  In this manner, the AUVic will be able to build a professionally designed and built AUV that far exceeds the capabilities of any one years team.

 

The 2002/2003 team is the first team to follow this incremental approach to building an AUV. Last years team tried to build a complete AUV which resulted in several partial complete subsystems and a barely functional mechanical design.  Most of these subsystems could not be used as a starting point, as they were poorly designed due to unrealistic time pressures.  This experience is a major reason for adopting the incremental approach.

 

Several goals, both technical and non-technical, have been defined for the AUViking team. The primary purpose of these goals is to ensure the University of Victoria has an UVic team in the future and to provide these teams with a mechanically sound AUV to build from. 

 

A strong recruiting effort at the start of this year has brought in several students from second and third year to work on the AUV.  These members have shown great enthusiasm for the project and will make the core of next years team.  In addition, many of the graduating members have indicated they wish to continue helping the team.    Efforts have also been made to increase awareness of the project by publishing a bi-monthly newsletter, establishing a team website, having an article in the Martlet, and displaying the AUVic during the CENG/ELEC 499 poster presentation.

 

The primary goals for AUViking will be to operate independently of any human operator, perform controlled dives and maneuvers, and to be able to reliably pass through the validation gate.  These goals require a sound mechanical design, a reliable propulsion system, and a navigation system to allow a straight path to be traversed.  To verify a sound mechanical design and reliable propulsion system AUViking will initially be configured to operate as an ROV.  This will allow for extensive testing of these two systems and provide a convenient method of testing other systems (i.e. testing of a pressure sensor by manually controlling AUViking to a given depth). The navigation system will consist of a high precision compass and suitable control software in order to allow AUViking to follow a compass bearing. 

 

Additional subsystems that will allow AUViking to complete the competition are being worked on, but the majority of time and money will be spent on the subsystems necessary to meet the goals discussed above.  The work on these other subsystems will provide a starting point for future teams and may allow us to exceed our goals for this year. However, if it appears the goals above will not be met work will be halted on these additional subsystems. All the subsystems being worked on are discussed in section 4.0. 

 


4.0 AUViking Overview

 

Figure 4.1 is an overview of the subsystems on AUViking. The majority of subsystems reside on an I2C bus which relies on a custom communication system and are implemented around a Microchip PIC16F876 microcontroller.  The high data rates required by the cameras make placing it on a separate connection a more suitable option.  Each camera is directly interfaced to the host through a USB connection where all vision processing is performed.   The final connection in AUViking is a TCP/IP link from the host to an external, dockside computer.

 

Figure 4.1 Block Diagram of AUViking

 

AUViking is far more than the subsystems shown in Figure 4.1. It is a complete autonomous vehicle requiring a robust and reliable mechanical design.  In addition, a complete power system must be contained onboard to drive all the electrical systems and the propulsion system.

4.1 Communication System

 

The AUVic Communication System (AUVic-CS) allows for communication between the host and most subsystems on the AUV [2].  There are three types of components in the communication system: the host, the hub, and intelligent peripherals (sensor or actuator).  Communication with intelligent peripherals is done through a well-defined interface enforced by the AUVic-CS.  An intelligent peripheral is required to follow this protocol and will be independent of any other systems on the AUV (except for power).  This allows these peripherals to be designed in parallel. 

 

The hub acts as a protocol translator between the host and intelligent peripheral network.  The intelligent peripherals communicate with the hub over a multi-drop, half-duplex inter-integrated circuit (I2C) network and the host communication with the hub via a standard RS232 serial port.  The hub also provides error checking and recovery and has the ability to reset any peripheral on the I2C network by toggling a Dallas 1-Wire digital switch contained on each intelligent peripheral.

 

The host performs integrated processing of data received from the various intelligent peripherals and the vision system in the AUV.  It is responsible for the high level control of AUViking.  Operation of the host is discussed in more detail in section 4.2.

4.2 Host

 

The host is the central processing unit in the AUViking. It is responsible for gathering sensor data, processing this data, and setting the actuators (motors) based on sensor data and desired goals for the AUV.   Intelligent behaviour emerges from AUViking by mission specific algorithms processing the sensor data and setting the motors accordingly.  For example, a simple algorithm on the host is collision avoidance that ensures the AUV is always a minimum distance away from the bottom of the pool by using data from the sonar system.

 

Vision processing is also performed by the host. This processing is done as a separate thread and results of the processing are passed to the mission specific algorithms.  In order to be able to handle the processing demands for vision a high speed processor is required.  AUViking uses a MSI 300MHz PC/104+ embedded PC for this reason.

4.3 Dockside Computer

 

A dockside PC can be connected to the Host via an external ethernet connection.  Software is currently underdevelopment that will allow all sensor and status information to be polled for AUViking via this TCP/IP connection.  This will facilitate debugging and understanding the capabilities of the AUV. 

 

This link also provides a means to allow AUViking to be operated as an ROV.  Software has already been developed that allows control of a single motor controller and it is expected that this software can easily be modified to allow full control over all motors on AUViking.  Controlling AUViking as an ROV will drastically reduce the difficulty in testing different sensor subsystems and allow us to better understand the dynamics of AUViking when moving through the water.

 

In addition, the host and all PIC16F876 will be re-programmable through this connection allowing all software aboard AUViking to be modified without requiring it to be opened or removed from the water.

4.4 Vision System

 

It is expected that the final vision system for AUViking will consist of two Intel Pro Video PC Cameras.  One of these cameras will be faced directly downwards and the other facing forward at an approximately 45 degree below horizontal.  Both cameras are connected directly to the host a USB connection.

 

The downward facing camera will be used to:

·       indicate when AUViking has passed over the decision point

·       identify which arrow at the decision point contains a lit light

·       provide data indicating the compass bearing AUViking needs to follow to reach the active target

·       indicate when AUViking is over the target so should release the token

 

The forward facing camera will be used to:

·       guide AUViking when approaching the decision point

·       guide AUViking when approaching the active target

 

Computationally expensive processing is required to obtain the required information from the images captured with the cameras.  It is expected that this computation can be done within the host.  However, the software is still under development so the exact amount of processing power required is unknown.  Testing of different frame rates and image resolutions is also required before the exact computational expense can be calculated.  If required the host can be replaced to give us the processing power required.

4.5 Sensor Controller

 

The sensor controller is responsible for obtaining data from an Invensys SPT4V0030 pressure sensor and two Dallas Semiconductor DS1812 temperature sensors while monitoring the voltage level of the motor and electronic batteries.  The pressure sensor is used to measure the depth of AUViking from the waterline and allows AUViking to dive to and operate at a given depth.  The temperature sensors measure the ambient temperature inside the AUV at two different locations in order to ensure the temperature remains at a safe level.  If this safe level is exceeded subsystem may start to fail or even be damaged. Battery voltage is monitored using the ADC capabilities of the PIC16F876 and a simple voltage divider.

4.6 Sonar Controller

 

Six Navman 002156 transducers are controlled by the sonar controller which allow for collision avoidance, wall tracking, and depth measuring.  A single transducer is placed on each vertical side of AUViking and the remaining two are placed on the bottom.  Collision avoidance ensures the safety of AUViking and is achieved by maintaining a threshold distance away from all objects detected.  Wall tracking is a potentially useful behavior that would allow AUViking to maintain a constant distance from the edge of the competition arena.  Depth measuring will be exploited to help line up AUViking over the top level of the active target.  

 

The sonar controller currently being designed is fair from optimal as only a single transducer can be operated at any given time. However, this limitation has greatly simplified the design of the system hopefully allowing it to be completed before the competition.  It is expected that next years team will concentrate on a more robust sonar controller. This design decision is driven by incremental design approach discussed in section 3.0. 

4.7 Navigation Controller

 

Navigation is primarily done with a 3-axis Honeywell HMR3000 compass which provides heading, pitch, and roll data.  Heading data has a resolution of 0.5°, with a response rate of 20Hz, and can compensate for static magnetic fields.  Pitch and roll data is available between +/- 40° and has an accuracy of better than 0.6°.  This data is used to allow AUViking to follow a given compass bearing and ensure the vehicle remain relatively level.

 

A simple inertial guidance system was also investigated.  This system used an Analog Devices AXDL202 2-axis accelerometer and the Honeywell HMR3000 compass.  The system calculated relative position based on the accelerations of AUViking.  Pitch and roll data from the compass was used to compensate for any accelerations due to gravity.  The inertial guidance system was found to work in principle, but was very inaccurate [4].  Due to the inaccuracy of this subsystem it will likely not be used on AUViking.  

4.8 Motor Controller

 

The AUVic Motor Controller (AUVic-MC) is a medium-power motor controller capable of driving a single DC permanent magnet motor [5]. The motor is controlled using a signed magnitude PWM control signal.  It can handle motors requiring up to 30V at 30A continuous current. This is sufficient to drive the small trolling motors that are commonly used on AUVs at the AUVSI competition.

 

A robust set of functionality is provided by the AUVic-MC. This includes 10-bit control over the speed of the motor, setting acceleration rates from 0.4096 second to ~7.5 hours, and setting the desired operating frequency.  Each of the three motors on AUViking is controlled by an AUVic-MC.

4.9 Mechanical Design

 

AUViking consists of a polycarbonate (Lexan) upper shell, an ultra high molecular weight polyethylene (UHMW) base plate, an aluminum central tube, and aluminum side handles.  The upper shell is transparent to allow for easy visual inspection of all subsystems, indicator LEDs, and LCDs.  It is attached to the UHMW base plate using a series of clamps and the seal made waterproof by using a custom nitrile rubber o-ring.  The base plate is made from aluminum to allow for easy mounting of external sensors and connectors.  Handles have been added to aid in transporting AUViking and act as a bumper while the AUV is in operation.  The central tube allows a single thruster to be used for controlling the vertical motion of AUViking.

Figure 4.2 Rendering of AUViking (21” x 15” x 5.375”, ~32Kg)

 

It is hoped the mechanical design of AUViking can be reused in the future.  For this reason, it has been designed to meet the maximum weight constraints of 32Kg for the 2004 competition.  To further increase the reusability of the mechanical design a simple and adjustable mounting system is being used.  This mounting system uses the UHMW base plate for all mounting.  The benefit of this approach is mounting of sensors or external connectors are easy as the UHMW plate can be replaced each year as requirements change.  A distinct weakness of this approach is that all mountings must be from the UHMW base plate as the upper shell will lose its structural strength if drilled through and the shell is far more expensive to replace.  Sensors that must reside on the side of the AUV are required to use ‘L-brackets’.

4.10 Propulsion System

 

The propulsion system on AUViking has been designed to decouple control over horizontal and vertical movement.  This significantly reduces the complexity of the required motion control software.  Decoupling the control also allows AUViking to dive “on the spot” – a useful behaviour allowing AUViking to dive closer to objects if required.   The two thrusters providing motion in the horizontal plane allow AUViking to turn around its vertical axis, make banking turns while moving forward or in reverse, and travel in straight lines.  To further reduce the complexity of the motion control software, AUViking will not make banking turns and instead will always travel in a straight line and turn by coming to a complete stop and turning on the spot.

 

All three thrusters on AUViking are identical in order to reduce fabrication time and costs (see Figure 4.2 and Figure 4.3).  A common thruster design also reduces the number of spares required.  The casing for the thrusters is made from Delrin.

 

 

Figure 4.3 Rendering of AUViking Thruster

 

 

Figure 4.4 Exploded View of AUViking Thruster

 

AUViking does not require a high top speed and the Global Motor motors used were chosen to keep power requirements and weight to a minimum while still providing sufficient thrust to allow AUViking to travel at a maximum speed of 0.5m/s.  In practice, AUViking will likely operate at a fraction of this speed in order to further reduce power requirements and to give sufficient time to perform all required processing.  The vertical motor will require minimal thrust to dive AUViking as it will be positively buoyant by just over 0.5% of its mass (0.5% is the constraint set by the competition rules).

4.11 Token Release Mechanism

 

The token release mechanism is in the preliminary design stage and research is being conducted into the possibility of using Nitanol wire.  Although conceptually simple, it is important that this system be extremely reliable and aid the token in falling in a straight path.  

4.12 Power System

 

Each motor will likely use a single 12V, 7AH Powersonic SLA battery.  At this time, it is unknown how much power each thruster will require on average.  The aim for the power system is to provide 1 hour of operation time.  This is far more than required by the competition (maximum completion time is 15min), but will allow use to conduct testing without constantly changing and recharging batteries.

 

A set of 4 Radioshack NiCd battery packs will be used to provide 14.4V at 4AH for use by the electronics.  The power supply system converts this voltage using step-down switching regulators and linear regulators to obtain regulated +/-5V and +/-12V.  These regulated voltages are provided for use by each controller.  Current requirements for these regulated voltages have been estimated at 3A, 0.5A, 1A, and 0.5A for the +5V, -5V, 12V, and -12V, respectively.

 

5.0 AUViking in the 6th AUVSI International AUV Competition

 

A preliminary algorithm has been completed that details how AUViking will complete the 6th AUVSI International AUV Competition. This preliminary algorithm was used to determine what subsystems were required and what the specifications for these subsystems should be.  The algorithm will need to be modified as subsystems are complete and testing is done to determine their true capabilities (i.e. if they exceed their specifications more sophisticated behaviour may be possible or if they do not meet their specification an alternative algorithm may be required).

 

Although the AUVic team is working on all subsystem required to implement the preliminary algorithm developed here it is expected that some of these systems will not be completed.  This section will conclude with a discussion of the subsystems required to meet this years goals.

5.1 Mission Specific Algorithm

 

The algorithm works by moving through a sequence of 10 steps.  Each step is conceptually simple, but requires a collection of sophisticated algorithms (mostly image processing) and sensor subsystems.  Failure by AUViking to detect a transition condition between steps will result in the failure of the algorithm.  The algorithm can be made more robust by adding in steps that will inform AUViking that is has missed a transition condition (for example, when making the transition between steps 1 and 2 if AUViking approached within a given distance to the walls of the pool or if a timer expires AUViking can assume it has missed the transition point and start a spiral search for the decision point). These additional steps have not been developed and will be added to the base algorithm presented here after extensive testing.

 

  1. Pass through Validation Gate: At the start of the competition AUViking will be positioned so it can travel a straight line through the validation gate to the decision point.  Once it is aligned, a start button will be pressed that will cause AUViking to record the current compass heading.  AUViking will start its path to the decision point by diving to 3 feet. It will than proceed along the straight line path to the decision point. A PID control algorithm will be used to allow AUViking to travel along the compass bearing despite possible thrust differences in the two horizontal motors and possible rotational tendencies when it dives.

 

  1. Identify Decision Point: AUViking will continue to travel along the recorded compass bearing until the vision system detects the decision point by processing images from the forward facing camera.  At this point, information from the forward and bottom camera will aid in bring AUViking over the decision point. 

 

 

  1. Determine Active Arrow: Once successfully hovering over the decision point the bottom facing camera will determine the active arrow (i.e. that arrow containing a lit lamp) using an appropriate image processing algorithm. 

 

  1. Calculate Heading to Active Target: After the active arrow has been identified image processing will be used to calculate a vector indicating the direction of the arrow.  This information will be used to rotate AUViking until it is in alignment with the arrow.  Correctly identifying the compass bearing indicated by the active arrow is critical as it is the only method of determine that active target. For this reason, AUViking may spend significant time to correctly orientate itself and modify its vertical position to optimize the orientation.  It is felt this method of orientating AUViking with the arrow will produce better results than mathematically calculating the required bearing based on the current compass bearing and the vector calculated for the active arrow.

 

  1. Identify Active Target: AUViking will continue to follow the bearing indicated by the active arrow until the vision system detected the active target by processing images from the forward facing camera.  Data from the vision system will than be used to aid AUViking in navigating over the active target.

 

  1. Position AUViking over Center of Active Target:  Images obtained from the bottom facing camera will be used to position AUViking over the center of the active target.  A physical or software “sightline” has been proposed for this purpose. 

 

  1. Release Token: Once the vision system indicates AUViking is correctly aligned over the active target the token release mechanism will be activated to release the first token. 

 

  1. Check for Token Hit: After releasing the first token the vision system will be used to determine where it landed.  If it landed on the highest level of the target the second token will be immediately release and AUViking will surface (see step 10).

 

  1. Adjust Position for 2nd Token:  If the first token did not land on the highest level of the target the vision system will provide information to allow AUViking to adjust its position.  After releasing the 2nd token AUViking will proceed to surface.

 

  1. Surface:

AUViking can be made to surface by bring the vertical motor to a halt as it will be positively buoyant by at least 0.5% of its mass.  The competition rules state a competition run has ended when the AUV surfaces.

5.2 Subsystems Required for Mission Specific Algorithm

 

Regardless of the algorithm used, certain subsystems are always required as they form the core of AUViking.  This includes the host, hub, motor controllers, power system, propulsion system, and the hull itself. To implement the above algorithm the following subsystems/sensors are also required:

  1. Vision System: It is clear that a sophisticated vision system is required in order to complete steps 2, 3, 4, 5, 6, 8, and 9.  Each of these steps require different image processing algorithms.  These algorithms are being developed in the order required by the mission specific algorithm.
  2. Pressure Sensor: To allow AUViking to dive and hover at a set depth as required by step 1, 4, 6, and 9. The accuracy of the depth measurement is not critical.
  3. Compass: To allow AUViking to follow the straight line path required for steps 1 and 4.  The accuracy of the bearing measurement is critical to the success of AUViking.
  4. Token release mechanism: This subsystem was designed specifically for this competition and is required for step 7.

 

The sonar system may be used to aid in positioning AUViking over the center of the target (step 6) by moving AUViking to minimize the distance reported by a bottom facing transducer.  However, it is expected the vision system will give better results.  A more important reason for including the sonar system on AUViking is for collision avoidance. 

The temperature sensing and voltage monitoring capabilities are used strictly for diagnostic purposed.  When in operation AUViking will perform self-diagnostics to ensure the internal temperature stays within safe bounds.  Voltage monitoring is provided as a convenience during testing and while at the competition so it can quickly be determined if the batteries need to be replaced.

 

Fortunately, the algorithm does not require an inertial guidance system.  As discussed in section 4.7, the implementation of this subsystem has been completed, but it suffers from accuracy problems making its use limited on AUViking.  It should be noted that work began on the inertial guidance system before the competition rules were published.

5.3 Subsystems Required for this Years Goals

 

In section 3.0 it was stated that the primary goals for AUViking are the ability to operate independent of any human operator, perform controlled dives and maneuvers, and to be able to reliably pass through the validation gate.   These are the same capabilities required to complete step 1 of the mission specific algorithm.

 

These goals can be met with the core subsystems of AUViking (host, hub, motor controllers, power system, propulsion system, and the hull itself), the compass, and the pressure sensor.  Sufficient time is also required for integrating these systems and writing the required host software.  Table 5.1 indicates the progress made of these subsystems.

 

Subsystem

Current State of Subsystem

Expected Completion Date

Host

·       Linux successfully installed

·       Host capabilities fully tested

Complete

Host Software

·       Software for communication system needs to be ported to Linux

·       No work has been done on mission specific algorithm

June 30

Hub

·       Complete except for having PCB manufactured and populated

May 30

Compass

·       Software must be ported to Linux

·       Testing of accuracy in proximity of motors must be performed

June 20

Pressure Sensor

·       Final testing required

June 20

Power System

·       Finalizing design

June 10

Motor Controllers

·       Complete except for  populating PCB

May 30

Propulsion System

·       Design completed

June 15

Hull

·       Design completed

June 15

Table 5.1 Timetable for Subsystems Required for this Years Goals

 

AUViking should be able to operate as an ROV shortly after completing the hull and propulsion system.  This will allow extensive testing of the mechanical properties of AUViking and facilitate writing of motor control software and a PID algorithm. During the month of July subsystems will be integrated into AUViking as they are completed.  It is expected the AUViking will be able to reliably pass through the validation gate by July 20.

 

6.0 Conclusion

 

An incremental design approach has been presented that encourages teams to concentrate on a small selection of subsystems and ensure these are designed and implemented to a high standard.  Future teams will than be able to reuse these subsystems with little or no modification.  This will allow the AUVic to produce an AUV that far exceeds the resources and skills of any single team.  It is hoped future teams will employ this design methodology.

 

The subsystem selected by the 2002/2003 were chosen to provide AUViking with the ability to operate independent of any human operator, to perform controlled dives and maneuvers, and to reliably pass through the validation gate.   Along with a reliable mechanical design and propulsion system, the following subsystems must be completed in order to achieve the desired abilities:

o      fully operational host processor with appropriate behavioral control software

o      complete communication protocol (including hub)

o      compass component of the navigation system

o      pressure sensor component of the sensor system

o      motor controllers

o      power system

It is expected the AUVic will reach its goal for this year.

 

To guide the development of AUViking a preliminary mission specific algorithm was developed for the 6th AUVSI International AUV Competition and used to derive the subsystem required by AUViking. This algorithm has driven not only the subsystem defined for AUViking, but also their specifications and relative priority.  Each of these subsystems has been discussed in order to provide an overview of AUViking.


 

References

 

[1]       AUVSI, “Official Rules and Mission for the 6th Annual International Autonomous Underwater Vehicle Competition”, 2003 March 28, [cited 2003 April 1], Available at: http://www.engr.uvic.ca/~macampbe/auv499/home/Rules_Mission_Final.pdf

 

[2]       D. Parks, “Embedded Communication System for an Autonomous Underwater Vehicle”, 2003 January 4, [cited 2002 April 1], Available at:

            http://www.engr.uvic.ca/~macampbe/auv499/overview/AUVic-CS_(ENGR446).pdf

 

[3]       Z. Rajabali, (insert link here)

 

[4]       M. Campbell, “AUV Inertial Guidance System”, 2003 April 1, [cited 2003 April 2], Available at:  http://www.engr.uvic.ca/~macampbe/auv499/igs/IGS_499_report.html

 

[5]       D. Parks, “AUViking Motor Controller”, 2003 March 25, [cited 2003 April 1],

Available at:

http://www.engr.uvic.ca/~macampbe/auv499/mc/motor_controller.html      


Appendix I – Progress Report #1

 

CENG 499

Progress Report #1

 

 

Date Submitted:             January 31, 2003

 

Team Members:             Zahid Rajabali (9809247)

                                    Mark Campbell (9805386)

                                    Donovan Parks (9905396)

 

Problem Definition

 

A group of engineering and computer science students, along with faculty and industry advisors, have formed a team (known as the AUVic) to compete in the 6th International Autonomous Underwater Vehicle (AUV) Competition (www.auvsi.org).  Our goal is to design and build an AUV capable of completing the tasks specified by this competition.  At a minimum, this requires an AUV that can:

 

The 6th International AUV Competition will be held on August 7th San Diego.

 

 

Method of Solution

 

The AUVic is composed on approximately 16 members working on different aspects of our 2nd generation AUV, AUViking. To facilitate parallel design and construction, AUViking is designed to be extremely modular.  Figure 1 shows a preliminary block diagram of the systems on AUViking.  

 

     

Figure 1. AUViking Systems Block Diagram

 

Centralized processing is performed by the host and is responsible for keeping track of the current task AUViking is working on and performing integrated processing of all controller data in order to determine how to complete this task.  Modularity is achieved by providing a well defined interface between the host and each controller (intelligent sensor or actuator) aboard AUViking.  This effectively “black boxes” each controller and allows them to be designed and implemented independent of the rest of AUViking.

 

The block diagram in Figure 1 was designed based on the rules for the 5th International AUV Competition.  Rules for the 6th International AUV Competition were recently released (January 26) and it is transparent some modifications to the current design our necessary.  Specifically, a “release token” system is required and perhaps a “light sensor” array.

 

A major component of an AUV is its mechanical design.  This includes the hull and propulsion system.  This aspect of AUViking is being handled by Dean Steinke as a MECH 499 project and will not be discussed here.

 

 

Scope of Project

 

Even with the large number of members currently involved with the AUVic it is highly unlikely an AUV capable of completing the 6th International AUV Competition can be designed and built.  Last year, the winning team, MIT, was using a 5th generation AUV and won the competition by reading 4 of 16 barcodes placed around the pool.  Due to the difficulty of the competition and financial and time constraints the AUVic team has decided to focus on a subset of the competition.

 

The primary goals for AUViking will be to: 

 

Systems that will allow AUViking to complete additional aspects of the competition are being worked on, but the majority of time and monies will be spent on systems necessary to complete these tasks.  It is hoped that next years team will be able to use AUViking as a solid starting point so they can concentrate on designing systems specific to the 7th International AUV Competition.

 

 

Team Organization

 

The AUVic team is composed into a “chain of command” to facilitate decision making and assigning of tasks.  A team captain (Donovan Parks) is responsible for guiding the overall team effort, ensuring systems stay on schedule, and handling administrative details. Each system is assigned a supervisor (Dean Steinke – mechanical, Ziko Rajabali – navigation, Kelly Stich – power, Jay Armstrong – sonar, Donovan Parks – motor controllers, Chris Ng – TCP/IP link) that is responsible for designing their system and coordinating the activities of any members that are assisting with that system.  Communication amongst team members is achieved by weekly meetings and through a mailing list.

 

 

Assigned Tasks

 

A brief description of the main task(s) assigned to each of the members of the CENG499 team will be outlined here.  It should be noted the numerous small tasks will be performed by each member as well - aiding with sponsorship efforts, finding waterproof connectors, reviewing PCB layouts, etc.

 

 

Mark Campbell (Inertial Guidance System)

 

The inertial guidance system will consist of a 2-axis accelerometer contained in single monolithic IC, a 3-axis compass, and a PIC16F876 microprocessor. The compass provides heading, pitch and roll information to the PIC.   With this information and sampled acceleration measurements the PIC will calculate the current position of the AUV relative to some initial starting point. This is analogous to dead reckoning in a sailboat. The current position will be sent to the host via the I2C network.

 

Work on the inertial guidance system began in September 2002 and it will be complete before April 2003.  Mark’s main focus is this system and he will have limited involvement with AUVic this semester outside the requirements of CENG499.

 

 

Zahid Rajabali (Navigation, Networking, Image Processing)

 

Project 1: Navigation

This is a system that has been in the making since last year. In the year prior, algorithms were developed, but the microprocessor-device communication was never established. My task for the last few months has been implementing this communication and verifying that the algorithms are indeed correct. Communication was established in early November, but verification of the algorithms was not completed as the HMR3000 (our navigational device) was fried (by my negligence). Since then, I have created an almost-fully functional GUI simulator for a Windows-based PC in C++, and have verified the algorithms up to this level. I have also been on the hunt for a donated HMR3000 or some similar device.

 

Project 2: Network

The implementation of a network is very high-level in this case, since we are dealing with a shrunk-down distribution of the Linux kernel on our host, with a network card designed for LAN connections. The only tasks involved, for the time being, is to ensure the network-communication

software is functional and the host can connect to a laptop.

 

Project 3: Image Processing

As this task was designated only this past Wednesday, two days prior to the release of this report, and the preliminary design rules were released not long before that, this project has

not yet begun. Its current status would be on a medium-high queue.

 

 

Donovan Parks (Motor Controllers, Reprogrammable PIC Controller, Control Algorithm)

 

The motor controller provides an intelligent interface to control the motors and performs self diagnostic.  Communication between the host and motor controller is done by I2C.  The host can set several properties of the motor controller: desired motor speed, acceleration rate, desired current and temperature limits, etc…  The motor speed is set using a PWM signal generated by a PIC16F876 that drives a MOSFET h-bridge being controlled by a LT1162 h-bridge controller.  Current and temperature limiting are performed by the PIC16F876 to ensure the motor controller stays within safe operating limits.

 

The design and construction of the motor controllers started in September 2002. The motor controller is currently being extended to allow the speed and direction of the motors to be determined from a quadrate encoded signal from the motors.  A PCB for the motor controller is in progress.

 

It is highly desirable to be able to reprogram AUViking without requiring the hull to be opened.  The host can be reprogrammed via the TCP/IP connection and the PIC16F876 in each controller can be reprogrammed via their serial bootloader.  The Reprogrammable PIC Controller will attach to a serial port on the host and allow reprogramming of any PIC16F876 by forwarding data from the external TCP/IP connection to the serial port.  The task is not high priority, but would significantly reduce the time to debug and test different configurations of AUViking.  However, several design issues still need to be resolved before the time required to complete this task can be estimated. This task will only be carried out to completion if it can be done in a reasonable amount of time and higher priority tasks are on schedule.  

 

To successfully navigate through the validation gate requires an AUV that can follow a compass bearing.  This can be achieved with a suitable control algorithm running on the host. Research, design, implementation, and testing of a suitable control algorithm (likely PID) must be done. 

 

 

Anticipated Timetable

 

The following tables give anticipated dates for milestones in each system listed above.  The priority ranking is from 1-10 with 10 being the highest priority.  It is a measure of how important the system is to AUViking for the 6th International AUV Competition.

 

Inertial Guidance System

 

Member(s): Mark

Task

Priority

Date To Complete

Completion Date

Research IGS Theory

2

September 21

September 21

Determine Packets to Send/Receive from Host

2

September 21

September 21

General IGS Algorithm

2

September 21

September 21

Learn Development Environment

2

October 20

October 20

Schematic

2

November 3

November 3

Perform calibration measurements for ADXL202

2

November 3

November 3

Build hardware

2

December 15

December 15

Develop IGS Software

2

February 15

 

Basic Testing

2

February 31

 

Final Testing and Modifications

2

April 15

 

 

Motor Controller

 

Member(s): Donovan

Task

Priority

Date To Complete

Completion Date

Quadrate Encoding

10

January 31

 

PCB Layout

10

February 7

 

PCB Testing

10

~ February 21*

 

*dependent on when manufactured PCB arrives

 

Reprogrammable PICs via Data Link

 

Member(s): Donovan

Task

Priority

Date To Complete

Completion Date

Feasibility Analysis

5

February 15

 

Completion

5

March 31

 

* timetable will be expanded after feasibility analysis is complete

 

PID Algorithm

 

Member(s): Donovan, Chris

Task

Priority

Date To Complete

Completion Date

Research

9

February 21

 

Software Simulation

9

March 21

 

Software Working on Host

9

March 31

 

Testing Performance on AUV

9

April 15*

 

* dependent on completion of several systems including the hull, propulsion system, …


Appendix II – Progress Report #2

 

CENG 499

Progress Report #2

 

 

Date Submitted:             February 27, 2003

 

Team Members: Zahid Rajabali (9809247)

Mark Campbell (9805386)

Donovan Parks (9905396)

 

Introduction

 

Progress on AUViking has been steady and we are confident a capable AUV will be ready for the 6th International AUV Competition (IAUVC) to be held on August 7-12.  Several new members have joined the team since January.  However, due to their inexperience (most of them are first and second year students) and the learning curve required to becoming familiar with AUV technology and AUViking we have not extended the scope of the project as outlined in the first progress report.  

 

Meetings are being held on a weekly basis to report any general news and facilitate the exchange of information and ideas.  The majority of time at these meeting is spent in smaller “system groups” where detailed design and implementation details are discussed.   During the week, work is done independently or during times set by the supervisor of each system.  This informal method of scheduling has proven effective and is well-suited to the varying work load of members due to school.

 

 

Revised Method of Solution

 

AUViking is being designed to complete in the 6th IAUVC.  The system block diagram in our initial progress report was based on the rules for the 5th IAUVC as this years rules were not yet available. Preliminary rules for the 6th IAUVC were made available on January 26 and have resulted in some minor additions to our system.

 

The modified or additional systems are highlight in red in Figure 1.  The 6th IAUVC is well suited to using vision so an additional camera has been added to the system.  More importantly, our requirements for the vision system have been greatly increased and it is now considered the most important sensor in the system.  With the new emphasis on vision, the requirements of the sonar system have been relaxed to only require crude ranging information suitable for collision avoidance (it had previously been a key system requiring centimeter accuracy in measuring the depth of objects).

 

A coin release system has been added to AUViking.  This system is required to hold two coins of a specified size and to be able to reliably drop them on command. The design and implementation of this system is being handled by AUVic members not involved in CENG 499.

 

Figure 1. Revised AUViking System Block Diagram

 

 

Progress of CENG499 Members

 

A description of the progress made by each member of the CENG499 team will be outlined here. In addition to the technical tasks discussed, numerous small tasks have been performed by each member. For example, our bi-monthly newsletter is produced by Donovan Parks for distribution to current and potential sponsors (this newsletter and general information on the AUVic can be found at www.engr.uvic.ca/~auv).

 

 

Mark Campbell (Inertial Guidance System)

 

Work on the IGS began in September 2002 and initial testing is now completed. The IGS was found to work in principle, but is very inaccurate.  Due to these inaccuracies it will not meet the requirements of AUViking.  Some consideration is being placed on using the accelerometer in the IGS as a redundant sensor to the compass for reporting pitch and roll information.  The following list summarizes the work that has been completed:

1.      An absolute coordinate system based on magnetic north and a relative coordinate system based on the AUV was established. 

 

2.      Research was undertaken regarding the operation of the PIC16F876 and its relevant peripheral modules and the accelerometer.  Significant time was spent reading through hundreds of pages of data sheets and manuals. 

 

3.      Based on the theoretical relationships between acceleration, velocity, time and position, a processor independent algorithm (pseudo code) was created that would allow the calculation of relative position based on acceleration samples (provided by an Analog Devices ADXL202 accelerometer) and heading, pitch and roll information (provided by a Honeywell HMR 3000 compass).

 

4.      Various settings for the accelerometer operation were decided upon.  The two most important being the duty cycle of its outputs and the bandwidth of one of its internal stages.     

 

5.      The accelerometer, which only comes in a surface mount package, was soldered to a custom copper clad board. This in turn was attached to a proto-typing board with spacers to provide for level mounting.  The accelerometer was then powered up in the lab and its operation tested with an oscilloscope.  Precise output measurements were taken for calibration purposes.

 

6.      Due to the complexity of the calculations required by the IGS, the source code was written in C.  Research was undertaken regarding the C programming language, the capability of a PIC16F876 microcontroller, the operation of the PIC's integrated development environment MPLAB and how to use High-Tech C's ANSI C compiler as a third party tool for MPLAB.  Again, much time was spent reading manuals in order to become familiar with this suite of tools.

 

7.      The code for the PIC was written. It is complete except for the functions that implements the I2C serial communications (these have been written and tested by Donovan Parks independent of the IGS and would require little effort to integrate into the IGS code).  It is about 620 lines long and when compiled produces an executable of about 4Kbytes – well within the 8K of program memory provided by the PIC16F876.

 

8.      Initially some debugging of the PIC code was done with the MPLAB simulator, but it has limited value when testing code that relies heavily on interrupts.  In order to debug the software in real time a LCD was borrowed from the lab technicians.  This was connected to one of the PIC ports so that numeric values could be displayed. Code was written that would take any variable of type double and display the number on the LCD.

 

9.      The IGS system, assembled on a breadboard and proto-typing board, was tested.

 

 

Testing Results

 

For the condition of the accelerometer and hardware being level and not moving, the values of Dx and Dy (duty cycles which are proportional to acceleration) were displayed on the LCD and found to be as follows. 

 

Dx = 51.80-52.00 %                   lab measurement --> 51.75%

Dy = 50.25-50.45 %                  lab measurement --> 50.30%

 

Both values had a range of about 0.2%.  With 1g being represented by about a 12.5% change in duty cycle, the 0.2% range corresponds to a 16 mg range.  The theoretical peak-to-peak noise was calculated to be 3.2 mg, which is five times smaller then what was found!  

 

The IGS software makes use of a dead-band, which is a range of duty cycle values centered around the 0 g value, for which the assumption is made that the acceleration is in fact 0 g.  This allows the noise to be ignored when the IGS hardware is level and stationary. The result is that no change in calculated position results from the noise.

 

However, the problem is that when the dead-band is sufficiently large to do its job, it also causes the small and yet significant accelerations due to actual movement of the hardware to be ignored.  If the dead-band is reduced then the noise causes fictitious positions to be calculated. 

 

It turns out that the magnitude of the accelerations produced by slowing moving the IGS hardware around from rest to approximately walking speeds is of the same size as the noise!

 

The accelerometer measures static acceleration as well as dynamic, so gravity itself can be used to produce accelerations by tilting the hardware. Using this technique to produce accelerations that were significant fractions of gravity and watching the value of the position displayed on the LCD, it was found that the software does in fact work in principle.  It is just not accurate for small acceleration values.   

 

 

Zahid Rajabali (Navigation, Networking, Image Processing)

 

Navigation

 

The navigation subsystem has not had any significant developments, although we seem to have a promising lead on acquiring a sponsored HMR magnetic-sensor device from Honeywell.

 

 

Networking

 

As a tradeoff to working with the Imaging system, no time has been dedicated to the Network subsystem.  In addition, the host is still not ready for network testing, thus this has been given a low priority.

 

 

Image Processing

 

At the time of the previous progress report, we had just begun the image processing subsystem in light of the new competition rules.  Since then, a large amount of time has been devoted to this sub-project, with many fruitful results.

 

The major imaging obstacles can be categorized in 4 components:

 

·       Physical Components

 

In this stage, the physical camera is made to function with the host processor hardware and OS software.  Since the medium and camera are known, the only connection between this stage and the next is the data stream that is the image to be processed. Timing issues (i.e. excess frames) will be dealt with in the next stage.

Thus far, we are having many issues getting the camera to work with the Red Hat distribution of the Linux kernel on a laptop, which indicates more and worse errors when attempting to function with the host.  We will continue working with the current camera for another few weeks before attempting a new camera.

 

 

·       Image Cleaning

 

It is a safe assumption that the picture we retrieve will be grainy, unclear, and blurred.  For this reason, we must first clean the image up prior to performing any tests on the image.  Fortunately, we found a copyrighted algorithm online called SUSAN which does this and edge/corner detection (the next stage).  Thus, we were able to kill two birds with one stone once we contacted the designers of SUSAN to confirm that we could use it.

 

 

·       Corner/Edge Detection

 

To find a triangle, we must find the corners and/or edges and convert them into Cartesian coordinates.  SUSAN detects corners and edges very well, but just re-draws the input image with lines on the edges and boxes on the corners.  Instead, we have modified the program to return the coordinates of the pixels.

·       Object Detection

 

Once we have an array of points representing the corners and lines, we can use them to find closed objects in the image.  We are using this method rather than triangles in particular for two reasons.  One of them is that we may use the same algorithm to later detect the circles of the target, but a more pressing reason is for extensibility for future years, at which time we will likely need to detect objects, but they will likely not be triangles.  Detecting an object is done conceptually by linking all corners by attempting to traverse the lines.  If we end up looping back to a corner we previously traveled, we label that array of corners as a closed shape.

 

Once we have a set of closed shapes, we will need to run a simple algebra algorithm on them to find an isosceles triangle, and in which direction it points.

Though this algorithm has been completed, we are now working on detecting closed shapes, and already have several crude methods of doing this.

 

 

Donovan Parks (Motor Controllers, Reprogrammable PIC Controller, Control Algorithm)

 

Motor Controllers

 

The motor controller has been extended to accept a quadrature encoded signal so the speed and direction of the propeller can be determined.  Research into the nature of a quadrature signal was conducted to determine how speed and directional information can be obtained from the signal.  Software has been written to allow the speed of the propeller to be calculated.  It is possible to write software to determine directional information, but this is unnecessary as AUViking always explicitly sets the propeller direction. A quadrature signal is capable of giving 4x resolution information (that is, it you have a circular encoder with x transitions per cycle the quadrature signal can be used to obtain 4x transitions per cycle), but the processing requirements for this are beyond the abilities of the PIC16F876 used on the motor controller.

 

It has been decided that this years AUV will not contain motors with a quadrature encoder.  The reason for this are:

 

The schematic for the motor controller has been finalized and work has started on designing the PCB.  Research has been conducted into appropriate methods for laying out the motor controller electronics to obtain maximum efficiency. This research has revealed several constraints on the PCB that should be met and have thus significantly increased the time required to finalize the design of the PCB.  Due to this the deadline for this task has been extended.

 

 

Reprogrammable PIC Controller

 

The feasibility of building a reprogrammable PIC controller system has been evaluated.  A solution has been found that will allow the majority of PICs in AUViking to be reprogrammed while using functionality that is already available.  This solution allows all PICs to be reprogrammed except for the Hub, requires the use of a serial port on the Host board, and requires separate serial data lines to be brought to all PICs.  A more desirable solution would allow the Hub to be reprogrammed and use the existing I2C network.  Unfortunately, a solution that meets these requirements would require a significant amount of additional work as it can not take advantage of functionality that already exists. 

 

The reprogrammable PIC controller system has been designed and implemented under Windows.  It works as expected and will be a valuable addition to AUViking. AUViking runs under Linux so work is in progress to port the implementation to Linux.  There has been some difficulty porting the solution due to a 3rd party PIC bootloader which is a critical component in the system.  A Linux version of the bootloader is available, but we have been unable to get it working.  Other bootloaders are available and it may be necessary to move to one of these.  

 

 

Control Algorithm

 

Initial research into a suitable control algorithm that will allow AUViking to follow a compass bearing has been completed.  A standard PID algorithm seems suitable and appears to be a wise choice given the large amount of information available. Unfortunately, a PID algorithm is extremely hard to tune by simulation as the PID parameters are very sensitive to the system it will be used on.  An accurate model of AUViking is not available at this time to allow for software tuning.  The general functionality of the PID algorithm can be verified independent of AUViking (i.e. a simple system can be simulated to show the algorithm is working as expected), but tuning of the algorithm will require AUViking to be near completion.  These findings are reflected in the revised timetable.

 

 

Revised Timetables

 

The following timetables contain some modifications from those in the first progress report and indicate the date of completed tasks.  The priority ranking is from 1-10 with 10 being the highest priority. It is a measure of how important the system is to AUViking for the 6th International AUV Competition.

 

Inertial Guidance System

 

Member(s): Mark

Task

Priority

Date To Complete

Completion Date

Research IGS Theory

2

September 21

September 21

Develop Co-ordinate System

2

September 21

September 21

Determine Packets to Send/Receive from Host

2

September 21

September 21

General IGS Algorithm

2

September 21

September 21

Learn Development Environment

2

October 20

October 20

Schematic

2

November 3

November 3

Perform calibration measurements for ADXL202

2

November 3

November 3

Build hardware

2

December 15

December 15

Develop IGS Software

2

February 15

January 28

Basic Testing

2

February 28

February 7

Final Testing

2

April 15

*

Documentation

2

April 15

 

* System deemed to be too inaccurate to meet the requirements of AUViking. 

 

 

 

 

 

 

 

 

Compass

 

Member(s): Ziko

Task

Priority

Date To Complete

Completion Date

Acquire  New Compass

9

February 15*

Work in Progress

Communication Code for Compass

9

March 15**

 

Testing of Compass Accuracy

9

March 31***

 

Documentation

9

April 10***

 

*Bumped up to March 15

**Bumped up to March 25

***Bumped up to May 1 due to exams

 

Image Processing

 

Member(s): Ziko, Matt, Niko, Patrick

Task

Priority

Date To Complete

Completion Date

Research Standard Algorithms

8

February 27

Feb 5

Block Diagram of Data Flow

 

8

February 27

Feb 7

Initial Implementation of

Algorithm(s)

 

8

March 21

Feb 20

Testing on Ideal Test Cases

8

March 28

Feb 28

Enhancements to Algorithm(s)

8

April 15

Work In Progress

Testing on Actual Test Cases

8

April 30

 

Enhancements to Algorithm(s)

8

May 15

 

Final Testing and Optimization

8

May 30

 

 

Tethered Data Link

 

Member(s): Ziko

Task

Priority

Date To Complete

Completion Date

Implement Network Software

7*

February 27

 

Verify Connection to Laptop

7*

February 27

 

Allow Host to be Reprogrammed

7*

March 31

 

 

Motor Control

 

Member(s): Donovan

Task

Priority

Date To Complete

Completion Date

Quadrate Encoding

10

January 31

January 28

Schematic Finalization

10

February 21

February 21

PCB Layout

10

February 28

 

PCB Testing

10

~March 31*

 

*dependent on when manufactured PCB arrives

 

Reprogrammable PICs via Data Link

 

Member(s): Donovan

Task

Priority

Date To Complete

Completion Date

Feasibility Analysis

4

February 15

February 10

Initial Design

4

February 17

February 12

Implementation in Windows

4

February 21

February 17

Implementation in Linux

4

March 21

 

 

PID Algorithm

 

Member(s): Donovan

Task

Priority

Date To Complete

Completion Date

Research

9

February 21

February 21

Implement PID Algorithm in C

9

March 15

 

Verify PID Algorithm on Simulation of a Simple System

9

March 31

 

Tuning of PID Parameters for AUViking

9

April 15*

 

* dependent on completion of several systems including the hull, propulsion, motor controllers

 

**