Wireless Video Sensor Networks for Sparse ... - Semantic Scholar

1

Wireless Video Sensor Networks for Sparse, Resource-Constrained, Multi-Robot Teams Richard M. Voyles∗ , Jaewook Bae† , Amy C. Larson‡ , and Mustafa A. Ayad∗ ∗ Department

of Electrical and Computer Engineering, University of Denver, CO Email: [email protected] † Samsung

Corp., Santa Clara, CA

Email: [email protected] ‡ Department

of Computer Science, University of Minnesota, Minneapolis, MN Email: [email protected]

Abstract Small-size robots provide access and maneuverability in the tight confines of highly rubbled and uncertain environments such as those encountered in Urban Search and Rescue (USAR). Small size also provides easy portability and deployability and the potential for redundancy through multi-robot teaming. Unfortunately, small size does not diminish the data demands of these applications, such as high-resolution imagery and other forms of high bandwidth data. Furthermore, achieving redundancy in tight environments requires wireless operation to avoid the entanglement of tethers, but wireless communication links have proven unreliable in such environments. The net effect of this is a set of robust networking requirements that include high bandwidth, low latency, and low power with multi-hop routing in a sparse and highly volatile network configuration, which has been collectively difficult to achieve. Our metric for benchmarking these requirements is a stream of uncompressed 320x240, 24-bit color images updated at 1 frame per second (roughly 1.8 Mbps - image compression is not the focus of this research as it only serves to increase the possible resolution or frame rate). No existing ad hoc wireless sensor network approaches have been able to achieve these requirements. Wi-Fi requires high power and size and does not have the latency, while Zig-bee does not have the bandwidth. Instead, this work focuses on augmenting the Bluetooth protocol, which is master/slave based, with a hybrid, multi-hop routing protocol. Bluetooth has the desired low power and high bandwidth characteristics, but lacks multi-hop routing and rapid recovery. In this paper, a hybrid routing protocol for ad hoc multi-robot networking is described that features: 1) high-bandwidth, 2) low power, and 3) low latency of data traffic for sparse, highly volatile networks – exactly what is required for large teams of highly distributed, small-scale robots. Furthermore, this paper compares simulations and robot implementations of different routing protocols over Bluetooth sensor networks and demonstrates the viability of our protocol as a wireless network solution for multi-robot teams characterized by high mobility in difficult RF environments. To the best of our knowledge, the work presented in this paper is the first attempt at comparison of different routing protocols for real robots with physical experiments over Bluetooth sensor networks. Index Terms

August 19, 2009

DRAFT

2

Sensor Networks, Bluetooth, Scatternet, Multi-robot networks

I. I NTRODUCTION Urban Search and Rescue (USAR) provides a very challenging application environment for many forms of robotic research for all venues of ground, sea, and air [1], [2], [3], [4]. For ground deployments, small tethered robots have proven most successful [2]. Small size provides access to voids and tight spaces not directly or safely accessible by the rescuer. Tethers provide high quality, drop-out free video, unlimited power, and a method for retrieval in the event of catastrophic failure. Unfortunately, tethers pose a significant burden to small-size robots because their weight and likelihood of a snag grow as a function of tether length. Furthermore, in tight environments, tethers prevent robot teaming due to entanglement issues. This is particularly problematic for USAR missions in increasingly larger search areas at disaster sites, which cannot be fully covered using a few tethered robots [5]. Communicating low noise, high resolution video is the primary goal of an untethered robot team in the USAR environment. This is because human analysis of the video feed remains the primary mode of survivor detection and of structure inspection. But providing high quality wireless video links in USAR environments has proven surprisingly difficult due mainly to limited bandwidth, lossy compression, and short communication range [2]. Fielded alternatives to this problem have included onboard storage of high quality video for later inspection in parallel with real-time low quality video, fiber optic reel systems, and copper tethers. By far, copper tethers are the most common alternative to otherwise unreliable wireless communications [2]. Thus, for small-scale USAR robots, the development of a reliable, low-power, multi-hop, ad-hoc network capable of delivering high-bandwidth data remains an open problem. Traditional mobile ad-hoc networks either have too low bandwidth for video or consume too much power, printed circuit board area, or computational resources. For example, Zig-bee and Wi-Fi have been broadly studied and commercialized in distributed robotics. While Wi-Fi features large bandwidth, it cannot be generally used by small scale robots due to power consumption and to its complicated structure. Zig-bee works well for small sensor networks, but its bandwidth is too small to transfer highquality video images. Bluetooth has also been studied as a low-power data network for robotics, but its master/slave, point-to-point architecture has not lent itself to dynamic, ad-hoc networks. Despite its architecture, Bluetooth is a promising technology for wireless communication among USAR miniature robots due to its low power, small footprint, high bandwidth, and low latency. The Bluetooth protocol has been developed for high speed connectivity, aiming to serve sound, video and other high-bandwidth applications. Bluetooth technology enables portable devices to form short-range point-to-point networks but is not generally applicable to large-scale networking. Therefore, we have been researching and developing new Bluetooth protocols that allow the configuration of large-scale, ad-hoc sensor networks. Our approach efficiently utilizes the functionality of the Bluetooth standard and is augmented by a routing protocol that can react quickly to network node failures without swamping the bandwidth. In this paper, we present our hybrid routing protocol that features high-bandwidth, low power, and low latency of data traffic for sparse, highly volatile networks. Our protocol combines a standard proactive approach with the August 19, 2009

DRAFT

3

(a)

(b) Fig. 1.

(a) Two tethered TerminatorBots collaboratively navigating on rock and wood chips (b) Deploying miniature USAR robot teams and

PDAs equipped with multi-hop Bluetooth cability in search is the goal

on-demand approach, to take advantage of the strengths of each. We have implemented and compared these three protocols both in simulation and on our custom robotic platform, TerminatorBot (detailed in [6] and shown in Fig. 1). Results presented in Sections VI and VII indicate the viability of our Bluetooth routing protocol as a solution to reliable, wireless networking for USAR small-scale robot teams. It is important that we point out the problem of routing messages given a connected network of mobile nodes is quite different than the problem of maintaining connectivity among a network of mobile nodes. The problem of maintaining connectivity while simultaneously achieving some team objective is central to research in multi-robot teams, but is not addressed here. Instead, we aim to provide a fast, reliable backbone for communication that can support higher-level algorithms for maintaining connectivity in an intelligent way. II. T HE ROBOTIC P LATFORM The TerminatorBot [7] is a small, cylindrical robot with two arms that it uses for both locomotion and manipulation (see Fig. 1). While locomoting, it drags its body over rubbled terrain like a cold-blooded animal (supported by its

August 19, 2009

DRAFT

4

environment). Together, the arms have six degrees of freedom (each arm has three degrees of freedom) allowing arbitrary manipulation of rigid bodies or highly flexible gaits durign locomotion. With a body roughly 75 mm in diameter and 200 mm long, it is well-suited to core-bored search applications in urban search and rescue [1]. In core-bored search, responders bore a hole (typically 76 mm, or 3 in) through a section of the collapsed structure to access a void. A “camera on a stick” is normally used for quick assessment, but robots provide the capability to search around and behind debris that might be blocking the view of the camera. Since time is of the essence, several robots could be deployed to search in parallel and to act as communication repeaters for each other in larger spaces and spaces with difficult radio propagation characteristics. From an architectural standpoint, the TerminatorBot consists of: •

the dual-arm mechanism

•

six motors to drive the mechanism

•

sensors for force, vision and control

•

a microcontroller subsystem

The microcontroller system is fabricated as a two-board set. The CPU board (UM001) contains the 8-bit Atmel microcontroller, communications interfaces and logic power supply. The I/O board (UM002) piggybacks onto the UM001 through a proprietary interface and contains the H-bridge motor drivers, encoder counters and dirty power supply for the motors. For this work, we developed a custom version of the UM001 CPU board with Bluetooth radio for implementation and validation. III. E XISTING W IRELESS , A D -H OC N ETWORK S OLUTIONS Despite the ubiquitous use of wireless technology for laptops and handheld devices, certain environments such as USAR continue to evade a wireless networking solution. Current technologies cannot reliably provide for the unique demands of medium range robot communication with high bandwidth and low power consumption across a highly volatile, mobile network in the challenging RF environment of a collapsed structure. Although no single solution provides for all these demands, existing technologies (e.g Analog RF, Wi-Fi, Zig-bee, and Bluetooth) offer solutions to at least a subset of these demands.

(a)

Fig. 2.

(b)

Bluetooth network topology : (a) a standard master/slave Piconet (b) the proposed Scatternet, linking multiple Piconets

August 19, 2009

DRAFT

5

A. Point-to-Point Protocols Analog RF is a well-known wireless communication technology, but it possesses significant vulnerability to noise. For example, in [8], Rybski et al. adapted exclusive, single-hop, time-multiplexed RF radio links to obtain a video signal from an untethered robot. However, the RF radio used exclusively for the video was vulnerable to noise caused by the motors and to de-tuning of the antenna due to its proximity to the ground. The video was suitable for certain coarse tasks, such as finding dark hiding places, but not suitable for most high fidelity tasks of USAR. Other technologies successfully applied to robotics include Wi-Fi (802.11) and Zig-bee. Wi-Fi is typically used on large platforms, such as the XR4000 from Nomadic Technologies or the Pioneer from ActivMedia. These platforms provide sufficient power and can handle the large physical and computational footprint [9], [10] of Wi-Fi. Furthermore, Wi-Fi evolved for personal use and is much better suited for quasi-static networks that exhibit low volatility. Smaller, resource-constrained platforms require something more efficient. Zig-bee is typically applied to small-scale robots or sensor nodes like the MICA mote from Crossbow Technologies (based on the UC, Berkeley mote). It works on the global 2.4GHz ISM band and supports IEEE802.15.4 [11]. However, the raw, over-the-air data rate is still low – less than 250kbs in the 2.4 GHz band. Another common wireless technology, Bluetooth was initially designed as a cable replacement. It has been an emerging candidate in sensor networks, since it features four times the bandwidth of Zig-bee [12], [13]. The power consumption is slightly higher than Zig-bee, but it is an insignificant difference relative to Wi-Fi. Leopold et al. determined that Bluetooth technology has the potential to support large, ad-hoc networking in certain niche robotics [12], but it is not amenable to this in its stock form. Bluetooth topology is based on one master and up to 7 slaves, known as a piconet, which has an asteroidal structure (see Fig.2a). A piconet is hierarchical in that the master node maintains routing information and it controls the data flow to slave nodes. A scatternet, which consists of multiple piconets, enables the configuration of large scale sensor networks (see Fig.2b) but this feature is not currently supported by Bluetooth. It has been difficult to realize wireless digital communication technology for small robots capable of transmitting raw video. Compressed motion video (e.g. MPEG) is also undesirable as dropouts in communication result in many subsequent garbled frames. While tethered solutions exist, wireless communication provides greater flexibility in mobility [14] and opens up the possibility of large-scale robot networks performing wide-area search and rescue missions. Of the wireless technologies discussed above, we think Bluetooth offers the most potential but requires a new routing protocol to control dataflow through large, ad-hoc networks in a scatternet configuration. B. Ad-Hoc Routing Protocols In the USAR environment with unpredictale RF environment, video may be transmitted back to the human operator over long ranges by routing it through a network of nodes (i.e. robots) using Bluetooth wireless technology. A routing protocol, which is implemented on top of the wireless transport layer, is necessary to establish connectivity among nodes and maintain viable routes through the multi-hop network. A robot network is a form of mobile ad-hoc network, whereby nodes move freely in and out of range, thereby making it more difficult to maintain viable routes August 19, 2009

DRAFT

6

through the network. Many researchers have developed various routing protocols for mobile ad-hoc networks (see [15] for a review). These protocols generally fall into three broad categories distinguishable by the manner in which routing information is maintained: proactive, reactive (also called “on-demand”), or hybrid that attempts to capture the strengths of both protocols.

Fig. 3. Sequence flow charts for different routing protocols: (a) CHGS proactive routing protocol, (b) AODV on-demand routing protocol, and (c) LSP hybrid routing protocol for WVSN

As the name implies, a proactive protocol proactively maintains routing information to any destination, regardless of need. This routing information is stored in a table, which is periodically updated. The table establishes a data pathway between every node pair. In proactive protocols, all nodes in the network are required to maintain whole August 19, 2009

DRAFT

7

up-to-date routing information. When a change occurs due to the loss of a node, every alternate route is known to all nodes so the broken link can be detoured around very quickly – a low-latency fix. The cost of this quick response to node failures is the very high overhead communication required to propagate changes in the routing table to all nodes. This is why proactive routing is used by the internet; the network is static and very dense. In highly volatile networks, the communication required to maintain the tables at each node can exceed the data being communicated. Some examples of proactive protocols include the Destination-Sequenced Distance Vector protocol (DSDV) [16] and Cluster Head Gateway Switch (CHGS) routing protocol [15], the latter of which we use in our hybrid scheme. Conversely, on-demand routing protocols only maintain up-to-date routing information on an as-needed basis. In other words, they react to need. When a failure is detected while attempting to route a message, the link failure notification is propagated to initiate the route discovery protocol to find a new route until the message reaches the source. Communication bandwidth consumed by overhead in this type of protocol is low, but the cost of this reduced overhead is slower recovery from node failures (high latency). Some examples of on-demand protocols include Ad-hoc On-demand Distance Vector routing (AODV) [17], Dynamic Source Routing (DSR) [18], and the Temporally Ordered Routing Algrorithm (TORA) [19]. IV. L OCALLY S WITCHABLE P ROTOCOL (LSP) In this paper, we present a hybrid routing protocol, called the Locally Switchable Protocol (LSP), shown in Fig. 3 (c), which applies a proactive routing protocol to a global area and a reactive routing protocol to a local area to recover a critical path failure as originally reported in [20]. This protocol allows us to obtain better throughput on a small scale network of sparse, highly volatile nodes, such as a robotic wireless video sensor network. Even if many on-demand routing protocols show better throughput than proactive protocols in an ad-hoc network, there still exist some disadvantages relative to the proactive approach, such as finding the shortest path given frequent network changes and slower route recovery for network errors. Our methodology maintains a proactive protocol over the global network. If a critical error on the path occurs, it uses an on-demand protocol locally to recover the path. Our approach to maintaining routing information is shown in Fig. 3. We use a slight variant of the Cluster Head Gateway Switch routing protocol as our global, proactive protocol. The benefit of the CHGS protocol over other proactive protocols is reduced overhead that results from a hierarchical approach. Instead of a “flat” network, the CHGS routing protocol is one of several heuristic routing protocols based on a clustered multi-hop approach. A cluster head maintains routing information for a group of in-range “slave” nodes. The reduced routing table only contains routes between the cluster heads plus a list of which slave nodes are associated with each cluster head. This protocol is well-suited to a Bluetooth network due to its similarity to the Bluetooth piconet. For the local, reactive response to failures for which there is no known alternate route, we use a variant of Ad-hoc On-demand Distance Vector routing.

August 19, 2009

DRAFT

8

V. I MPLEMENTATION In this section, we present the implementation of our hybrid routing protocol for multi-hop wireless communication over Bluetooth. We discuss the inquiry procedure of Bluetooth devices in RF proximity and the packet types for the routing table. A. Device discovery: Inquiry and Inquiry Scan

Operation Type

Minimum Time

Average Time

Maximum Time

Inquiry

0.00125s

3-5s

10.24-30.72s

Page

0.0025s

1.28s

2.56s

Total

0.00375s

4.28-5.28s

12.8-33.28s

TABLE I M EAN TIME REQUIRED TO COMPLETE INQUIRY / PAGE PROCEDURE [21]

x 10

4

7 Data throughput transfered (bytes)

Data throughput transfered (bytes)

11 10 9 8 7

6 20

40 60 80 100 120 Inquiry process period (seconds)

(a)

Fig. 4.

140

x 10

4

6

Inquiry process period : 33.557 sec

5 4 3 2 1 0 2

3 4 5 6 7 Number of nodes in RF proximity

8

(b)

Data throughput transferred : (a) over different inquiry periods and (b) for an example with 33.557 seconds period.

There exist two phases for establishing connections in the Bluetooth protocol. First, in the inquiry state, a unit sends out inquiry packets, then in the page state, it receives the inquiry reply. Table I presents the mean time required for each. Each state can make it difficult to proceed to another state [22]. During the inquiry state, the device cannot listen to any packets from other devices. Therefore, it will cause a serious date transfer delay (an example is shown in Fig. 4(b)). Since inquiry and page functions in Bluetooth communication are highly time-consuming processes, we established a reasonable period of 134 seconds for the inquiry scanning during initial network set-up.

August 19, 2009

DRAFT

9

(a)

Fig. 5.

(b)

Packet format for building routing table: (a) proactive routing protocol and (b) on-demand routing protocol.

B. Protocols for LSP 1) Proactive routing protocol: The hierarchical Bluetooth topology consists of one master and up to seven slaves that compose a piconet. This is similar to the Cluster-Head Gateway Switched routing protocol, but in CHGS, a routing table is created between the masters of each piconet, forming a scatternet. When a Bluetooth scatternet formation is finished, each node in the proactive routing protocol maintains a global routing table by exchanging routing tables (see Fig. 5 (a)). The cluster member table of a master is broadcast periodically. The size of this routing table may be variable between 13 bytes (minimum requirement) and at most 34 bytes (13 bytes + maximum number of corresponding neighbor slaves x 3). All masters in the networks are assigned with unique numbers based on a simple loop free algorithm. After gathering the reduced routing table information, which consists only of the master connected to each slave plus the connectivity of the masters, we can build an adjacent distance vector table, which shows the distance between master nodes (see Fig. 6(b)). Once the vector table is established, we use Dijkstra’s algorithm to find the shortest path (see Fig. 6(c)). 2) On-demand Routing Protocol: When triggered, the on-demand routing protocol initiates a route discovery by broadcasting a routing request (RREQ) packet containing the source address (SourceID), destination address (TargetID), and hop-count (NumberOfLinks) as depicted in Fig. 5(b). The size of this routing packet is variable with the total number of bytes equal to 11 bytes + hop-count x 3. Hop-count is initially 0 and is incremented at each passing through a node as the RREQ packets move toward the sink node. When RREQs arrive at the sink node, the sink node can choose the shortest path among the RREQs and other paths are discarded (see Fig. 7(a)). The sink node responds to the RREQ packet through the shortest path. As the RREQ packet travels back to the source node, all intermediate nodes build a new routing entry for the sink node (see Fig. 7(b)).

August 19, 2009

DRAFT

10

(a)

(b)

(c)

Fig. 6.

(a) Hierarchical topology. (b) Adjacent distance vector table : 0-itself, 1-connection, and 99-disconnection. (c) Hierarchical structure

and shortest path found by Dijkstra algorithm.

3) LSP Protocol: In our hybrid LSP protocol, there are two phases corresponding to the two protocols – proactive phase and on-demand phase. As long as the sensor network has at least one known path to the destination, it operates very similar to the proactive routing mechanism (see Fig. 8(a)). When network failures result in no known path to the destination, the LSP locally uses AODV to discover a new route. For example, in Fig. 8(b), the route has failed since there is no master between master 2 and master 4. The LSP applies the on-demand routing protocol to quickly find a route with minimal delay. The benefits of this protocol to robotic wireless networks are many. The scatternet topology greatly reduces the impact of failure of the slave nodes. Slave nodes do not influence message routing so their disappearance has no impact on the network. If node failure is randomly distributed, as it likely is with a swarm of robots under decentralized control, a random failure will likely occur at a slave, with no effect. If a gateway node fails, the master knows what other slaves are available and can reactively make a substitution with relatively minor overhead packets. (Much lower overhead than that required to proactively maintain the entire network.) Finally, if a master disappears, the network must reactively re-establish the piconet, which is the worst-case scenario. The disappearance of a master incurs a greater hit to latency in LSP than a proactive protocol, but the probability is comparatively low, so the savings in network overhead traffic makes LSP superior for robotic networks, as we will show in the following sections.

August 19, 2009

DRAFT

11

(a)

(b)

(c)

Fig. 7.

Flat network topology. (a) Propagation of the RREQ from the source node to the sink node. (b) Propagation of the RREQ from the

sink node to the source node. (c) Routing vector table during (a) procedure.

VI. S IMULATION A simulator for the Locally Selectable Protocol as applied to robotic networks was presented in [20]. We developed a simulator, as shown in Fig.9(a) and 10, to test the Bluetooth network topologies for sparse robotic networks. The simulator can deploy a number of robots in the console and then assign the roles of master and slave to each using the Least Cluster Change (LCC) algorithm [23]. It is able to graphically show the connection of the robot nodes in range. (“In range” is determined by a simple distance threshold.) It can also measure the packet delivery time to update routing information and can predict the behavior and performance of sensor networks. The simulator can be used to measure recovery time and the number of message packets required to recover network topology changes for specific topologies in Monte Carlo style and also compute the number of links of flat networks (AODV) and hierarchical scatternets (CHGS and LSP) as seen in Fig.9(b). As reflected in Eq. 1, the primary disadvantage of the flat network is that the number of links grows dramatically as the number of nodes increases.

Nlink =

August 19, 2009

Nnode (Nnode − 1) 2

(1)

DRAFT

12

(a)

(b)

(c)

(d)

(e)

(f)

Fig. 8. (a) Initial network topology. (b) Master 3 disappeared on the path. (c) on-demand routing protocol: RREQ is propagated to the temporary sink (master 4). (d) on-demand routing protocol: RREQ is propagated to the temporary source (master 2). (e) Two different routing protocols exist. (f) After a period to update routing tables, the three nodes between master 2 and master 4 are assigned to 2 master nodes and another master node that doubles as a gateway.

where Nlink and Nnode are the number of links and nodes, respectively. The simulation results of the routing protocols are summarized in Table II. LSP shows 13 msec and 14 msec under both the compact and extreme case while both the proactive and reactive protocols show unacceptable recovery delays for one of the cases. As mentioned in Section V, the disappearnce of slave nodes has no impact on routing, getway nodes have a minor impact, and master nodes have the greatest impact. Since the assignment of duties is purely a function of the node distribution and the local RF environment, the likelihood of failure of a master node is assumed to be identical to that of a gateway or slave. One might argue that a master node transmits and receives messages more than a slave node and, therefore, is more likely to fail due to power limitations. While this may be true in a static network, in the highly volatile topologies in which we are interested, mobility within a highly unpredictable RF environment is assumed to be a greater cause of node disappearance than loss of power. This is further reinforced by the high power consumption of motors compared to the Bluetooth radio. As a result, we consider node failure (disappearance from the current network topology) to be approximately uniform across node types. August 19, 2009

DRAFT

13

(a)

Fig. 9.

Fig. 10.

(b)

(a) GUI of simulator for WVSN. (b) Maximum connection overhead versus number of nodes.

(a)

(b)

(c)

(d)

Network topology simulation for 8 USAR robots: (a) before deployment (b) during deployment (c) snapshot of scatternet under

construction (d) scatternet network topology using the Least Cluster Change algorithm. Blue = master, white = gateway, gray = slave, green = source, red = destination

VII. E XPERIMENT AND R ESULTS To compare protocols, we implemented each using ten UM001 CPU boards of the search and rescue robot, TerminatorBot. The boards, shown in Fig. 11, are based on the Atmel 8-bit embedded microcontroller, ATmega128, with Bluetooth communication capabilities using the LMX9830 Bluetooth modules from National Semiconductor Corporation. Since we only have three TerminatorBot mechanisms, we simulated the mobility of the robots by moving the CPU boards manually. The three routing protocols were implemented and compared using two different network topologies. One of the network formations (Fig. 12(a)) has one single path over the whole network. The other network formation (Fig. August 19, 2009

DRAFT

14

Routing method

Single period(no failure)

Compact case

Extreme case

Proactive

Routing Packet(bytes): 34

34

34

Recovery Delay(msec) :

13

34054


20

20


134

21


27

27


13

14

Reactive

LSP

TABLE II S IMULATION COMPARISON OF ROUTING PROTOCOLS FOR RECOVERING PATH FAILURE ON TWO DIFFERENT CASES IN F IG . 12 ( A ) AND ( B ). (T HE ROUTING UPDATE PERIOD OF PROACTIVE ROUTING PROTOCOL AND LSP IS 50000( MSEC ). B OLD TYPEFACE MEANS WORST PERFORMANCE .)

(a)

Fig. 11.

(b)

(a) Bluetooth communication test before deployment (b) 10 Tbot CPUs deployed by the designated topology.

12(b)) has multiple paths over the whole network. With such network formations, we measured data throughput and recovery time over five hops as shown in Fig. 13. Overall data throughput of the AODV routing protocol showed the best performance. However, the recovery time of the AODV routing protocol showed the worst performance. Under high mobility conditions of the networks, we measured the routing packet size while frequently changing the on/off status of other robot nodes that were not involved in the actual routing path. Results are shown in Fig. 14. The hybrid LSP protocol performed better than the standard CHGS protocol with respect to packet overhead.

August 19, 2009

DRAFT

15

(a)

Fig. 12.

(b)

(a) Extreme case of serially connected scatternets. (b) Compact formation of scatternets with alternative path.

(a)

(b)

Fig. 13. (a) Throughput for different routing protocols over four hops. (b) Average recovery time for different routing protocols, once a failure on the networks occurred

A. Future Work Our prior work in USAR was based on tethered robots, which are restricted to operate in isolation. With our new LSP routing protocol, we can now implement a team of untethered robots that can transfer imagery from the frontier of the team’s exploration back to the user. As part of an end-to-end system, we have developed a gestural joystick [24] to provide motions commands to one robot at a time and a PDA-based Host Controller Interface (HCI) for viewing the sensor data from the robot. It is assumed the other robots will be implementing autonomous behaviors while they are not communicating with the user. These autonomous behaviors have not yet been implemented on the TerminatorBot. The system performs remote operation through wireless communication over Bluetooth networks. We are expanding the user interface to select a particular robot within the network for user interaction. The PDA will be the August 19, 2009

DRAFT

16

Routing packet(bytes)

200 Table−driven LSP On−demand

150

100

50

0 2

3

4 5 6 Number of nodes

Fig. 14.

Average routing packet overheads over different routing protocols.

Fig. 15.

Summary of the routing protocols.

7

8

destination node for display of the imagery. The application example using robotic sensor networks for human-inthe-loop control of a USAR robot is shown in Fig.16 [25]. VIII. C ONCLUSION In this paper, we have introduced a new multi-hop networking protocol, the Locally Selectable Protocol, on top of Bluetooth communication for use in sparse, highly volatile networks typified by multi-robot teams in harsh RF environments. An example application domain is small-scale urban search and rescue robots. We have presented simulation results that show our protocol has the potential to outperform standard Cluster Head Gateway Switched routing and Ad-hoc On-demand Distance Vector routing for these types of networks. We also detailed the implementation of our Locally Selectable Protocol on an 8-bit microcontroller and tested it against implementations of AODV and CHGS protocols. In fact, one of the strengths of this paper is the implementation of these protocols for head-to-head tests in real environments. We have used Bluetooth v2.0 ad-hoc wireless communication to resolve the bottle neck of bandwidth and power constraints, demonstrating its feasibility for ad-hoc networks of small-scale USAR robots. Our hybrid routing protocol, called the Locally Selectable Protocol, maintains a high data transfer rate and has shown low recovery

August 19, 2009

DRAFT

17

(a)

Fig. 16.

(b)

(a) Installation human-in-the-loop device (b)Block diagram for the system

time under both compact and extreme cases. We have shown that LSP can cope with frequent network failures in bad network topologies better than the proactive or on-demand routing protocols tested. LSP provides the best compromise between latency and throughput for sparse, highly volatile networks. We feel this protocol is an important step for sparse networks of power-constrained, highly volatile, mobile nodes with need for high bandwidth. However, we acknowledge routing protocols are only part of the story for multi-robot teaming. There is also a need for methodologies for maintaining connectivity of the nodes while simultaneously achieving task goals. Along these lines, we are investigating methods for ad-hoc mapping of RF environments for non-line-of-sight scenarios. ACKNOWLEDGEMENTS This work was sponsored in part by the NSF Safety, Security and Rescue Research Center and by the NSF under grant 0719306. R EFERENCES [1] R. Voyles, A. Larson, J. Bae, and M. Lapoint, “Core-bored search-and-rescue applications for an agile limbed robot,” in Proceedings of the 2004 IEEE/RSJ International Conference on Intelligent Robots and Systems, vol. 1, 2004, pp. 58–66. [2] R. Murphy, “Human-robot interaction in rescue robotics,” IEEE Systems, Man and Cybernetics, vol. 34, no. 2, May 2004. [3] A. Wolf, B. Ben, R. Casciola, A. Costa, M. Schwerin, E. Shammas, and H. Choset, “A mobile hyper redundant mechanism for search and rescue tasks,” Las Vegas, Nevada, USA, October 2003, pp. 2889–2895. [4] J. Casper and R. Murphy, “Human-robot interactions during the robot assisted urban search and rescue response at the world trade center,” IEEE Systems, Man and Cybernetics, vol. 33, no. 3, June 2003. [5] B. Shah and H. Choset, “Survey on urban search and rescue robots,” Robotics Society of Japan, vol. 22, no. 5, July 2004. [6] R. Voyles, J. Bae, and E. Estrine, “Human-activated displacement control appliance for use with computerized device/mechanism,” US Patent 5,406,551, 2005. [7] R. Voyles and A. Larson, “Terminatorbot: A novel robot with dual-use mechanism for locomotion and manipulation,” IEEE/ASME Transactions on Mechatronics, vol. 10, no. 1, pp. 17–25, 2005. [8] P. Rypski, Stoeter, M. S.A. Gini, D. Hougen, and N. Pananikolopoulos, “Performance of a distributed robotic system using shared communications channels,” IEEE Transactions on Robotics And Automation, vol. 18, no. 5, pp. 713–727, Oct. 2002.

August 19, 2009

DRAFT

18

[9] I. Rekleitis and G. Dudek, “Automated calibration of a camera sensor network,” in IEEE/RSJ International Conference on Intelligent Robots and Systems, 2005. [10] B. Maxwell, N. Ward, and F. Heckel, “A configurable interface and software architecture for robot rescue,” in Sixteenth Conference on Innovative Applications of Artificial Intelligence, San Jose, CA, USA, July 2004, pp. 25–29. [11] P. Levis and D. Culler, “Mate: A tiny virtual machine for sensor networks,” in International Conference on Architectural Support for Programming Languages and Operating Systems, San Jose, CA, USA, Oct. 2002, to appear. [12] M. Leopold, M. Dydensborg, and P. Bonnet, “Bluetooth and sensor networks: A reality check,” in SenSys, Los Angeles, California, USA, November 2003. [13] Z. Jian, Z. Fei, and W. Bin, “Cluster based routing in bluetooth ad-hoc network,” in Proceedings of Wireless Communications, Networking and Mobile Computing, vol. 2, no. 12, Sep. 2005, pp. 747–752. [14] D. H. Barnhard, B. J. Wimpey, and W. D. Potter, “Odin and hodur: Using bluetooth communication for coordinated robotic search,” in Proceeding of the International Conference on Artificial Intelligence, Las Vegas, Nevada, USA, 2004. [15] E. M. Royer and C. K. Toh, “A review of current routing protocols for ad hoc mobile wireless networks,” IEEE Personal Communication, pp. 46–55, Apr. 1999. [16] C. E. Perkins and P. Bhagwat, “Highly dynamic destination-sequenced distance-vector routing(dsdv) for mobile computers,” in Computer Communications Review, Oct. 1994, pp. 234–244. [17] C. E. Perkins and E. M. Royer, “Ad-hoc on-demand distance vector routing,” in Second IEEE Workshop on Mobile Computer Systems and Applications, 1999, pp. 99–109. [18] D. Johnson and D. Maltz, “Dynamic source routing in ad hoc wireless networks,” in Mobile Computing, 1996, pp. 153–181. [19] V. Park and M. Corson, “A highly adaptive distributed routing algorithm for mobile wireless networks,” in Proceedings of INFOCOM, 1997. [20] J. Bae and R. Voyles, “Wireless video sensor network from a team of urban search and rescue robot,” in Proceedings of the International Conference on Wireless Networks, 2006. [21] “Bluetooth specification version 1.2,” in http://www.bluetooth.org, vol. 1. [22] T. Salonidis, P. Bhagwat, L. Tassiulas, and R. LaMaire, “Distributed topology construction of bluetooth personal area networks,” in IEEE INFOCOM, 2001, pp. 1577–1586. [23] C. C. Chiang, H.-K. Wu, W. Liu, and M. Gerla, “Routing in clustered multihop mobile wireless networks with fading channel,” in Proceedings of IEEE SICON, Apr. 1997, pp. 197–211. [24] J. Bae and R. Voyles, “Wearable joystick for gloves-on human/computer interaction,” in Proceedings of the SPIE Defense and Security Symposium, Orlando, FL, April 2006. [25] R. Voyles and J. Bae, “The gestural joystick and the efficacy of the path tortuosity metric for human/robot interaction,” in Proceedings of the Performance Metrics for Intelligent Systems Workshop, Gaitherburg, MD, August 2008.

August 19, 2009

DRAFT