Skip Header NavigationIntranet 
CENTER FOR EMBEDDED NETWORKED SENSINGContactDirectionsEmploymentEventsNews
HomeAbout UsResearchEducationResourcesPeople

Research Project


Robogaming

Technology > Actuation > Robogaming

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

OVERVIEW

An emerging area of research in embedded systems is the use of actuation and controlled mobility. Autonomous devices capable of performing varying degrees of self-initiated motion can be introduced into a sensor network to provide several performance advantages such as enhanced coverage, resource redistribution, zooming-in capability for phenomenon of particular interest, repairing communication connectivity, fault detection, calibration and localization. This opens up several research challenges in developing methods for determining the use of motion and providing navigational and other support for autonomous controlled mobility. Real Action Gaming robots (ragobots) is a laboratory scale test-bed for exploring these research issues in a fun setting for students. The ragobots testbed also provides an exciting application for embedded systems and is an important educational aid for introducing students at all levels to sensor networks and robotics.

APPROACH

The ragobots testebed consists of multiple robots moving on an instrumented 3D terrain. The terrain provides the experimental functionality required from the ragobot testbed and enables researchers to operate in fully controlled and reproducible robot environment. The terrain also provides various facilities for robot control, such as localization and reconfigurable structures with which the robots may interact. The following figures gives an overview of various components of the testbed.

Figure 15: Ragobot platform overview.

SYSTEMS / EXPERIMENTS

The test-bed prototype consists of several entities, consisting of the robots, the terrain on which the robots move, a central server which controls the robots and provides localization and other experimentation services. These are described in detail below.

Hardware

This consists of several entities, labeled workerbots, marinebots, structures, resources, localization infrastructure, PicoNIMS enabled terrain reconfiguration infrastructure and static terrain components. These components are discussed below.

1. Workerbots: These are robots, consisting of following components (Figure 16)

a. a processor and radio platform: MICA2
b. a twin-DC-motor enabled traction mechanism to move on a 2D surface with small undulations
c. two servos for pan and tilt control for a pointing device
d. tilt sensor
e. an IR range sensor (emitter and detector) mounted on the pan and tilt
f. an object gripping mechanism
g. Battery Monitoring Circuit
h. Battery Charging circuit
i. Contact sensor mounted on gripper to detect resource

Figure16: Workerbot system block diagram.

2. Marinebots: These are a workerbot, (optionally without the servo controlled gripper) but with a simulated weapon system added:

a. IR emitter with embedded digital signature to reveal identity of firing robot and the class of weapon used (the class of weapon depends on resources spent and influences the extent of damage in the victim entity)
b. IR detector to detect when “hit” by another robot’s IR emissions. This detector may be directional.

3. Structures: These components represent stationary structures available to the player in the game. These are locations for collecting resources. The structures can be damaged by firing from enemy robots and can be repaired by collecting sufficient resources. They consist of:

a. Mica2 processor and radio platform
b. IR emitter, strategically pointed at resource collection point for robot to acknowledge deposition of a collected resource.
c. IR weapon sensor to sense damage when hit
d. RC Servo enabled collapsible and repairable walls/roof.

4. Resources: These are detectable objects which are deigned to represent various resources to be collected by the player during the game.
5. Terrain: This consists of a custom-tiled floor with obstacles and undulations, some of which block the robots and some allow the robot to pass.
6. Localization infrastructure: This consists of an overhead web-cam connected to a PC. Each robot has a special pattern pasted to its top which helps the image processing algorithm to recognize the various robots on the terrain.
7. PicoNIMS enabled terrain reconfiguration infrastructure: This consists of two standard PicoNIMS nodes with added gripper functions. These can add, remove and relocate components in the player terrain.
8. Distributed Speaker System: A set of 4 to 6 speakers, placed across the terrain (embedded underneath the terrain floor) for generating sound effects at relevant places.
9. Overhead Graphics Projector: This is an LCD projector mounted to have an arieal perspective of the terrain and is used to generate visuals on the terrain.

The range sensors and weapon detection sensors together enable the robots to detect obstacles and other IR emissions. This could be used for

1. sensing uncertainty control
2. obstacle sensitive navigation
3. obstacle sensitive deployment
4. LoS sensing range based coverage topology management
5. target detection (with targets modeled by IR emitters, range can be controlled by selecting detection thresholds)

Figure 17:Prototype robot.

The first component being developed is the workerbot. The initial hardware design of this robot, shown in Figure 17, is discussed next. The Ragobot robot consists of four hardware layers. The upper-most, observation, layer hosts a dual-axis pan-tilt actuator platform for positioning a spotlight, infrared ranging sensor, and any sensor needed in the future. The next layer down, Ragobot, is the primary controller board. The Ragobot layer circuit board hosts the physical interface to the Berkeley Mote (which provides processing and communication facilities), 27 LED’s in various configurations and colors (for entertainment and status display purposes), an advanced power supply, a battery charger, programming and expansion headers, and a dual DC motor controller module (an off-the-shelf solution provided by Polulu, Inc.).

Below the Ragobot layer is the Redloc layer, which is presently undeveloped. Redloc will host an sparse 2D array of infrared receivers in addition to a supplemental sensor suite for the robot (odometers, compass, and attitude sensor). The redloc layer’s IR array will use a beam-forming approach to provide simulated weapons fire between robots as well as provide point-to-point communications links for location specific tasks such as signaling that the robot has arrived at the hangar.

The lowest layer of the Ragobot is a commercial traction platform which makes use of two DC motors to drive tank treads through a three gear, fixed-ratio drivetrain. The traction platform’s motors are connected through the Ragobot layer to a Polulu motor controller, which provides the Berkeley Mote the ability to command the platform to move at over 100 different speeds each in both the forward and reverse directions.

Since the Ragobot contains RF electronics, analog sensing circuits, and digital logic, significant design effort was required to ensure that noise injection between sources is minimized. If the traction platform is powered directly from the on-board battery, severe fluctuations in the power rail supplying the radio, sensing, and digital electronics appear (Figure 18).

Figure 18: Power supply characteristics without filtering out noise.

To solve this problem a sophisticated power supply and filtering network were employed. Analog simulation of the Ragobot running at full speed while simultaneously sensing and transmitting on the radio (i.e. worst case) reveals that our filter performance is sufficient to provide an RF quiet operating environment (Figure 19).

Figure 19: Frequency Response of power supply filters.

Software
Software for Ragobot is designed using component based framework provided by TinyOS and nesC. NesC is programming language designed for event-driven embedded systems. Following are the design goals for our software design.

Design Goals
Modularity: Software component should be designed in modular way to enable software reuse and enhancement easy.
Efficiency: Since we are implementing software in very constrained processing environment, efficiency is an important issue. The software design should be efficient in terms of RAM usage, code space usage, processing time.
Hardware Independence: It should be easy to change underlying hardware of Ragobot. To achieve this goal, interaction with hardware should be abstracted in a small number of driver components, which provides a hardware abstraction layer. All other components should use interface provided by driver component.
Real-time constraints: Real-time nature of the application puts real-time constraints on processing time. Software design should take these real-time constraints into consideration.

Figure 20 provides component interface diagram of Ragobot software. These component interfaces corresponds to nesC interface definitions. The components interfaces are divided in following two layers to achieve the modularity and hardware independence goals.

Figure 20: Robot software overview.

The lower level interfaces layer provides interfaces for different hardware components. Implementation of the driver for a particular hardware should provide appropriate interface specified at this layer. For example, change in a different hardware for IR ranging can be transparently achieved by modifying the IR ranger driver.

Game-Server

Apart from the robot software, the system also needs corresponding software on the server which allows players and researchers to control the testbed and robots. This software has been modularized using TCP-sockets. A game server application runs on the main server machine which is connected to a mote or wireless communication with the robots. However, client applications carrying out experiment or game specific functionality can reside on other machines and communicate using TCP with the server. The server is multi-threaded and supports multiple simultaneous clients each of which could control multiple robots. A block diagram of the server side software appears below.

Client/Server communication flowchart

Server Software

ACCOMPLISHMENTS

Key accomplishments in the first phase of the project include:

  1. Initial hardware was designed and a PCB has been fabricated for it.
  2. The first version of robot software has been developed which provides basic drivers for all hardware components.
  3. A prototype robot is functional and is being used for testing various components.
  4. An image processing platform for overhead camera based localization has been decided and is under development.
  5. Education objectives realized:
    a. A course project based on this project was offered in CS213: Distributed Embedded Systems to help graduate students learn about embedded actuated platforms.
    b. A course projects based on ragobots has been offered in EE 206: Mobile and Wireless Communications to expose students to mobile communication systems which exploit controllably actuated elements.

Key accomplishments in the second phase of the project include:

  1. Server side programs to accept connections from multiple experimeter clients and send commands to the robots in a centrally coordinated fashion was developed. This development was also used to support undergraduate educaton objectives trough the CENS summer internship program.
  2. Reconfigurable terrain structures have been designed using Nickel-Titanium shape-memory alloys. These structures can be electronically controlled to modify their shapes in support of gaming and experimentation functionality. This development was also used to support undergraduate educaton objectives trough the CENS summer internship program.
  3. A physical 3D terrain with support for challenging robot navigation algorithms has been developed. The terrain art is designed to simulate a rugged undulating outdoor land site.
  4. An overhead camera based localization system was developed and tested. This system is able to provide robot locations o the experimentation server.
  5. A revised robot PCB has been designed to add more functionality to the existing design, and notably to add support for a newly available XYZ sensor node.
  6. An additional sensor board with an onboard DSP is being designed to add advanced sensing functionality to the robot.
  7. New sensors, including vision, accelerometrs, magentometer and Infrared have been added.
  8. Ultrasound localization support is being designed for supporting reliable and accurate robot location. A novel localization strategy to minimize the effect of environmental interference is being investigated using this platform.
  9. Acoustic sensing and sound generating caability is being added to enable target tracking and related experiments.

FUTURE DIRECTIONS

The ongoing and future work on this research project includes:

  1. The revised version of the prototype hardware developed is currently being tested. The significantly advanced sensing capabilities which have been specified are now being integrated into the prototype.
  2. Higher level functionality for the robot software is being developed. Both robot side and server side software are undergoing development to enable multi-robot experimentation.
  3. A new localization system using ultrasound transducers is being designed.
  4. Central control for reconfigurable terrain components is being developed.
  5. Algorithm development for games and various experiments are underway.

PEOPLE

FACULTY

Prof. Mani Srivastava, Electrical Engineering, UCLA
Prof. Deborah Estrin Computer Science, UCLA
Prof. Gaurav S. Sukhatme, Computer Science, USC
Prof William J Kaiser, Electrical Engineering, UCLA

STUDENTS

Aman Kansal
Jonathan Friedman
Parixit Aghera
Balaji Vasu
Advait Dixit
David Lee