Self-Powered Autonomous Aquatic Vehicle (SPAAV)

Matt Haywood

Electrical Engineering

Andy Litzinger

Electrical Engineering

Max Kelley

Electrical Engineering

Tyler Malay

Mechanical Engineering

Matthew Webster

Mechanical Engineering

Erika Bliss

Industrial Engineering

ABSTRACTAutonomous aquatic vehicles have a multitude of applications, such as underwater mapping and search and recovery missions, where they provide a greater advantage in comparison to the current alternatives. The purpose of this project is to develop a base platform that can easily be expanded upon to satisfy the specific needs of the customer. At this point, RIT SPAAV (Self-Powered Autonomous Aquatic Vehicle) has a modular mounting design and a flexible sensor network that is capable of capturing perception and vessel health data, relaying it to shore and storing it on the boat for later retrieval.

INTRODUCTIONToday, there exists a strong need for autonomous vehicles in a number of different applications where a human crew may be too dangerous, cost-prohibitive, or inefficient to deploy. Oftentimes, these autonomous vehicles are limited to daytime operation and use non-renewable resources for their power source. One of the most prominent fields for autonomous vehicles is in aquatic applications, where operations such as search and recovery, underwater mapping, and environmental monitoring can be extremely expensive in terms of time and resources.

RIT SPAAV (Self-Powered Autonomous Aquatic Vehicle) shall fit these needs by providing a self-sufficient watercraft that is capable of extended operations with little to no human intervention and no need to return to shore to refuel. This project aims to develop a base platform capable of energy harvesting, autonomous navigation, and wireless telemetry which may be easily expanded upon to meet the specific needs of a given customer application.

DESIGN PROCESS Before designing SPAAV, it was necessary to establish a list of customer requirements which would be common to most applications of the vehicle. First of all, the vehicle must be capable of autonomous navigation in a large body of fresh water – for example, Lake Ontario or any of the Finger Lakes. To more specifically validate this requirement, SPAAV should be able to complete a course consisting of three GPS waypoints with approximately 100 meters between points within six hours. To ensure the safety of the operator and of the other vessels on the course, SPAAV must implement a “remote kill” functionality which would be a fail-safe means of stopping navigation. In order to withstand the specified maximum environmental conditions of 1.5 meter waves and maximum wind speed of 10 m/s, SPAAV must be of a durable, water-tight build. While out completing its mission, SPAAV must be able to collect data from an array of basic sensors and be able to store the data for retrieval upon its return to shore, with the optional ability to wirelessly transmit this information live to shore. Finally, SPAAV must derive all of its power from a renewable power source without having to return to shore for recharging.

Multidisciplinary Senior Design ConferenceKate Gleason College of Engineering

Rochester Institute of TechnologyRochester, New York 14623

Project Number: P16250

Project P16250

Balancing the need for a watertight, durable build with the complexity of designing a watercraft from the ground up, the design of SPAAV was based around existing boats or water vessels which would be realistic to acquire. Luckily, one member of P16250 was able to secure the use of a 16-foot catamaran which featured twin hulls for stability, and the design for SPAAV proceeded to develop around the use of this vessel. The single stipulation with the use of this vessel was that the boat should not be irreversibly modified such that at the culmination of the project, any additions may be easily removed.

Due to the scope of this project and the large number of materials that would need to be acquired, the design was carefully crafted to meet customer requirements while maximizing the use of loaned or donated materials and funds. The chosen design was based on several selection criteria, such as durability, complexity, time to implement, total power consumption, total weight and total cost. Due to this project being student-proposed, the team had an initial budget of $500 from the Senior Design Department. Further sponsorship included $5000 from Boeing, $2500 from Synaptics, $1100 in contributed supplies from Retrotech, as well as supplies and labor from Solartech, Smidgens, and loaned materials from Alfred State. These donated or loaned items include a 30A PWM charge controller, five 20W photovoltaic modules, two 18W marine-grade photovoltaic modules, a weather-resistant enclosure with divider plate, and laser cut sheet steel components.

PRELIMINARY DESIGN

Figure 1: SPAAV model

The design consists of a 16-foot catamaran with two DC electric trolling motors (Figure 1). A single steering linkage driven by an electric linear actuator couples the two trolling motors. The boat utilizes a photovoltaic array to convert solar energy into electricity which is stored in a high-capacity, lithium-iron-phosphate (LiFePO4) battery pack for extended operation. 32-bit ARM microcontrollers form the basis of each node on the boat-wide Controller Area Network (CAN), which is linked to a single-board computer running Linux. The boat communicates with the shore via a long-range Wi-Fi link attached to the Ethernet interface of the single-board computer.

ENGINEERING MODELBody - Catamaran The mounting design for the project revolved heavily around what type of aquatic craft could be acquired. A catamaran was loaned to the project with the intention of it being returned upon project completion. Using a loaned craft required the mounting structure to be

2

able to be mounted to the catamaran without making any permanent changes to the craft’s structure. This also meant that the chosen mounting structure had to have the ability to be adaptable to other types of water craft designs (i.e. flat bottom, v-hull, tri-hull, etc). Aluminum extrusion (T-slot) was chosen as the material for the mounting structure because it could be adapted to the existing structure of the catamaran very easily, making the design both versatile and modular. Another advantage to using T-slot is that it allowed for the mounting location of the different subsystems to be moved. Having a movable modular mounting design helps balance the catamaran when it is in water. Since trolling motors were limited with how deep they could be in the water, shifting weight towards the stern of the craft would allow the motors to sit lower in the water.

Trolling Motors To propel the catamaran, two trolling motors were chosen.  Electric trolling motors were chosen for their ability to be easily controlled versus the conventional method of propelling this type of craft via sail, which is complex in terms of control and stability of the craft.   Additionally, the craft had to be self-sustaining and thus a gasoline engine would not fit for this project. The weight and length of the catamaran were the two determinants in choosing the correct motor size. During initial research, was found online from a trolling motor vendor and was used to determine the approximate size of motors to use.  Since the craft had been loaned to the team for the project we had the length set at 16 feet which the table suggests that the required motor have a minimum of 40 lbs. of thrust.  The next concern was weight, it was determined that the overall weight of the boat fully with all components would weigh less than 1,500lbs which the table recommends a minimum of 30lbs. of thrust.  With this information we were able to start looking at trolling motors.  We decided that the entire system should be kept at 12V which further narrowed our list of trolling motors.   The last step in determining the trolling motors was total current draw of the motors.  With this we determined that the best motors to use would be the 45 lb-thrust motor by Minn-Kota.  With the craft being so light yet long this would give us the required thrust needed to accomplish the tasks assigned.  Additionally, a motor of this size and having two would allow the motors to work at lower velocities thus further reducing the overall load on the system while allowing for extra thrust if the boat were to need extra thrust during adverse conditions.

Figure 2: Table used to determine the correct trolling motor needed for the project [1].

Steering The boat uses a parallel steering linkage actuated by a linear actuator. The motors are coupled together for simplicity in control since having independently steered motors does not increase mobility significantly. Coupled motors also allows for cheaper construction, since only one linear actuator is needed to control both motors. Finite element analysis was used to determine if the steel steering arms and aluminum tie rod would withstand the actuator’s rated 34 lb of force without any significant stress or deformation (Figure 3Error: Reference source not found).

3 Copyright © 2016 by Rochester Institute of Technology

Project P16250

Figure 3 FEA of steering arm. Applied force is 70lb from the actuator, with a resulting force of 24 ksi in the material and 90 ksi in the joint.

The steering arms are attached to the motor shafts with a pair of U-bolt clamps and were tested for slipping by holding the motor stationary and commanding a force from the actuator. No slipping between the arm and the motor was noticed, as well as confirmation of the FEA that there is no significant bending or torsion in either of the steering arms. The tie rod allows for approximately two inches of adjustability for fine tuning the alignment of the motors, utilizing a right hand thread and left hand thread tie rod end and jam nuts.

Motor Controller In order to power and control the two DC trolling motors and DC linear actuator, a motor controller would need to be used. This motor controller would need to interpret logic-level commands, preferably over the boat’s CAN bus, and translate them into changes in motor speed or linear position of the actuator. Originally, in order to achieve the amount of control desired, it was thought that a custom three-channel motor controller would need to be designed. Due to the DC trolling motors selected, the motor controller would need to control a minimum of 45A at 12V for each trolling motor, and 10A for the linear actuator. These current densities require wide printed-circuit board (PCB) traces and thicker copper layers which lead to increased PCB cost and turnaround time. Additionally, appropriate thermal analysis would need to be conducted to determine heatsink requirements for the high-power transistors which would reside on the circuit board. On top of these complications, expensive high-power connectors would be required to mate the motor leads with the circuit board, and of course, the entire system would need to have microcontroller firmware written in order to be controlled via the CAN bus, or by any other means.

A commercial solution was found in the Roboteq FDC3260, which offered three channels of DC motor control at 40A continuous/60A peak current each, all controllable via CAN, RS232, RC, or analog interfaces. Additionally, the controller offered feedback inputs and built-in current sensing to allow for closed-loop position, speed, or torque control. The controller cost $600 and would eliminate the copious hours of design, assembly, and debugging time that would inevitably come with designing our own controller.

4

Emergency Stop MechanismDuring testing and operation, SPAAV will inevitably come in contact with other vessels. As the boat does not yet incorporate obstacle avoidance, it is currently necessary to interrupt the navigation of the boat when it approaches another vessel. This functionality was required to be fail-safe for safety reasons to avoid vessel runaway, so an XBEE wireless communications link was utilized along with the RSSI output such that the motor power is cut when the XBEE link is lost or the kill command is issued. The motor power is interrupted by means of a solid-state relay, which may be exchanged for a mechanical relay or contactor for greater reliability.

The XBEE wireless link also serves as a "back-door" debugging link to allow for troubleshooting if the Wi-Fi communications link or single-board computer is malfunctioning.

Energy Monitoring One of the most important aspects of this project is the requirement to power the vessel entirely from a renewable power source to prevent the need for refueling in the midst of a deployment. This also means that the power consumption of the vessel should be optimized to reduce the draw on the energy harvesting system. In order to optimize power consumption, it is necessary to understand what parts of the system are consuming the most power and have the ability to turn on or off various components as necessary.

In order to accomplish this, a power monitoring board was developed which would control and monitor power to the on-board computer, wireless communications system, motor controller, and an additional auxiliary power connection. This power monitoring board would employ current sensors and an analog-to-digital converter (ADC) to determine power consumption by measuring current and voltage. Hall-effect current sensors were selected due to their low series resistance and galvanic isolation between load and sense circuitry. These sensors, manufactured by Allegro Microsystems, come in a wide assortment of current measurement ranges and provide a simple analog output voltage that is proportional to the current passing through the sensor, allowing for ease of measurement through a single ADC channel.

For control and switching, PCB-mount solid-state relays were selected due to their small size and low holding current when compared to mechanical relays. For the motor controller relay, a high-power (100A) solid-state relay from Crydom was selected in a panel-mount package to allow for heat dissipation.

Housing of Electronics With this project being a boat with electronic and power distribution systems, the IP rating of the enclosures had to be determined to be of IP65 or higher. The IP or International Protection Marking rating system is a classification given to electrical enclosures that classifies and rates the degree of protection provided against the intrusion of foreign debris such as dust and water. The two letters of the IPXX tell the user of the level of protection. The 6 indicates that the enclosure is completely dust tight. The 5 indicates the enclosure is protected against low pressure water jets from all directions. While and IP64 could have been used since it protects against water spray from all directions, it was decided that the pressure of water caused by a wave could be higher then what is considered “spray” and thus the IP65 rating was used as the minimum rating of all enclosures and connectors for the electrical system.

Navigation and Localization In any mobile robot application, the ability to navigate requires two things, to know where you want to go and where you currently are. The former is relatively easy in this application because a user will provide this input. To be able to know where the robot is, is a bit more complicated. It requires not only to know some x and y location (latitude and longitude) but also to know orientation. To do this the vessel is equipped with a global positioning system (GPS) and inertial measurement unit (IMU). The IMU is equipped with an accelerometer, gyroscope, and magnetometer (digital compass). In this system the GPS will add an absolute location while the IMU will provide relative heading and position.

For the robot to be able to get to the user’s select endpoint, it will generate a path based on the shortest distance. Then break the path into n number of waypoints, the number of waypoints will be based off of the GPS refresh rate and estimated time to get to the endpoint. The boat will use the IMU as it navigates between waypoints, and use the GPS to determine its course to the next waypoint. When it reaches the endpoint the boat will wait for a predetermined amount of time and then either proceed to the next waypoint or return to some home location. The user would be able to select up to three waypoints at first but the system should be built in such a way that this can be increased.

5 Copyright © 2016 by Rochester Institute of Technology

Project P16250

DATA ANALYSISThe main concern with using T-slot is whether it would be rigid enough to support the weight of the trolling motors,

electrical boxes, and solar modules. A worse case bending analysis, as shown in Figure 4 , was done to determine the amount of deflection that could occur. The analysis was conducted by assuming that the ends of the T-slot were supported and there was a point load acting in the middle. The length of the T-slot was assumed to be 48.5 in. The T-slot chosen for the analysis was 1515-UL from 8020 Inc. (1.5 in x1.5 in).

Figure 4: Worse case deflection for a beam supported at both ends and a point load acting in the center [2]

It was assumed that the maximum weight wouldn’t be more than 200 pounds on any one piece of T-slot. Since a point load would give a maximum deflection with a center load and both ends simply supported, the T-slot would only deflect about 0.2 inches. It was determined that the T-slot would be sufficient enough to hold up the amount of weight required and wouldn’t deflect enough to cause any concern.

Table 1 Statistical data from GPS and distances from Mean GPS point

Latitude (deg) Longitude (deg)Distance from previous point (meters)

Haversine formula Pythagorean theoremmean ### ### 3.75E-03 3.75E-03Variance 3.03E-11 4.30E-11 2.08E-03 2.08E-03STD 5.51E-06 6.55E-06 4.57E-02 4.57E-02Max ### ### 6.20E-01 6.20E-01Min ### ### 0.00E+00 0.00E+00

Table 1 shows statistical data from GPS points collected at a stationary position. 10266 samples were collected of these there were 14 distinct points and those point where plotted in a mapping program and shown in Figure 5. From the raw samples the mean was determined and the distance of each point from that mean was calculated using two methods. One method used was based on the Pythagorean theorem which is based off of a flat earth approximation. The other method uses the Haversine formula which take into account that earth is round. As can be seen from the table the statistical analysis comes out to be the same. This is due to how close the points are, and there for both methods can be considered valid.

Figure 5 Distinct location for stationary GPS test

6

RESULTS AND DISCUSSIONAt present, autonomy was not achieved due to time limitation, however remote control was implemented using a standard RC controller. Figure 6 shows the data collected when the boat was taken out to Lake Ontario. The map on the right shows the GPS locations with a color plot of Heading. The heading was provided by the GPS unit and is with respect to magnetic north. The map on the left shows the GPS locations with a color plot of the speed of the boat, which was also provided by the GPS unit.

Figure 6 Right: GPS location with color plot of heading Left: GPS location with color gradation indicative of speed

0.00 500.00 1000.00 1500.00 2000.00 2500.00 3000.00 3500.00 4000.00 4500.00 5000.000.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

Time (sec)

Spee

d (m

/s)

Figure 7 Plot of Speed over time

Figure 7 shows the speed of the boat from the Lake Ontario test. As it can be seen the average speed of the boat was 2 m/s at full throttle.

7 Copyright © 2016 by Rochester Institute of Technology

Project P16250

CONCLUSIONS In summary, we were successfully able to develop a self-powered aquatic surface craft which is currently able to be remote controlled. The sensor network has been developed to the point that autonomy could be implemented given enough time and computer engineering resources. The mechanical systems, such as mounting hardware and steering linkage design have been implemented and validated to meet performance requirements. Additionally, the majority of the electrical systems have been implemented and validated to a point where obtaining autonomy would just be a matter of writing firmware and patching the motor controller into the CAN bus.

RECOMMENDATIONS FOR FUTURE WORKThere is significant unused space on the boat where additional photovoltaic (PV) modules could be added to allow for more energy harvesting capacity and extended runtime. Additionally, it would be recommended to utilize an array of identical PV modules as this would allow for the maximum power-point tracking algorithm in the MPPT to work more efficiently. Mixing different PV modules which have different open-circuit voltages require the modules to be connected in series-parallel combinations to prevent limiting by the lowest voltage panel, and even then maximum power transfer is not achieved.

Additionally, the steering actuator mount should be modified to provide an adjustable post, such that it would be able to be removed and rotated along with the motors for easier storage and transportation.

The CAN network implementation did not occur until later in the project, and as a back-up measure an off-the-shelf RC controller was acquired to interface with the Roboteq motor controller in order to pilot the boat remotely. In order to achieve autonomy, the Roboteq controller’s CAN interface will need to be connected to the boat’s CAN bus and software/firmware will need to be written to send the appropriate commands to control the motors over this interface. The Roboteq controller supports several CAN protocol stacks such as as CANopen, miniCAN, and a simplified raw CAN interface. CANopen would likely be the most logical choice to adopt boat-wide, as it implements a comprehensive layer that allows for setting and getting parameters from various nodes on the network.

Although autonomy was not achieved, the original intent was to use the Robot Operating System (ROS) due to its comprehensive suite of plugins and considerable community support. Additionally, ROS offers a plugin that supports CANopen, which would allow messages from the boat CAN bus to pass easily into the ROS environment as native ROS messages. It may also make sense to upgrade to a higher-power onboard computer such as an x86-based system rather than an ARM single-board computer due to the processing requirements that will come along with implementing obstacle avoidance, such as interpretation of computer vision data or other high-bandwidth sensor data.

REFERENCES[1] Trolling Motors, 2015, “Trolling Motor Thrust Guide.”, from https://www.trollingmotors.net/blogs/selection/86933703-trolling-motor-thrust-guide.

[2] 8020, 2016, “The Core Building Block.”, from https://8020.net/university-tslot.

ACKNOWLEDGMENTS Team P16250 would like to thank our customer, Chris Mieney, for his continual encouragement and constructive criticism along

the way. Additionally, we would like to thank Boeing, Alfred State, Synaptics, Smidgens, SolarTech and Retrotech for their generous donations of resources that have facilitated in the creation of SPAAV. Finally, we would like to thank Dr. DeBartolo and our guide, Michael Blachowicz, for making this student-proposed project possible.

8