The Cambridge Autonomous Underwater Vehicle
Creating autonomous systems is a fascinating topic and has been ever since Isaac Asimov wrote about robotics in the early 1940s. Such a system can navigate unknown terrains, perform tasks and make decisions without assistance from humans. Lawn mowers and vacuum cleaners, able to operate without intervention, are simple examples of these concepts. Autonomous Underwater Vehicles (AUVs) are now becoming a major area of research and development with large companies investing in advancing this technology for both defense and academic purposes.
Several competitions have arisen from the recent interest, such as the Autonomous Underwater Vehicle Student Initiative (AUVSI) challenge, the Defense Advanced Research Projects Agency (DARPA) grand challenge and the Student Autonomous Underwater Vehicle Challenge-Europe (SAUC-E). All are aimed at encouraging student teams to develop solutions to some interesting problems.
The Cambridge Autonomous Underwater Vehicle (CAUV) team is a group of students from the University of Cambridge that has developed a Linux-powered AUV for the annual SAUC-E. The AUV must be able to complete an underwater assault course with no communication with the surface, external processors or outside intervention.
The CAUV team includes about 20 undergraduate students from around the university, studying computer science, engineering or natural sciences. Most students join to gain experience in the difficulties involved with team-oriented multidisciplinary design projects, with problems ranging from how to manage a team effectively to designing components that will operate correctly together in a system.
In previous years, we've done well in the competition. We took second place in 2007, and we won a prize for innovation in systems engineering from Direction des Constructions Navales Services (DCNS) in 2008. Preparations for the 2009 SAUC-E competition are underway, with high hopes of another strong result.
Although the end-of-year competition is our short-term goal, we also have a long-term goal that heavily influences the design decisions we make. Part of our wider design aim for this project involves deployment into the Arctic through a bore hole in pack ice. To facilitate this, we chose a thin cylindrical design and avoided objects that would stick out of the hull, such as fins and external thrusters.
The chassis is small, lightweight and modular. The AUV is controlled by internal vector thrusters, two sets of two orthogonal thrusters that shoot jets of water to turn the vehicle and a propeller mounted at the stern. Most of the AUV is custom built in order to achieve the small size we require. Early on in the design process, we chose to split the AUV into five sections: the nose cone, the bow thrusters, the electronics racks, the stern thrusters and the tail cone.
The nose, tail and electronics sections are constructed from carbon fiber molded to a Myring Hull shape, allowing for minimum weight and maximum internal diameter. The nose cone contains a camera looking through a Perspex window, surrounded by a ring of bright LEDs to illuminate objects for the cameras in low light conditions. The bow thrusters' section houses a second camera and the vector bow thrusters along with associated electronics.
The electronics section houses the VIA EPIA PX10000G motherboard, which is supplemented with an array of dsPIC electronics to control the AUV and navigation equipment. The main sensory inputs are two orthogonal cameras and an inertial navigation system built by the CAUV team. The AUV's 12 2400mAhr Lithium polymer batteries make up the power core and offer a substantial working range.
We can estimate the best range and duration for the AUV using a basic fluid dynamics model of the AUV combined with data for power consumption and battery capacity. These calculations give a maximum range of 41km–51km at a cruise speed of 2.4m/s with a duration of 6–8 hours. The model also estimated the maximum speed at 4.2m/s.
Although our lightweight, high-density battery module allows for a good range, it does require careful management to avoid damage that can lead to explosions. This is where our custom-built battery management boards come in. Each battery has its own circuit that constantly monitors the temperature, charge and discharge rates. If any abnormal activity is detected, the battery is shut down and a log recorded in a central monitoring chip. At the 2008 competition, the battery management system was tested unintentionally when the AUV developed a leak, covering much of the electronics in water. Thankfully, the system worked perfectly, shutting down the batteries and protecting our electronics.
Waterproofing is a big concern for us, especially with the connectors that link the modules together. We fitted rubber O-rings to make the actual seal, but in order for them to be effective they need to be squashed against a smooth flat surface. To achieve this, we machined our connectors from aluminum with a 30-degree angle to act as the squash face for the O-ring. As some parts of the AUV need to be accessed more than others, we designed two types of connectors: quick and semi-permanent. The quick connector consists of a threaded aluminum sheath that screws over an aluminum ring attached to the receiving part of the hull, squashing the two parts of the connector together. The semi-permanent connectors use bolts that go up inside the AUV to compress the O-rings.
The AUV also is equipped with a mission-specific module (MSM) system so that extra hardware or sensors can be attached without major modification to the base of the AUV. We machined the MSM connector from an aluminum block, fitted bolts for the module to screw on to and provided a variety of wires connected up to the AUV electronics. Initially, these wires linked the mission-specific modules to the I2C bus of a dsPIC; however, we will change this to a more generic serial connection to the PICO ITX in the future. In previous years, this connection has been used to attach a marker dropping system required for the competition. This year, we plan to attach a much-needed sonar unit that has been kindly donated by Tritech International.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- RSS Feeds
- New Products
- Validate an E-Mail Address with PHP, the Right Way
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?







1 hour 33 min ago
3 hours 24 min ago
8 hours 37 min ago
11 hours 49 min ago
14 hours 4 min ago
14 hours 33 min ago
15 hours 31 min ago
16 hours 59 min ago
18 hours 8 min ago
18 hours 55 min ago