See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220838876

Remote access lab for Mitsubishi RV-2AJ robot

Conference Paper · October 2011

DOI: 10.1109/LARC.2011.6086802 · Source: DBLP

CITATIONS READS
3 1,788

3 authors, including:

Jaime Alberto Buitrago Fáber D. Giraldo

University of Quindio University of Quindio
9 PUBLICATIONS   29 CITATIONS    65 PUBLICATIONS   106 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

MMQEF: a framework to evaluate quality in MDE environments View project

Semilleros de Investigación Grupo SINFOCI Universidad del Quindío View project

All content following this page was uploaded by Fáber D. Giraldo on 04 March 2014.

The user has requested enhancement of the downloaded file.

 Remote Access Lab for Mitsubishi RV-2AJ Robot
Jaime A. Buitrago, Fáber D. Giraldo and Julián A. Lamprea
System and Computer Engineering
University of Quindío
Armenia, Colombia
{jalbertob, fdgiraldo, jalamprea}@uniquindio.edu.co
Abstract— this paper presents the architecture of the remote
access laboratory for experimentation with the Mitsubishi RV-
2AJ manipulator robot. This lab has been developed using Java
technology, and a client/server approach based on Servlets has
been specifically implemented. The lab allows users to control
and monitor the robot via Internet using a client application.
Through this lab, the user can manipulate the robot to obtain its
current status and visual feedback of real-time image. This
laboratory also supports education process in the field of
robotics; it provides students and researchers with an instant
access to real experimental interface.
Keywords- Remote lab; Mitsubishi RV-2AJ manipulator robot;
Software Architecture; Client/Server.
I. INTRODUCTION
This article presents the remote access lab for the
experimentation robot manipulator Mitsubishi RV-2AJ, that
has been developed in the research Project “Distributed Lab
with Remote Access through RENATA for Robotics
Experimentation”. The objective of this Project is to build a red
of remote Access labs among Universidad del Valle and
Universidad del Quindío. The tool supports the practical
component in manipulator and mobile robotics courses using
the experimentation platforms available in this institutions
(mobile robot Pioneer 3DX and manipulator robot Mitsubishi
RV-2AJ) and the high speed communication cannel supported
by the National Academic Network of Advanced Technology
RENATA.
Remote access labs emerge as real-equipment based
systems, which allow users to develop practices through a
computer connected to Internet in areas where laboratory
activities play a fundamental role [2][3]. Among these areas,
Robotics is highlighted not only as a field of knowledge that is
constantly changing and with a strong projection to the future,
but also because the experiences in robotics provide an
innovative framework for addressing concepts related to other
disciplines [5][6]. However, many educational institutions do
not have enough versatile and robust tools for experimentation
in robotics.
Any development in Robotics necessarily involves the
construction of hardware to support it or to get to simulation
only, since the experimental equipment is expensive due to its
high reliability and its incorporated software. This issue slows
down the research and learning process, limiting the possibility
to develop, create and test new methods and systems in this
area, and providing a restricted group of people with access to
these technologies. One answer to this problem is the creation
of remote access laboratories through a communication
infrastructure provided by Internet and high speed academical
networks such RENATA1 that share and optimize access and
use of robots.
II. REMOTE ACCESS LABS
A remote access lab can be defined as a laboratory that uses
a communications network, where users and lab computers are
geographically separated and telecommunications technologies
are used for accessing to these devices [1][7][8][9]. These
laboratories are systems that share computers, allowing users to
practice through a computer connected to Internet. By using a
web interface, users can change parameters of control and do
internships, and they can watch and download results. These
labs offer access to physical systems, allowing remote
interaction and the execution of tasks that are usually
performed locally through the use of information technologies
and telecommunications. These labs require a permanent
connection between the user and the website (server); they also
have the potential to provide constant access when it is
necessary [1][7][8][9]. So, these labs are not restricted to
synchronized attendance by teachers, students and schedules.
Remote access laboratories are systems based on real
instrumentation laboratory (not simulated practices), which
allow students to practice activities locally or remotely,
transferring information between the process and the student in
a bidirectional way, and offering virtual lab capabilities.
Students use and control all available resources in the
laboratory through workstations in a local network or via
Internet. In general, these labs require specific server
computers that give the machines access to operate remotely.
Another reason that makes remote labs server-dependant is the
user lab management, typically executed by the server.
In recent years, remote labs have had an important impact
on education systems due to the advantages obtained by using
these technologies for supporting and complementing teaching-
learning processes, especially in areas such as engineering
where laboratory activities play a fundamental role
[3][10][11][12][13]. Moreover, remote labs reduce the
classroom practices, generating significant cost decreases. This
type of educational strategy (distance) helps students become
more self-sufficient, which is a very relevant competence in the
formation of an engineer. However, the teacher must
participate directly and actively during the student’s process in
the same way that he/she works in classroom education [14].
1
www.renata.edu.co
 The first Works done under the concept of telerobotics
through internet for industrial manipulator robotics were
projects executed by the University of South California with
the Project Mercury and the Project Telegarden. To access this
robot, the users have to send the movements to the robots by
filling up a HTML form. They select points in images from the
working environment and specify some movements in form of
command files.
One of the most important works in the international
context is the Telerobot from University of Western Australia
(UWA) [1]. This Project allows to teleoperate the arm robot
ABB ARB 1400. To access this telerobot, the users have to
send the required movements by filling up a HTML form. They
select points in images from the working environment and
specify some movements in form of command files. Besides,
there are observer-users that don’t control the robot, but
observe what it does. To control the robot, to control the robot,
the user has to file up an HTML form in a Web server that
receives the request and sends a CGI command (Common
Gateway Interface). One CGI is sent for each request, and some
copies can be simultaneously executed to serve one operator
and many observers. Just one person can control the robot at a
time. The CGI determines if the request has come from an
operator and establishes the communication with the robot
server and the image server.
In the national context, there has been a huge development
in the remote labs, specifically, in Universidad del Valle and
Universidad del Quindío, with the Distributed Laboratory for
Robotics Experimentation [13]. In the same way,
[16][17][18][19], present the development of web based remote
labs in different fields. These developments present huge
advance in this type of labs where the objective is to have
hardware resources for academic and investigative use.
III. REMOTE ACCESS LABORATORY FOR EXPERIMENTATION
WITH THE MITSUBUSHI RV-2AJ MANIPULATOR ROBOT
Our remote access lab consists of a MITSUBUSHI RV-2AJ
manipulator robot, a server, a communication scheme and the
users. Due to the complexity and dynamics of the system, it is
necessary to define a communication infrastructure for the
efficient transmission of information, allowing users to connect
with the robot. Also, this communication infrastructure must
integrate these components to ensure the system’s reliability
and the information transport without interruption between the
users and the robot manipulator. Figure 1 shows the
components and the overall structure of the remote
experimentation system.
A. Communication insfrastructure
The communication infrastructure for the lab has a
client/server architecture that consists of three levels composed
by the robot (robot controller), the users and the server which
acts as an intermediary level (Figure 1). This infrastructure has
three key components for implementing the remote access
laboratory: the robot manipulator controller, the server and the
video server.
1) Mitsubishi RV-2AJ manipulator Robot [22]
The Mitsubishi RV-2AJ Robot is an industrial manipulator
with 5 degrees of freedom and with an anthropomorphic
articulation that offers a load capacity of up to 2 kg. The robot
has a reach of 410 mm and combines a maximum speed of
2.100 mm/s with a repeatability of ± 0.02 mm. This makes the
robot ideal to work in small environments and in academic and
research practices. This robot is equipped with Mitsubishi
CR1-571 controller, which is the interface to the system server.
Figure 1. Communication infrastructure of the remote access lab
2) Robot manipulator controller [22]
The Mitsubishi MELFA CR1-571 controller has a 64-bit
DSP/RISC microprocessor, which allows the execution of 32
programs simultaneously in multitask mode. This controller
communicates with the server through a RS-232 serial link.
The robot controller is the hardware interface between the
server and the robot manipulator. Data transmission between
the manipulator and the server is performed through this
device, allowing the user to send information to the
manipulator and the server, and to receive it from them.
3) Server
Users of the remote lab are managed by the server, which is
a DELL Precision Workstation T3400. This server has a
database that contains the information schema for user
registration and storage of information generated with the
experiments. This server is responsible for managing the
system's resources (data, video, etc.), including client interface.
In addition, the server acts as a middleware level of
architecture that binds the users to the robot and gives them the
ability to monitor and control the robot. This server includes
the web page containing the applet that acts like a graphical
interface, through which users can interact with the robot
manipulator. The servers’ database is built using a MySQL
database manager, and the http request/response is managed by
an Apache web server.
The middleware is based on standard Java Servlets. This
technology is supported by the Tomcat Servlet container and is
accessed via HTTP requests directed to port 8080 in the server.
Servlets use the JDBC API to access the database and they use
Java Communications API to communicate with the server and
the robot controller. This approach guarantees users
transparency and reliability when communicating with the
robot manipulator.
 4) Video Server
For visual feedback, it is used MJPG video stream
generated by Axis 214 PTZ Network Camera that acts as a
video server. This is a color camera for high-level professional
surveillance and remote monitoring. The users and the video
server use Ethernet TCP/IP communication to communicate
through port 80.
B. Software Architecture
The software architecture for remote access lab is based on
a client/server approach. Middleware is the component that
allows the user to connect with the robot manipulator controller
in a transparent way. Figure 2 shows the general structure of
the remote lab. This structure has three key elements for the
implementation of the software architecture: communication
between the robot controller and the server, the server and the
client application. Each of these components is linked by the
communication structure, and through this structure users get
access to the remote lab for experimentation with the robot
manipulator.
Figure 2. Software architecture for remote lab
1) Communication between the controller and the server
Communication between the controller and the server is
done through the RS-232 serial port. The controller and the
server have a port that is in charge of this communication. This
serial communication is performed at a speed of 9600 bps, 8
data bits, 2 parity bits, 2 stop bits and control flow based on
hardware (DTR, RTS/CTS).
The communication protocol used between the controller
and the server was obtained by analyzing the Mitsubishi
software for the control and supervision of their robots. The
goal was to extract and identify this protocol in order to know
how effective the communication was. For this task, the serial
port of the server was monitored to identify the protocol. It was
found that the controller receives a chain of specific characters
to perform various functions on the robot manipulator. This
protocol was sent independently in order to verify that the
driver responded in the same way it does with the
manufacturer's proprietary software. Each command was
checked, obtaining the same answer. This ensured that these
commands can be sent in a separate and distinct way, with the
purpose of creating a library or an API to perform the function
of sending these commands to the server and receiving them
from it in order to be performed in the robot controller.
The API for sending commands to the robot controller and
receiving them from it was built using the Java
Communications API to access the server's serial port. One of
the operations defined in this API is the communication
initialization of the robot controller. Other functions are
moving the robot through its axis or into a coordinate space,
opening and closing the gripper, sending and executing
programs in MELFA IV BASIC language, and monitoring the
position.
2) Server
Data transmission between user and robot controller has
client/server architecture with a servlet-based middleware.
With this structure, the robot can be accessed through the port
8080 of the server, avoiding possible crashes caused by
network firewalls. The server is the software module that
enables users to send information to the manipulator robot
controller and receive information from it. This server is one of
the main components of the remote access lab architecture,
which has the role of an intermediary (middleware) between
the robot controller and the users, giving them the ability to
monitor and control the robot.
The server is responsible for managing the system resources
and modules, such as database, application security through
user connections’ validation approaches and automatic error
control.
Figure 3 presents the architecture of the server; it receives all
HTTP requests sent to the robot from Web browsers. Client
application requests information through HTTP requests to the
server. The requests are received by the server; it assigns the
most appropriate servlet for processing the respective request
(functions, status and files). These servlets answer requests and
send the information to the API SerialCommRV2AJ, which is
responsible for sending the functions to the robot controller
through the serial port. Two special Servlets (practice and
resource) were implemented, which answer requests from the
management interface for the access and control of students to
the remote interface. Also, these servlets validate the
information to access and control practices through the
database; this information is managed in the system
management interface. The server uses the JDBC (Java
Database Connectivity) API for database access.
3) Client application
The client application for the control and supervision of the
robot manipulator is built over Java Applets. Once the user has
access to the system for remote experimentation using a Web
browser, the applet is downloaded (Figure 4). It is displayed
by any web browser supporting Java applications. The user
interface allows operating the robot to move it through their
axes or by using coordinates. It also allows the user to
increase and speed each of these movements. Gripper's control
permits to open or close the gripper.
The client console shows the user the events and actions
generated by the robot. Besides, it provides the user with the
information received from the controller about the current
position of the robot manipulator in relation to its axes and
coordinates. For visual feedback, it was used a MJPG video
stream generated by the Axis Camera. Access to the stream is
done directly from the applet to the server, via an HTTP
request once the application stars. This camera captures
images with resolution of 352x240 pixels, in Motion JPEG
format and a frame rate between 10 and 15 frames per second.
In order to move the robot to a specific position, it was built a
panel for editing the axes and the position in coordinates, and
for placing the robot in the original position.
Figure 3. Architecture of server
Figure 4. GUI Remote access lab
IV. TESTING AND RESULTS
This section presents a summary of the main results of the
tests performed about the remote lab. The mail goal of these
tests is to verify the functionality and behavior of the system.
Tests were performed on the main components of the
laboratory: the robot manipulator controller, the server and the
client application.
A. Communication between robot controller and server
The communication between the robot controller and the
server was evaluated. It was measured the time of transmission
when sending multiple commands over the serial port of the
robot controller, which depend directly on the length of the
command character and the speed of the port (in this case is
9600 bps). Results obtained were between 200 and 400 ms per
command. Table 1 shows an example with the timing of the
commands sent for moving the robot to a position.
TABLE I. RESPONSE TIMES FOR MOVING THE ROBOT TO A POSITION
Command Time(ms)
1;1;RSTALRM 203
1;1;PPOSF 203
1;1;STATE 204
1;1;CNTLON 203
1;1;EXECSPD 200.0 218
1;1;EXECPCOSIROP=(293.17,-
250
278.56,455.57,15.13,110.00,0.00)(6,0)
1;1;EXECMVS PCOSIROP 235
1;1;CNTLOFF 203
Total 1719
The delay generated in the communication between the
robot controller and the server is very high in any request for
moving it because the data transfer rate between them is low
(9600 bps) and it cannot increase. This data transfer rate is a
bottleneck generated by the transmission speed and the
communication protocol established by the manufacturer. This
problem is inherent in the system and it has a direct
relationship with the inertia of the robot manipulator.
B. Load and stress tests of robot server
Most of the performance problems occur only when the
server is attacked by a high load of users. Therefore, it is
necessary to stress tests over the robot server. The goal of these
tests is to determine how many concurrent users can handle the
server without problems.
In the first test performed over the server, it was tested the
access of 20 simultaneous users in one second, repeating this
request 10 times. This test represented 200 users accessing the
server. The test showed that the access mean is small,
indicating that the response times of the server are constant. It
also shows that the value of standard deviation is low;
demonstrating that the response from this server did not present
high variations between one user and another. The report of the
test showed no error in the server performance; so, this can
attend approximately 190 users per second. In the second test,
50 accessing users’ requests were sent simultaneously in 1
second, repeating these requests 10 times. This test represented
500 users accessing to the server. The test report did not show
any error, so it was possible to serve more than 450 users per
second. In this case, the minimum (Min) and maximum (Max)
response time for requests were the order of less than 1 ms and
32 ms respectively. In the last test performed on the server, we
sent 500 users simultaneously accessing in one second,
repeating this request 10 times (5000 users). This test had a
performance of more than 500 users per second with a 2% error
in the server. It showed that when the number of users exceeds
1000, the robot server does not respond, or response time is
very long. This was evidenced by observing the mean and the
standard deviation, which has very high values. Moreover, the
maximum response time (Max) of the requests was near 3
seconds. Figure 5 presents a summary of the testing load and
stress performed over the robot server.
 connection was made using the RENATA academic network
from the University of Valle2 (Colombia). It was noted that the
average delay in this connection was less than the public IP;
also, it was saw a fluctuation in the video transmission between
12 and 15 frames per second. It showed a better system
performance when it was used RENATA academic network.
Finally, tests were performed with remote users located in
Spain, using the CLARA3 academic network (it connects with
the RENATA network through a 45 Mbps channel). The video
reception was constant oscillating between 7 and 10 frames per
second and the average delay was less than 500 ms.

V. ACADEMIC PROPOSAL
The Access remote laboratory for experimentation with the
manipulator robot Mitsubishi RV-2AJ is a tool that supports
Figure 5. Report of results for load and stress tests performed over the server the practical component in manipulator and industrial robotics
C. Temporary delay tests courses, where the students do their practices through this
remote lab. Four remote practices are proposed, which have
This test was performed in order to measure the continuity been developed to complement the theoretical knowledge in
in the video transmission and the behavior of time delay when these types of courses. The main goal is to acquire the
accessing the remote lab from different locations and using necessary competences to control and program the manipulator
different types of connections (academic and commercial robot by solving a problem. In order to do this, the student
networks). Different users (one at a time and at different times) programmes sequences of movements supported by the
were linked to the experimental interface and accessed for MELFA BASIC IV programation language so that the robot
controlling the robot manipulator during 10 minutes performs a specific task. The concepts to manipulator robotics
approximately. During this time we evaluated the rate of are grounded on the direct and inverse kinematics, working
images update for the real video (measured in frames per space, sequential programming of actions, trajectory follow up
second) and temporal delays (maximum, minimum and and sensorial feedback.
average) observed by the user. The results are summarized in
Table 2; it exposes the user's geographical location, the The proposed practices are:
temporal delay, the number of frames per second received in
PRACTICE NUMBER 1: Identification and operation of an
video, the bandwidth of the link and the physical distance
industrial robot manipulator: Robot Mitsubishi RV-2AJ. for
between the user and the robot server.
this practice, the student is supposed to understand the different
types of manipulator robots and clasify them according to their
TABLE II. TEMPORAL DELAY AND VIDEO TRANSMISION morphology. In the same way, they will identify the influence
Temporal Delay (ms) Video Distance Bandwidth of a robot's morphology in the performance of a task. The
Location
Min Max Average (fps) (kms) (Mbps) specific objectives are:
University of
Quindío 1 23 10.15 15 >1 100
Local IP • To get familiar with the Manipulator Robot Mitsubishi
University of
Quindío 15 230 61.07 10 >1 100
RV-2AJ
Public IP
University of 12 to 150 to 10 (RENATA • To know the system connecting the robot
15 78 29.33 Network)
Valle 15 200
Autonomous • To understand and differentiate the robot axes
University of 45 (CLARA
Barcelona Network)
Spain 312 781 455.57 7 to 10 > 10.000 10 • To know and differentiate the Cartesian space of the robot
(CLARA – (RENATA
RENATA Network) • To understand the operation of the robot manipulator of
Network)
University gripper
Castilla la 45 (CLARA
Mancha Network) PRACTICE NUMBER 2. Teleopeation of the manipulator
Ciudad Real 328 719 437.86 8 to 10 > 10.000 10
Spain (CLARA (RENATA robot Mitsubishi RV-2AJ. By moving the robot through its
– RENATA
Network)
Network) axes (direct kinematics) and coordinates (inverse kinematics).
We performed a first test connecting a user with Here, students get to know and analyses the position and
experimentation interface in a computer located within the orientation of a manipulator robot in its working space and
internal network of the university. The access was performed comprehend the direct and inverse cinematic model of
using the public and local IP server. When the public IP was manipulator robot. The objectives are:
used the delay time remained in an average around 60 ms this
value can be explained if it is considered that the information
requests made by the users are captured by the reverse proxy of
2
the University network that links these requests to the video www.univalle.edu.co
server. Video transmission was constant (10 fps). The second 3
www.redclara.net
• To analyses and study the position and orientation of the
manipulator robot in the space.
• To move the manipulator robot through its axes (degrees
of freedom)
• To move the manipulator robot in the Cartesian space
(XYZ).
PRACTICE NUMBER 3: Programming of the manipulator
robot through MELFA-BASIC IV language. In this practice,
students are supposed to understand that, through the
programming of a manipulator robot, they can implement
solutions to problems in their real life environment. The
specific objectives are:
• To design and implement programs for the movement of
the robot with memorized positions.
• To store and send programs to the robot manipulator
controller.
• To design and implement programs pick and place.
A) Results
These practices were developed by undergraduate students
at Universidad del Valle and Universidad del Cauca, in their
respective industrial robotics academic spaces. The experience
presented a first contact among students from different
universities with the remote laboratory. The development of the
practices was successful. There were no problems with the
availability and communication of the remote lab. However,
some aspects need to be taken into account:
• It is necessary to take a first look at the real laboratory so
that the student gets to know the manipulator robot and
identifies its real space and dimentions.
• The lab should have more visual and sensorial
information.
• The lighting and the contrast of the robot with its
environment need to be improved.
VI. CONCLUSIONS AND FURTHER WORK
The remote access laboratory for experimentation with the
Mitsubishi RV-2AJ manipulator robot provides a tool to
support courses about industrial robotics and manipulators; it
provides students, teachers and researchers with an online
access to the Mitsubishi RV-2AJ robot. The synergy of these
tools promotes and facilitates academic and scientific
development in this area, enhancing collaborative work when
community socialize access to shared resources through
communication infrastructures as RENATA network, allowing
the development of cooperation projects between institutions.
The features of Java portability with several tools for the
development of network applications, such applets and servlets,
make it an efficient programming language for the
implementation of interactive web applications. Through the
applets, it is possible to create highly dynamic user interfaces,
able of running in most web browsers. The use of servlets helps
to extend the functionality of the robot server, allowing the
execution of processes within the context of web server; these
processes are capable of handling http requests and returning
data, static files or HTML pages. Servlets can access databases,
perform calculations and communicate with other components.
The combination of applets and servlets permit to build
communication systems of three layers, which allow
connecting clients and application servers running behind
network firewalls. Applets can communicate via HTTP
requests on port 8080 with servlets running on the server side.
The communication infrastructure deployed for the
experimentation interface with the robot manipulator has a
persistent communication link between the users and the robot
controller, avoiding deadlock caused by network firewalls. So,
the robot can be accessed from any internet point. Also, this
architecture can achieve levels of transparency, modularity and
extensibility that facilitate the addition and operation of new
components. The results of the tests on the components of the
remote access lab confirmed that the experimental system can
be available for service in the educational community and it is
useful as a learning tool for courses in robotics.
ACKNOWLEDGMENT
Authors thank COLCIENCIAS and RENATA (Colombia)
for partial funding on this work through the Project entitled
"FRAMEWORK PARA EL DESARROLLO DE
LABORATORIOS DE ACCESO REMOTO SOBRE REDES
DE ALTA VELOCIDAD (RENATA) EN EL ÁREA DE LA
ROBÓTICA", Grant 558-2009 (Call COLCIENCIAS 487 -
RENATA 2009).
REFERENCES
[1] Dalton Barnaby, Techniques for Web Telerobotics. Tesis doctoral,
Department of Mechanical and Materials Engineering University of
Western Australia, Australia 2001.
[2] Meléndez J., Colomer J., De la Rosa, L.L, Fabregat, R. , Macaya D.,
Experiencias en teleoperación de procesos y telenseñanza en la
Universitat de Girona, II Jornadas de Trabajo Enseñanza vía
Internet/Web de la Ingeniería de Sistemas y Automática (EIWISA
2001), Madrid 2001.
[3] Herrera O., Alves G., Fuller D., Alduante R., Remote Lab Experiments:
Opening Possibilities for Distance Learning in Engineering Fields,
Education for the 21st Century-Imact of ICT and Digital Resourses, IFIP
International Federation for Information Processing, SpringerLink 2006.
[4] Rodríguez F., Khamis A., Barber R., Salichs M., A Remote Laboratory
for Teaching Mobile Robotics, IFAC Conference on Telematics
Applications and Robotics, Alemania 2001.
[5] Sánchez L., Rodríguez J., Narváez R., Un laboratorio escolar de robótica
remoto en ambiente colaborativo. Departamento de Ciencias de la
Computación. Universidad Nacional de Comahue 2005, en:
http://colos.fcu.um.es/TICEC05/TICEC05/54_567.pdf. Consultado en
Febrero de 2007.
[6] Organización de las Naciones Unidas para la Educación, la Ciencia y la
Cultura, Informe de la reunión de expertos sobre laboratorios virtuales.
Paris 2000, en:
http://unesdoc.unesco.org/images/0011/001191/119102S.pdf.
Consultado en Febrero de 2008.
[7] Khamis R. Alaa, Interacción Remota con Robots Móviles Basada en
Internet. Tesis Doctoral Universidad Carlos III de Madrid, 2006.
[8] Nuño Ortega E., Basañez Luis, Teleoperación: técnicas, aplicaciones,
entorno sensorial y teleoperación inteligente. Reporte de Trabajo de
Investigación Universidad Politecnica de Cataluña, 2004, en:
http://bibliotecnica.upc.es/reports/ioc/IOC-DT-P-2004-05.pdf.
Consultado en Marzo de 2008.
[9] L. Rosado, J. R. Herreros. Nuevas aportaciones didácticas de los
laboratorios virtuales y remotos en la enseñanza de la Física. IV
Conference m-ICTE2006 will be held in Seville. España, Diciembre
2006.
[10] Masár I., Bischoff A., Gerke M., Remote experimentation in distance
education for control engineers, Proceedings of Virtual University 2004,
Bratislava, Slovakia, Diciembre 2004.
[11] Moreno Ruiz Desire, Internet y Educación, Revista Digital Investigación
y Educación, revista No. 15, Febrero de 2005.
[12] Sánchez José, Candelas Francisco, Recursos Didácticos Basados en
Internet para el Apoyo a la Enseñanza de Materias del Area de
Ingeniería de Sistemas y Automática. Revista Iberoamericana de
Automática e Informática Industrial, Volumen 2, Numero 2, 2005.
[13] Caicedo, Eduardo. Laboratorio Distribuido con acceso remoto para la
enseñanza de la Robótica. Revista en Educación en Ingeniería. ACOFI.
N°. 7, Pag 51-61, Junio de 2009.
[14] Herrera, O.A., Alves, G.R., Fuller, D., Aldimate, R.G. Remote Lab
Experiments Opening Possibilities for Distance Learning in Engineering
Fields. International Federation for Information Processing, Volume
210, Education for the 21st Century-Impact of ICT and EHgital
Resources, eds. D. Kumar, and Turner J., pp. 321-325. Boston, 2006.
[15] Tak-Sum Ho Teresa, System Architecture for Internet-based
Teleoperation System. Tesis Maestría, University of Alberta, Edmonton
Alberta 1999.
[16] H. Barco, P. Arango, E. Restrepo P. Laboratorios Remotos de Física
General. Una Alternativa Para la Enseñanza. MOMENTO. Revista de
F´ısica, No 34, Junio 2007.
[17] Sandoval M. John A., Ramirez S. J. M., Valencia, A. L. DESARROLLO
TECNOLÓGICO DE LOS LABORATORIOS REMOTOS DE
ESTRUCTURAS E INGENIERÍA SÍSMICA Y DINÁMICA
ESTRUCTURAL, Ciencia e Ingeniería Neogranadina, Vol. 18-2, pp. 77-
99. Bogotá, Diciembre 2008. ISSN 0124-8170.
[18] Tovar E. H. et all, LABORATORIOS REMOTOS DE FISICA
BÁSICA. REVISTA COLOMBIANA DE FISICA, VOL. 35, No.1.
2003.
[19] AEDO C. J. E., ALVAREZ, M., GIRALDO A. H., "Implementación de
una tecnología para la construcción de laboratorios remotos para la
enseñanza de la electrónica usando Internet" En: España. 2002. Evento:
6 Congreso Iberoamericano de Informática Educativa Ponencia: 4
Simposio Internacional Informática Educativa, Universidad De Vigo,
p.79 – 87.
[20] Brady K., Tarn T. J., Internet-Based Remote Teleoperation, Proceedings
of the 1998 IEEE, International Conference on Robotics and
Automation, May 1998.
[21] Fung W. K., Xi N., Lo W. T., Liu Y. H., Adaptive real-time Internet-
based teleoperation systems for efficiency improvement using network
QoS, Proceedings of the 2003 IEEE/ASME International Conference on
Advanced Intelligent Mechatronics, 2003.
[22] RV-1A/RV-2AJ Series. Standard Specifications Manual. Mitsubushi
Industrial Robot.

View publication stats