A Web Lab For Mobile Robotics Education
A Web Lab For Mobile Robotics Education
1
Robotics and Automation
Roma, Italy, 10-14 April 2007
Abstract— This paper presents an architecture for the Web services technology and a Web Lab in mobile
building remote access laboratories (or Web Labs) robotics built according to the architecture are presented
following the service-oriented computing approach. In as well. The paper is organized as follows. Section II
this architecture the application’s building blocks are
services that can be recursively composed resulting in presents some related work; Section III presents a service-
more comprehensive services. Remote access labora- oriented architecture for Web Labs; Section IV provides
tories can benefit of this approach. Every lab resource an implementation of this architecture; Section V de-
(physical or logical) is modeled and implemented as a scribes a Web Lab in mobile robotics developed according
service (in our case, a Web service) and lab exper- to the implemented architecture; and Section VI closes
iments are assembled by composing these services.
A Web Lab built according to this architecture is the paper with conclusions and future work.
presented with examples of remote experiments in the
field of mobile robotics. II. Related Work
I. Introduction Web Labs were initially developed with well known
Remote Access Laboratories or Web Labs have been Web technologies, such as Java applets on the client
proposed as powerful tools for the sharing of expen- side [3] and server-side extensions based on CGI (Com-
sive equipment and for bringing experimentation into mon Gateway Interface), ASP (Active Server Pages),
distance learning. The challenge regarding Web Labs or JSP (Java Server Pages) [4][5]. Distributed objects
implementations is to provide an infrastructure where approaches based on Java RMI (Remote Method Invo-
remote experiments are easily assembled and modified. cation) and CORBA (Common Object Request Broker
Architecture) were proposed as well [6]. Other implemen-
This paper proposes a service-oriented computing ap-
tations require platform dependent software in the client
proach for building Web Labs. Considered as an evo-
terminal [7]. All of these approaches have in common
lution of distributed computing, service-oriented com-
the limited software reuse, customization, and interoper-
puting is defined as ”the approach that uses services as
ability. These limitations are due to the low granularity
fundamental elements in application development” [1].
of software artifacts and the adoption of interaction
Using composition mechanisms (or orchestration), more
protocols that are usually blocked by network firewalls.
comprehensive services can be built from existing ones.
Since the composed service is itself a service, it can take More recently, Web Lab architectures based on soft-
part in further compositions [2]. ware components were proposed [8]. Although com-
Implementing Web Labs according to service-oriented ponents increase software reuse and customization,
computing brings some remarkable benefits. Firstly, lab component-based architectures still lack interoperability
resources (physical and logical) are modeled and im- among different platforms and administrative domains.
plemented as services, for instance, a robot exports a Architectures based on Web services are an attempt to
set of services, each one performing an specific function build Web Labs that fulfill the requirements of software
(sensing, navigation, and so on). Secondly, experiments reuse, customization, and interoperability [9][10].
can be synthesized as a composition of services. In this The related work closer to the described in this pa-
way, new experiments may use existing ones as units per is the iLAB project [11]. iLAB identifies a set of
of composition, and the updating of an experiment is administrative functionalities such as user subscription,
restricted to its composition’s logic. Finally, the concept authorization and authentication, group management,
of federation of services allows Web Labs to use resources and access control. Such tasks are common to all Web
maintained by other Web Labs located in different ad- Labs and are decoupled from the domain specific func-
ministrative domains. tionalities the Web Labs support. The administrative
This paper describes an architecture based on compo- tasks are managed by a Service Broker that mediates the
sition and federation of services for building Web Labs. access to the associated Web Labs. The Service Broker
A complete implementation of this architecture using supports in some way the federated operation of Web
Labs. The architecture proposed in this paper shares
1 State University of Campinas, Campinas-SP, Brazil; some similarities with iLAB, for instance:
2 Renato Archer Research Center, Campinas-SP, Brazil;
3 Federal University of Uberlândia, Uberlândia-MG, Brazil • decoupling between use and management of Web
[email protected] Labs;
• use of Web services for management and access to Notice that credentials and sessions refer to a specific
Web Labs; participant accessing a specific Web Lab. Examples of
• federated operation of Web Labs. credentials include the user’s identification, roles (e.g.,
iLAB makes no restriction about the implementation student, instructor), permissions (e.g., usage, manage-
of the Web Labs, except the interfaces for attaching to ment), and privileges (e.g., group leader).
the Service Broker. Sessions are responsible for managing the interaction
The architecture proposed in this paper differs from between a participant and a Web Lab. Sessions maintain
iLAB in three important aspects: state information related to the interaction such as the
1) the scope of the federation of Web Labs is enlarged identification of the participant, the remaining access
by allowing Web Labs to share resources (not only time, and the actions the participant has performed.
subscribed users); Web Labs publish the services they offer. Services are
2) instead of rely on a centralized access control (Ser- units of composition on interaction with the Web Lab
vice Broker), each federated Web Lab sets its own employed for purposes such as access, interaction, com-
access policies; munication, and management. Experiments offered by
3) the federation imposes that each federated Web Web Labs are modeled as a composition of services. For
Lab must implement a minimum security infras- instance, an experiment in environmental mapping can
tructure. compose a service of locomotion (e.g., random walk) with
Composition plays a key role in this proposed archi- a service of telemetry (e.g., sonar readings). A Web Lab
tecture for Web Labs. Intra-domain composition allows maintains a set of Resources, both physical such as robots
a Web Lab to combine its resources within experiments. and cameras, and logical such as robot simulators and
Inter-domain composition allows a Web Lab to combine navigation maps. Resources are manipulated remotely
its own resources with resources offered by other Web through services. A Web Lab has a self-relationship
Labs. Inter-domain composition enlarges the range of that models a federation of Web Labs. The model does
experiments a Web Lab can offer and constitutes the not impose a particular mechanism for building such a
truly motivation for a federated operation of Web Labs. federation.
The architecture also gives each Web Lab the freedom
Resource Service
to set its owns access rules. Policies is a flexible way to manipulates
set the condition upon which users can access the Web composes
Lab. For instance, a policy must require that foreign publish
maintains
users be authenticated, present credentials issued by the Web Lab Experiment
offers
Web Lab he/she was subscribed, and has a time slot
already reserved to perform experiments. The flexibility federates
1382
Authorized licensed use limited to: ULAKBIM UASL - Erciyes Universitesi. Downloaded on January 04,2023 at 14:44:19 UTC from IEEE Xplore. Restrictions apply.
WeE2.1
1383
Authorized licensed use limited to: ULAKBIM UASL - Erciyes Universitesi. Downloaded on January 04,2023 at 14:44:19 UTC from IEEE Xplore. Restrictions apply.
WeE2.1
If a producer states a lifetime for a submitted XML dual-Xeon processors running the GNU/Linux operat-
document, the document persists on the service during ing system. The infrastructure is complemented by the
this lifetime, otherwise, the service discards the docu- robots’ application programming interface (API).
ment after it was delivered. The kind of information Figure 3 illustrates the infrastructure components and
present in these documents can serve several purposes, the interaction protocols on the server side. The compo-
for instance, notification (e.g., alarms); configuration nents on the client side consist of common Web browsers,
(e.g., formats and sizes of audio and video); user gener- Java clients (Java processes that run on the client
ated information (e.g., chat messages); synchronization desktop) loaded from the Java Web Start application
messages (e.g., whiteboard updates); and logging infor- launcher, and MPEG-4 media players such as MPlayer
mation (e.g., session-related data). or Windows Media Player. Java clients discover Web
A media streaming service was implemented above the services by querying the UDDI service and invoke them
diffusion service. Media producers publish their capa- through the SOAP (Simple Object Access Protocol)
bilities, media ports, and negotiation interfaces. Media protocol.
consumers access these informations and, if the case, Client Side
negotiate a proper media quality and format through the HTTP JSP/Servlet
producer’s negotiation interface. The media flow is not Web Browser Container Framegrabber
(Tomcat)
transferred through the diffusion service.
SOAP JPEG
Other Web Lab implementations may choose different
SOAP
approaches for supporting communication. Both com- Java Client
Web Services Robot API
Container
mercial and open source products supporting media (Axis)
(Java)
implemented.
Fig. 3. GigaBOT Web Lab Infrastructure.
V. GigaBOT Web Lab
GigaBOT is a Web Lab for mobile robotics education B. Interaction Services
implemented following the architecture described above.
Interaction services are services supporting the inter-
Being domain independent, access and communication
action with the Web Lab domain-specific resources. The
services don’t need any adaptation to the mobile robotics
GigaBOT Web Lab provides six interaction services: lo-
domain. The interaction services, otherwise, have been
comotion, telemetry, vision, panoramic camera, actions,
developed for this specific domain and will be described
and code submission services.
next.
The locomotion service exports operations for moving
and turning the robot to a relative or absolute position
A. Lab Infrastructure
and for adjusting and limiting the speed and acceleration
The GigaBOT Web Lab operates two ActivMedia’s of the robot. Operations supporting robot locomotion
Pioneer P3-DX robots with sixteen sonars and protection can be synchronous (blocking while the movement com-
bumpers. One robot is fitted with on-board processor, pletes) or asynchronous.
wireless network interface (802.11g), and a Canon VC- The telemetry service allows the obtaining of telemetry
C4 on-board camera with PTZ (pan/tilt/zoom) and con- data such as current robot position, sonars readings,
nected to framegrabber. The second robot does not have robot physical dimensions, and voltage supplied by the
on-board processor, being controlled via serial port by an battery.
HP IPaq H5555 handheld with 802.11b wireless network. The vision service allows to control the robot’s on-
The handheld runs the Familiar Linux v0.8.1 operating board camera. The control parameters includes the ab-
system. This robot is fitted with an Axis 206W wireless solute and relative values of pan (horizontal movement),
network camera. An Axis 213 PTZ network camera is tilt (vertical movement), zoom, and focus. The service
available to allow a panoramic view of the execution of also allows the capture of a static image in JPEG format.
experiments. The panoramic camera service provides access to the
The software infrastructure at the lab’s side is com- Axis 213 PTZ resource. The service supports the same
posed of a Web service container (Apache Axis Java), operations as the vision service plus operations for video
a JSP/Servlet container (Apache Tomcat), a UDDI recording.
(Universal Description Discovery Integration) server The action service wraps some of the built-in robot
(jUDDI), and a relational database (MySQL). Axis, actions into Web services. An action establishes a set of
Tomcat, and jUDDI are supplied by the Apache Software basic operations which, together, perform a specific task.
Foundation [14]. Containers and databases execute on a Each action added to the robot is inserted into a queue
1384
Authorized licensed use limited to: ULAKBIM UASL - Erciyes Universitesi. Downloaded on January 04,2023 at 14:44:19 UTC from IEEE Xplore. Restrictions apply.
WeE2.1
with a given priority. Actions are performed in a sequence from the robot, and the already detected obstacles; and
given by their priorities. Nine actions are available: six a tabbed panel for navigation (bottom right).
related to prevention and recover from collisions (e.g.,
moving with frontal and lateral obstacle avoidance), and
three actions related to locomotion (e.g., moving the
robot to a giving point).
Finally, the code submission service allows users to
submit and execute C++, Java, or Python code on a
server connected to the robot. The submitted code must
control the robot by calling the methods supplied in the
robot’s application programming interface (API). This
service also provides methods for controlling the execu-
tion of the submitted program, for instance, retrieving its
process identifier (pid) and standard output printouts,
and controlling its state of execution (suspend, resume,
kill).
C. Lab Experiments
The experiments provided by the GigaBOT Web Lab
are programmed using the composition of the interaction,
access, and communication services. The level of diffi-
Fig. 4. Interface for the basic telemetry experiments.
culty of a proposed experiment can vary from the entire
coding of a robot navigation algorithm to the adjusting of Experiments are built by composing the six interactive
parameters of a supplied algorithm. Intermediate levels services. The composition logic can be coded in general
include the coding of a new action. An experiment can purpose programming languages such as Java or C++,
be executed on the user’s computer or on a server located or expressed in specialized composition languages such
at the Web Lab and connected to the robot. as BPEL (Business Process Execution Language) [15].
Six experiment classes were developed for the Web BPEL allows the specification of workflows of service
Lab: calls in XML. The advantage of BPEL is the availability
1) Basic Telemetry: experiments that allow to control of sophisticated engines supporting graphical edition as
the robot as well as to inspect the sonar readings. well as execution and debugging of BPEL scripts.
Control can be performed As an example of composition with BPEL consider an
• by issuing basic commands (move and turn) via experiment in the Vision-based Navigation class where
a graphical user interface; the robot must follow a colored strip on the floor using
• by drawing a route with the mouse on a navi- solely its on-board camera. This experiment composes
gation map; the vision, motion, and communication services with
• by combining a set of pre-programmed actions a image processing algorithm written using the Java
(e.g., random walking with obstacle avoid- Advanced Imaging (JAI) system [16]. Figure 5 illustrates
ance). the interface of this experiment. The image on the left
2) Navigation on Structured Environments: experi- shows the image captured from the on-board camera
ments that allow the mapping of the robot’s en- (highlighted in black). The image on the center shows
vironment and navigation based on environmental the detected borders of the strip, and the image on
maps. the right shows the trajectory computed from the other
3) Navigation on Non Structured Environments: ex- two images. The interface allows the user to adjust the
periments that allow navigation and environmental maximum speed in which the robot follows the strip
mapping simultaneously. as well as some parameters of the image processing
4) Vision-based Navigation: experiments that allow algorithm. A movie of the experiment is recorded from
navigation using the robot’s vision system. the panoramic camera.
5) Code Submission: allows the user to write naviga- The composition logic employs a cycle with the follow-
tion code and submit it directly to the robot. ing steps:
6) Cooperative Robotics: experiments employing two 1) invoke the communication service to start the
robots developing cooperative tasks. movie recording from the panoramic camera;
Figure 4 shows the interface for the Basic Telemetry 2) invoke the vision service to acquire an image from
experiments. The interface consists of two panels with the robot’s on-board camera;
images from the on-board and panoramic cameras (left); 3) invoke the image processing algorithm to identify
a navigation map (top right) with the actual robot po- the strip. If no strip is identified do: (i) invoke the
sition, the sonar readings represented as lines emanating locomotion service to stop the robot; (ii) invoke the
1385
Authorized licensed use limited to: ULAKBIM UASL - Erciyes Universitesi. Downloaded on January 04,2023 at 14:44:19 UTC from IEEE Xplore. Restrictions apply.
WeE2.1
1386
Authorized licensed use limited to: ULAKBIM UASL - Erciyes Universitesi. Downloaded on January 04,2023 at 14:44:19 UTC from IEEE Xplore. Restrictions apply.