University of Cambridge LogoCambrand LogoSchlumberger Logo

  • Barracuda

    Barracuda AUV above water on stands

    The design of Barracuda represents a return to CAUVs older design criteria: a sleek, highly integrated AUV that is equipped with a variety of sensors and computing platforms.


    Past experience had shown that designing a vehicle within a single year meant there was insufficient time for all elements of the vehicle to reach a standard the team would like. Therefore, it was decided to perform the design & manufacture of Barracuda over a two year cycle. Starting at the end of 2010, the vehicle was to be ready for the 2012 SAUC-E competition. The previous vehicle (Red Herring) had proven to be a reliable platform for software testing, as well as allowing easy modification to prototype & test new components. However, the simple framework proved cumbersome and difficult to move, and incurred significant setup costs.


    Barracuda's design aimed to return to a compact structure like that of Blackghost, without compromising the capabilities of the vehicle. However, additional requirements were placed upon the design, including hot-swappable batteries, easy transportation (1-man portable), and most importantly, to be reliable. Keeping all areas of the team involved in the design process was also important, so that all the required specifications could be met.


    The design and manufacture of Barracuda was a significant undertaking for CAUV. With the limited student resources at hand, there were plenty of opportunities for delays. With the competition deadline upon us, Barracuda was shipped in parts. The entire team worked relentlessly to perform the final assembly, which was achieved during the 4th day. On day 5, with almost no integration issues, the AUV was ready to perform. This was primarily a testament to the care and attention the team members had undertook, along with the significant use of computer aided design.


    Barracuda AUV partially complete during manufacture

    Barracuda's main body is around 1.5m long, with a diameter of 6 inches. With a cross-sectional area only one half of that of Red Herring, the AUV is much smaller and lighter vehicle. The design  consists of several cylindrical sections (which can be disassembled using only a screwdriver), which allows for easy transportation over long distances. In addition, should a design change be required, only redesign of a particular module (rather than the entire vehicle) are needed.


    The batteries are located in 'clip-on' modules on the side of the main body, using wet-mateable connectors, allowing batteries to be swapped in around 2 minutes. For comparison, the battery-swap process took around thirty minutes on Red Herring (and was extremely laborious).


    The front of the vehicle mostly consists of the multi-beam SONAR, however it also houses the forwards camera, inertial measurement unit and compass and a pressure sensor.  In the centre of the Barracuda is the Electronics vessel, where the computers and most of the other essential electronics live, followed by a wet electronics section which has, as well as a downward facing camera, a slot for a mission specific module (for instance an acoustic modem). The antenna module is situated at the rear, and houses the GPS, WiFi and XBee communication systems.

    Like all CAUV vehicles, Barracuda uses vector thrusters to manoeuvre, currently the Seabotix thrusters from Red Herring. However we plan to replace most of these with lighter rim driven thrusters, designed during a 4th year Masters project. This should be more reliable and compact than the standard design. Also Barracuda has two rear thrusters compared to Red Herring’s one. This reduces the risk of rolling, but also combined with the more hydrodynamic shape of Barracuda, gives us the ability to move considerably faster, hence wasting less time between tasks.

    Barracuda electronics rackElectronics

    With higher demands and less space to work with, the electronics had to be designed with the shape of the vehicle in mind. This means that the computers and other standard parts have to be small, while the large numbers of custom boards have been designed around where they would fit (for instance the long thin boards in the battery modules).


    In order to make the system more manageable and upgrading easier, the electronics architecture has been completely overhauled since Red Herring. The new architecture uses standardised schematics and a standardised microcontroller, as well as a powerful 32 bit MCU. Communications between boards run over multinode CAN, a robust industry standard technology which allows us to easily extend our electronics system.


    With electronics distributed throughout the vehicle, external connectors are essential to allowing us to easily disconnect the various components. In Red Herring these connections had to be routed through a ribbon cable connected to the end plates to get to the central electronics board, which led to interference in the data channels; however the design of Barracuda means these can be connected individually.


    Laptop screen showing image processing pipeline

    Since Barracuda, like Red Herring, has an x86 PC, the software development for Barracuda has been an almost seamless extension of that of the previous vehicle, while the addition of a PandaBoard gives us the option to offload the logic processing to a separate processor. This continuity has allowed us to further develop the base capabilities of our code, which now include a simulator, SLAM and AI integration into the GUI, as well as a new messaging layer for more reliable and faster communications when testing or receiving data.


    At the SAUC-E 2012 competition, the self-learning control loops proved capable of dealing with the modified dynamics surprisingly quickly, while an unexpected rule change at the competition demonstrated the advantages of being able to quickly iterate Python scripts to control behaviour. While we managed to implement and test successfully buoy circling and pipe- and wall-following algorithms in the simulator, ultimately the limited tethered testing time available prevented us from tuning parameters for real world dynamics.


    This year we hope to integrate SLAM into the AI, allowing easy access to location information, as well as try to reconstruct some of the obstacles we expect to face at the competition to allow us more accurate testing. Also we want to try some of the challenges we have not been able to attempt before, including locating a pinger using hydrophones.