The AFμS Project

As my senior capstone, I will be working on The AFμS Project, which stands for Autonomous Flocking micro Submersibles. The aim of this is to design and build affordable, small submersibles that have the capability to work in a swarm. Currently there are several companies making small submersibles with these capabilities, but most of them are too expensive for indevidual or undergraduate level research. The final product should present a platform on which researchers can mount their own sensors and easily utilize for whatever data collection they need.

Currently this project consists of a team of two computer engineering students, myself and Jacob Karaul, as well as two mechanical engineering students, Alex Pradhan and Sam Veith.

Along with the technological challenges that will accompany this project, which will be documented here as they unfold, there is the challenge of organizing development across a multidiscipline team. To confront this, I researched methodologies often used by startups within similar fields, several of which have been implemented into our planning and ideation sessions, photos of which are in the provided gallery.

The project poster is provided below.

poster

An initial version of the project definition is provided below.

Final Paper 1.0

 

A live updated gallery can be found at this link.

The latest design report is available here: ECE-498 AFuS Design Report

The specifications section of the latest design report are displayed below for convenience.
This system is being designed with the aim of its use within a flock. While aspects of its functionality are chosen specifically to allow for this behavior, the specifications in the scope of this design report represent our expectations of not having a final product with full flocking capabilities within the timeline of this project. However, functionality is included that is not required for a solo system, and ideally the end result within this project scope is a functional proof of concept for an AUV with flocking capabilities.
In an attempt to ensure that our project is applicable to the sector it is being designed for, we held an ideation session at the start of the design process. This involved collecting and collating use cases for an AUV, then sorting them as a function of importance to the consumer and how widespread the specific use case is. These results were then analyzed, condensed, and repeatedly sorted through until a set of design parameters were generated with the goal of maximizing usefulness to the prospective customer. Further information on this process is available in Appendix A. The design requirements detailed in this report only cover the aspects that the computer and electrical team are directly involved in the design of.
The most important requirement of this system is that any environmental impact is mitigated. This means that the AUV must exhibit robustness and durability to avoid breakage and therefore contamination of the local environment. Most of the requirements to fulfill this need falls on the side of the mechanical engineering team, though ensuring that the AUV has the capability to keep itself out of dangerous situations is an interdepartmental effort. To be able to do this, the foremost requirement is that the AUV is able to translate itself in 3D space, which is a boolean requirement; it either can or cannot. A highly related requirement is the ability to translocate to a designated set of coordinates. The selected range for this to be considered successful is within 5 meters of the point. While this may seem like a wide region of error, it must be considered that this device will be acting on the scale of lakes, oceans and rivers. If the device can translocate to a point, it must also be able to hold its position within said range of that point for at least 5 minutes.
Another important factor for avoiding environmental impact is avoiding collisions between the AVU and other objects, not only to protect the AUV, but to protect whatever it has the potential to collide with as well. To avoid objects, the AUV must be able to detect them at a minimum range of 1.5m. As the AUV may not be the object that is moving in this situation, it must be able to avoid an oncoming collision at a relative velocity of 1m/s from the time the AUV was detected. To be able to react quickly in situations like these, the AUV must be able to accelerate itself to its maximal velocity at at least 1m/s2. For it to be able to handle and remove itself from currents, the AUV will need to be able to travel at least at 3m/s. If an obstacle is detected and avoided during point to point travel, the AUV must continue to the designated point.
For the AUV to be able to provide useful sensor data, it must be able to traverse a designated area, staying within the region, and passing over all parts of the area evenly e.g. not simply containing its exploration to a corner of the zone.
The chosen method of communication is wireless optical transmission/reception. Pertinent specifications for any communication system include Bit Error Rate (BER), minimum transmission distance, and data rate. Additionally, turbidity is included as optical communication capabilities can largely vary with clarity. These factors are all closely related, thus the requirement will include them all in a single scenario: At a turbidity of 10 NTU, the AUV must be able to communicate optically at a distance of 0.5 meters at a data rate of 62.5 bps with a BER of 10% or less.
A value of 10 NTU was found to the average during low-flow periods in rivers and lakes, where this sub will be tested experimentally. Both BER and distance were estimated from a set of tests run on an underwater optical communication system in various turbidity conditions. Finally, the data rate was calculated from early tests run with optical components, described in the Preliminary Testing Results section, and a communication protocol. While the communication modulation technique is not yet set in stone, a clocking pulse-position modulation (PPM) scheme is being seriously considered and is used for this calculation.

PPM is an encoding technique that modulates the time since the last clock pulse before transmitting a high pulse as a means of communicating data. For example, in a 15 ms period, a delay since the last clock pulse of 5 ms may indicate a ‘0’ and a delay of 10 ms may indicate a ‘1’. This method allows for the detection of errors in a noisy channel by utilizing a fixed set of known locations a pulse must be at any given clock cycle. If pulses are not in the correct position within a clock cycle or are not the correct pulse width, then an error is detected. Except for the unique case in which an error both erases the original pulse and creates a pulse in another allowable pulse location, errors should be easily detectable.

This protocol, however, does not provide a method for synchronization. That is, the clock at the receiving end may be out of phase, faster or slower than the clock at the transmitting end and thus the actual time since the last clock pulse is compromised. To account for this, clocking can be implemented by sending a pulse at the beginning of every clock cycle, as illustrated above. Blue pulses represent data, green dashed lines represent the start of clock cycles, and red pulses represent the pulse at the beginning of every clock cycle. The receiving end can use this periodic clocking pulse to establish the beginning and end of every cycle and stay synchronized with the transmitter.
Returning back to data rate, a single clock cycle of PPM consists of four block times for encoding a single bit per cycle: the time for a clock pulse, an intermediate period between pulses, the time for a data pulse indicating a bit of 1, and another intermediate period between pulses. In the above figure, there is space for two data pulses and thus two bits can be transmitted every clock cycle. The block time used here is 4 ms, the minimum pulse period found for an early prototyping for a white light optical system as described in Preliminary Testing Results. Using a minimum pulse period and intermediary period between pulses of 4 ms, the data rate R can be computed as R=(1 bit)/(4 blocks*4*10-3 seconds)=62.5 bps.
While many of the aspects of this requirement are not necessarily numerically quantifiable, one of the largest design requirements is that the AFµS system is as consumer facing as possible. This means making sure its features suit those that could be needed by the people of whom the specific functionality of the system is useful. These requirements are the addition of the modular sensor bay, ensuring that the final design is ergonomic enough to be easily deployed and retrieved, the ability to passively recharge itself, and that its price point is affordable for individual researchers, with the explicit goal of a sub-$500 product.