Annual Technical Conference 2011 of IET-YP Sri Lanka, 17th December 2011
BUILDING A LOW-COST TELEPRESENCE ROBOT WITH GENERIC HARDWARE Vajira Thambawita (
[email protected]), Kalindu Herath (
[email protected]) Supervised by: Dr. Roshan Ragel and Dr. Dhammika Elkaduwe Department of Computer Engineering – University of Peradeniya – Sri Lanka
Abstract
Robots are now commercially produced. Anybots QB
Telepresence robotics is an application in robotics
Telepresence Robot [1] is one of such commercially
which allows you to mark your presence in a location
available robot. Video conferencing is one of the key
where you are not physically present. Unfortunately, the
technologies in these robots to implement the virtual
use of Telepresence robots is greatly limited due to the
presence apart from having a physical presence through
high cost of commercially available robots. The
the robots. But due to the extreme cost they are limited
limitation is overcome in this project by producing
to high end offices and less number of people.
Telepresence
for
Most of commercially available robots have specialized
institutional or house hold use, at a lower cost. The
hardware for processing activities. As a result the
existing commercial Telepresence robots use dedicated
production cost of the robot increases rapidly. This
and specialized hardware components for their key
project suggests a way to produce a Telepresence Robot
activities. The major drawback of using these hardware
using generic hardware and a sophisticated software.
components is their high cost and therefore the
Our design consists of a normal old laptop mother board
unaffordable price of the robot. As a low cost
and a processor for the main processing hardware of the
alternative, use of special hardware components is
robot. In addition, the other peripherals of the laptop
avoided wherever possible and attempts are made to
such as screen, microphone, speakers, webcam (if
obtain the same functionalities through the use of
equipped), wireless network card (if equipped) are used
general
laptop
with the streaming and networking activities at the
motherboard) and software. This project allows
robot. External circuitry (i.e. Motor Circuit) is
implementing
basic
controlled via parallel port or USB port interfacing. The
functionalities for the cost of around USD 250.
suggested Telepresence robot is developed in way it can
Although the software of the robot system is highly
be integrated to a Wireless Network.
robots
purpose
a
which
hardware
are
(such
Telepresence
appropriate
as
robot
a
with
extensible, the overall functions are greatly limited with the processing power and the battery life of the laptop.
2.
Methodology
The structure of the robot consists of a base plate where 1.
Introduction
two DC motor power wheels and a freely rotatable
Telepresence [4] is an extension of Robotic Technology
wheel are fixed to, and a laptop computer placed at a
which allows a person to appear or be present at a
height of three feet from the base plate. The controller
separate location virtually. In 1980s, the study of using
of the robot is in a different location and controls the
robots to represent a person has started and in early
robot via a Wireless Local Area Network (WLAN).
1990s similar kind of Telepresence robots were
Avoiding specialized hardware in this project adds a
available. As the other kinds of robots, the Telepresence
new challenge. That is the way of implementing
Annual Technical Conference 2011 of IET-YP Sri Lanka, 17th December 2011
efficient and reliable functionalities on the software
battery and Wi-Fi signal strength information of the
which were successfully implemented on hardware in
robot sent by the robot to the controller are
existing
communicated using this channel.
Telepresence
robots.
In
our
software
implementation there are two main software programs,
As mentioned above the controller needs to know the
one for the controller of the robot and the other is for the
remaining battery power and the current Wi-Fi signal
robot. The structure of two programs is almost the same
strength at the robot to avoid the robot going to an
except the robot software uses computer interfacing to
uncontrollable state. In addition, the robot’s computer
control the motors at the robot. However both software
should be able to lock remotely so that unnecessary
programs are written in Java and are consisted of Video
interference from human can be avoided. These
and
functionalities involve native methods of the windows
Audio
Streaming
through
WLAN,
Socket
Programming, Native Access and Image Processing.
platform and cannot be implemented using only Java
Video and audio streaming is necessary for both
functions. Therefore the software programs use platform
controller and robot software programs since both
depended methods to achieve these tasks.
parties
remote
In addition to above software implementations, parallel
environment. Therefore software programs consist of
port and USB port interfacing is used for driving motors
two
for
the robot. The controller sends controlling signals using
transmitting and receiving audio and video data.
the software via WLAN network to the robot, and the
Moving on to the transmitting process in the
robot reads the control signals and controls the driver
implementation, the initial step of this process is to
motors accordingly.
detect and occupy the media devices; the web cam and
This method of implementation avoids costly signal
the microphone using JMF (Java Media Framework)
processing modules, separate LCD screens, Wi-Fi
[2]. JMF keeps a registry of media devices available in
network modules and servo motors and allows
the system, and the program accesses this registry and
developing a Telepresence robot at a low cost.
require
independent
hearing
and
and
seeing
concurrent
the
processes
gets device information such as audio format, video format, sampling rate, locator of the device etc.
3.
According to collected information, the transmitting
The initial test for the software was done with two
process makes an object for input device and take input
laptop computers with an ad-hoc type Wi-Fi connection.
media data. Afterwards the data are converted to RTP
The intention of the initial test was to see the processing
(Real-time Transfer Protocol) [3] compatible format,
power required and the delay of RTP stream.
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
Tests and Results
Intel core2duo 2.0 GHz 2GB RAM laptop as the controller
Intel Pentium III 1.0 GHz 128MB RAM laptop as the robot
video is duplicated before converting to RTP and one data stream is directly played backed. In the receiver
Measurement
process, the program defines the source address of the
Controller Normal
Multithreaded
45%-55%
N/A
2-3 sec
N/A
stream and tunes the channel for receiving and received
Required Processing
media data is played back.
Power
Apart from the video and audio communication
RTP delay
described above, there is a separate channel for data
Table 1 : Controller software runtime evaluation results
communication. The commands related to movements of the robot sent by the controller to the robot, the
Annual Technical Conference 2011 of IET-YP Sri Lanka, 17th December 2011
Measurement
Required Processing
signal system is combined with acknowledgements, the
Robot Normal
Multithreaded
responsiveness of the motor controlling unit was
70-75%
90%
significantly reduced because of the bandwidth and processing power limitations.
Power RTP delay
3-4 sec
2-3 sec
Table 2 : Robot software runtime evaluation results
4.
Conclusion
Considering all the facts, it can be stated that this 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
Controller’s
Robot’s software
Resolution
software
640 x 480
2-3s RTP delay
Failed to transmit
352 x 288
2-3s RTP delay
3-4s RTP delay
hardware scheme allows achieving a cost effective solution 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. The physical memory limitation in the robot’s computer prevents the use of multithreading and
network congestion reduction
techniques in software implementation. Using Java on
70-75% CPU 320 x 240
implementation of a Telepresence robot using generic
2-3s RTP delay
Around 3s RTP delay
35-40% CPU
70% CPU
Table 3 : Software performance in runtime with video resolution
windows platform might be the reason for these weaknesses in the software since Java operates on a virtual machine. Therefore we propose to perform another test implementing the software functions using C++ or C programming language as the future work. Considering the hardware, the moving speed of the robot is limited due to use of high torque DC motors so
The second test shows that reduction in video resolution
that there should be a mechanism to increase the speed
affects only to the robot’s software program. The higher
while keeping the stability and adequate torque at the
video resolution is failed due to limited physical
motors.
memory of the robot’s computer. Considering the test results it is observed that 640 x 480 video resolution can
5.
References
be used with controller’s program where as 352 x 288 vide resolution is more suitable for the robot’s program
[1] Erico Guizzo. Anybots qb telepresence robot.
for more quality of operation. The reliability of the
http://spectrum.ieee.org/automaton/robotics/industrial-
software programs is reduced due to unexpected crashes
robots/051810-anybots-qb-new- telepresence-robot
on test. The main cause of these crashes was the
[2] Budi Kurniawan. Program multimedia with jmf.
instability of external Java libraries used such as
http://www.javaworld.com/jw-04-2001/jw-0406-
Freedom to Media in Java (FMJ), Jacob.
jmf1.html.
In the third test the bandwidth requirements for the
[3] Wikipedia. Real-time transport protocol.
software programs was tested. The above tests were
http://en.wikipedia.org/.
done using IEEE802.11g connection with 54Mbps
[4] Wikipedia. Telepresence.
bandwidth and did not show any incompatibility for
http://en.wikipedia.org/wiki/Telepresence
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
