EXECUTIVE SUMMARY · Web viewShort for ‘State Machine’, Smach is a python-based tool for designing, maintaining, and debugging large and significantly complex finite state machines

TEAM NAME: Temple WaterfOWLs 2016 Page 1 of 56

February

COLLEGE OF ENGINEERING

Preliminary Design Document for:

Robust System for Autonomous Nautical Navigation and Task Integration

Submitted to:

Dr. Brian ThomsonSenior Design Project II

Temple University College of Engineering 1947 North 12th Street

Philadelphia, Pennsylvania 19122

February 12, 2016

Prepared by:

E. Doyle, C. Durand, D. Graney, R. King Faculty Advisors: Dr. Li Bai, Dr. John Helferty

Temple WaterfOWLS 2016 Temple University

College of Engineering 1947 North 12th Street

Philadelphia, Pennsylvania 19122

For further information, please contact Dr. David Brookstein (email: [email protected]).

Senior Design Project II 016

Senior Design Project February 12,


Team SD2-08

Team Members Emilie Doyle, Claire Durand, Daniel Graney, Rachel King

Advisors Dr. Li Bai, Dr. John Helferty

Coordinator Dr. Brian Thomas

Department(s) Electrical and Computer Engineering

Project Title Robust System for Autonomous Nautical Navigation and Task Integration

Abstract The mission of the 2016 WaterfOwls RoboBoat project is to produce an autonomous boat capable of competing in the AUVSI Roboboat competition and fulfill the obstacle avoidance task as well as the speed and thrust tests. The team must design a computer vision and navigation system to build upon the boat built by the 2015 team, as well as to redesign the propulsion system. The computer vision system implements a Bumblebee2 stereo camera and the OpenCV computer vision software library in order to detect buoy objects. It then transmits that information to the navigation pipeline using an on-board laptop, which processes this input and appropriately engages the motor control system, located on a BeagleBoneBlack microcontroller. Communication between the various systems is performed using the Robot Operating System (ROS) and housed on a hardware system bequeathed by the 2015 team. The motor housing is redesigned and 3D-printed in order to provide ideal thrust.

URL https://sites.google.com/a/temple.edu/waterfowls2016/



EXECUTIVE SUMMARY

Each July teams of engineering, science, and technical students from around the world gather in the balmy vacation city of Virginia Beach, Virginia to showcase the fruits of their academic labor at the Annual Roboboat autonomous surface vehicle (ASV) competition organized by the Association for Unmanned Vehicle Systems International (AUVSI). Contestant teams design respective ASVs which are tasked with completing several challenges. Challenges range from simple speed tests to the navigation of an obstacle field composed of buoys. Successful completion of competition tasks require that various active systems aboard the ASV survey and interpret environmental conditions, process relevant data, and execute physical maneuvers in accordance with mission objectives. ASVs provide a unique platform for researchers, search and rescue operations, and military ventures alike. Unlike their aerial and underwater counterparts which have been integral to scientific exploration, weather prediction, and highly volatile espionage missions among myriad additional applications, ASVs have not been utilized to their fullest applicability. The AUVSI Roboboat competition aims to educate and inspire young engineers and scientists in regards to the variety of functions an ASV may serve and challenges competitors to apply knowledge and conduct research across disciplines, preparing students for the modern diversified industrial challenges of the 21st century.

Several tasks make up the whole Roboboat competition, each one allows a contestant team to score points, and after all tasks have been undertaken these points are summed, with the team awarded the greatest quantity of points crowned winner. Among the most heavily weighted tasks, the obstacle avoidance task will both provide an opportunity to score a considerable number of points so that Temple University’s team may win the overall competition, while not overextending the available labor bandwidth a team of four students may provide. To complete this task the ASV being developed must possess some kind of camera system which can capture a digital picture, an image processor which can interpret that captured digital images, a finite state machine to direct appropriate amounts of power to the final component: a propulsion system that can propel the ASV forward and around objects.

A stereoscopic camera system will serve as the image capture device. Stereoscopic cameras consist of dual lens and sensor mechanisms and can use known geometric qualities of their own housing in addition to minor discrepancies in the images captured from the right and left lenses respectively to calculate distances of objects which are in the line of sight to the camera. By utilizing the Robot Operating System software framework-imaging data can then be processed by algorithms which identify obstacles and determine the best course of action for avoiding them. Data is then sent to a finite state machine, which configures how power should be distributed to the propulsion system to drive the vehicle forward, make a turn, or stop. The propulsion system will be designed to reliably execute these actions in the most efficient way possible.

Successful completion of the obstacle avoidance task will award Temple University’s Roboboat team a large number of competition points. Perfect execution of this task may even result in an overall competition win, which would speak volumes to the quality of a Temple University College of Engineering education. Additionally because this task requires the design and implementation of a visual processing system future teams of engineering students who choose to adopt the Roboboat as a senior design project or even simply as an engineering club project will have a well-developed platform on which to further advance the ASVs capabilities. For winning the competition an award of $7000 is granted to the team, which could be recycled into the project and help to fund the future of Temple’s involvement with Roboboat. And of course the students involved with the project will leave it with a greater understanding of interdisciplinary systems engineering and an appreciation for the complexities of the modern world.



1. Problem.............................................................................................................................61.1. Overall Objectives...................................................................................................................61.2. Historical and Economic Perspective........................................................................................6

1.2.1. Temple WaterfOWLs 2015.......................................................................................................61.2.2. Historic Perspective.................................................................................................................61.2.3. Economic Perspective..............................................................................................................7

1.3. Design Concept........................................................................................................................71.4. Major Design and Implementation Challenges.........................................................................81.5. Implications of Project Success................................................................................................8

2. DESIGN REQUIREMENTS....................................................................................................82.1. Target Specifications................................................................................................................82.2. Final Specifications................................................................................................................10

3. APPROACH.......................................................................................................................103.1. Imaging Pipeline....................................................................................................................103.2. Navigation Pipeline................................................................................................................13

3.2.1. Matrix Analysis.......................................................................................................................143.2.2. Finite State Machine Integration – ROS Smach......................................................................18

3.3. ROS Integration and Use........................................................................................................193.4. Propulsion System.................................................................................................................20

3.4.1. Propeller Design Approach....................................................................................................223.4.2. Nozzle Design Approach........................................................................................................24

3.5. Network Design.....................................................................................................................273.6. Hardware Design and Rendering............................................................................................28

3.6.1. BeagleBoneBlack Configuration.............................................................................................283.6.2. Motor Connection Permanence.............................................................................................293.6.3. Single Pull, Single Throw Switch Installation..........................................................................29

4. EVALUATION....................................................................................................................304.1. Testing Methods....................................................................................................................30

4.1.1. Computer Vision Algorithm Testing Method.........................................................................304.1.2. Navigation Logic Testing Methods.........................................................................................324.1.3. System Testing in Pool Methods............................................................................................334.1.4. Additive Manufacturing Methods..........................................................................................344.1.5. Computational Fluid Dynamics Methods for Nozzle and Propeller Blades............................34

4.2. Testing Results.......................................................................................................................354.2.1. Computer Vision Algorithm Testing Results...........................................................................354.2.2. Navigation Logic Testing........................................................................................................384.2.3. System Testing in Pool Results...............................................................................................424.2.4. Additive Manufacturing Results.............................................................................................424.2.5. Computational Fluid Dynamics Results for Nozzle and Propeller Blades...............................44

4.3. Hardware..............................................................................................................................474.3.1. Electrical Hardware................................................................................................................474.3.2. Mechanical Hardware............................................................................................................48

4.4. Software................................................................................................................................50



5. SUMMARY AND FUTURE WORK.......................................................................................50

6. ACKNOWLEDGEMENTS....................................................................................................51

7. REFERENCES.....................................................................................................................52



1. PROBLEM

1.1. Overall Objectives

The overall objective of this project is to produce a boat that is able to autonomously maneuver through a buoy field for the 9th Annual AUVSI International Roboboat Competition in July 2016. This project builds upon the work done by the previous Temple WaterfOWLs electrical engineering, and mechanical engineering teams. The objective of this project is to take the current electrical and mechanical systems in place on the boat built by the previous teams and augment the systems so that the buoy avoidance challenge may be successfully completed.

The design challenges for the 9th Annual AUVSI International Roboboat Competition are as follows:

Communicate via HTTP requests to report results and request navigation information Navigation through a buoy field Locate, detect and report the frequency of an underwater acoustic pinger Visually interpret docking images and dock at specified image Launch and collect an autonomous underwater vehicle (AUV)

Please note that all of the tasks are autonomous unless stated otherwise (Roboboat-Foundation).

The 2015 WaterfOWLs teams’ objective was to design a boat that could be entered and compete in the 8 th

Annual AUVSI International Roboboat Competition (July 2015) with the goal that some of these tasks could be accomplished autonomously by their systems. While the teams made incredible progress throughout the course of the 2014-2015 school year, the boat ultimately was only able to complete the first task (communicate via HTTP requests and report results and request navigation information). Reflecting back on the work that the previous teams accomplished, it would appear that the teams attempted to accomplish all of the tasks, and in that they spread themselves too thin and were not able to fully complete the tasks. It is based on that observation that Temple WaterfOWLs 2016 has chosen to focus specifically on the buoy field navigation challenge. The rules for the 9 th Annual AUVSI International Roboboat Competition can be found in Appendix D.

1.2. Historical and Economic Perspective

1.2.1. Temple WaterfOWLs 2015

The 2015 WaterfOWLs consisted of two separate teams- one mechanical and one electrical team. The mechanical team designed a prototype, and then the final hull for the boat. The final hull was then crafted out of carbon fiber thanks to the help and support of Viking Yachts. Additionally, the mechanical team designed a hub-less propulsion system. The electrical team designed the layout and implemented the hardware and power distribution for the boat.

1.2.2. Historic Perspective

Unmanned aerial vehicles (UAVs) are being used increasingly often for surveying land waging war, and delivering payloads with more accuracy and less operational risk than traditionally piloted flying machines are capable of. Additionally autonomous underwater vehicles (AUVs) have been extending the investigative reach of marine scientists to depths, which would not be possible with onboard human crew. Oddly enough, the development of unmanned aquatic surface vehicles (UASVs) has not kept the same pace. This is rapidly being rethought and the dawn of the autonomous boat is breaking.



Unmanned aquatic surface vehicles (UASVs) have been found to have greater maximum payload capacity and mission endurance than their sister systems found under the water or in the air, and due to their floating on the surface of the water, they do not require the use of energy in order to maintain operational depth or height. Additionally UASVs offer a unique vantage point, which allows for mission activities to occur either above or below the surface of a body of water, which makes them more adaptable than either UAVS or AUVs (Ullah, 2014).

Unmanned vehicles are useful for a wide variety of applications, yet the industrial development of UASVs is severely lacking when compared to that of comparable aerial or underwater vehicles. Developing a multi-use UAVS platform will take advantage of an already reliable technological development and expand it into a market which is as of yet, unconquered (Tuna, Arkoc, Koulouras, Potirakis, 2013).

1.2.3. Economic Perspective

The AUVSI Roboboat Competition serves a s a small-scale spotlight for the development of autonomous navigation technology. With the various algorithms and hardware platforms developed by teams who compete, more information and ideas are added to the pool of research geared towards autonomous applications, and are not limited to autonomous surface vehicles. Perhaps the most widespread commercial application is that of autonomous automobiles. From an industrial standpoint, the money to be made selling consumer autonomous cars is tremendous. However, economic applications reach beyond sales;; autonomous cars would be safer than human driven cars. Furthermore, the cost of decreasing roadway accidents due to a sophisticated network of autonomous vehicles would be significant. The benefits include savings from lack of structural damages, which are typically paid for with public revenue, as well as the decreased cost of insurance for both the insurance companies and the consumers. Autonomous navigation technology would economically influence industrial applications as well. By developing systems for driver-less truck routes, forklifts, and any other machine, manufacturers could save money on labor costs. Additionally, this research could contribute military applications. Self-driving planes and ships could provide tactical, and therefore fiscal, advantages in military combat, as well as keep American soldiers safer (Rastelli, Penas, 2015).

1.3. Design Concept

The proposed solution is a design that incorporates stereo-vision, color detection, cross- system communication and propulsion redesign. The proposed system has three main components the Imaging Pipeline, the Navigation Pipeline and the motor controls.

Figure 1: Main Components of Proposed Solution

These three systems must work in tandem in order for the boat to be completely autonomous. The code for the pipelines are written in different languages, so the Robot Operating System (ROS) must be used as a wrapper to enable communication between the different systems.



The Imaging Pipeline uses a Bumblebee stereo-vision camera in order to see the obstacles or items in the direct path of the boat. The images returned from the camera are then passed through blob and edge detection algorithms to determine the location of the buoys or obstacles, and that information is processed and passed, using ROS, to the Navigation Pipeline. The Navigation Pipeline relies on a series of tiered finite state machines (FSM) in order to determine what action, if any, should be taken in order to successfully navigate the situation. The necessary action is then ported to the motor controls, which then responds accordingly.

1.4. Major Design and Implementation Challenges

One of the biggest challenges faced with this project is the ability to test the design. The boat is approximately 3x4x2ft and is quite cumbersome to move around. Testing has been accomplished through the use of facilities such as the indoor pools at Pearson Hall, however since that is an indoor environment, and the competition itself is outdoors then it might not portray accurate results. One major factor in this is the glare produced by the sun reflecting off objects, such as buoys. In an indoor facility you may have bright overhead lights but it is not the same as sunlight interference. Outdoor testing has been accomplished at Core Creek Park, but transporting the boat, team and supplies is costly, in time, effort and money.

An additional challenge that arose is the availability of finances and resources. The overall cost of maintaining and transporting the boat to the 9th Annual AUVSI International Roboboat Competition is well above the provided budget. This creates a financial deficit, which hinders the design process. This is a major concern due to the fact that project design is a dynamic process. With the limited resource, the design must adapt to the budget instead of the design process.

1.5. Implications of Project Success

The success of this project indicates the ability to adapt the model to fit other applications. Extensibility of such a system is not limited to solely aquatic pursuits. A similar model could be applied to the autonomous car industry, further increasing reliability, safety, and precision. This system could also be applied to marine biome research, as well as environmental surveying and dam sustainability surveying. Additional applications include military-marine recognizant solutions as well as disaster response, search and rescue (Jie, Abdulla, Snasel, 2009).

2. DESIGN REQUIREMENTS

2.1. Target Specifications

Specifications for the boat are provided by the competition rules. Below is an excerpt from the 2015 final rules, since the 2016 final rules have not been published yet. The following are the general requirements for applicants.



Table 1: 2015 Roboboat General Guidelines

Requirement Description

Autonomy The vehicle must be fully autonomous and all decisions must be taken onboard the UAV

Buoyancy The vehicle must be positively buoyant and stay buoyant for at least 30 minutes in the water

Communication No communication to the vehicle can change its software and/or logic during a run

Deployable The vehicle must have its own 3 or 4 point harness for crane deployment

Energy source The vehicle must use self-contained electrical energy source(s). Sailboat are permitted

Kill switch The vehicle must be equipped with at least one 1.5in diameter red button that, when actuated, disconnects power from all motors and actuators

e-Kill switch In addition to the physical kill-switch, the vehicle must have at least one remote kill switch that provides the same functionality

Payload The vehicle must have a forward facing location where a GoPro or similar device might be attached

Propulsion Any propulsion system can be used (thruster, paddle, etc.), but moving parts must have a shroud

Remote control The vehicle must be capable of remote control to be brought back to the dock

Safety All sharp, pointed, moving, sensitive, or dangerous parts must be covered and clearly identified

Size The vehicle must fit within a six-foot long, by three-foot wide, by three-foot high “box”

Surface The vehicle must float or use ground effect of the water. Mostly submerged or flying craft are forbidden

Towable The vehicle must have designated tow points and a tow harness installed at all times

Waterproof The vehicle must be rain/splash resistant. The competition is held “rain or shine”.

Weight The vehicle and all sub-vehicles must have a combined weight of 140 lbs. or less.

However, due to the inherited hull, structure, and hardware systems, the aspirations of the team stretch far beyond physical parameters.

However, due to the inherited hull, structure, and hardware systems, the aspirations of the team stretch far beyond physical parameters. Our main goal for this project is to participate in the design process of creating an obstacle-avoiding vehicle. The metrics for success are as follows:

· - Successful communication between Imaging, Navigation, and Motor Control pipelines

· - Obstacle detection using an optimized algorithm

TEAM NAME: Temple WaterfOWLs 2016 Page 10 of


· - Dynamically operating Finite State Machine

· - Well-tested motor power distribution map for optimal boat movement

· - Rendering of optimized Propulsion System

· - A system able to move forward and avoid obstacles in its path

What is most important to the success of the project is the multi-disciplinary design of a streamline, functional system. We hope to develop based on a division-of-labor approach which will allow the electrical team to develop the State Machine, Object Detection Algorithm, and Motor Control map separately, while the mechanical team designs the most efficient propulsion system as possible

2.2. Final Specifications

The Final specifications for the project very closely reflect the target specifications we set out to achieve. The main difference between Target and Final specifications come from changes in time constraint, logistics and budget. Ultimately, when key pieces of hardware failed, the physical manifestations of elements in our specifications, which require motor control, failed to be achieved, including testing of a power distribution map. However, our final product can be measured by the following metrics:

· - Successful communication between Imaging, Navigation, and Motor Control pipelines

· - Obstacle detection using an optimized algorithm

· - Dynamically operating Finite State Machine

· - Rendering of optimized Propulsion System

The physical, qualitative properties of the boat in Figure 2 remain applicable to the inherited hull.

3. APPROACH

3.1. Imaging Pipeline

The main focus of this year's iteration on the boat was the navigation, specifically, in the field of buoys for the obstacle avoidance task. Therefore, the primary role of the vision system was that of object detection. The image pipeline was to implement OpenCV 3.0 using Python 2.7 scripts in order to process the images collected by the Bumblebee2 stereo camera.

Since the obstacles were colored buoys several image processing options were available in order achieve buoy detection. One possibility was to use Blob Detection in order to isolate the buoys as blobs. The SimpleBlobDetector provided by the OpenCV library took in input thresholds and filters the image based on color, area, circularity, inertia, and convexity in order to output the center and radii of circular blobs. (OpenCV) The Blob Detector returned keypoints which could be drawn on the image using the OpenCV function drawKeypoints() and from which coordinates could be extracted.

The Canny method could also be used to examine the level of filtering needed in order to semi-accurately detect the contour of the buoys. The Canny edge detection algorithm applied a double threshold to the image in order to image. Pixels above the high threshold belonged to an edge whereas pixels below the low threshold do not. Pixels with a value between the high and low thresholds only belonged to an edge if they were adjacent to an edge. (Marengoni, Stringhini, 2011) The Canny method returned contour objects,



which could be drawn on the image using the OpenCV function drawContours(). In order to obtain approximate coordinates from these contours, the OpenCV minEnclosingCircle() was used to return the center coordinates and radius of the “circle of the minimum area enclosing (the) 2D point set.” (OpenCV). Additionally, the Canny method’s returned contours could be passed through the OpenCV contourArea() function in order to obtain the area of the enclosed contour in pixels (px).

Both functions operated over the entire image, but armed with the object coordinates, the list of buoys could be filtered to retain only the objects found in the bottom half of the picture since anything in the top half was above the water line, and therefore irrelevant to navigation. (In the future, if timing/efficiency is a concern, the image could be cropped so that only the bottom half remained). Since the Canny method provided more information about the detected objects, the list of buoys detected using the Canny method could also be filtered to retain only with an object area larger than 200 px (in order to eliminate noise “objects”) and with a radius smaller than 75 px (in order to eliminate noise “strips” with a large area). The objects remaining in the list were treated as obstacles.

After the testing described in Section 4.1.1 Computer Vision Algorithm Testing, it was determined that the Canny method should be pursued and perfected. As for the testing, this was accomplished using a Python script.

In order to transmit the information about the detected obstacles to the navigation pipeline, an 8x8 grid was transposed on the bottom half of the image. If an item was detected in one of the grid cells, the corresponding cell in a 2D array was incremented in order to simplify and track the locations of detected buoys. For example, the objects detected (circled in dark blue) in Fig 3 below would yield the following matrix. Notice that the only non-zero numbers are in cells (3,3) and (8,5).



Figure 2: Output Image with Overlaid Grid and Detected Buoy Contours and minEstimatedCircle

Table 2 - Buoy Matrix

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 2 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 2 0 0 0



Also note that there are technically two objects detected in these two cells. However, it makes little to no difference to the navigation whether there is one buoys or more than one in each cell since it is a cell path to be avoided as long as the number of objects in the cell is non-zero. Therefore, the matrix cell values can be further simplified to binary values. This paired with the number of 8 cells in a row meant that transmission could be rendered even more efficient by transforming each row into a binary number, and only transmitting a list of 8 numbers that encapture the obstacle information. To accomplish this, the python script initialized a list of 8 0’s. If a buoys was detected, 2 to the power of that column number was added to the integer at the row index of the list. Once this is done, the list is ready to be returned.

3.2. Navigation Pipeline

If the computer vision of the Imaging Pipeline is the eyes of the boat, and the motor controllers are the feet, then the Navigation Pipeline is the brain. Just like the eyes processes light rays into images and the brain decides how to act given that information, the Navigation system makes decisions on which direction the boat should turn, and how quickly it should do so, based on the information collected and processed by the Bumblebee camera and passed down by a network of ROS nodes. The structural basis of the Navigation pipeline is a Finite State Machine (FSM), which is simply a logical model used by computer programs to make decisions based on given conditions. In this instance, the FSM has multiple tiers for the different level of complexities involved. The highest tier is the decisions that the boat makes: turning right, turning left, going straight, object detection, ext. Another tier is that which processes the array of data passed from the Camera Vision pipeline, determining where in the boat line of sight an object lies is. Another layer is the ROS commands which need to be communicated to the Motor Control pipeline to actually control the boat. The state machine implements a lookup-table algorithm, which can dynamically add states as the complexity of the system increases.



Figure 3: Navigation Finite State Machine

To navigate the buoy fields and transitions through the states of the FSM, the system needs some metric to understand whether an object is in its field or not. The Imaging Pipeline provides the input stereovision images. However, those two-dimensional images need to be translated into a format, which the one- dimensional state machine can understand. Figure 3 shows an example of a static image read by the Bumblebee Stereo Vision Camera. To represent this image numerically, the team devised a system where the Imaging Pipeline returns a matrix of data. That matrix maps where exactly the objects are on in the boat’s line of vision. It is broken up into an 8-by-8 grid, and if a buoy lies within a box, then a ‘1’ is placed in that box. Otherwise, that box contains a zero. The corresponding matrix for Figure 3 and be seen in Figure 5.

3.2.1. Matrix Analysis

In the Imaging Pipeline, an 8x8 matrix representing the bottom half of the image is output. The matrix only covers the bottom half of the image in order to align with where the horizon is. There will be no buoys above the horizon; however, there is the potential for other circular shaped items of comparable size that could be recognized by the Canny Algorithm. In order to eliminate the chance for false positives above the horizon, the matrix returned only pertains to the bottom half of the image.

The contents of the returned matrix pertain to the location of the center of the buoys that were located based on the Canny Algorithm. In the matrix, the center of the buoy is denoted as a 1, or Boolean true. All of the other spaces are denoted as a 0, or Boolean false. The matrix is then collapsed into a set of eight integers. Each of these integers represents one of the rows of the matrix. These integers are passed to the navigation logic python script. This script analyzes specific rows of the matrix in order to determine what direction or course should be pursued in order to avoid obstacles.



The navigation logic python script (navLog.py) reads in the integer values of the image matrix. It focuses on a specific row, which we have determined to allow adequate time to move or turn if necessary. In analyzing this row, the script searches for an adequate opening for which the boat can proceed through. In pool testing, the team established that due to the width of the boat, it requires at least two horizontal cells in a row of the matrix of free space in order to successfully proceed forward.

At this point is it important to reflect back on the fact that the in the creation of the matrix, only the cell in which the center of the buoy falls are identified as ‘danger areas’ or areas to avoid. A situation could arise in which the center of the buoy narrowly falls into one cell, but nearly half of the buoy lies in the cell next to it, and therefore is not registered in that second cell. Pictorial representations of potential situations are shown in the figures below, with buoys represented as blue circles, in a part of the matrix. The projected path is shown in yellow. This is a concern for navigation if the logic is searching for two horizontal cells through which to pass. If the center falls in the one cell, and the next cell is deemed “clear” and then the boat proceeds to pass through that area, it may still hit that buoy despite the area looking clear (Matrix Situation 1). In order to combat this, the navigation logic script searches for four horizontal cells that are open, instead of only two cells. This is to account for if the situation previously discussed should occur not only on one side of the projected path, but also on the other side (Matrix Situation 2). This should leave us ample space for the boat to proceed. In the event that this occurs on both sides, and could potentially block up to half of one cell on both the left and right side, there still would be the two center cells, as well as the remaining halves of the outer cells through which the vehicle can proceed (Matrix Situation 4).

It is important to note that the use of three horizontal cells could be considered instead of four horizontal cells. However, due to how the boat is centered and may be positioned going into this type of situation, it is highly likely that it could still come into contact with the buoy since it does not allow for a high margin of error. It is also important to note that the boat is relatively small compared to other entries. The size constraints for entry into the competition are that the vehicle must fit within a 9-foot by 3-foot by 3-foot box. The small size of our craft may allow for easier passage through the buoy minefield.

Matrix Situation 1: Two Cell Path with Partial Obstacle

Matrix Situation 2: Two Cell Path with Two Partial Obstacles



Matrix Situation 3: Four Cell Path with Partial Obstacle

Matrix Situation 4: Four Cell Path with Partial Obstacle

In conjunction with the concern about buoys in the horizontal range encroaching on the pathway of the boat, there is also concern for a similar situation in the vertical direction. The situation is almost identical, if the matrix was transposed (Matrix Situation 5). In order to prevent this situation, the navigation logic script also takes into account the value of the row above the row it is currently analyzing (Matrix Situation 6). In each instance of checking for four horizontal cells of the matrix in a row that are clear, it also must check the cells directly above the cells. This way it enables that a buoy is not centered in the next row barely, with half of the buoy hanging over into the row that is currently being analyzed

Matrix Situation 5: Four Cell Path with Vertical Partial Obstacle

Matrix Situation 6: Four Cell Double Layer Path with Vertical Partial Obstacle

The cells in the matrix that are searched in order to find the projected best path are found by systematically searching starting at the center of the matrix row. Pictorial representations of situations are shown below. They are represented by a section of the matrix, with the proposed pathway shown in purple. The location of the four horizontal cells that are identified as the projected path and found by searching through the matrix row (indexed 0 through 7) systematically, by first checking the immediate middle four cells (2 through 5) (Matrix Path Search 1). Next, it searches for four cells with centers displaced from the middle of the array by one cell. These coincide with indices of 1 through 4 (Matrix Path Search 2) as well as 3 through 6 (Matrix Path Search 3). Then it searches for four horizontal cells with center displaced by two cells. These correspond with indices of 0 through 3 (Matrix Path Search 4) and 4 through 7 (Matrix Path Search 5). In the event that there is no set of four horizontal cells that are open, the default is to make a



hard turn to the left. These instances are cycled through using an if-else if –else statement.

0 1 2 3 4 5 6 7

Matrix Path Search 1: Center in Middle of Row

0 1 2 3 4 5 6 7

Matrix Path Search 2: Center Displaced One Cell to Left

0 1 2 3 4 5 6 7

Matrix Path Search 3: Center Displaced One Cell to Right

0 1 2 3 4 5 6 7

Matrix Path Search 4: Center Displaced Two Cells to Left

0 1 2 3 4 5 6 7

Matrix Path Search 5: Center Displaced Two Cells to Right

Based on the location of the available four horizontal cells, a command for motion is returned. The possible commands are as follows; forward, moderate left, moderate right, left, right, hard turn. The command is then published to a ROS topic through the use of a simple ROS publisher node. This node calls the navigation logic python script, and the command that is returned is then published. After it is published to the topic, a different node can then subscribe to the topic and obtain the information. This subscriber node enables the finite state machine to determine the appropriate motor powers.



3.2.2. Finite State Machine Integration – ROS Smach

In choosing a method for finite state machine implementation, the team had a few options to choose from. Because all ROS commands were to be written in Python, it was chosen as the programming language of choice. Manual creation of states involves the creation of an entire finite state machine class with methods to add states and run the machine. Implementation appears quite complicated in this method. Additionally, the possibility of using a lookup-table was considered; in this method, as opposed to a manual coding of an FSM, changing of state behaves (i.e. under what condition a state transitions to another) becomes trivial. However, implementation was also complicated, and involved a computationally heavy ‘iterator’ in order to sort through the table of states. The option we chose to pursue was that of Smach due to its easy integration with ROS and heavily documented online presence.

Short for ‘State Machine’, Smach is a python-based tool for designing, maintaining, and debugging large and significantly complex finite state machines. Smach uses a few easy to understand interfaces, which are simple and streamline to invoke:

STATES – The status of the machine given an outcome. To implement, one simply creates a class which inherits characteristics of the tool’s ‘State’ class, and performs all necessary tasks in the ‘execute’ method, returning an outcome which could influence the transition to the next state

CONTAINER – The most common instance of a container is a finite state machine itself which holds the other states. In the implementation of this structure, you add states to the FSM in a single line of code, specifying a map of outcomes and their respective transitions, as well as any input and output data which needs to be passed between states. When instantiating the container, a set of possible outcomes for which the FSM will finish and stop being completed.

There are many other types of containers. For example, Concurrences, which is a FSM that can run multiple states in parallel, and Sequences, which makes it easy to execute a set of states in sequence.

Figure 4: Smach Example



Figure 4 depicts a simple example of a container (FSM) names SM_PATH, with two States, FOO and BAR, which transition to one another based on the outcomes outcome1 and outcome2 respectively. If the current state is FOO and outcome2 occurs, then the machine reaches outcome4 and exits.

Smach makes for easy integration of a hierarchical, nested state machine due to the ease of adding one Container to another. In this way, it contributes to the overarching goal of writing modular, easily edited code for the legacy team to pick up the project.

3.3. ROS Integration and Use

The Robot Operating System (ROS) is a flexible framework used to write software for robots. It consists of a collection of tools, libraries and conventions that aim to simplify the task of creating complex and robust robot behaviors. ROS supports development in both Python and C++ languages (ROS Wiki). In the project, ROS is used to communicate between the Imaging Pipeline, which is written in Python, and the motor controllers, which are writing in C++. ROS serves as a translator between the systems.

The ROS file system consists of units of organized software called packages. Each package has a manifest file that serves as a description of metadata and dependencies of the package. Within the package there are processes called nodes that are used to perform computations. These nodes communicate with other nodes via services and topics. Services are a direct communication between nodes, while topics are an indirect means of communication that require nodes to publish information to a topic, and others to subscribe to the topic in order to receive the information in the form of a data structure called a message. Topics are the most prevalently used in the system (ROS Wiki). A basic diagram of ROS interconnectivity is shown below.

Figure 5: ROS interconnectivity Between Nodes and Topics

An example of the ROS system that is in place in the Temple WaterfOWLS 2016 project can be seen below.

Figure 7: Propulsion Design 1.0



Figure 6: ROS Node Network and Interfacing

In this instance, there are two nodes; mc_node_zack.py (Motor Control Node), and motor_comm_node.py (Motor Communication Node). The Motor Communication Node publishes information, in the form of a message data structure called MotorResponse.msg, including the header, motor id, RPM, bus voltage, temperature and the fault flag. The Motor Control Node then subscribes to that topic to gain that information. The Motor Control Node also publishes individual RPMs of the motors to the MotorRPM topic. Both nodes subscribe to the Motor Power topic, which provides the information about the percentage of power that each motor gets. Interfacing with thecommand line publishes this information.

The nodes that were created for this project are fairly simple. The only item published or subscribed to is a string command that comes from the processed image pipeline matrix, and subscribed to by the navigation pipeline. An example of the node setup code can be seen below.

3.4. Propulsion System

Boat propulsion can be achieved in a number of ways. For small craft the most common methods of marine propulsion are water jet, electric/electric-diesel/diesel motor, and wind propulsion systems. Wind propulsion is the oldest method, but sails are not simple and the mechanisms needed to control them would be complicated and difficult to integrate into the corresponding electrical/computer system that will serve as the

operator of our vessel. Wind propulsion is dependent on weather conditions, which are unreliable, and so this method is



not suitable for installation.

Water jets have been very popular for the propulsion of small water craft since the 1950s and provide a great deal of thrust for their size. However they are very costly not only upfront but over time their maintenance requires a great deal of attention and monetary investment, and so they are unsuitable considering the budget and planning horizon of the senior design project.

Variations of electric/electric-diesel/diesel motors have been in use since the early 1900s. Because of the limited hull capacity and expense any motor reliant on dense fuel requiring a dedicated fuel tank is unsuitable. Two twin brushless DC motors which can harness electricity from the lithium batteries already housed within the hull to serve power to the electrical systems will not require any additional fuel storages, are waterproof, and are already in possession. These motors are suitable drivers for a set of twin ducted propellers (Carlton, 2012).

Propellers and their housings will be designed using Solidworks and 3D printed in order to keep both weight and cost low. 3D printing is provided gratis by the college for senior design projects, and the geometries involved in the manufacturing of propellers and propeller ducts requires a level of detail that would come at a high premium if machined using traditional subtractive manufacturing methods. Torque generated by the motors will pass through a simple single gear train which uses a bevel gear to redirect the axis of rotation by 90 degrees. This will allow for the motors to be mounted above the water line of the vessel, prolonging their operational lifetime. The propellers will be designed from the ground up using Ansys Fluent to optimize the angle of attack for a custom blade profile based off of an Eppler 858 Wing profile. This particular profile was chosen because of its relatively thick cross section. Thinner profiles resulted in material fraying when they were printed. The Eppler 858 profile was thick enough that it could be printed without fraying at scale. It has been modified to make it more hydrodynamic by rounding off the leading edge in order to decrease drag on the blade while it moves through the water.



12 𝑃 ∗ 𝑅𝑃𝑀 − 𝐾𝑡𝑠 ∗ 101.3 𝑃

Figure 8: Admiral Taylor, 1917

3.4.1. Propeller Design Approach

Propellers are sometimes called screw propellers because of a popular analogy between the motion of a propeller through water to the motion of a wood screw through a soft pine. Following this analogy, the pitch of a propeller is similar to the pitch of a screw – each rotation of the propeller will “drive” the propeller forward, which will result in an advancement of the propeller (and thus the vessel to which the propeller is attached) forward in the direction of the axis of rotation.

Water is not soft pine of course. In fact water is a fluid, and so the forward motion of the propeller is more complicated than the forward motion of a screw. As the propeller rotates, there is an apparent slip of the body through the fluid. Slip is effectively the difference between the actual advancement of the vessel through the water and the theoretical advancement that would take place if a propeller behaved exactly like a wood screw. Apparent slip can be expressed as follows (Gerr, 2001):

Where:

𝑆𝑙𝑖𝑝𝐴 = (12 ∗ 𝑅𝑃𝑀)SlipA= Apparent SlipP = Propeller face pitch in inchesKts = Boat Speed through water in knotsRPM = Revolutions per minute of the propeller

However this provides only an estimate of slip, and to calculate efficiency and thrust performance more accurately the relationship between propeller speed through the water, the speed of the boat, and the theoretical propeller advancement.

When the boat is moving through the water, a boundary layer develops along the hull, and so there is an entrainment associated with the boats movement. As this entrained fluid gradually falls astern of the boat a wake is formed behind the boat. Because this is where the propellers are mounted, they are subject to a different fluid velocity than the forward velocity of the boat. For instance, if a boat speed was moving along at 5 knots and was pulling a wake of half a knot then the propeller would only actually be advancing through the water at 4 and a half knots.

Therefor to calculate the real slip (SlipR) of a propeller the wake must be combined with the apparent slip. Esteemed Admiral David Taylor while designing navy ships for use in World War I devised a measure of wake in relation to boat speed. Taylor wake fraction (Wt) is defined:

𝑊𝑡 = 𝑉 − 𝑉𝑎𝑉Where:Wt = Taylor Wake FractionV = Boat Speed Through WaterVa = Speed of Water at the Propeller

𝑐𝑢.



Figure 9: Wake Factor vs Block Coefficient

Figure 10: Sample Bp Chart

Taylor wake fraction can be used to compute a wake factor (Wf). Wake factor usage will allow for computation of propeller geometries by directly using the speed of water at the propeller, rather than having to continually compute our values from the boat speed. Wake factor is defined:𝑊𝑓 = 1 − 𝑊𝑡Where:Wf = Wake FactorWt = Taylor Wake Fraction

Now it becomes necessary to compute a block coefficient. This is a ratio of the area of the vessel, which is submerged by the product of the length, breadth, and draught of the maximum waterline. Block Coefficient is defined:

Where:

𝐶𝑏 = 𝐷𝑖𝑠𝑝𝑊𝐿 ∗ 𝐵𝑊𝐿 ∗ 𝐻𝑑 ∗ 64 𝑙𝑏. Disp = Displacement of Water in pounds WL = Waterline length in feetBW = Waterline beam in feet Hd = Hull Draft in feet

Measuring the boat’s dimensions and the static waterline will then allow us to compute a block coefficient. This then can be used to determine the wake factor of the craft using the Wake Factor vs Block Coefficient Chart (Gerr, 2001).

After a wake factor is determine then choosing a velocity that the boat should perform at during peak thrust, the velocity which the propellers will experience

can be calculated.

This allows for the computation of a power factor (Bp), which will subsequently allow for a δ value. δ here is called the advance coefficient. Using a chart of Bp vs. δ the maximum efficiency can be used in determining the value of advance coefficient to use for geometric design of the propeller. These charts will give pitch ratios and subsequent diameter measurements for maximum efficiency based on Bp values crossed with the necessary δs needed for calculation, additionally they are easy and exciting to use.

Once a δ value is determined then a diameter can be calculated using:

𝐷 = 𝛿 ∗ 𝑉𝑎 ∗ 12𝑁Where:δ = Advance Coefficient N = Shaft RPMD = Propeller Diameter in inchesVa = Speed of Advance of the Propeller



Through the Wake

Propeller efficiency can be determined directly from the Bp-δ chart.An accelerating nozzle has been used to shroud each propeller. Nozzles improve the performance of the enclosed propeller by decreasing the relative pressure on the inflow fluid. This serves the design by lowering thrust and torque felt by the propeller. Consecutively a circulation occurs due to the geometry of the duct, giving an inward resultant force, which actually give the duct itself a positive thrust when moving (Gerr, 2001).

Propeller blades are in effect rotating airfoils which when propelled through a fluid result in a lifting and a drag force. However, in opposition to how airfoils traditionally lift a vessel, with the lift force vector normal to the chord line of the airfoil, when designing a propeller a derivative force called thrust is the target quantity which causes motion in the direction perpendicular to the plane of rotation of the blade. Thrust cat be expressed: 𝑑𝑇 = 𝑑𝐿 ∗ cos 𝜙 + 𝛼 − 𝑑𝐷 ∗ sin (𝜙 − 𝛼)Where:T = Thrust L = Liftϕ = Inflow Fluid Angleα = Local Angle of Incidence of Blade Section

Inflow fluid angle is determined using:

Where:Φ = Inflow Fluid AngleU = Freestream Fluid VelocityΩ = Radial Velocityy = Local Distance from Axis of Rotation

𝜙 = arctan ( 𝑈 Ω ∗ 𝑦

Thrust can then be maximized if a blade profile is examined at a variety of angles of incidence, a differential of thrust is determined for each and then in functional design the most optimum angle of incidence is maintained over the entire length of the blade.

3.4.2. Nozzle Design Approach

Nozzle Design Approach

Nozzle shrouds are designed utilizing the same aerodynamic theory which is behind lifting airfoils: circulation of flow. Mathematically described as the line integral of a velocity about any closed curve, circulation of fluid is the primary physical phenomenon which drives airfoil lift. And is defined as follows:

Where:Γ = CirculationC = Closed Curve of Interest u = Velocity

)



dl = Infinitesimal Length∇ = Curl of Vector FielddS = Infinitesimal Area Enclosed by CStokes theorem has been applied between the first and second expressions of Γ above for any area S which is enclosed by the curve C. Treating the fluid in question as an Euler fluid, that is neglecting viscous

effects and inflicting a constant density upon it, it can be shown that circulation about a curve is intransient such that:

Where:t = Time

During the early 20th century a Russian scientist by the name of Nikolai Joukowski and the German mathematician Martin Kutta through their combined research and experimentation in the fledgling field of aerodynamics developed what is now called the Kutta-Joukowski Theorem. The Kutta-Joukowski Theorem proposes that flow circulation and the lifting force witnessed by an airfoil are intimately related. Examining Bernoulli’s Equation which has been arranged to describe the pressure difference between the top and bottom surfaces of an airfoil:

Where:pb = Bottom Surface Pressure pt = Top Surface Pressureρ = Fluid Densityut = Fluid Velocity along Top Surfaceub = Fluid Velocity along Bottom Surface

A resulting force which acts on an airfoil is called lift, which acts in the positive y direction of an airfoil positioned in the first Cartesian quadrant with its chord parallel to the x-axis and its leading edge oriented toward the y axis, is defined as the integral of the velocity differences from the leading edge where x=0 to the trailing edge where x=c as follows:

And then by the definition of circulation:

Figure 11: Circulation around nozzles, Accelerating(Left), Decelerating (Right)



It can be stated finally:By revolving an airfoil about a central axis a nozzle is rendered. This nozzle utilizes the same geometrical features of an airfoil in order to generate a lifting force, and by angling the airfoil it may be directed so that the vertical and horizontal vector components are cancelled and merged respectively. Then depending on

design intent an additional thrust can be harnessed to supplement acceleration constructively or

destructively to various extents.

The first design utilized a Kort nozzle with a push-pull profile. This was integrated because early on in the design of the electrical systems the software architecture had not designated the method of turning for the boat. A nozzle which would benefit both forward and backward movement of fluid through the thruster was chosen to maximize the versatility of the mechanical systems.

Figure 12: Kort nozzle profiles a) Accelerating b)Push-pull c) Slotted d) Decelerating

Once the software side of how the boat would turn had been decided upon, the design was reconfigured. When the boat is moving forward both thrusters are engaged for forward motion. Turning requires a choice to be made. Either one thruster would decrease or disengage its forward thrust, creating a moment around the associated side of the boat, or one thruster would reverse direction, theoretically creating a



greater moment about the associated side. However stopping and reversing the direction of a propeller is not enough to reverse the direction of thrust generated. In fact to create a reverse thrust would require the use of a twin propeller system, increasing cost, potential for mechanical issue when in operation, and drag of the thruster body. Thus a system where both thrusters are engaged for forward movement and a single thruster is disengaged for turning was decided upon.

This allowed for a reconsideration of chosen nozzle profile. A Rice-Speed nozzle profile is based upon air wing sections which display optimum lift/drag ratios (Celik, 2009). It has been found to increase performance by up to 10% from a standard profile used for the geometry of the Kort nozzle of the previous design. Rice Speed nozzles are designed with a profile which increases the forward thrust by up to 10 % (Joung, 2012)

Additional design considerations were to minimize drag, to house the motor within the assembly seamlessly, and to provide a route which the motor control wires could run from the propeller shaft to the interior of the boat in a way which protected their connections from becoming dislodged.

3.5. Network Design

Part of designing a robotic system with multiply microcontrollers and processors is the communication system between them. As such, the 2016 team designed a custom network based on the inherited, unsuccessfully implemented hardware. The TP-Link Router was originally configured to dynamically assign IP addresses to devices on the network. It was reconfigured to hold static IP and connect to a specified range of static IP addresses. Set lists of devices were bound to the router by editing its configuration to recognize the machine’s IP and MAC Addresses. Because of this, the engineers’ Remote Laptops could connect to the router’s broadcasted network. Additionally, the team edited the properties of the laptop to use a set IP address instead of obtaining one automatically so that the device could be recognized by the router. The Remote Laptop can as a result connect to the On-Board Laptop via a Secure Shell (SSH) interface. Because the On-Board Laptop and BeagleBoneBlack are both housed on the boat, a hard Ethernet connection to the Router added them to the network. A static IP was assigned to the On- Board Laptop by editing a network configuration file. Ultimately, to control the motors, the On-Board Laptop is able to SSH into the BeagleBoneBlack via our established network. A diagram of the network design can be seen in the following figure.



Figure 13: Network Design

3.6. Hardware Design and Rendering

The hardware that the WaterfOWLS 2015 team designed and instated was more than adequate for our use in the continuation of the project barring a few small changes. The main changes in the hardware come from the configuration of the BeagleBoneBlack processor. Additional design changes include the permanent fixture of the motor connectors, as well as simple updates such as connecting a switch between the voltage bus and the Lithium Polymer battery.

3.6.1. BeagleBoneBlack Configuration

The main processor on the boat is the BeagleBoneBlack. Due to the BeagleBone’s significance in the overall design of this project, a lot of time and resources went into deciding the optimal configuration for the BeagleBone. One of the main decisions regarding the BeagleBone was what operating system it should be running. BeagleBoneBlacks are shipped with a debian kernel already on the processor. The debian kernel seems like a pragmatic operating system to use, however its downfall lies in the fact that it must compile ROS from source code. In the process of compiling ROS, some dependencies and drivers were not obtainable, so the native debian kernel was not an ideal choice for the processor. Another likely choice for operating system for the BeagleBoneBlack is Ubuntu. Ubuntu is the only operating system that is fully supported by ROS, so it would seem to be an ideal choice. There are three versions of Ubuntu that are supported with the version of ROS that our system requires, ROS Hydro. The acceptable versions of Ubuntu include Ubuntu 12.04 Precise Pangolin, 12.10 Quantal Quetzal and 13.04 Raring Ringtail. Due to the configuration of the project, the only version that could be used was 12.04 Precise Pangolin. There are many resources online covering how to flash the BeagleBoneBlack memory in order to change the operating system. Ubuntu 12.04 appeared to be the logical choice, until further research unearthed a problem with newer BeagleBoneBlack boards. Due to a bug in the Rev C file, newer BeagleBoneBlacks could not be flashed with Ubuntu. After further research, another suitable operating system was found. The operating system that was decided upon for use with this project was Angstrom. Angstrom is not fully supported by ROS, but it is a highly stable experimental version. Additionally, there were no bugs or problems that prevented the flashing of the memory of the BeagleBoneBlack,



In order to change the operating system of the BeagleBoneBlack to Angstrom, an image of the Angstrom distribution needed to be downloaded onto a MicroSD card. Through the use of an SD card adapter and formatter, the team was able to load the image of the Angstrom distribution onto the MicroSD. The MicroSD was then inserted into the BeagleBoneBlack. The flashing button was held down and then power was supplied to the board. The flashing process was simple and effective. After the flashing was done, denoted by all of the diagnostic and power lights remaining on, the MicroSD card was removed and then the processor was rebooted. At this point we were able to SSH into the processor from the boat laptop, or to connect the processor up to a monitor and keyboard and directly access it.

The BeagleBoneBlack was configured to access the internet through the SSH portal by setting a gateway to forward the IP to. ROS was then obtained through the use of git. After ROS was done downloading, roscore was launched in order to configure ROS on the machine for the first time.

3.6.2. Motor Connection Permanence

One challenged the team encountered throughout the span of the project was the unreliability of the motors. The reason for the unreliability of the motors was determined to be poor solder joints in the circuitry that connects the signals to the motors. The poor solder joints appear to be a result of wear and tear due to use and travel. Due to these poor connections, the wires would come loose and the signal would not be passed to the motors. These connections were located in the protective tubing that ran from inside the boat, down the side to the motor casing. The circuitry inside this tubing had at least two connector joints per wire per motor. There were six wires in total, so this presented the chance for many joint and connector failures. This problem was then augmented by the inability to easily access the circuitry inside the protective tubing. In order to remedy this problem, the circuit design was altered to just have one strand of wire, per each of the motor leads (six in total, three per each motor). In addition to simplifying the wiring and circuitry, the connectors were also moved to inside the boat, so that they could be easily accessed, without having to remove the motors, motor casing, frames, and the protective tubing. Removing the protective tubing was not ideal because each time it is removed it greatly increases the chance of it breaking, or it not acting as a sealant as well as it could. All of the connector joints were replaced and re- soldered to ensure that this problem would not occur again. Additionally, if the need should arise to replace the circuitry, it will be much more accessible.

3.6.3. Single Pull, Single Throw Switch Installation

One important and simple design change that was instated was the insertion of a switch between the Lithium Polymer (LiPo) battery and the voltage bus. This is an important safety update. Before this change, a team member had to manually connect the positive and negative connectors to the boat circuitry. Due to the significant voltage in the battery (29.8V), the change for arcing in substantially higher. As team members would connect the battery leads, arcing would sometimes occur and cause sparks to occur. Frequent sparking is not a safe or ideal situation, especially while near expensive components. To combat this, a simple single pull, single throw switch was inserted between the positive lead of the battery, and the voltage bus. The voltage bus is responsible for distributing voltage to all the vital components of the boat’s circuitry. The use of the switch prevents the danger encountered by team members while trying to attach the battery to the circuit.



4. EVALUATION

4.1. Testing Methods

4.1.1. Computer Vision Algorithm Testing Method

In order to determine the best algorithm for buoy detection, static images were looped through the Blob Detection and Canny methods. To test the algorithms, 52 images taken with the Bumblebee camera during one of the indoor pool tests were gathered into one folder. One of these pictures is shown in Fig 16 for reference. Two python scripts, canny.py and blob.py, were written to loop over all of the images in the foler and perform the Canny Edge Detection and the Blob Detection, respectively. The scripts generated the grid over the bottom half of the image.

Figure 14. Input photo left0002.jpg

For the Canny edge detection, the script drew the contours of the identified buoy-shaped (and sized) objects detected within the grid on the output image, in bright green, as can be seen in Fig 17. Fig 17 also showcases the minimum estimated circles printed on the output image in navy blue.



Figure 15. Canny Edge Detection test output image

For the Blob detection method, the script drew red circles around the detected key points as shown in Fig18. Note that in this script, all of the detected key points are drawn on. However, only the ones in the bottom half are considered for the ultimate matrix returned to the navigation pipeline.



Figure 16. Blob Detection test output image

The images run through the algorithms were evaluated for accuracy and efficiency in identifying buoy- shaped (and sized) objects. Metrics for success in static image testing included the ratio of buoys successfully detected against buoys present, as well as the number of false positives.

4.1.2. Navigation Logic Testing Methods

In order to test the effectiveness of the matrix analysis completed in the navigation logic python script, a set of images taken from the boat were run through the logic in order to examine the output command. These command results were then compared to what the team determined a logical response to the obstacle placement would be.



Figure 17: Test Image left0000.jpg

In the picture above we see a buoy placed in the middle-right of the field of view. Logically, one would think that in order to avoid this buoy, a vehicle must turn left. In the code below, what is printed is the image, the values returned from the computer vision scripts. Additionally, there is the view of the two rows of the matrix. These rows are the third and fourth rows from the top of the matrix. The last line that is printed is the command. In this instance, the navigation logic also returns the command ‘left’ which matches with the logical choice.

Figure 18: Test Results for left0000.jpg

4.1.3. System Testing in Pool Methods

In order to test the complete system, the boat was taken from the laboratory to the indoor pool at Pearson Hall. At these testing sessions interoperability between the Imaging Pipeline, Navigation Pipeline and the



motor controllers were tested. Further static images from the Bumblebee stereovision camera were collected for further algorithm evaluation and testing. Four tests at Pearson Pool have been scheduled over the course of the Spring 2016 semester. Competition regulation buoys were used in these tests to simulation real competition situations.

4.1.4. Additive Manufacturing Methods

Computer aided design software allowed for all mechanical parts to be rendered digitally and fitted together with a high degree of accuracy. Marine propulsion components are composed largely of curved geometries fitted as seamlessly as possible in order to minimize skin friction and limit the overall drag force produced. The level of skill required to manufacture a propeller or a nozzle was beyond the skills of the design team and would be very expensive to outsource. Additionally the hiring of an outside machinist would likely push the project over budget, and production time would be unpredictable.

Additive manufacturing has recently become accessible for students of the College of Engineering, and designs being produced for senior design teams are free of charge. With no cost, quick manufacturing time, and a high degree of accuracy, the only limit to the design is the physical parameters of the additive manufacturing hardware, or 3D printers.

4.1.5. Computational Fluid Dynamics Methods for Nozzle and Propeller Blades

Ansys Fluent was used to simulate flow through 2D cross sectional nozzle profiles. Ansys Fluent is a Computational Fluid Dynamics software package which is proven reliable in a wide range of industrial applications. Computational Fluid Dynamics (CFD) is the science of predicting fluid flow and related phenomena. Detailed information can be accrued from CFD models regarding pressure and velocity distributions, as well as resultant force calculations. CFD is advantageous when compared to experimental lab testing because it can be done entirely on a computer and requires no physical testing or the complications which are intrinsically linked to such testing. Working within the platform of a senior design course where limited budgets and relatively short time schedules loom, CFD simulations provide an effective and efficient alternative.

For simulations involving flow around both the nozzle and the propeller blade a pressure based solver was chosen as it provides the best economy of time and handles incompressible fluid flows well, the alternative in Ansys Fluent being a density based solver which is usually reserved for use only when flow velocity achieves a very high mach number.

CFD software works by solving the Navier-Stokes equations iteratively. Several algorithms exist which can do this, and the most widely used is the Semi-Implicit Method for Pressure Linked Equations, or SIMPLE algorithm. Incompressible flows are well suited for solving by the SIMPLE algorithm and it was chosen as the most appropriate solver. When a solution converges then results of CFD simulation have been rendered and can be used.

Due to the iterative nature of CFD solvers it is necessary to check a few parameters upon solution convergence. Mass flux should be confirmed to fall within less than 1% of the smallest flux through a domain’s boundary.

Propeller blade profile optimization involved simulating flow over the airfoil profile which was selected and changing the angle at which freestream fluid flow met the solid. Free stream velocity was calculated according to the tangential velocity associated with the propeller movement. Two velocities were used, one representing fluid flow at the root of the blade and one representing fluid flow at the tip. Angles of attack were varied according to the theoretical specifications made available from references. Coefficients



of lift and of drag were collected from Ansys Fluent and compiled in Microsoft Excel, were they were then graphed for data presentation.

4.2. Testing Results

4.2.1. Computer Vision Algorithm Testing Results

According to the cited metrics for success (detected buoys versus buoys not detected and false positives), the output images were analyzed and returned the following tables. The detected buoys, the undetected buoys and false positives were pulled directly from the output image. The “Total buoys” column consists of the sum of the detected buoys and undetected buoys. The “Negatives” column consists of the sum ofhte undetected buoys and the false positives. The “Pos/Neg ratio” column consisted of the ration of the detected buoys to the negatives.

Table 3. Measured metrics for the Canny method

Detectedbuoys

Undetectedbuoys

Falsepositives

Totalbuoys

Negatives Pos/Neg ratio

1 1 1 2 2 0.51 2 1 3 3 0.3333333333

1 2 1 3 3 0.3333333333

0 3 0 3 3 0

1 2 1 3 3 0.3333333333

1 4 0 5 4 0.25

0 4 1 4 5 0

0 4 0 4 4 0

0 3 2 3 5 0

1 3 0 4 3 0.3333333333

0 4 1 4 5 0

1 3 0 4 3 0.3333333333

2 2 0 4 2 1

0 4 2 4 6 0

1 3 0 4 3 0.3333333333

1 3 0 4 3 0.3333333333

0 3 0 3 3 0

1 2 0 3 2 0.5

0 3 0 3 3 0

0 4 2 4 6 0

0 4 1 4 5 0

1 3 0 4 3 0.3333333333

1 3 0 4 3 0.3333333333

2 2 1 4 3 0.6666666667

2 1 1 3 2 1

2 1 1 3 2 1

1 2 0 3 2 0.5



1 3 1 4 4 0.252 2 0 4 2 1

0 4 0 4 4 0

0 4 0 4 4 0

0 4 1 4 5 0

2 2 1 4 3 0.6666666667

0 4 0 4 4 0

1 3 2 4 5 0.2

1 3 2 4 5 0.2

1 3 1 4 4 0.25

0 4 0 4 4 0

1 1 1 2 2 0.5

1 2 2 3 4 0.25

1 2 1 3 3 0.3333333333

0 4 1 4 5 0

1 4 0 5 4 0.25

0 5 1 5 6 0

1 4 0 5 4 0.25

1 4 1 5 5 0.2

2 4 1 6 5 0.4

2 3 1 5 4 0.5

1 4 0 5 4 0.25

1 4 0 5 4 0.25

1 4 1 5 5 0.2

The average of the “Pos/Neg ratio” column for the Canny method was calculated and found to be

𝑃𝑜𝑠𝑁𝑒𝑔!"##$,!"# = 0.282Table 4. Metrics measurements for the Blob Detect method

Detectedbuoys

Undetectedbuoys

Falsepositives

Negatives Pos/Neg ratio

0 2 0 2 00 3 0 3 0

0 3 0 3 0

0 3 0 3 0

1 2 0 2 0.5

0 4 0 4 0



0 4 0 4 01 4 0 4 0.25

1 3 0 3 0.3333333333

0 4 0 4 0

1 3 0 3 0.3333333333

1 3 0 3 0.3333333333

2 3 0 3 0.6666666667

0 4 0 4 0

0 4 0 4 0

0 4 0 4 0

0 3 0 3 0

0 3 0 3 0

0 3 0 3 0

0 3 0 3 0

0 4 0 4 0

0 4 0 4 0

0 4 0 4 0

0 4 1 5 0

0 3 0 3 0

0 3 0 3 0

0 3 0 3 0

0 4 1 5 0

0 4 0 4 0

0 4 0 4 0

1 3 0 3 0.3333333333

0 4 0 4 0

0 4 0 4 0

0 4 0 4 0

0 3 0 3 0

0 3 0 3 0

0 4 0 4 0

0 4 0 4 0

0 3 1 4 0

1 3 1 4 0.25

1 2 0 2 0.5

0 4 0 4 0

1 3 0 3 0.3333333333

0 5 0 5 0

0 5 0 5 0

1 4 0 4 0.25

1 4 0 4 0.25



1 4 0 4 0.251 4 0 4 0.25

1 4 0 4 0.25

1 4 0 4 0.25

The average of the “Pos/Neg ratio” column for the Blob Detect method was calculated and found to be

𝑃𝑜𝑠𝑁𝑒𝑔!"#$,!"# = 0.105

Since !"#!"#!"#$,!"# < !"#!"#!"##$,!"#

, the Canny method is preferable to the Blob Detect method. In general,

the Blob Detect method seemed to “detect” small flags in the top half of the image and rarely detect buoys. On the other hand, the Canny method has many false positives in the bottom half of the image, it is also more successful in detecting actual buoys, and avoiding obstacles is of more immediate concern. The Canny method could use perfecting in the parameters, but it is still significantly better than the Blob Detect method.

4.2.2. Navigation Logic Testing

In the following image, left0001.jpg, there is a buoy placed in the center-left of the field of view, right where the navigation logic is analyzing. One might deduce that the vehicle should turn some sort of right. It is not as close to the center as the previous image.




When the image is run through the navigation logic script, the results are that the command is to make a moderate right. This is significant since the buoy is not as close to the center as the previous example, so the motor power percentages should reflect that as well.

Figure 20: Test Results Command for left0001.jpg

In the following image, left0009.jpg, there is a buoy that is recognized that is rather far off, slightly to the right of the center of the view. Since the danger is not too immediate, the logical choice would be to proceed forward. It is also important to note that there is an additional buoy in the far left of the field of view. Unfortunately the Imaging Pipeline did not detect this buoy, but in the current situation the boat does have room to proceed forward.




The output of the navigation logic script does indeed suggest forward as the command the boat should proceed with.

Figure 22: Test Results Command left0009.jpg

In the image below, left0004.jpg, there are two buoys. The imaging pipeline appears to have identified both collectively as one buoy due to the proximity and placement of the buoys. The center of this collective buoy is further back than the immediate danger zone. One might consider the need to turn to the left to avoid this obstacle, or maybe even move forward a bit before turning.




The logic as is suggests that the boat can still move forward successfully. However, if we change the priority and search one row back, the logic then informs the boat that it should turn to the left. Assigning and determining priority could be the focus of further expansion of this algorithm and project.

Figure 24: Normal Test Results Command for left0004.jpg

Figure 25: Test Results Command for left0004.jpg with Later Priority



4.2.3. System Testing in Pool Results

The first pool test was used as a chance to observe the complete system in the state that we were given from the previous team. There were issues with the motors, which were soon after debugged as an issue with received current. Additionally, the Bumblebee stereovision camera was not connecting to the system. We were able to obtain physical data regarding water level and such. Additionally we were able to gain static images to use in evaluation of algorithms and finite state machine development.

4.2.4. Additive Manufacturing Results

The first design was rendered in Solidworks and printed with a MakerBot 3D Printer. Several issues became immediately clear. The original design of the propeller used a very thin blade profile. This could not be manufactured effectively, and the very thin blades resulted in a fraying of the propeller blades when they were printed.

Figure 26: Rendering of First Propeller Design and 3D Printed Propeller with Fraying



Figure 27: Rendering of Second, Thicker Propeller Design and 3D Printed Propeller

The propeller was redesigned with the same blade profile with an increased thickness to chord ratio and it was printed successfully

The first design of the motor mount printed with an inexplicable error. When a Solidworks model is ready to be printed it must first be saved as an .stl file, which simplifies the information stored in the file to surface information only. This surface only file can then be sent to a Makerbot 3D printer and printed, but it is recommended that files first go through a software program built into the Makerbot interface program which analyzes the model’s surfaces and determines if the object can be physically printed or not. In spite of each design passing through this software without any warnings or errors, the first printing of the motor mount had a solid block of plastic printed where there was a cavity designated by the computer model. In an attempt to fix this the printed part was machined on a lathe, however the operating temperatures of the lathe began to melt the plastic.

The model was redesigned from nothing in order to avoid whatever error was present in the original model. And although the cavity was present in the second printing, the holes where screws would have actually mounted the motors to the mount were printed filled in.

Figure 28: Rear View of First Printing with Melted Plastic from Maching Visible

The final design has been printed using the Objet 3D printer which has a considerably smaller printing

Figure 30: Mesh of Kort Nozzle 19a Profile



filament and a higher degree of accuracy for prints. The entire thruster was also redesigned, due in part to experimental data which has now been collected and due to the Object printer having a larger maximum printing surface.

Figure 29: Front View of Second Printing with Screw Mount Errors

4.2.5. Computational Fluid Dynamics Results for Nozzle and Propeller Blades

Prior to the execution of a CFD simulation a fluid domain must be defined and then a “mesh” must be generated appropriately. Ansys Fluent uses a finite volume method of breaking up the fluid domain into finite subdomains. Except for a seldom few elementary flows, it is usually feasible to find an analytical solution to the governing equations of fluid flow, and thus this subdividing is necessary. “Meshing” a domain is the vernacular used in most CFD software communities andpackages which is used to describe this process, the resulting divided domain referred to as the “mesh”.Meshes are made up of “cells” which connect at “nodes”. How densely a mesh’s cells are packed effects the accuracy and the computation time of a simulation, and so meshes are crafted with some care. It is strategic to increase the density of a mesh around corners and along boundaries of geometric features. Mesh skewness describes how distorted cells are within a mesh where the more distorted, or skewed, a cell is, the less accurate the results for that portion of the domain are. Figure 30 shows the mesh used for the first design of the nozzle which used a Kort 19a profile. Below the mesh a skewness report is di splayed.

Figure 32: Velocity Vectors and Contours, Pressure Contours for Kort 19aFigure 31: Cl, Cd, and Evidence of Convergence for Kort 19a



Additionally graphs of calculated coefficients of lift and drag are included to show that the solution had stabilized, as well as output information that Ansys Fluent prints stating that the iterative solution of the Navier-Stokes equation had converged in Figure 23. Finally for the first nozzle profile three graphs are included which show velocity distribution as a vector plot and as a contour plot, and a contour plot of pressure distributions in Figure 24.

For this simulation a single cross section of the nozzle was investigated, and coefficients of lift and drag were computed. The coefficients are preprogrammed into the Ansys Fluent package and simply measure resultant forces along the x and y axis for surfaces that were designated by the software user. Coefficients of lift will produce a lifting force in the direction of the y axis, however because the nozzle is revolved a full 360 deg. this force will be cancelled out by the section of nozzle on the opposite side. By convention coefficients of drag are measured positive if the resulting drag force is opposed to the fluid flow. A negative coefficient of drag is being reported here by Ansys Fluent which means that the nozzle profile will indeed produce an additional thrust once the boat has achieved forward motion.

After reviewing further literature evidence appeared that a newly developed Rice-Speed nozzle profile could be used to improve thrust and propeller efficiency further, and so this profile was tested using the same test parameters as before. Again Figure 23 shows the mesh used and its skewness report, evidence of convergence is provided and results are reported. The coefficient of drag increased in magnitude while remaining oriented in the direction which the vessel will be moving, indicating that indeed this new profile provides better performance than the first design.

Figure 35: Mesh of Rice Speed Nozzle Profile

Figure 33: Velocity Vectors and Contours, Pressure Contours for Rice Speed



Figure 34: Cl, Cd, and Evidence of Convergence for Rice Speed Nozzle

By cycling through angles of attack for the chosen airfoil profile and varying freestream velocity in accordance to the tangential velocity which is present it was found that the optimal angle of attack was 8 degrees. When combined with the inflow fluid angle of the free stream at the root this amounted to a total angle of blade incidence of 38 degrees. These angles can be mapped onto the hub of the propeller easily, but it is advantageous to modify them slightly in order to maximize blade area, and thus maximize effective lifting surface. Tilting the blades slightly so that they run from the beginning of the hub to the end

Figure 36: Cross Section of Propeller Blade



only resulted in a tenth of a degree alteration in angle of attack and the increased blade area will improve propeller performance. Figure 24 shows a cross section of propeller blade with the hub.

4.3. Hardware

4.3.1. Electrical Hardware

The focus of the electrical portion of this project is on the programming of the boat; therefore the final hardware specifications are largely that of the legacy project, Temple WaterfOWLs 2015. The WaterfOWLs 2015 team used a selection matrix to identify which part would be the best for each job or situation. For onboard computing they chose a motherboard and aBeagleBoneBlack. For vision sensing they chose a Bumblebee stereovision camera (Million, Simon,Smith, Throne). The schematics for the overallsystem, as well as the onboard voltage distribution are shown below.

Figure 37: Legacy Hardware Electrical Schematic Overview

Figure 39: Final Propulsion Assembly



Figure 38: Legacy Hardware Voltage Distribution

4.3.2. Mechanical Hardware

The final mechanical design components are far improved over the original design. Increased propeller performance due to the gathering of additional information regarding propeller design, and test results accrued from Ansys Fluent will result in a final design capable of propelling the craft an expected maximum 10.5 ft/s, an improvement over the design completed in the previous year. Streamlined design of the propulsion assembly has minimized drag and the design has been built in a way that is sturdy and will hold up over prolonged use. Final hardware rendering shows how the front support was created to house and secure the motor and to slide into grooves cut from the nozzle.

With an intention to 3D print the mechanical components from the start impacted greatly how the design could be creatively developed. Support struts could be cut directly from the profile of the nozzle so that when they slide into place the over all curvature is consistent and flush.

Figure 40: Fully Assembly Exploded



Additional advantages that 3D printing allowed include the ability to cut a variety of housings for the hardware that would eventually hold the entire assembly together, as well as allow electrical wires to be securely run from the motor to the internal electronics of the boat.

Figure 28 shows the entire mechanical assembly exploded so that it can be explicitly shown. The front support which is the three strutted spherically headed cylinder toward the bottom left of the figure houses the motor which attaches via four support screws. The motor shaft is coupled to the drive shaft and the propeller hub is keyed onto that shaft which comes to rest on a bearing which lodges into a rear support (not pictured) which is connected to the Rice Speed nozzle. The three struts of the front support finally slide into the nozzle walls and then three set screws fall through holes in the side of the nozzle and mate with nuts which are lodged within the feet of the front support struts. Finally the Assembly is attached to the rear of the boat via bolts. A hole in the top strut allows for the wires which deliver power to the motors.



4.4. Software

All of the current WaterfOWLs code is hosted on GitHub at the following link: https://github.com/TempleWaterfOWLS

5. SUMMARY AND FUTURE WORK

Temple WaterfOWLs 2016 sought to not only continue but also improve upon the excellent work of the 2015 WaterfOWLs. Equipped with the physical hardware and the haul of the boat as well as firmware to control its motors, the 2016 team was tasked with developing the software systems needed to complete the task of autonomous obstacle detection, and designing a new propulsion system to enable that obstacles were avoided.

The progress with the mechanical aspect of the project has been the completion of the redesign of the propulsion system. This system was analyzed through the use of ANSIS and evaluated to be able to be printed using the machine shop’s facilities. However, when the parts were printed, they were not up to par due to fraying. The models were then reanalyzed and printed using a different machine in order for the parts to be printed effectively and efficiently. This second redesign proved to be printed better and appear to be fine for use in the system. Future work includes running an experiment on the isolated propulsion system to evaluate efficiency, and to mount the new propulsion system on the boat and evaluate in future pool tests. Because of the high financial expense and long manufacturing time of 3D printing, alternative manufacturing processes may be pursued. Potentially the assembly could be manufactured in a hard foam in sectional cuts using an automated foam cutting machine and then have a carbon fiber casing fabricated over top for waterproofing. Although this method is not nearly as simple as additively manufacturing the components, it may be realizable without over extending the project budget.

The progress with the computer vision, or Imaging Pipeline, has been the decision of what algorithm to use to detect the circular buoys in competition. The algorithm that was picked is the Canny Algorithm. As compared to the BlobDetection algorithm, the Canny Algorithm returned less false positives, and was also able to identify the buoy in the static image. Future work on the Imaging Pipeline includes determining a refresh rate in which live images can be analyzed successfully for competition use, as well as integration with the complete system. Additionally, it appears that the images received from the Bumblebee stereovision camera appear to be mostly in gray-scale, so the current plan for image processing will be altered to be entirely in gray-scale, which is how most image processing is done normally.

On of the biggest challenges that were encountered this past semester was the recreation of the network configuration. The network was not configured to withstand static IP addresses of nodes in the network and therefore would not allow for communication between nodes in the network. It was what one IT professional labeled as “unsettling”. Resolving this issue took a lot of time, but it was also very beneficial in increasing the general knowledge of the team in the realm of network configuration. Going forward, the network issues appear to be resolved so no further plans have been made for further development or extension of the network.

The simple set sophisticated system of ROS nodes is a communication system in itself, and is only going to be expanded on in our future expansion of software systems. ROS is the glue between the Imaging Python and the motor controllers. The system consists of a series of 'nodes' which either subscribe or publish to another node, creating a network of stored information over multiple processors and platforms. To run the motors themselves, ROS is executed with a series of Python scripts that publish to the nodes 'Motor Power' and 'Motor Response'. The navigation system itself ultimately publishes to ROS nodes to control the motors themselves based on what state it decides it is in. Using a matrix of input data provided from the Imaging Pipeline, the Navigation system can tell whether or not it needs to turn the motors right



or left based, and executes that decision by publishing to a ROS node. In the future, the ROS librarh 'smach' (short for state machine). Is going to be implemented in the Navigation pipeline to automatically publish and subscribe to ROS nodes. The integration of this tool will allow for more seamless state-to-state flow, especially between layers of the state machine.

In order to test the complete system as it would perform in a competition setting, three more indoor pool tests have been scheduled to take place at Pearson Pool. Additionally, outdoor tests will be scheduled once the weather warms up. These will most likely take place at Core Creek Park.

The current navigation logic script represents a very simple algorithm. In order to further develop it, it should take into consideration additional rows in order to plan a full path instead of just part of a path. In order to take into consideration additional rows, a priority value should be assigned to the various rows. Planning a full path would also be ideal because it would allow for the algorithm to record the motions in order to keep the boat on track and maintain a heading.

6. ACKNOWLEDGEMENTS

We would like to acknowledge our faculty advisors, Dr. Li Bai and Dr. John Helferty, for their constant support and guidance. We would like to acknowledge The Computer Fusion Lab at Temple University for providing us with workspace. We would also like to acknowledge the members of the 2015 WaterfOWLs team for the incredible work they did to start this legacy project. We are grateful to Jacob Simon, Joseph Throne, Taylor Millon, Zack Smith, Troy Seningen, Selman Gokcepinar, Mohammad Albahrani, and Michael Krump for all of the tremendous work they put into the project, as well as the sponsorship they gained from VideoRay, Sparkfun Electronics, and Texas Instruments. We would also like to thank the online ROS, and OpenCV communities for their assistance. We would like to thank the staff at Pearson Pool for their assistance and help with pool rental. We would also like to thank David Ryskalczyk of the College of Engineering IT Department for his unlimited wealth of knowledge and assistance, especially with network configuration.



7. REFERENCES

Carlton, J. (2012). Marine propellers and propulsion (3rd ed.). Oxford: Butterworth-Heinemann.

Celik., F., Dogrul, A., & Arikan, Y. (2009). Investigation of the Optimum Duct Geometry for a Passenger Ferry. Yildiz Technical University.

Gerr, D. (1989). Propeller handbook: The complete reference for choosing, installing, and understanding boat propellers. Camden, Me.: International Marine Pub.

Jie Wu; Abdulla, H.M.D.; Snasel, V., "Application of Binocular Vision and Diamond Search Technology in Computer Vision Navigation," in Intelligent Networking and Collaborative Systems, 2009. INCOS '09. International Conference on , vol., no., pp.87-92, 4-6 Nov. 2009 doi: 10.1109/INCOS.2009.41

Joung, T., Sammut, K., He, F., & Lee, S. (03/01/2012). International journal of naval architecture and ocean engineering: Shape optimization of an autonomous underwater vehicle with a ducted propeller using computational fluid dynamics analysis Society of Naval Architects of Korea.

Marengoni, M.; Stringhini, D., "High Level Computer Vision Using OpenCV," in Graphics, Patterns and Images Tutorials (SIBGRAPI-T), 2011 24th SIBGRAPI Conference on , vol., no., pp.11-24, 28-30 Aug. 2011 doi: 10.1109/SIBGRAPI-T.2011.11

Million, T., Simon, J., Smith, Z., Throne, J. (2015) A Robust System for Autonomous Nautical Navigation and Task Integration.

OpenCV SimpleBlobDetector. Retrieved November 26, 2015 from the OpenCV Documentation: http://docs.opencv.org/2.4/modules/features2d/doc/common_interfaces_of_feature_detectors.html

Pivano, L., Johansen, T. A., & Smogeli, O. N. (2009). A four-quadrant thrust estimation scheme for marine propellers: Theory and experiments. IEEE Transactions on Control Systems Technology, 17(1), 215-226. doi:10.1109/TCST.2008.922602

Rastelli, J., & Peñas, M. (2015). Fuzzy logic steering control of autonomous vehicles inside roundabouts. Applied Soft Computing, 662-669.

RoboBoat - Foundation. (n.d.). Retrieved February 10, 2016, from http://www.auvsifoundation.org/foundation/competitions/competition-central/roboboat

ROS Wiki. (n.d.). Retrieved February 09, 2016, from http://wiki.ros.org/ROS/Tutorials/NavigatingTheFilesystem

Tuna, G., Arkoc, O., Koulouras, G., & Potirakis, S. M. (2013). Navigation system of an unmanned boat for autonomous analyses of water quality. Elektronika Ir Elektrotechnika, 19(8), 3. doi:10.5755/j01.eee.19.8.5387

Ullah, S. (2014). Autonomous surveying boat.

龙 , 余 , Yu, L., Druckenbrod, M., Greve, M., 王珂琦 , Wang, K., & Abdel-Maksoud, M. (2015). Numerical and experimental analysis of a ducted propeller designed by a fully automated optimization process under open water condition. China Ocean Engineering, 29(5), 733-744. doi:10.1007/s13344-015-0051-x



APPENDIX A: COST

The estimated total expense report from the 2015 WaterfOWLS team came to a total of $7582. It is important to note that the team did not actual spend all of this money. This included expenses that covered such topics as pontoons, motion, processors, sensors, power, communication, nuts and bolts, testing, and miscellaneous. Many items were donated, and some items they included were projected costs, including items such as a trailer for transporting the boat, and a canopy for use at the competition. Costs that were not included in their analysis include the cost for team transportation and housing during the week of the competition. It is important to note that some of these values are also estimates.

Table 5: WaterfOWLS 2016 Purchased Electrical Components and Parts Expenses

ItemUnit Price Quantity Vendor System

Cost ofproduct(s)

Total Cost

Zippy Compact 25C 8S 5800 LiPO Battery 82.23 2

Hobby King Power 164.46 164.46

MR JIG soldering aid 7.01 1Hobby King Hardware 7.01 7.01

Turnigy 870E Digital Multimeter w/Backlit Display 6.99 1

Hobby King Hardware 6.99 6.99

battery charger & adapter 39.99 1Hobby King Power 39.99 39.99

Zippy Compact 25C 8S 5800 LiPO Battery 64.38 1

Hobby King Power 64.38 64.38

BeagleBoneBlack 56.95 1 Amazon Processor 56.95 56.95

4mm Easy Solder Gold Connectors (10 pairs) 3.09 1


Dual Power Heat Gun 750W/1500W Output (120V/60Hz Version) 16.69 1


Total Cost 359.56



Table 6: WaterfOWLS 2016 Propulsion System Manufacturing Costs

Part Price - street Price - EDU Time

RiceSpeed Nozzle 2007.34 1004 81.38 x2

Prop Right 117.29 59 10.25

Prop Left 117.29 59 10.25

Front Support 204.89 103 25.48 x2

Further costs to consider include travel to the competition, as well as lodgings. The projected costs are shown below in the table below. These numbers were approximated based on two people of the same gender going to the competition, which would require only one hotel room with two beds. The hotel is The Founder’s Inn and Spa and is the hotel associated with the competition at which all teams must stay. The dates projected for the hotel stay coincide with the week of the competition, as well as one day before and one day after the competition to allow for adequate travel time. It also takes into account the added amount of tax on the room. This analysis also takes into account the cost of gas, number of miles from Temple University to the hotel, and even if there are toll roads, which would also increase our spending. Through route research, the ideal route was determined to be to take US 113 South to US 12 South, which would be 275 miles and require no tolls. This path was chosen because it took less time, had no toll roads, and fewer miles to travel, all of which save us time and money. Researching the projected range of the cost of a gallon of gas for July 2016, and then using the top value of the range to be conservative estimated the total cost for gas for the round trip. The last cost to be factored into the analysis is the cost for registration for the competition, which was $750 this year.

Table 7: Travel, Lodging and Registration Costs

Lodging

Hotel Room Nights Cost/night Cost Cost plus tax

Founder's Inn and Spa 1 10 $129 $1,290 $1,480

Travel

Path Miles Tolls? Time Approx cost per gallon of gas Approx cost for all gas

US 113S to US 13S 275 none 5 hr 6 min $2.75 $70.68

Misc.



Registration $750

Total Costs: 2300.68



APPENDIX B: SCHEDULE

Legend: CV- Computer Vision/Imaging Pipeline MC- motor controllersMech- mechanical system/propulsion system

02/02- First Boat Pool TestCV: ROS skeleton (create software architecture)

write fake output script for testing (of ROS architecture and of motor control)

obtain test images (buoys in tub of water outside)

improve image processing algorithm (using static images) At Test: test static processing and obtain more test images

MC: Create simple, autonomous state machine in Python on personal machine

Construct and document a design for motor control state machine

Finish version 1 of simple Motor Control Pipeline, controllable by manual commands (Turtlebot)

Mech: Theoretical calculations02/12- Preliminary Design Document DueMech: Redesign of propulsion system CAD models Full Assembly 02/18- Preliminary Design Review

02/23- Second Boat Pool Test CV:

Use new images to perfect image processing (based on distance of buoys from boat)

Develop image processing reaction scripts (will need Raquel for this as control is involved)

lock on to distant buoy

get around buoy (will require testing as to how long it should keep turning around buoy)

This will require perfecting the image processing

At Test: test live processing “lock on” and “get around” scripts MC: Run rests on turning radius with Turtlebot and speed tests

Adjust algorithm turning mechanics (aka adjust how the boat turns based on what we found at the test)

Run manual test cases with fake image data

Mech: CFD Simulations from Components02/27-03/05 - Spring Break!



03/15- Third Boat Pool TestCV: Tweak reaction scripts as needed

String the “lock on” and “get around” scripts together in some sort of statemachine-like thing

Maybe write some scripts that test different “distances” aka increments of how big the buoy should be before we start turning

MC: Finalize communication protocol between Vision and Motor Control pipelines

Static Image Testing

Mech: Manufacture Components

03/25- Independent Propulsion Study 04/05- Fourth Boat Pool TestCV: Calibration and tweaking

At Test: test calibration MC: Run tests with actual buoys

Adjustments based on Test results

Being process of processing real time images

Mech: Redesign04/15- Final Design Document Due

04/18- Final Poster and Website Due MC: Testing with a field of Buoys

Speed and Accuracy Tests

Perfecting communication between all pipelines

Algorithm optimization

04/21- Final Design Review

04/23- Senior Design Day



APPENDIX C: AUVSI ROBOBOAT 2016 PRELIMINARY COMPETITION RULES

1. Introduction

This is a very high-level overview of the RoboBoat 2016 rules. Publishing the Final Rules always takes a

considerable amount of time and this document is designed to start a discussion around the proposed

challenge ideas.

If you did not attend RoboBoat last year, you will want to first familiarize yourself with the 2015 Rules as

this document implies a level of familiarity with them. See: http://goo.gl/pCkKxW

2. Challenge Overview

We will re-use the same Start and Speed gate challenge. The Start gate will be 50-100ft from the dock and

the Speed gate will be 30-50ft from the Start gate.

The Obstacle Avoidance challenge from 2015 will be tweaked and re-used. The Automated Docking

platforms from course A & course B will be assembled together to form a donut-shaped floating island

(see: Appendix 1: Floating Island diagram below). In addition, a foot-long hook- side Velcro patch will be

added to each bay. To prove that you successfully docked, you must attach a loop-side piece of Velcro

with you team name.

We will also tweak the Acoustic Beacon Positioning challenge. In each course, two pingers will be active

during each run. The two pingers on the same course will be on frequencies at least 2 kHz apart from each

other. You have to identify the two buoys with an active pinger, circle them and report the pairs of (buoy

color, frequency) detected.

We will preserve the intent of the interoperability challenge but radically change it. The goal for 2016 is to

launch and recover an autonomous AUV (underwater) rather than a UAV (aerial). The AUV will be

launched from outside of the floating island. From there it has to navigate under the dock to reach the

center of the floating island. A display facing down will be submerged a few inches below the water

surface. Your AUV must take a picture of the display, identify the number between 0 and 9 shown, and

report both the picture taken and the number identified.

In 2015, teams will continue to roll out their own network solution. Last year, several teams had issues

with wireless technologies using 2.4Ghz frequency. If you did experience problems or did not enter 2015

RoboBoat, you may want to explore different solutions. Don't forget that if you opt for a wireless

technology, you are responsible for ensuring that you use either a public frequency or acquire a license to



stay compliant with FCC regulations.

Instructions about registration, introduction video, website and journal paper deadlines will be posted on

www.roboboat.org.

Finally, we will strictly enforce the safety rules and deployment requirements. Any vehicle or team that

does not meet the following rules will not be deployed into the water (no exceptions):

• Demonstrate the e-stop (remote kill switch) and the physical emergency stop buttons.

• Provide a transport cart and a 3 or 4-point harness to deploy the vehicle by crane.

• Provide a 2-point harness to tow the vehicle.

• No sharp edges exposed, un-shrouded propellers, or exposed electronics.

3. What is coming next

We intend to complete the Final Rules by February 26, 2016. We will start hosting Google Hangouts every

other Thursday beginning on January 7th 2016 for interactive feedback sessions.

4. Feedback and Questions

Rules / Technical Issues: o Félix Pageau o [email protected] o +1 607 220 4636 cell

Event Planning / Logistics o Cheri Koch o [email protected] o +1 850 642 0536 cell

Sponsorship / Marketing / Media o Andrea Ansell o [email protected] o +1 703-963-5108

5. Appendices

Appendix 1: Floating Island diagram

Floating island - Aerial View



Figure 1. Floating Island diagram for Automated Docking and Interoperability challenges



APPENDIX D: SELECTED CODE

SMACH:

import rospy import smach

import smach_rosfrom std_msgs.msg import String

def snag(i):a = ["objectFound", "objectRight", "routeClear"] rospy.loginfo("dir: " + a[i])return a[i]

#functions to set up subscriber node def callback(data):

rospy.loginfo("direction: " + data.data)

def listener():rospy.init_node('listner', anonymous=True) rospy.Subscriber('topic', String, callback) rospy.loginfo(String)#rospy.spin()#return String#rospy.loginfo('state: ' + data.data) # rospy.spin()

#default stateclass Scanning(smach.State):

def init (self):smach.State. init (self, outcomes=['objectFound', 'exit'],

input_keys=['counter_in'], output_keys = ['counter_out'])

def execute(self, userdata): rospy.loginfo('executing state SCANNING') if userdata.counter_in < 3:

state = snag(userdata.counter_in) else:

state = "exit"userdata.counter_out = userdata.counter_in + 1 return state#return test_listen()

# return listener()#Object has been found...where do we go?



class Deciding(smach.State): def init (self):

smach.State. init (self, outcomes=['objectRight', 'objectLeft', 'objectFound', 'exit'],

input_keys=['counter_in'], output_keys = ['counter_out'])

def execute(self, userdata): rospy.loginfo('executing state DECIDING') if userdata.counter_in < 3:


state = "exit"userdata.counter_in = userdata.counter_out + 1 return state

class TurningRight(smach.State): def init (self):

smach.State. init (self, outcomes=['routeClear', 'exit'],input_keys=['counter_in'], output_keys = ['counter_out'])

def execute(self, userdata): rospy.loginfo('executing state TURNING RIGHT') if userdata.counter_in < 3:


state = "exit"userdata.counter_out = userdata.counter_out + 1 return state

class TurningLeft(smach.State): def init (self):

smach.State. init (self, outcomes=['routeClear', 'exit'],input_keys=['counter_in'], output_keys = ['counter_out'])

def execute(self, userdata): rospy.loginfo('executing state TURNING LEFT') #implementif userdata.counter_in < 3:

state = snag(userdata.counter_in)

else:state = "exit"



userdata.counter_out = userdata.counter_in + 1 return state

def main():

rospy.init_node('smach state_machine') #create top level SMACH state machinesm = smach.StateMachine(outcomes=['last_outcome']) #open the container !sm.userdata.counter = 0 with sm:# listener()

#Add states to the container smach.StateMachine.add('SCANNING', Scanning(),

transitions='objectFound':'DECIDING','exit':'last_outcome',

remapping = 'counter_in':'counter','counter_out':'counter')

smach.StateMachine.add('DECIDING', Deciding(),transitions='objectRight':'TURNINGLEFT',

'objectLeft':'TURNINGRIGHT', 'objectFound':'SCANNING', 'exit':'last_outcome',

remapping = 'counter_in':'counter','counter_out':'counter')

smach.StateMachine.add('TURNINGRIGHT', TurningRight(),transitions='routeClear':'SCANNING',

'exit':'last_outcome', remapping = 'counter_in':'counter',

'counter_out':'counter')

smach.StateMachine.add('TURNINGLEFT', TurningRight(),transitions='routeClear':'SCANNING',

'exit':'last_outcome', remapping = 'counter_in':'counter',

'counter_out':'counter')

outcome = sm.execute()



if name == ' main ': main()

navLog.py

#!/usr/bin/env python

import sys import os import os.path #import canny#import canny_single import numpy

def main():# read in the integer values which represent the binary of

where the buoys# are in the matrix through the use of canny_single and providing the # image to be checked #int_values=canny_single.canny_single("left0002.jpg")int_values= [0,16,0,0,0,0,0,0] print("Image: " + "left0009.jpg") print ("Int_values ",int_values)# convert the 4th row into 8 bit binary to determine precise

local of buoysrow=3 nextRow=row-1M= '0:08b'.format((int_values[row]/2)) nextM='0:08b'.format((int_values[nextRow]/2)) print ("NM " + nextM)print("M " + M) m=[0]*8nm=[0]*8

# Initialize output array m = [0]*len(M)nm= [0]*len(M)

# M is read in as a string, but we need to access the bits as binary for i in range(len(M)):

m[i]= str2oppbool(M[i]) nm[i]=



str2oppbool(nextM[i])

# input argument is currently just the row of the matrix (start at 5th



one)# starting at middle, check to find where 2 spots are open and

determine# the relative command that should be sent# you need to check both rows because the center of the buoy

could be in the# next row and it could still prevent passage due to a small

fraction of it# from passing through# We have identified that the boat needs approx 2 squares to

pass throughif m[2] and m[3] and m[4] and m[5] and nm[2] and nm[3] and nm[4]

and nm[5]:command="forward" # R= 0.6 L= 0.6

elif m[1] and m[2] and m[3] and m[4] and nm[1] and nm[2] and nm[3] and nm[4]:

command= "moderate left" # R= 0.6 L=0.45elif m[3] and m[4] and m[5] and m[6] and nm[3] and nm[4] and nm[5]

and nm[6]:command="moderate right" # R=0.45 L=0.6

elif m[0] and m[1] and m[2] and m[3] and nm[0] and nm[1] and nm[2] and nm[3]:

command="left" # R= 0.6 L=0.3elif m[4] and m[5] and m[6] and m[7] and nm[4] and nm[5] and nm[6]

and nm[7]:command="right" # R=0.3

L=0.6 else:command="run awayyyy" # R= 0 L=0.6, maybe even higher## really cant stop, prolly should pick a default side and make a ## hard turn to attempt to avoid all, maybe default left?

print (command) return command

# then publish the command to the topic

# Stolen from the interet for our convenience# switched it to be for the false values since we want the path to # be clear, which is represented by a 0, or boolean falsedef str2oppbool(v):

return v.lower() in ("0")

if name ==" main ": main()



Canny.py

#!/usr/local/bin/python

# lol do I even still use all of these imports? import osimport cv2 import mathimport numpy as np import argparse import globimport sys

## Set folder of input and output images infolder = "input-photos/"outfolder = "output-photos-canny/"

## Set number image and matrix parameters cols = rows = 8width = 640height = 480

## I divide the following height by two because the grid should only cover half of the imageblockw = width/cols blockh = height/(rows*2)

filename = "canny_matrices.txt"

## Main function def main():

f = open(filename, 'w')## Iterate through all of the input jpg photos in the

directory under the working dir## and run the findBuoys Canny function on them. for i in os.listdir(os.getcwd()+"/input-photos/"):

if i.endswith(".jpg"): print i findBuoys(i, f) continue

else:



continue

## Close OpenCV and exit Python script when done



cv2.destroyAllWindows() sys.exit(0)

### findBuoys(input_image_name)## Function to use Canny Edge Detection + findContours methods to find buoys in every image in the## input photo folder, then save the images with the detected contours in the output photo folder.## It uses weird statistics magic that I stole from the internet to set the parameter for Canny ED.def findBuoys(imgname, f):

## Load image from input photo folder img = cv2.imread(infolder + imgname)

# Set some parameters automatically (based on statistics magic that I stole from the internet)

sigma=0.33med = np.median(img)lower = int(max(0, (1.0 - sigma) * med)) upper = int(min(255, (1.0 + sigma) * med)) edged = cv2.Canny(img, lower, upper)

## Make image single stream black and white gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)

## List that tracks the contours we're interested in (below the halfway point,

## and with a radius that isn't too extravagant - ie <75px ) filteredContour = []

## This one is going to contain the center of the contour contour_centers = []

## Find the contours in the image composed of Canny edges im2, contour,hier = cv2.findContours(edged, cv2.RETR_TREE,

cv2.CHAIN_APPROX_SIMPLE)for iteration in range(0,len(contour)):

random)## Make sure the contour isn't too small (200 is chosen at

area_of_contour = cv2.contourArea(contour[iteration]) if



area_of_contour >= 200:

## Obtain the approximate center and radius of each



contour(x,y), radius =

cv2.minEnclosingCircle(contour[iteration]) center = (int(x), int(y))

if radius < 75 and center[1]>height/2:

# print "Contour %d of size %d"%(iteration,areaOfContour)

filteredContour.append(contour[iteration]) contour_centers.append(center)radius = int(radius)## Draw radius on imageimg = cv2.circle(img, center, radius, (255, 0, 0), 2)

## Draw all contours larger than 200 (in filteredContour) cv2.drawContours(img, filteredContour, -1, (0,255,0), 2)## End for loop through contours of Canny edge detected image

## Draw the matrix on the output image img = draw_matrix(img)

## Generate the matrix for the image mat = generate_matrix(contour_centers)

## Save each matrix to an output file print_matrix_to_txt(mat, f, imgname)

## Save Images with Canny blobs in output photo folder stg = outfolder + imgnameprint stg cv2.imwrite(stg, img)

## End of findBuoys

## Draw gridlines on imagedef draw_matrix(processed_img):

for h in range(rows):img_w_matrix = cv2.line(processed_img, (0,

height/2+h*blockh), (width, height/2+h*blockh), (255, 204, 0), 2)

for w in range(cols):img_w_matrix = cv2.line(processed_img, (w*blockw,

height/2), (w*blockw, height), (255, 204, 0), 2)



return processed_img



## End of draw_matrix

## Generate the matrix that is to be passed to the navigation portion def generate_matrix(contour_centers):

# Creates a list containing 8 lists initialized to 0 Matrix = [[0 for x in range(cols)] for x in range(rows)]

## Initialize output list of 8 8-bit ints with the default, no- buoy, 0

output_matrix = [0]*8

## Iterates through the bottom half of the image grid and increments the Matrix cell is a contour center is found there

for r in range(rows):for c in range(cols):

for cnt in contour_centers:if cnt[1] > height/2+r*blockh and cnt[1] <

height/2+(r+1)*blockh and cnt[0] > c*blockw and cnt[0] < (c+1)*blockw:

Matrix[r][c] = Matrix[r][c]+1

if Matrix[r][c] > 0:output_matrix[r] = output_matrix[r] + 2**(8-c)

## Print buoys center matrix print Matrixreturn output_matrix

## End of

generateMatrix()

## Function to print matrices to output file def print_matrix_to_txt(mat, f, img):

f.write(img) f.write("\n") f.write(str(mat)) f.write("\n")'''for i in

range(len(mat)): f.write(str(mat[i]))

'''# End of print_matrix



## Do the main thingif name == ' main ':



main()

Documents

EXECUTIVE SUMMARY · Web viewShort for ‘State Machine’, Smach is a python-based tool for designing, maintaining, and debugging large and significantly complex finite state machines