Project Albatross: Subsurface Data Acquisition using Semi-Autonomous Aquatic Robotics (Part 1)

Credit: The project as being from students from Northeastern University competing in the university’s 2019 ECE Capstone Design Competition. 

Project Address: https://hackaday.io/project/165920-project-albatross

DESCRIPTION

Team Members 

- Steven Seeberger 

- Dave Evans 

- Patrick Gannon 

- Nick Sullo 

- Connal West 

Advisors 

- Bahram Shafai 

- Ethan Edson 

This project details the design and implementation of a novel aquatic robot that uses an autonomous surface vehicle (ASV) and a towed underwater glider (AUV) to capture water quality measurements at multiple depths across a body of water and display those measurements to an onshore user in real-time. The robot is designed to utilize open source software and hardware and to be low-cost so that smaller, lower budget research teams can implement it and start taking pertinent water quality data easily. 

*This project was submitted to the Spring 2019 Northeastern University ECE Capstone Design Competition and won first overall prize.*

DETAILS

The following links can be used to accessed videos related to our project...

Final Presentation Video
https://drive.google.com/open?id=1P5icCjOM0kk32vqfPv54V5IbKkrnPn1Z

Project Demonstration Video
https://drive.google.com/open?id=1uB6J3WNWfwTFQ6hGoxX8WPGmXahOR9xL

FILES

Project Albatross. - Final Presentation.pdf    Download

Project Albatross - Final Report.pdf                 Download

COMPONENTS

QUANTITY COMPONENT NAME
1      ×  T-Slotted Aluminum Extrusion (x2 48 in, x6 24 in, x4 16 in, x1 30 in ,x2 3in, x6 1in)

20 ×  T-Slotted Aluminum Extrusion Small Corner Brackets

1 × 3V 1 Channel Relays

1 × 3.3V-5V Bi-Directional Level Shifters

12 × 12 in. Steel Duct Clamping

1 × Nema 23 Stepper Motor 2.8A 178.5oz.in/1.26Nm

1 × AMIS-30543 Stepper Motor Driver

1 × K=10 Analog Electrical Conductivity Sensor

1 × Analog pH Sensor

1 × Bar30 High-Resolution 300m Depth/Pressure Sensor

1 × Analog Turbidity Sensor

1 × Analog Dissolved Oxygen Sensor

1 × Various Hardware (Nuts, Screws, Wing Nuts, etc.)

1 × 1/4 in.-20 Threaded Rod (~16 in)

3 × #8-32 Threaded Rod (Electronic Components / Misc. Electronic Components)

2 × ROV Tether - 14 meters

1 × 32 GB SD Card

1 × Enclosure Vent and Plug

1 × Loctite Marine Epoxy

1 × M10 Cable Penetrator for 8mm Cable

1 × Tether Cable Thimble

1 × Elastomeric Sealant - Clear, 10 fl. oz.

1 × Aluminum Bar

1 × Heavy Duty Velcro

1 × Aluminum Sheet

1 × Plumber's Tape

1 × Various PVC Fittings

1 × PVC Cement

1 × Readytosky 3DR 500MW Radio Telemetry Kit 915MHz

1 × Latex Tubing

2 × 3/4 in PVC Pipe (~6in)

2 × 4 in x 2ft PVC Pipe

1 × Loctite Marine Sealant (Flexible)

1 × Spring Link (Carabiner)

6 × Home Depot 5 Gallon Bucket

2 × HiLetgo BTS7960 43A High Power Motor Driver

1 × USB to Serial Converter

6 × 500 GPH bilge pumps

1 × Raspberry Pi 3 Model B

1 × Pixhawk PX4 Autopilot Controller with GPS Module

2 × 12 Volt 35 Ah Sealed Lead Acid Rechargeable Battery

3 × Arduino Uno

1 × UPG D1761 Sealed Lead Acid Charger

1 × Boost Converter

1 × 12V Rechargeable Power Supply

6 × Home Depot 5 Gallon Bucket Leakproof Lid

1 × 50ft Thick Rope

1 × Heavy Duty Zip Ties

1 × 32 Qt. Sterilite Gasket Box

3 × 150ml Plastic Syringes

6 × 55mm Plastic Propellers

BUILD INSTRUCTIONS

1. Introduction to and Basic Overview of the Project

Project Albatross was developed in response to the greatly heightened need for water quality monitoring in the world today. With the looming threat of climate change, the rising of the oceans, ocean acidification, the rampant spread of plastic pollution in water bodies, and other harmful environmental issues, it is more important now than it ever was for us to understand the health of our water bodies so that we can help fix the issues they face. 

Using robots to take water quality measurements is not exactly a new concept. Autonomous underwater vehicles (AUVs) such as REMUS and various underwater gliders have been in use since the early 2000s, with the designs for these vehicles, in some cases, being proposed much earlier. However, while these robots work spectacularly for their intended purposes, they contain multiple limitations. The first is that they are typically very expensive and only used by a select cohort of research institutions that either developed them or have the exorbitant budget necessary to purchase them. Smaller research institutions or companies (such as universities with smaller budgets, marinas, nonprofit wildlife societies, etc.) often do not purchase these robots for this reason, and instead rely on old fashioned manual data capturing instead. 

Manual data capturing involves a crew of people going out on a boat to manually drop a CTD module (conductivity, temperature, and depth sensing module) to different depths at various locations, which of course is more costly and time consuming than using a robot for data capturing. In addition, as manual data capturing takes more time, scientists taking manual data often space out the locations at which they take their samples greatly so that they can cover larger areas in a reasonable time frame. This wide spread between data points leads to very sparse datasets being produced, which often suffer from the effect of aliasing when they are used to discern trends in the measurements. Finally, manual data capturing leads to mainly vertical profiles being taken of a water body, as the CTD devices are more easily dropped vertically to different depths at a given location than they are dragged horizontally from location to location. This solely vertical profile of a water body leads to potential gaps in knowledge and information when trying to determine trends in the water measurements. 

Going back to the current robot applications themselves, it is evident that underwater vehicles (AUVs and underwater remotely operated vehicles [ROVs]) provide superior measurements as they can capture data over a large range of depths (sometimes up to thousands of meters). By contrast, another class of vehicles known as surface vehicles (autonomous surface vehicles [ASVs] and surface ROVs) are basically boats that only move and collect data at the water's surface. However, while AUVs provide better measurements, the fastest and most well-developed form of wireless communication, radio frequency (RF) communication, does not work underwater. As such, most AUVs have to surface at multiple points throughout a given mission to relay information wirelessly back to a ground control station. This surfacing wastes precious time and energy, and prevents any real-time analysis of data from occurring. ASVs can, of course, use radio communication always since they operate at the surface. Such a trade-off between measurement capabilities and the ability to perform real-time radio communication with a ground control station motivates the idea for a combined ASV-AUV system that highlights the advantages of both approaches. 

We are by no means the first group to propose a combined ASV-AUV system. Our research produced information about a few other groups who have tried to develop similar designs (https://ieeexplore.ieee.org/document/5509187, https://www.liquid-robotics.com/wave-glider/how-it-works/). However, we wanted to develop a low-cost, open source, fully modular, and intuitive to use system that included custom construction, hardware design, and software design. Our goal was to produce a system that could be built and used by anyone for under $1500 to motivate smaller groups around the world to begin taking pertinent water quality measurements with greater accuracy and ease. Thus, Project Albatross was born.

The basics of the system's design are as follows. 

2. Building the ASV

To build the frame for our autonomous surface vehicle (ASV), we utilized T-slotted aluminum extrusion. Aluminum was the perfect choice for our vehicle frame as it is lightweight, strong, relatively low cost, and resistant to corrosion and rust. T-slotted aluminum bars allowed us to build our frame without any welding or specialty power tools. This was key as our frame design changed a few times throughout the project as we iterated through different motor positions and frame features, so we were able to unscrew joints and move the frame bars with relative ease. 

Our frame design was intentionally simplistic as this made the surface vehicle easy to construct without sacrificing performance. The frame was about 4 feet in length and 2 feet in width, with 4 crossbars for support and 6 vertical bars for mounting the 6 motors used by the vehicle. The crossbars were connected to the frame's sidebars using heavy duty corner brackets, while the remaining joints that needed less support were connected with small 1'' x 1'' corner brackets. A wooden board was screwed into the middle three crossbars to support the main electronics housing. 

From here, 6 Home Depot five gallon buckets with Leakproof Lids attached were used to provide flotation for the frame. The lids were sealed to the buckets using a marine sealant produced by Sudbury Boat Care known as an Elastomeric Sealant. This sealant is designed for applications above and below the waterline and advertises that it provides superior adhesion to polyethylene plastic (which the buckets are made from). Once the sealant cured for 24 hours to secure the lids to the buckets, the buckets were attached to the frame using 12'' steel duct clamping and custom T-slotted aluminum fittings. 

The motors were then attached to the vertical frame bars using custom-cut acrylic mounts. 500 gallon per hour bilge pumps were used for the propulsion motors. 6 motors were used in the design (four are shown in the pictures here, but two more were added later), and all were mounted facing the stern of the vehicle. 

A 32 Qt. Sterilite Gasket Box served as the main electronics housing for the vehicle. We secured it to the wooden board by simply drilling four holes in its bottom and screwing it into the board. Placement of the box was key here, as we wanted to make sure that the vehicle would still sit balanced in the water once the heavy electronics (mainly the batteries) were placed into the housing. A smaller waterproof electronics enclosure was also used for the more delicate electronics (the Pixhawk and Raspberry Pi). A long T-slotted aluminum bar was added to the front of the vehicle facing vertically upwards to mount the radio antenna onto. Two T-slotted aluminum bars of about 18'' in length each were added off the stern of the vehicle for the future tether connecting the ASV to the AUV to attach to. Zip ties were used to secure the motor wires to the frame. 

The images below show our surface vehicle in its first flotation test. It was a great success! The vehicle sat balanced in the water as hoped and was able to support the major added weight of the two 12 V 35 Ah sealed lead acid rechargeable batteries that would be used to power the motors. Our construction efforts and buoyancy calculations paid off! 

3. Configuring the Pixhawk to Correctly Run the Motors

Once the ASV was built, the next main step was to configure the Pixhawk for our application. As the Pixhawk would be autonomously controlling the ASV, it would act as a Rover styled robot. Therefore, we downloaded ArduRover firmware to the Pixhawk and configured it to be a "boat" rover using the Mission Planner software. We chose Mission Planner as our ground control station as it contains the most functionality for configuring and monitoring the Pixhawk-controlled robot and also has the most development support online. Mission Planner can be installed from here http://ardupilot.org/planner/docs/mission-planner-installation.html. An example of the Mission Planner mission monitoring screen (the "Flight Data" screen) where the robot mission can be monitored in real time is shown below. 

The main configuration tasks were performed in the "Initial Setup" and "Config/Tuning" tabs. Some of the steps included setting the robot's yaw angle to be controlled using skid steering (http://ardupilot.org/rover/docs/rover-motor-and-servo-connections.html), setting the type of motor to be "Brushed with Relay", and assigning which pins would be used to control the left and right motors, respectively. For our application, the bilge pumps act as simple brushed motors that we would control using a no-frills motor driver capable of dedicated forward and reverse motion and of sustaining the necessary current (up to 3A per bilge pump, as determined through empirical testing with the pumps). We settled on a HiLetgo BTS7960 motor driver (link given in the components list) and chose to use one to control the left 3 motors and a second to control the right 3 motors. This was made possible through the use of a skid-steering steering control configuration and through the high current limit (43A) of each motor driver. 

While it might seem trivial, it took us some time to figure out how to configure the Pixhawk properly to expect regular, brushed motors with separate forward and reverse control. This is because the Pixhawk is mainly targeted towards DIY drone users, who most often use brushless motors controlled by fancier ESCs (electronic speed controllers). As such, much of the online documentation that discusses setting up the Pixhawk talks about properly connecting ESCs and using Mission Planner commands to have the ESCs self-calibrate themselves. If you're just trying to control brushed motors, the configuration documentation really just barely skims over how to do so. To save from future digging, make sure you just set the MOT_PWM_TYPE parameter to "Brushed With Relay" and then assign two motor pins to "Throttle Left" and "Throttle Right" respectively (SERVO3_FUNCTION = 73 [Throttle Left] SERVO1_FUNCTION = 74 [Throttle Right]). 

In this mode, the Pixhawk expects that an external relay will be used to flip between forward and reverse motion. Thus, it expects that (as is the case with our motor driver), one pin on the driver is used to drive the motor forwards and a second pin is used to drive the motor backwards, with the same positive pulse PWM signal being sent. The pins used by the Pixhawk for relay control are auxiliary pins 5 and 6. If desirable, you can configure in Mission Planner which relay controls which motors' directions (the throttle left or throttle right motors) by modifying the RELAY_PIN and RELAY_PIN2 parameters in the Config/Tuning tab under the Standard Params. We will go over how to connect the circuitry for the motor control next. 

4. Connecting the ASV Motor Circuit

To connect the bilge pumps to properly to the Pixhawk, we had to implement a circuit including two relays, the two HiLetgo BTS7960 motor drivers, two buffer circuits, and three different power source voltage levels. The resulting circuit is diagrammed below. As the diagram shows, the two relays were needed to switch between the signal coming from the Pixhawk controlling forward motion and reverse motion. On the motor drivers, the RPWM pin is for controlling the motors with a clockwise rotation (which was forward using our propellers) while the LPWM pin is for controlling them with a counterclockwise rotation (which was reverse using our propellers). Pin 1 on the Main Out on the Pixhawk was used for driving the right side motors (those connected to Motor Driver 1) and Pin 3 on the Main Out was used for driving the left side motors (those connected to Motor Driver 2). Thus, by using relays to control whether these signals are sent to the RPWM pins or the LPWM pins on the drivers, the Pixhawk can flip between forward and reverse motion as needed. As mentioned previously, Pin 6 on the Pixhawk's Aux Out controls the flipping of the right side motors' relay, while Pin 5 on the Aux Out controls the flipping of the left side motors' relay. 

In connecting Auxiliary Pins 5 and 6 to the relay IN pins directly, we encountered an issue with current sourcing. While the relays only required ~2mA of current to flip properly, the Pixhawk Aux Out pins could not maintain this current. This caused a voltage sag that prevented the Pixhawk from being able to flip the relays. We expect that this is most likely due to the fact that the Pixhawk expects to be connected to a more sophisticated IC or microcontroller that only requires hundreds of microamps to function properly. Therefore, we had to implement a buffer circuit to beef up the input resistance of the relays and cause them to draw less current. In this manner, the voltage did not sag and the Pixhawk was able to flip the relays as intended. 

Unfortunately, the power distribution for this setup was not perfectly straightforward, as each component ran on a different power level. The Pixhawk output pins ran on 3.3V logic, so 3.3V relays were needed (requiring a 3.3V power source). The HiLetgo BTS7960 motor drivers required a 5V power source to run their operations properly. Finally, the bilge pumps nominally ran from a 12V source, so this level was needed as well. As we found two old car battery-type batteries in our capstone lab (12 Volt 35 Ah Sealed Lead Acid Rechargeable Batteries, to be more specific) we chose to use these batteries to power the bilge pumps connected to each motor driver separately. This provided more than enough power to run the pumps for the ~1-2 hour missions we were planning on running. 

In a more sophisticated power distribution setup, we would have used a set of battery eliminator circuits and/or buck converters to step some of this 12V sourcing down to 3.3V and 5V to run the remaining circuit components. However, as we had extra Arduino Unos lying around the lab anyway and needed a quick and dirty way of implementing the buffer circuitry (we oddly didn't have many basic circuit components available to us in the lab),  we simply used an extra Arduino Uno as a 3.3V source, 5V source, and go between for the Pixhawk to relay connections (the Pixhawk Aux Out would connect to a digital input port on the Uno, and then the Uno would be programmed to flip the correct digital output port connected to the relay based on the input coming from the Pixhawk). We realize this is a hacky solution, and we were actually pretty embarrassed to use it. But it certainly worked as intended and saved us some much needed time that we needed to work on the rest of the project. Ideally, we would have built the buffer circuit using a simple op-amp circuit as shown in the diagram below and then performed the power distribution fully from the 12V SLA batteries as explained previously. 

With this circuit completed, we had a surface vehicle capable of motion! The inbuilt "Auto" flight mode in ArduRover on the Pixhawk made it simple to turn this motion into autonomous GPS waypoint following. Thus, from here we were up and running with an autonomous ASV, and planned a few waypoint paths in Mission Planner for testing on a local pond (Jamaica Pond). Our testing showed that the vehicle was able to successfully move from waypoint to waypoint, but did so with an erratic and indirect motion. The next big step, therefore, was tuning the motion parameters used by the Pixhawk's PID controller.

 
5. Setting up the Telemetry Radio

To maintain a radio link between the ASV and our ground control station (GCS), we used a telemetry radio connection between a Pixhawk connected antenna and a GCS connected antenna. After performing some research into various telemetry radios, we chose to use the Readytosky 3DR 500MW Radio Telemetry Kit for our application. It operated at 915MHz, which was perfect for us as this is in the United States ISM band and therefore does not require a license for operation. It was also a more budget friendly option compared to some of the other telemetry radios out there, while still boasting fairly high transmission range of "several kilometers". 

We expected that there would be some tuning and configuration necessary for proper operation of the radio system, but it was actually very plug and play. The only setup step was downloading the necessary drivers to run the antenna connected to the GCS. Once this driver was installed, we were able to launch Mission Planner and connect to the Pixhawk via the radio link immediately! We also opted to use a larger antenna than the one included in the kit on the ASV end, as we had a larger antenna available in our lab and knew it would help increase our range a bit. 

From here we performed some baseline range testing of the radio system to see how far we could actually reliably send the ASV away from shore. We found that we could go 1/10 of a kilometer in an open field with no degradation in signal strength. As we were testing in the city of Boston, we had trouble finding nearby open fields much larger than this. However, when the time came in the end for testing the whole system, we found that we could send the ASV about a half a kilometer away with still no degradation in signal strength. We therefore expected that we could probably get about 2 kilometers of effective range using this radio system. Not bad for a small telemetry radio! 

6. Tuning the Pixhawk's PID Controller and Autonomous Motion Algorithm

With the ASV built and capable of motion from the Pixhawk commands for navigating to a GPS waypoint, we next had to tune the Pixhawk's PID controller for our specific vehicle. We did so by tuning the P, I, and D weights for steering and throttle in the Config/Tuning tab under the Basic Tuning tab based on empirical tests. While at our local pond, we would direct the vehicle to move to a waypoint that was directly in front of it, about 50 feet away. After changing the P, I, and D weights, we would observe the resulting change in the vehicle's motion to see how direct and fluid it was. Making these weight changes helped improve the motion, but the big breakthrough that made the motion more consistent was disabling pivot turns by setting the PIVOT_TURN_ANGLE parameter to 0. Despite any tuning of the P, I, and D parameters or any other parameters, our vehicle would continuously rely on pivot turns (stopping fully, making a turn, and then moving straight again) for moving back to the desired path. However, with any form of water current or additional drift, the ASV would never be able to stay perfectly on path and would spend the entire trip performing harsh course corrections. Disabling pivot turns completely allowed these course corrections to be less frequent and more gradual, allowing the vehicle to reach the waypoint quicker and more directly. 

7. Building a Custom Message for Data Transmission

Once things were progressing well with the hardware and functionality of the ASV, we shifted our attention to the big software challenges of the project. The first was building a custom message recognizable by the Pixhawk and Mission Planner so that we could send our water quality data measurements to the shoreline successfully. As the Raspberry Pi served as the master computer for the ASV and would communicate with the Arduino Unos capturing data in the AUV, the plan was to have the Raspberry Pi run a DroneKit enabled Python script so that it could successfully communicate with the Pixhawk over a serial connection. In this script, a custom message type would be defined for packaging together the 6 water quality measurements our AUV was taking into a data structure with the appropriate data types. This custom message would then be filled with the current iteration of data and passed along to the Pixhawk. Modifications were made to the ArduRover firmware on the Pixhawk to define the custom message type here so that the Pixhawk would recognize the message being sent by the DroneKit script. 

With the message capable of being properly handled by the Pixhawk, the final step was to pass the data over the telemetry radio link with the ground control station (GCS) to send the data to the Mission Planner application running on the GCS. For this stage to occur properly, modifications had to be made to the Mission Planner application code to define the custom message type here as well and perform handling of the message upon reception. Mission Planner is a C# open source application, so we modified it by using a Visual Studio C# development environment. 

With these software changes made, it was possible to successfully send data from the Raspberry Pi, to the Pixhawk, and over the radio link to Mission Planner so that it could be saved and displayed to the user in real time!
 
8. Coding the Remaining Communication Chain

With the custom message built to facilitate communication of data from the Raspberry Pi to the GCS, the remaining communication step was to build the code for communicating between the Raspberry Pi and the two Arduino Unos in the AUV. Thus, the DroneKit enabled Python script had to be modified to account for this communication and two Arduino ino files had to be created. 

As explained previously, one Arduino in the AUV would be dedicated to controlling the stepper motor functions for buoyancy control, while the other Arduino would be dedicated to taking water quality sensor data. The sensor Arduino would talk with the Raspberry Pi on the topside over a serial communication line (the ROV tether we bought), and it would also talk with the buoyancy Arduino over a software serial connection. A software serial connection is a connection that utilizes the library (or in our case, the AltSoftSerial library as it was recommended to us as being a better choice) to create a second serial port on the Arduino Uno. 

In this manner, as the depth/temperature sensor was connected to the buoyancy Arduino so that it could access depth measurements faster, the communication of sending depth and temperature measurements to the topside would go Buoyancy Arduino --> Sensor Arduino --> Raspberry Pi, and updates on what depth should be held by the buoyancy system would be sent from  

Part 2 Link:

Project Albatross: Subsurface Data Acquisition using Semi-Autonomous Aquatic Robotics (Part 2)