Build Instructions

Collapse

• 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. 

View all 15 instructions