The Cambridge Autonomous Underwater Vehicle
The Inertial Measurement Unit (IMU) module is used to form a dead reckoning of the AUV position. It uses accelerometers, gyros and pressure sensors to calculate the position and orientation of the AUV. Due to the integration that is required to calculate the position, an error is built up over time, known as drift. To correct the drift, the camera will be used to calculate a more accurate position at a much lower refresh rate using a technique called simultaneous localization and mapping (SLAM). Ideally, we would use a GPS system to correct the error; unfortunately, these will not work when the AUV is submerged and also are restricted under the competition rules.
The IMU module has two main parts: an Inertial Navigation System (INS) and an autopilot. The INS circuit records data from the sensors and runs a continual integration loop in order to calculate the AUV's position. The autopilot circuit controls the propeller and four thrusters to move the AUV around the pool. If the vehicle is being operated in remotely operated vehicle (ROV) mode, the INS performs simple movement tasks, forwarding instructions from the main CPU. However, if in AUV mode with the autopilot active, it can use the current position (calculated by the INS circuit) to move to any destination set by the main CPU.
The navigation system, running on a dsPIC, communicates with the autonomy software, running on the PICO, using a simple serial protocol. To simplify the software, the board uses an FTDI chip to handle the USB-to-UART conversion. The protocol used sends simple command strings with checksum values attached to detect errors.
In both 2007 and 2008, CAUV was the smallest robot at the competition, weighing in at less than 7kg. We use one of the world's smallest full-featured x86 motherboards to power the Ubuntu 8.10 operating system. Although the PICO board is small in size, it still is able to pack a punch with a 1GHz VIA C7 processor and 1GB of RAM, all of which is utilized by the onboard autonomy and image-processing software. Soon we would like to upgrade the processor to a Mobile ITX and possibly fit two boards in for some dual-processing fun.
The operating system used by the AUV is Ubuntu 8.10, chosen for its high reliability, low cost and ease of configuration. To save on some processing power and storage space, we have disabled or removed many of the default applications, such as GNOME. In previous years, we have used the Ubuntu Server edition and experimented with several different scheduling algorithms.
The primary storage device is a 4GB CompactFlash card, chosen for its low price, small size and energy efficiency compared to the equivalent mechanical device. All of these items are commodity goods that were bought off the shelf. Primarily used for cost and time reasons, there also is the added benefit that the community knowledge and support are outstanding.
Three modules make up the software: the decision-making software, the image-processing software and the navigation software. In 2008, we wrote all the software in Java, excluding the navigation software, as this is based on the dsPICs. For the 2009 software, we are porting our Java prototype to C++ and incorporating the OpenCV image-processing library to replace our custom image-processing system. The software modules are implemented separately and communicate via a network, allowing for one module to be run onshore during testing should we need to.
For the past two years, we have not had a sonar system to work with, so we have relied completely on vision. The AUV is fitted with two Webcams: one facing downward and one forward. The vision system must be able to recognize gates, buoys, tires and cones from any angle as well as differentiate the color of these objects in low light conditions in order to complete the assault course.
Our image-processing system is built on a series of filters joined together into a pipe, with filters including edge detection, Hough transforms and segmentation. This flexible system allows fast reconfiguration of processing methods should this be required.
Communication with the AUV is a vital part of the whole system. Without a reliable and usable way to relay information to and from the AUV, any data collected may lose its value. At the physical layer, we have two ways to communicate with the AUV. In the nose cone, we have an off-the-shelf Wi-Fi USB stick that can be used for remote surface communication. Naturally, this doesn't work so well underwater, so we have a second method for submerged communication. On the top of the AUV, we have a waterproof connector that is connected to the Ethernet port on the PICO. This means we can receive telemetry and image feeds from the AUV in real time, so long as we have a cable long enough.
We have integrated a PlayStation II controller into the GUI that can be used when the AUV is tethered and in ROV mode. As well as being fun to play with, it creates a fast and effective remote control system.
The communication between the GUI and the AUV is a standard TCP/IP connection, with another of our own protocols running on top of this. The AUV is set up to send as much information as possible back to the GUI, where it is displayed graphically, if possible. The GUI contains a 3-D map of the path taken by the AUV and a series of graphs to plot telemetry. We hope to extend this map in the future to incorporate images taken by the AUV and show objects found by the AUV. To produce this map, we require a reliable, accurate stream of position data from our onboard navigation system, the inertial navigation system.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Android's Limits
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?