UNIVERSITY OF CINCINNATI _____________ , 20 _____ I,______________________________________________, hereby submit this as part of the requirements for the degree of: ________________________________________________ in: ________________________________________________ It is entitled: ________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________ Approved by: ________________________ ________________________ ________________________ ________________________ ________________________
Transcript
UNIVERSITY OF CINCINNATI
_____________ , 20 _____
I,______________________________________________,hereby submit this as part of the requirements for thedegree of:
In the Department of Mechanical, Industrial and Nuclear Engineering
Of the College of Engineering
2000
by
Meyyapa Ganesh Murugappan
B.E (Mechanical Engineering), College of Engineering, Guindy,
Anna University, Chennai
India, 1999
Thesis Advisor and Committee Chair: Dr. Ernest L. Hall
1
Abstract Obstacle avoidance is an important feature of any autonomous vehicle. This work
is about building an online database system to handle various types of obstacles presented
in the annual International Ground Robotics Competition. The system is designed for the
mobile robot Bearcat II. A reliable database system for all types of obstacles and
solutions to avoid is built. Further to maintain the database system in today�s electronic
age, it has been integrated to have web access.
The various types of obstacles presented in the previous year contest are studied
and an algorithm to avoid them is worked out. The solutions are entered into the database
system. A web server to maintain the database system developed is implemented. It is
designed to update the system for new types of obstacle to be presented in future. To
maintain the system over web, XML (eXtensible Markup Language) standards for the
data are established. The presentation will be put up on the XSL (eXtensible Stylesheet
Language). A portable server side dynamic web content of the database system is
provided with the development of java servlets. Servlets being portable to any platform, it
will be put up on the robotics sun web server.
The Online Obstacle Avoidance System will be a great tool for the robot team as
new team members can take over the work instead of starting from scratch. It will reduce
the time involved in designing solutions for new problems to be presented in the future.
This system could be of great use in designing the robot during the final design phase of
the contest.
2
3
Acknowledgments
I am grateful to my advisor Dr. Ernest Hall who gave me his valuable suggestions
and motivation to make my thesis a success. He helped and encouraged me from all
perspectives to complete this work.
I am thankful for the robotics team members with whom I worked during my
study at University of Cincinnati. It brought a teamwork culture in me. The robot team is
the inspiration for my thesis work.
I wish to thank my committee members Dr. Richard L. Shell and Dr. Ronald L.
Huston for supporting my work.
Last but not least my parents and family should be thanked. They stand behind all
my success.
4
Table of Contents
Chapter 1 Introduction
1.1 Objective 10
1.2 Organization of Thesis 11
Chapter 2 Vision System
2.1 Calibration 13
2.2 Line-Following 13
2.3 Obstacle Avoidance Sonar System 14
2.4 Laser Sensors 14
Chapter 3 Obstacles Posed
3.1 Bucket 16
3.2 Barrel 18
3.3 Ramp 19
3.4 Pothole 20
Chapter 4 Database
4.1 Why Database 22
4.2 Relational Database 22
4.3 Advantages of Relational Database 22
4.4 Database Design 23
5
4.5 Obstacle Avoidance Database 24
Chapter 5 Web Technologies
5.1 Static Web Page 26
5.2 Dynamic Web Page 26
5.3 Java Servlets 27
5.3.1 Examples 28
5.4 Servlet Architecture Overview 29
5.5 Servlet Lifecycle 30
Chapter 6 Markup Languages
6.1 XML 34
6.2 Three-Tiered Architecture 37
6.3 HTML Display of XML 38
Chapter 7 Obstacle Avoidance Online System
7.1 Web Interface Design 40
Chapter 8 Conclusions and Recommendations
8.1 Conclusions and Recommendations 42
6
Appendix A
Programs Related to the Online Obstacle Avoidance System 44
7
List of Figures
Chapter 1
1.1 Bearcat I mobile robot 9
1.2 Bearcat II mobile robot 10
Chapter 2
2.1 Line Following Movie 14
2.2 Turning a Curve Movie 14
Chapter 3
3.1 Robot facing an Obstacle 16
3.2 Bucket on Left side of track 17
3.3 Bucket on Right side of track 17
3.4 Bucket Obstacle 17
3.5 Barrels on Left side of track 18
3.6 Barrels on Right side of track 18
3.7 Barrel Obstacle 19
3.8 Ramp Obstacle 19
3.9 Pothole on Left side of track 20
3.10 Pothole on Right side of track 20
3.11 Pothole Obstacle 21
Chapter 4
4.1 Database Design 23
4.2 Obstacle Description Table 24
4.3 Obstacle Navigation Table 24
8
Chapter 5
5.1 Static Web Page 26
5.2 Dynamic Web Page 27
5.3 Java Servlets 27
5.4 Servlet Input Output 30
5.5 Servlet Methods 31
5.6 Servlet Life Cycle diagram 32
Chapter 6
6.1 XML Example Structure 35
6.2 Three-Tiered Architecture 37
6.3 XSLT Process 38
Chapter 7
7.1 Online Obstacle Avoidance Architecture 39
7.2 Obstacle Avoidance Welcome Page 40
7.3 Obstacle Avoidance Servlet 41
9
Chapter 1
Introduction
The Center for Robotics Research at University of Cincinnati has been a
participant at Intelligent Ground Vehicle Competition for last nine years. Ever year new
contest rules are established to promote research at International level in designing
unmanned vehicle. The Bearcat robot of University of Cincinnati�s Robotics team has
undergone two major versions till now. The Bearcat I was designed with a width of 4 feet
and length of 6 feet. It weighed about 600 pounds. To adapt to the new rules of the
contest the robot is re-designed in 1998. As per the new rule the track width is reduced to
10 feet. The Bearcat II robot is much more compact and rigid. It weighs 450 lbs. and is 2
feet wide and 4 feet long.
Fig 1.1: Bearcat I mobile robot
10
Every year new problems are presented and several teams working on different
parts of the world are coming up with their own solution. I believe knowledge transfer is
essential as starting from scratch in any field won�t be a good solution. To achieve the
knowledge transfer a database system is a good solution. In this database system the
various types of obstacles presented in past and solution to navigate around it are
documented.
1.1 Objective
Objective of my work is to build an online obstacle avoidance system. The system
will help in documenting all the obstacles, which our robot has encountered in the past
Fig 1.2: Bearcat II mobile robot
11
and how it successfully navigated it. To make it available any time to the team members
it is given a web interface using the latest technologies. It will be an useful tool while it is
time to work on new obstacle avoidance problems to be faced in future.
1.2 Organization of Thesis
The thesis is organized into several chapters to document the ideas and
technologies used.
Chapter 2 is about the existing vision system and what is expected from the
bearcat robot vision system in the future. Chapter 3 is discusses various types of obstacles
faced by our robot in the past and how it overcame it. Chapter 4 describes the relational
database being built for the obstacle avoidance system. Chapter 5 deals with the platform
independent Java servlet technology. Chapter 6 is about the XML standards adopted. The
web interface for system is explained in Chapter 7 and future recommendations are given
at Chapter 8.
12
Chapter 2
Vision System
David Marr�s work at MIT�s[1] Artificial Intelligence Laboratory on artificial
vision for robots revealed how robot vision system is to be designed. He is an expert on
the human visual system and his goal was to learn why the initial attempts to construct a
robot capable of understanding its surroundings were unsuccessful [1].
Marr believed that it was important to establish scientific foundations for vision,
and that while doing so, one must limit the scope of investigation by excluding
everything that depends on training, culture, and so on, and focus on the mechanical or
involuntary aspects of vision. This low-level vision is the part that enables us to recreate
the three-dimensional organization of the physical world around us from the excitations
that stimulate the retina. Marr asked the questions:
��How is it possible to define the contours of objects from the variations of
their light intensity?
��How is it possible to sense depth?
��How is movement sensed?
He then developed working algorithmic solutions to answer each of these
questions.
Marr's theory was that image processing in the human visual system has a
complicated hierarchical structure that involves several layers of processing. At each
processing level, the retinal system provides a visual representation that scales
13
progressively in a geometrical manner. His arguments hinged on the detection of
intensity changes. He theorized that intensity changes occur at different scales in an
image, so that their optimal detection requires the use of operators of different sizes. He
also theorized that sudden intensity changes produce a peak or trough in the first
derivative of the image. These two hypotheses require that a vision filter have two
characteristics: it should be a differential operator, and it should be capable of being
tuned to act at any desired scale.
2.1 Calibration
Vision systems for robots consists of two components one an optical system to
collect and focus the light from a finite field view and an optoelectrical system to take
focused light and give a computer readable signal [2].
The reduction of the three-dimensional position of a point to its two-dimensional
projection by the vision camera is the basic problem with the use of vision system with
robots. This mapping of the two-dimensional points and reorganization of the three-
dimensional image is done by the vision calibration [7].
2.2 Line-Following
The robot has to follow a track of 10 feet width with two lines on either side of it.
With the camera calibration our robot will be able to follow the line. It tracks either one
of the lines and makes its navigation parallel to that line. If there is a break in that line, it
searches for the line on the other camera. Once it catches that line the robot navigates
itself parallel to that line.
14
2.3 Obstacle Avoidance Sonar System
The rotating sonar mounted in front of the robot senses the obstacle. With the
width of space occupied by the obstacle and distance from where robot sensed the
obstacle is navigated around.
2.4 Laser Sensors
At present our bearcat robot obstacle avoidance is based on the rotating sonar
system. The best approach would be to adapt to the laser sensor to avoid obstacles. We
are experimenting with the sick optics laser sensors.
Fig 2.1: Robot Line Following Movie
Fig 2.2: Robot Navigating around a Curve Movie
15
With laser beam the width of the light sent out to sense can be much narrow than
the sound from sonar. The velocity of laser beam will be also faster than the sound wave
of sonar.
16
Chapter 3
Obstacles Posed
Several obstacles are posed at the International Ground Robotics Competition.
The major obstacles to navigate around are
��Bucket
��Barrel
��Ramp
��Pothole
The algorithm proposed is to make the robot go along the middle of the remaining
space when there is an obstacle present. Considering the obstacle is detected within a
distance d and detecting the obstacle width to be w. The robot is made to navigate around
that obstacle so that it will follow the central line of the remaining space in the course.
3.1 Bucket
Bucket is a ten-gallon bucket in white color. It can be placed on either side of the
line. Its width is about 1 foot.
w
d
Fig 3.1: Robot facing an Obstacle
17
w
d
w
d
Bucket
Right side of the track
Left side of track
Fig 3.2: Bucket on Left side of track
Fig 3.3: Bucket on Right side of track
Fig 3.4: Bucket Obstacle
18
3.2 Barrel
The Barrel has red and white strips on it. In the contest it can be placed on either
side of the track. In the course it can also be placed several in a row.
w
d
w
d
Fig 3.5: Barrels on Left side of track
Fig 3.6: Barrels on Right side of track
19
3.3 Ramp
Ramp is another obstacle, which has an elevation of 15 degrees. For the ramp the
robot speed have to be reduced to give more torque to go past the ramp.
Ramp
Fig 3.7: Barrels Obstacle
Fig 3.8: Ramp Obstacle
Left side of the track
Right side of the track
Center of the track Barrel
Right side of the track- 3 Barrel
Left side of the track- 3 Barrel
20
In consideration with the ramp the robot design calculations are made. It is
ensured to have sufficient torque to over come even a ramp of about 30 degrees elevation.
3.4 Pothole
The new obstacle introduced is a simulated pothole. If the pothole is a real
pothole, the laser optic sensor could be used to locate the pothole with the depression.
w
d
w
d
Fig 3.9: Pothole on Left side of track
Fig 3.10: Pothole on Right side of track
21
Pothole
Right side of the track
Left side of track
Fig 3.11: Pothole Obstacle
22
Chapter 4
Database
A database is a self-describing collection of integrated records[4]. Here the
structure of the database is stored in itself. In the database system on opposed to tradition
file management system the data items are integrated by the database system itself.
4.1 Why Database
A database is a fundamental key in knowledge transfer. It is a repository of the
data. For us to improve the way of life, the knowledge gained by the experience should
be transferred to the next generation to have better way of life. In any practical
application database will organize data neatly and provide better form of data
management.
4.2 Relation Database
E. F. Codd in 1969, then a researcher at IBM, conceived the relational database
model. The model is based on branches of mathematics called set theory and predicate
logic. The basic idea behind the relational model is that a database consists of a series of
unordered tables (or relations) that can be manipulated using non-procedural operations
that return tables [4]. This model was in vast contrast to the more traditional database
theories of the time that were much more complicated, less flexible and dependent on the
physical storage methods of the data.
4.3 Advantages of Relational Database
The advantages of a relational database are numerous. Some of them are as
follows
��Data entry, updates and deletions will be efficient.
23
��Data retrieval, summarization and reporting will also be efficient.
��Being well-formulated database, its behavior is predictable
��It is self-documenting.
��Changes to the database schema are easy to make.
4.4 Database Design
An Information system design involves lot of steps in it. First the requirements
analysis is carried out with methodologies like Critical Success Factor Analysis, Decision
Analysis. From that point on the design branches out into two phase namely database
design and systems design.
In database design Conceptual design is carried out with doing Entity
Relationship Diagram (ERD). Conceptual design is followed by logical design where the
database will be done normalized into tables. Final phase is the physical design where the
tables are populated with data.
Fig 4.1: Database Design[3]
24
4.5 Obstacle Avoidance Database
In the database designed for the obstacle avoidance systems the physical features
of the obstacles are documented in a table as ObsDescription and the navigation to be
made for each type of obstacle is documented into another table.
ObstacleID Description Shape Color OB01 Bucket on left track edge Cylindrical White OB02 Bucket on right edge Cylindrical White OB03 Single Trafiic Barrel on the lefttrack edge Cylindrical Red&WhiteOB04 Single Trafiic Barrel on right of track Cylindrical Red&WhiteOB05 Single Trafiic Barrel on center of track Cylinders in a row Red&WhiteOB06 Traffic Barrels in Series close to the left track Cylinders in a row Red&WhiteOB07 Traffic Barrels in Series close to the right track Cylinders in a row Red&WhiteOB08 Ramp Square Projection Grey OB09 Pothole on left track edge Ellleptical Projection White/BlackOB10 Pothole on right track edge Ellleptical Projection White/Black
ObstacleID Description Type Width NavAngle3fts NavTime3fts NavAngle1ft NavTime1ftOB01 Bucket on
the left track edge
Bucket 1 9.5 towards right & back
2.28 sec 26.5 towards right & back
.84 sec
OB02 Bucket on the right track edge
Bucket 1 9.5 towards left & back
2.28 sec 26.5 towards left & back
.84 sec
OB03 Single Trafiic Barrel on the left track edge
Barrel 2 18.4 towards right & back
2.37 sec 45 towards right & back
1.06 sec
OB04 Single Trafiic Barrel on the right track edge
Barrel 2 18.4 towards left & back
2.37 sec 45 towards left & back
1.06 sec
OB05 Single Trafiic Barrel on center of track
Barrel 2 45 towards right/left & back
3.18 sec 71.5 towards right/left & back
2.37 sec
OB06 Traffic Barrels in
Barrel 6 45 towards right & back
3.18 sec 71.5 towards right & back
2.37 sec
Fig 4.2: Obstacle Description Table
25
ObstacleID Description Type Width NavAngle3fts NavTime3fts NavAngle1ft NavTime1ftSeries close to the left track
OB07 Traffic Barrels in Series close to the right track
Barrel 6 45 towards left & back
3.18 sec 71.5 towards left & back
2.37 sec
OB08 Ramp Ramp 10 No turn 0 sec No turn 0 sec OB09 Pothole on
the left track edge
Pothole 2 18.4 towards right & back
2.37 sec 45 towards right & back
1.06 sec
OB10 Pothole on the right track edge
Pothole 2 18.4 towards left & back
2.37 sec 45 towards right & back
1.06 sec
Fig 4.3: Obstacle Navigation Table
26
Chapter 5
Web Technologies
5.1 Static Web Page
When a client browser requests a web page, the web server resolves the request
being sent in and tries to get the requested page from the server and sends back the file
content to the client browser. This is a static web page architecture. When all pages on
the website are built with static web pages then there will be lot of files to be maintained
and further the dynamic nature can�t be brought out[3].
5.2 Dynamic Web Page
To provide state of art information from the backend database, a dynamic web
page is essential. When the client browser requests a web page, the web server resolves
the request [3]. It executes the complied code on the server, which retrieves data from the
backend database and provides current data on the web from the database. The dynamic
web page is generated here with java servlets with XML standards to the data.
Client Server
HTTP Request
HTML Response
Fig 5.1: Static Web Page
27
5.3 Java Servlets
Servlets are modules that run inside request/response-oriented servers, such as
Java-enabled web servers, and extend them in some manner[5]. For example, a servlet
might be responsible for taking data in an HTML order-entry form and applying the
business logic used to update a company's order database. Servlets are to servers what
applets are to browsers.
The Servlet API, which we use to write servlets, assumes nothing about how a
servlet is loaded, the server environment in which the servlet runs, or the protocol used to
Request object
Client-Browser
Server-Servlets Database-
Access
Client Server
HTTP Request
HTML Response
RDBMS
SQL Request
SQLResult Response
Fig 5.2: Dynamic Web Page
Fig 5.3: Java Servlets
28
transmit data to and from the user. This allows servlets to be embedded in many different
web servers.
Servlets are an effective substitute for CGI scripts. They provide a way to
generate dynamic documents that is both easier to write and faster to run. They also
address the problem of doing server-side programming with platform-specific APIs.
Servlets are developed with the Java Servlet API, a standard Java extension. While it is
not part of the core Java framework, which must always be part of all products bearing
the Java brand, it will be made available with such products by their vendors as an add-on
package. Many popular web servers support it.
5.3.1 Example Uses
A few of the many applications for servlets include,
��Processing data POSTed over HTTPS using an HTML form, including
purchase order or credit card data. A servlet like this could be part of an
order-entry and processing system, working with product and inventory
databases, and perhaps an on-line payment system.
��Allowing collaboration between people. A servlet can handle multiple
requests concurrently; they can synchronize requests to support systems
such as on-line conferencing.
��Forwarding requests. Servlets can forward requests to other servers and
servlets. This allows them to be used to balance load among several
servers that mirror the same content. It also allows them to be used to
29
partition a single logical service over several servers, according to task
type or organizational boundaries.
��Being a community of active agents. A servlet writer could define active
agents that share work among each other. Each agent would be a servlet,
and the agents could pass data among themselves.
5.4 Servlet Architecture Overview
The central abstraction in the Servlet API is the Servlet interface. All servlets
implement this interface, either directly or, more commonly, by extending a class that
implements it such as HttpServlet. The Servlet interface provides for methods that
manage the servlet and its communications with clients. Servlet writers provide some or
all of these methods when developing a servlet.
When a servlet accepts a call from a client, it receives two objects: one is a
ServletRequest and the other is a ServletResponse. The ServletRequest class encapsulates
the communication from the client to the server, while the ServletResponse class
encapsulates the communication from the servlet back to the client.
The ServletRequest interface allows the servlet access to information such as the
names of the parameters passed in by the client, the protocol (scheme) being used by the
client, and the names of the remote host that made the request and the server that received
it. It also provides the servlet with access to the input stream, ServletInputStream,
through which the servlet gets data from clients that are using application protocols such
as the HTTP POST and PUT methods. Subclasses of ServletRequest allow the servlet to
30
retrieve more protocol-specific data. For example, HttpServletRequest contains methods
for accessing HTTP-specific header information.
The ServletResponse interface gives the servlet methods for replying to the client.
It allows the servlet to set the content length and mime type of the reply, and provides an
output stream, ServletOutputStream, and a Writer through which the servlet can send the
reply data. Subclasses of ServletResponse give the servlet more protocol-specific
capabilities. For example, HttpServletResponse contains methods that allow the servlet to
manipulate HTTP-specific header information.
The classes and interfaces described above make up a basic Servlet. HTTP
servlets have some additional objects that provide session-tracking capabilities. The
servlet writer can use these APIs to maintain state between the servlet and the client that
persists across multiple connections during some time period.
5.5 Servlet Lifecycle
Servers load and run servlets, which then accept zero or more requests from
clients and return data to them[6]. They can also remove servlets. These are the steps of a
servlets lifecycle. The next paragraphs describe each step in more detail, concentrating on
concurrency issues.
Servlet Input Output
Servlet Request Servlet Response
Fig 5.4: Servlet Input Output
31
When a server loads a servlet, it runs the servlet's init method. Even though most
servlets are run in multi-threaded servers, there are no concurrency issues during servlet
initialization. This is because the server calls the init method once, when it loads the
servlet, and will not call it again unless it is reloading the servlet. The server cannot
reload a servlet until after it has removed the servlet by calling the destroy method.
Initialization is allowed to complete before client requests are handled (that is, before the
service method is called) or the servlet is destroyed.
init
destroy
service Fig 5.5: Servlet Methods
32
After the server loads and initializes the servlet, the servlet is able to handle client
requests. It processes them in its service method. Each client's request has its call to the
service method run in its own servlet thread: the method receives the client's request, and
sends the client its response.
Servlets can run multiple service methods at a time. It is important, therefore, that
service methods be written in a thread-safe manner. For example, if a service method
might update a field in the servlet object, that access should be synchronized. If, for some
reason, a server should not run multiple service methods concurrently, the servlet should
implement the SingleThreadModel interface. This interface guarantees that no two
threads will execute the servlet's service methods concurrently.
Servlet destroy
Process client requests
Servlet startup
Server
Server
Fig 5.6: Servlet Life Cycle Diagram
33
Servlets run until they are removed from the service, for example, at the request
of a system administrator. When a server removes a servlet, it runs the servlet's destroy
method. The method is run once; the server will not run it again until after it reloads and
reinitializes the servlet. When the destroy method runs, however, other threads might be
running service requests. If, in cleaning up, it is necessary to access shared resources
(such as network connections to be closed), that access should be synchronized.
During a servlet's lifecycle, it is important to write thread-safe code for destroying
the servlet and, unless the servlet implements the SingleThreadModel interface, servicing
client requests.
34
Chapter 6 Markup Languages
6.1 XML
Extensible Markup Language is a text-based format that lets developers describe,
deliver and exchange structured data between a range of applications to clients for local
display and manipulation. XML also facilitates the transfer of structured data between
servers themselves. Vast stores of legacy information exist today, distributed across
disparate, incompatible databases. XML allows the identification, exchange and
processing of this data in a manner that is mutually understood, using custom formats for
particular applications if needed.
XML stands for eXtensible Markup Language. It looks a lot like HTML. In fact,
both HTML and XML are commonly viewed as a subset of SGML (Standard
Generalized Markup Language). SGML is very complicated, a fact that has lead to its
failure to gain widespread usage. HTML, its greatly simplified descendant, has been a
resounding success, but it is beginning to demonstrate some significant limitations. XML
is in between these markup languages in terms of complexity. It is more complex than
HTML, but still significantly fewer complexes than SGML. It is essentially an attempt to
define a common ground between HTML and SGML.
A weather report XML will look like
<weatherreport>
<date>November 18, 2000</date>
<time>08:00</time>
35
<area>
<city>Cincinnati</city>
<state>OH</state>
<country>USA</country>
</area>
<measurements>
<skies>partly cloudy</skies>
<temperature>46</temperature>
<wind>
<direction>SW</direction>
<windspeed>6</windspeed>
</wind>
<humidity>87</humidity>
<visibility>10</visibility>
<uv-index>1</uv-index>
</measurements>
</weatherreport>
Like SGML, XML is a metalanguage for defining markup languages. XML
allows us to define our own markup language consisting of new �tags�, which we can use
to encode the information in our web documents far more precisely than can be done with
HTML. XML is not a replacement for HTML. It is, instead, a supplement to HTML.
While HTML will continue to be used for standard web pages, XML will be useful for
applications that need more intelligent documents and more processing ability. The main
limitations of HTML are lack of extensibility, structure, and validation.
Fig 6.1: XML Structure Example
36
Extensibility: HTML has a fixed number of tags. While the W3C and browser
developers can add tags, users cannot create their own tags to more accurately describe
their data.
Structure: HTML does not support the creation of nested tags, which would be
used to describe and represent databases or object hierarchies.
Validation: HTML does not support document validation. It has no means of
allowing an application to check the data for validity, or to ensure that the markup is
correct and well formed.
XML differs from HTML in all three of these major areas:
• It allows developers to define new tags and attributes as needed
• It allows document tags to be nested as deeply as needed.
• Any XML document can include or make reference to a description of its
grammar and syntax for use by applications that need to validate the
structure of a document.
XML will be most widely used in applications, which cannot be accomplished
within the limitations of HTML. According to Jon Bosak of Sun Microsystems (Future of
the web)
"These applications can be divided into four broad categories:
Applications that require the Web client to mediate between two or more
heterogeneous databases
37
Applications that require the Web client to present different views of the same
data to different users.
Applications that require the Web client to present different views of the same
data to different users.
Applications in which intelligent Web agents attempt to tailor information
discovery to the needs of the individual users.
One more quote from Mr. Bosak: "XML can do for data what Java has done for
programs, which is to make the data both platform-independent and vendor-
independent".
6.2 Three-Tiered Architecture
Fig 6.2: Three-Tiered Architecture
38
XML can be generated from existing databases using a scalable three-tier model.
With XML, structured data is maintained separately from the business rules and the
display. Data integration, delivery, manipulation and display are the steps in the
underlying process as summarized in the following diagram
6.3 HTML Display of XML data
XML based data is transformed into HTML with XSL (eXtensible Stylesheet
Language). The process of this transformation is referred as XSL Transformation. XSLT
(eXtensible Stylesheet Language Transformation) can be done both at client level and
server level. If the client is capable of XSLT processing then overhead load is transferred
to the client and processing is done there. If the client is incapable of XSLT processing,
HTML itself generated at server level.
XSLTXML HTML
XSL
XSLT
Fig 6.3: XSLT Process
39
Chapter 7 Obstacle Avoidance Online System
The solution for the obstacles encountered in the past years are maintained in the
database system designed. This database is made capable of data entry and data retrieval
over web by establishing XML standards for the data and java servlets.
The architecture of the system is as follows.
For the list of obstacles presented till now in the contest the obstacle avoidance
navigating angle is being worked out and entered into database. For new obstacles posed
in years to come, the solution should be worked out and updated into the database
Obstacle RDBMS
Web Browser
Web Server
Laser Scanner Image
Database Server
XML Results HTTP Request
XML/HTML Response
Query
Data Result Optimized Query
Fig 7.1: Online Obstacle Avoidance Architecture
40
system. A web interface, which will provide dynamic access to the database over web, is
developed with java servlets.
The only commercial browser which offers support to XML is Internet Explorer 5
and above. To account for other browsers, HTML based result is sent out to other clients.
The nature of client browser is determined by the environmental variable inside the
servlets.
7.1 Web Interface Design
The Online system is designed with a static welcome page which directs to Java
servlet page where the records from the database is pulled up into the web in either
HTML or XML format depending on the client browser type.
Fig 7.2: Obstacle Avoidance Welcome Page
41
Fig 7.2: Obstacle Avoidance Servlet
42
Chapter 8
Conclusions and Recommendations
The online obstacle avoidance system is built and it will be implemented into the
robotics sun web server. The system will provide easy access of data and entry of data in
future.
The online system will be accessible with any popular web browser like Internet
Explorer or Netscape Navigator. It will be available on the University of Cincinnati
robotics web server.
In years to come with the technology remote method invocation could be done.
The robot could be made to have web access and retrieve navigation details by itself and
navigate around. It will help in reduction of lot of on time processing in the robot central
processing unit.
Online systems for various systems of our robot could be designed. As of now we
have online fault diagnosis system and online obstacle avoidance system for the robot.
These ideas could be extended to various other systems of the robot.
43
References
[1] D. Marr, �Representing and computing visual information�, Artificial
Intelligence: An MIT perspective, pp. 15-80, 1981
[2] Jolion Jean-Michel, �Computer Vision Methodologies�, Computer Vision and
