Skip Header NavigationIntranet 
CENTER FOR EMBEDDED NETWORKED SENSINGContactDirectionsEmploymentEventsNews
HomeAbout UsResearchEducationResourcesPeople

Research Project


Testbeds

Technology > Actuation > Testbeds

On this page: Overview | Approach | Systems/Experiments | Accomplishments | Future Directions | People

OVERVIEW

A Small Submarine Robot for Experiments in Underwater Sensor Networks

We have designed a small underwater robot for experiments with sensor-actuator networks. One set of experiments (where the robot is used as data mule) is described above. Others are planned for the future. The robot is based on the mote platform, which is used extensively in the sensor networking community as an experimental testbed. The robot is composed of two parts: the base on which all the electronics are mounted, and the housing which is a protective enclosure. The robot is a cylinder standing 23.5 cm high and 6 cm in diameter and uses a simple mechanism which functions by changing the volume of the robot using a piston. This change in piston position leads to a change in volume which varies the robot's buoyancy. When the piston moves up, water is pulled in, increasing the robot's total volume and thereby causing it to descend since its buoyancy has decreased. As the piston moves down, water is pushed out thereby decreasing the robot's total volume causing it to ascend due to increased buoyancy.

APPROACH

Autonomous Robot Boat

We have designed, and begun construction of, a 1m long air boat to use as an autonomous profiler and sampler in small bays. The boat will be equipped with a fluorometer that will measure chlorophyll a content, a biologically meaningful indicator of plankton abundance. Sensors measuring temperature, salinity, and geographic position have also been incorporated into the design to provide an environmental context to the biological data. The boat will autonomously profile a body of water along a pre-set pattern using either GPS-based positioning, or using a bacterial chemotaxis-inspired algorithm (discussed in the Marine Microorganism Monitoring section). An on-board, custom-designed water sampler will allow for samples to be collected for later off-line analysis (in the immediate future). The figures show a schematic of our design and a first prototype under construction and test.

Figure 26: Schematic of Robot Boat for Sampling Experiments

Figure 27: Views of the prototype Robot Boat for Sampling Experiments

Robomote

The Robomote is a tabletop sensor actuator platform for experiments on a testbed. It is designed to be compatible with the Berkeley Mote. Robomote consists of an Atmel 8535 microcontroller. This is a 8-bit AVR RISC MCU with 8k bytes of In-system programmable flash alongwith 512 bytes of EEPROM and 512 bytes of Internal SRAM. The microcontroller also incorporates various desirable features like programmable sleep modes and reprogramming capability. It has two motors, a compass for bearing and IR bump sensors. The robomote is complete with the addition of a Berkeley mote. The mote is used as the master and all basic functionality of the robomote are exported to the mote via modular interfaces. We have alsowritten TinyOS components for the mote to incorporate control of the robomote into TinyOS apps. Just as the mote has a radio component and can send out packets, it now has an actuation component and can physically actuate at will.

The main feature of a actuator system is its ability to move. This is facilitated by wheels that are run by motors. However, precise control of the motors is very difficult. Odometry error is a well-known problem. It arises from many factors like slipping, one solution to alleviate this problem is incorporation of a feedback controller that corrects for the error in odometry. Considering that these actuator nodes have to be cheap, some feedback mechanism must be present to acheive any reliable actuation.The robomote has optical encoders that produce 150 ticks per revolution of the wheel. The baseboard implements a PI-controller that is activated at 2Hz which corrects errors in the wheel ticks.

Figure 28: (Left) System Architecture of Robomote and (right) Robomote Software Architecture

As mentioned earlier, we intend to use the mote as the master. Hence, the system software on the robomote has been designed to provide the basic functionality as modules on the mote. We have designed modules in TinyOS to allow easy access to robomote's functionality in TinyOS.

The TinyOS modules consist of two layers. There is a Hardware Abstraction Layer that takes care of the communication with the robomote. The second layer exposes the functionality of each individual feature (e.g.: compass) of the robomote to applications in TinyOS. It is possible to include just the required components into existing TinyOS apps and easy use. This is illustrated better in diagram above.
Our setup includes a testbed with beacons at known locations. Using these, we have a coarse localization implemented (based on triangulation). There is also an Orientation component that combines the Compass with the localization to get relative bearing on which direction to go next,given a destination.
We have written a higher level Navigation component that performs the task of navigating from point A to point B using this localization and orientation.

Figure 29: (Left) Top view of Robomote v2 with mote attached and (Right) Power Consumption

SYSTEMS / EXPERIMENTS

Figure 25: Software Architecture Schematic

The main control (MC) of the robot is the control center. All other significant subsystems are separate modules. The depth controller (DC) is responsible for regulating the robot's depth in response to depth commands from the MC. The MC program clocks the DC as to how often a reading of depth and a correction is made. In our experiments the DC was clocked at roughly 200ms. This was done for two reasons, the first being that the timers in TinyOS are still not fully mature as of this writing and experience some problems, while the single clock mechanism of TinyOS is fully functional (which we are currently using). The second reason is that it gives the implementer of sensor network algorithms more control over how many readings are taken (to conserve some cpu cycles) and what mechanism is chosen to use for clocking the DC. As the DC is clocked, it sends an event back to the MC program informing it with the current depth of the robot. When the desired depth is reached, it is still necessary to clock the DC so it can continue to perform its job of regulating the robot's depth. This is because even in our experimental testbed (a tank) the robot is constantly buffeted by small eddies. The DC uses the pressure sensor for depth and the motor control module (MCM) to move the piston accordingly. This isolates the DC from the sensors used to measure depth.

ACCOMPLISHMENTS

FUTURE DIRECTIONS

PEOPLE

FACULTY

Prof. David Caron
Prof. Gaurav S. Sukhatme
Prof. Aristides Requicha

STAFF

Carl Oberg

STUDENTS

Sandeep Babel
Vitaly Bokser
Karthik Dantu
Hardik Shah
Bin Zhang