Low Cost Telepresence Robot

Abstract

Introduction Telepresence [4] is an extension of Robotic Technology which allows a person to appear or present at a separate location virtually. In 1980s, the study of using robots to represent a person has started and in early 1990s similar kind of Telepresence robots were available. As the other kinds of robots, the Telepresence Robots are now commercially produced. Anybots QB Telepresence Robot [1] is one of such commercially available robots. Video Conferencing is the key technology in these robots to implement the virtual presence. But due to the extreme cost they are limited to high end offices and less number of people. The endeavor of this project is to produce a low cost Telepresence Robot in a way that the robot can be integrated into wireless network of an institution. Most of commercially available robots have specialized hardware for processing activities. This architecture of the robot increases the cost rapidly. Therefore, as the main cost reduction method, our design consists of a normal laptop mother board and a processor for the main processing hardware of the robot. In addition, the other peripherals of the laptop such as screen, microphone, speakers, webcam (if equipped), wireless network card (if equipped) are used with the streaming and networking activities at the robot. External circuitry (i.e. Motor Circuit) is controlled via parallel port or USB port interfacing. Therefore, our approach for cost reduction is based on minimizing the hardware and hardware activities, and having sophisticated software. Methodology

Full text

Low Cost Telepresence Robot
Vajira Thambawita, Kalindu Herath , Roshan Ragel and Dhammika Elkaduwe
Department of Computer Engineering, Faculty of Engineering,
Introduction
Telepresence [4] is an extension of Robotic Technology which allows a person to appear or
present at a separate location virtually. In 1980s, the study of using robots to represent a person
has started and in early 1990s similar kind of Telepresence robots were available. As the other
kinds of robots, the Telepresence Robots are now commercially produced. Anybots QB
Telepresence Robot [1] is one of such commercially available robots. Video Conferencing is the
key technology in these robots to implement the virtual presence. But due to the extreme cost
they are limited to high end offices and less number of people.
The endeavor of this project is to produce a low cost Telepresence Robot in a way that the robot
can be integrated into wireless network of an institution. Most of commercially available robots
have specialized hardware for processing activities. This architecture of the robot increases the
cost rapidly. Therefore, as the main cost reduction method, our design consists of a normal
laptop mother board and a processor for the main processing hardware of the robot. In addition,
the other peripherals of the laptop such as screen, microphone, speakers, webcam (if equipped),
wireless network card (if equipped) are used with the streaming and networking activities at the
robot. External circuitry (i.e. Motor Circuit) is controlled via parallel port or USB port
interfacing. Therefore, our approach for cost reduction is based on minimizing the hardware and
hardware activities, and having sophisticated software.
Methodology
Considering the design, the structure of the robot consists of a base plate where two DC motor
power wheels and a freely rotatable wheel are fixed to, and a laptop computer placed at a height
of three feet from the base plate. The controller of the robot is in a different location and controls
the robot via a Wireless Local Area Network (WLAN).
Avoiding specialized hardware in this project adds a new challenge. That is the way of
implementing efficient and reliable functionalities on the software which were successfully
implemented on hardware in existing Telepresence robots. In our software implementation there
are two main software programs, one for the controller of the robot and the other is for the robot.
The structure of two programs is almost the same except the robot software uses computer
interfacing to control the motors at the robot. However both software programs are written in
Java and are consisted of Video and Audio Streaming through WLAN, Socket Programming,
Native Access and Image Processing.

Video and audio streaming is necessary for both controller and robot software programs since
both parties require hearing and seeing the remote environment. Therefore software programs
consist of two independent and concurrent processes for transmitting and receiving audio and
video data. Moving on to the transmitting process in the implementation, the initial step of this
process is to detect and occupy the media devices; the web cam and the microphone using JMF
(Java Media Framework) [2]. JMF keeps a registry of media devices available in the system, and
the program accesses this registry and gets device information such as audio format, video
format, sampling rate, locator of the device etc. According to collected information, the
transmitting process makes an object for input device and take input media data. Afterwards the
data are converted to RTP (Real-time Transfer Protocol) [3] compatible format, and then this
RTP stream is sent to the receiver at the other end, over previously configured WLAN network.
It is useful to have a way of seeing the grabbed video from the current environment. To achieve
this, the input video is duplicated before converting to RTP and one data stream is directly
played backed. In the receiver process, the program defines the source address of the stream and
tunes the channel for receiving and received media data is played back.
Apart from the video and audio communication described above, there is a separate channel for
data communication. The commands related to movements of the robot sent by the controller to
the robot, the battery and Wi-Fi signal strength information of the robot sent by the robot to the
controller are communicated using this channel.
As mentioned above the controller needs to know the remaining battery power and the current
Wi-Fi signal strength at the robot to avoid the robot going to an uncontrollable state. In addition,
the robot’s computer should be able to lock remotely so that unnecessary interference from
human can be avoided. These functionalities involve native methods of the windows platform
and cannot be implemented using only Java functions. Therefore the software programs use
platform depended methods to achieve these tasks.
In addition to above software implementations, parallel port and USB port interfacing is used for
driving motors the robot. The controller sends controlling signals using the software via WLAN
network to the robot, and the robot reads the control signals and controls the driver motors
accordingly.
This method of implementation avoids costly signal processing modules, separate LCD screens,
Wi-Fi network modules and servo motors and allows developing a Telepresence robot at a low
cost.
Tests and Results
The initial test for the software was done with two laptop computers with an ad-hoc type Wi-Fi
connection. The intention of the initial test was to see the processing power required and the
delay of RTP stream.
 Intel core2duo 2.0 GHz 2GB RAM laptop as the controller
 Intel Pentium III 1.0 GHz 128MB RAM laptop as the robot

Measurement
Controller
Robot
Normal
Multithreaded
Normal
Multithreaded
Required Processing Power
45%-55%
N/A
70-75%
90%
RTP delay
2-3 sec
N/A
3-4 sec
2-3 sec
Table 1 : Software runtime evaluation results
The above test shows that there is a three second RTP media streaming delay at both ends. In
addition multithreading software causes excessive CPU load for the robot’s computer. Therefore
in the second test the behavior of the software programs according to steaming video size was
observed.
Video Resolution
Controller’s software
Robot’s software
640 x 480
2-3 sec RTP delay
Failed to transmit
352 x 288
2-3 sec RTP delay
3-4 sec RTP delay, 70-75% CPU
320 x 240
2-3 sec RTP delay, 35-40% CPU
Around 3 sec RTP delay, 70% CPU
Table 2 : Software performance in runtime with video resolution
The second test shows that reduction in video resolution affects only to the robot’s software
program. The higher video resolution is failed due to limited physical memory of the robot’s
computer. Considering the test results it is observed that 640 x 480 video resolution can be used
with controller’s program where as 352 x 288 vide resolution is more suitable for the robot’s
program for more quality of operation.
In the third test the bandwidth requirements for the software programs was tested. The above
tests were done using IEEE802.11g connection with 54Mbps bandwidth and did not show any
incompatibility for bandwidth. However the third test showed that the system does not properly
work with IEE802.11b type WLAN connection. In addition, as the motor controlling signal
system is combined with acknowledgements, the responsiveness of the motor controlling unit
was significantly reduced because of the bandwidth and processing power limitations.
Considering all the facts, it can be stated that this implementation of a Telepresence robot allows
achieving cost constraints and also is successful in implementing basic operations of the robot on
the software. However the implementation lacks efficient audio and video streaming over a
WLAN. In addition, the moving speed of the robot is limited due to use of high torque DC
motors so that there should be a mechanism to increase the speed while keeping the stability and
adequate torque at the motors.
References
[1] Erico Guizzo. Anybots qb telepresence robot.
http://spectrum.ieee.org/automaton/robotics/industrial-robots/051810-anybots-qb-new
telepresence-robot.
[2] Budi Kurniawan. Program multimedia with jmf. http://www.javaworld.com/jw-04-2001/jw-
0406-jmf1.html.
[3] Wikipedia. Real-time transport protocol. http://en.wikipedia.org/.
[4] Wikipedia. Telepresence. http://en.wikipedia.org/wiki/Telepresence