Controlling Remote Robotic Arm through Internet Report

Controlling Remote Robotic Arm Through Internet

PRILIMINARY PROJECT REPORT

ON

“CONTROLLING REMOTE ROBOTIC ARM THROUGH INTERNET”

BY

SANDIP RANSING

TUSHAR THIKEKAR

PARTH BHATT

PRAJAKTA KATHE

www.funonrails.com twitter @sandipransing

http://www.funonrails.com/


INDEX

CHAPTER 1 : PROBLEM STATEMENT ..........................................1 CHAPTER 2 : FEASIBILITY STUDY… ............................................2

2.1 Historical survey.........................................................................................5

2.2 Background and need……………………………………………………..6

2.3 Hardware setup……………………………………………………………7

2.4 Performance of system…………………………………………………..11

2.5 Conclusion……………………………………………………………….12

2.6 Recommendation for future work……………………………………….12

CHAPTER 3 : PLATFORM SPECIFICATION ...............................14

3.1 Software Required ....................................................................................14

3.2 Hardware Required ...................................................................................25

CHAPTER 4 : SOFTWARE REQUIREMENTS SPECIFICATION...........30

4.1 Introduction ..............................................................................................30

4.1.1 Purpose ......................................................................................30

4.1.2 Document Conventions .............................................................30

4.1.3 Intended Audience and Reading Suggestions ...........................30

4.1.4 Project Scope .............................................................................31

4.1.5 References .................................................................................31

4.2 Overall Description ..................................................................................31

4.2.1 Product Perspective ...................................................................31

4.2.2 Product Features ........................................................................31

4.2.3 User Classes and Characteristics ..............................................32

4.2.4 Operating Environment ............................................................32

4.2.5 Design and Implementation Constraints ...................................33




4.2.6 User Documentation .................................................................33

4.2.7 Assumptions and Dependencies ...............................................33

4.3 System Features .......................................................................................33

4.3.1 Login to the server ....................................................................33

4.4 External Interface Requirements .............................................................35

4.4.1 User Interfaces ..........................................................................35

4.4.2 Hardware Interfaces ..................................................................35

4.4.3 Software Interfaces ...................................................................35

4.4.4 Communications Interfaces ......................................................35

4.5 Other Nonfunctional Requirements ........................................................36

4.5.1 Performance Requirements ......................................................36

4.5.2 Safety Requirements ................................................................36

4.5.3 Security Requirements .............................................................36

4.5.4 Software Quality Attributes ......................................................37

4.6 Other Requirements…………………………………………………….38

Appendix A: Glossary ……..............................................................38

Appendix B: Analysis Models ….....................................................39

CHAPTER 5 : HIGH LEVEL DESIGN DOCUMENT .....................41

5.1 Introduction ...............................................................................................41

5.1.1 Background ................................................................................41

5.1.2 Design Goals ..............................................................................42

5.2 Architecture ...............................................................................................43

5.2.1 Introduction ................................................................................43

5.2.2 Data ............................................................................................44

5.2.3 Communication ..........................................................................45

5.3 Operation ...................................................................................................46




5.3.1 User types ...................................................................................46

5.3.2 Installation ..................................................................................47

5.3.3 Licensing……………………………………………………….47

5.3.4 Upgrades ....................................................................................48

5.3.5 Uninstall .....................................................................................48

5.4 Development .............................................................................................49

5.5 Miscellanea / Appendices ..........................................................................50

5.5.1 Conformance with standards ......................................................50

5.5.2 Security .......................................................................................50

5.5.3 Glossary ......................................................................................50

5.5.4 Bibliography ...............................................................................51




Chapter 1Problem Statement




Chapter 2Feasibility Study

2.1 Historical Survey

A major step in the online control came with the experiments using the Internet

done by Kuchlin (1997) with Highrobot Telerobotics. The experiments resulted in the

development of a software model based on an object-oriented concept that could interact

remotely with robot programs. Kuchlin also explored the extensive capabilities of Java

with Transmission Control Protocol and Internet Protocol (TCP/IP). In the experiments,

Java program could run .on arbitrary remote computer platforms interacting with a

robotic control.

In a study conducted to access a remote manufacturing system through internet,

Calkin and Parkin (1998) developed simulation tools for remotely-controlled robots. The

simulation tools for the robotic hardware were developed using Java and VRML 97 to

create a desktop virtual-reality environment. A VRML browser was developed by the

researchers to enable a client computer to request transmission of web pages from the

host computer. However, a drawback was that the client computer had to have the VRML

browser and Vcollide’s libraries installed in order to communicate with the host

computer. Many users were inconvenienced because of the installations. In addition, the

VRML browser and Vcollide’s library required a computer with more complicated

configurations and a larger amount of memory.

Rodrigues de Queiroz and Bergerman (1998) attempted remote control operation

at the Automation Institute in Brazil. Based on their research, the Automation nstitute

proposed the first Brazilian Robotics and Computer Vision Virtual aboratoryRCVVL).

In the RCVVL, communication between the user and the remote laboratory was

accomplished through a graphical interface which was developed with Java and

Hypertext Markup Language (HTML). The use of such programs made the RCVVL

accessible worldwide via Internet. Users could access the remote laboratory without

having to download executable source codes. The RCVVL utilized two cameras, one on




top of the robot and the other on the ceiling of the laboratory.Current images were

updated at a rate of three frames per second. This research demonstrated the ability to

visibly control a robot through Internet from a remote place. Nevertheless, the

researchers did not design the RCVVL to run a program from the client site. In addition,

the researchers did not make source codes available and the updating rate of the image

was too slow. Thus, there was a clear need to develop a workable web-based control

system to promote distance access.

The objective of this study was to develop a prototype Web-based Controlling

System (WCS) that could serve as a remote control tool for an unmanned manufacturing

cell in an educational laboratory. This system is designed to serve as an OL for distance

education. The WCS was comprised of hardware components interfaced with Internet

tools to control and program the unmanned cell through Internet from a remote site.

Students were able to interact via Internet with the unmanned cell to carry out

technological activities. The WCS, which was programmable through the client’s

computer, was compatible with any operating system (OS) and provides simultaneous

text and visual feedback at a visual frame rate of 1 frame/sec.

2.2 Background and Need

An issue with people who want to control the distant robotic application while

working at different places worldwide. While working everyday there are many cases

when we need distance remote application to be run that time remote applications

interfaces is a major option and has been accepted widely.

“CONTROLLING REMOTE ROBOTIC ARM THROUGH INTERNET”

is the best solution for the distance remote applications in many fields which require

laboratory activities, such as manufacturing, controlling water level in ‘Dams’, to help

Doctors in conducting distant surgery on patients.

The advancement of Internet technology tools developed in 1990s made it

possible to access at distance. The Internet technology tools allowed development of such

idea. Obviously, an On Line access is beneficial to distance application because it

provides people with instant access to a remote lab without investment in both travel time

and expense.




The benefit of an online laboratory is that enrollment of distance education

in manufacturing courses and degree programs will be expected to increase. An online

access for robotic applications would be maximized by remote control technology

through Internet.

2.3 Hardware Setup

The proposed WCS consisted of a computer, power supply circuit, stepper motor,

stepper motor interface, PLC devices, actuators such as a cameras. The working

configuration is illustrated in Figure below. The computer, which connected all other

components together, was the control center as well as the web server that enables access

from client computers through internet for remote controlling.

The computer was equipped with server software called VQ Server. The VQ

Server applied in this study was version 1.9.55. It was specialized to enable creation of

host web pages in HTML format for access from client’s computers. The computer was

also equipped with Web Cam 123 to receive images from a digital camera and an author-

written program for overall control.

In turn, the program activated or stopped the stepper motor and activities to rotate

steeper motor by any angle for a specific task that to be performed The process was

monitored with a digital camera, which sent image pixels to the computer to make the

control process visible at the remote site.

Figure A2.3.1 Client/Server Program




The client/server program was developed with Java using TCP and Socket

programming with a text feedback to the client’s computer. Since client programs were

written in Java, they could be accessed from any WWW browser and ran locally on a

user’s computer. The client program consisted of buttons, a textbox, and network sockets,

which were designed to send and receive data from the server. Buttons and one textbox

were developed in the client applet. These buttons were configured as:

• button to activate a horn on the server side,

• button to deactivate the entire system for emergency purposes, and

• button to initiate a program on the server side.

• button to control movement of stepper motor.

The textbox displayed messages from the server side as well as messages naming

the next action to take place at the server side. The network socket was used to transmit

data from the client to the server. When a button was depressed, a data string was sent

through the socket to the server.

The server program, upon receiving the data strings from the client, converted the

string into integer values and passed the integer values to next step. In this step the switch

structure was reviewed and executed based on the appropriate batch file. After executing

the batch file, the server returned the integer value to the client indicating the successful

execution of the command. Figure B depicts the client side screen.




Figure B Screen view of the webpage

2.3.2 The Website

A web site was developed with HTML to transfer files between the client

computer and the server computer. The website can be accessed through any WWW

browser so that the stepper motor could be programmed and controlled via the website.

2.3.3 The program for visual feedback

On-site visual feedback was enabled through the use of a Web Camera via

internet. The software, Web Cam 123 provided by the Web Cam Corporation, was

employed to receive the on-site pixels. These pixels were integrated into the Website

HTML file and sent to the client computer to enable the visual aid.

2.3.4 WEBCIMS Software Description




The Java Web CIMS software had two main parts: the client/server program and

the Stepper Motor program. The C language was used to write relay programs to activate

the relays through the parallel ports. Java language was used to write client/server

programs.

The client /server involved TCP/IP communication using TCP/IP stream sockets.

It was a reliable, two-way data connection between two applications. TCP/IP stream

sockets delivered sequenced and unduplicated data (i.e., the data bytes were received in

the same order that they were sent). Java programming platforms provided classes that

create stream sockets.

In TCP/IP communication, the web server delivered the Graphical User Interface

(GUI) program to the client and the client GUI communicated directly with the server

program through TCP/IP streaming ports. A direct communication link was created

between each client and the server. When using this programming method, Java was the

rational programming platform for the client GUI. Java applets could be delivered via

web pages and executed in most popular web browsers, including Netscape

Communicator and Internet Explorer.

Upon request of data from the client computer, the server sent out the appropriate

information to the client. The web page on the client computer displayed the Java

buttons. The server program sat and waited for user commands to be selected on the GUI

(i.e., clicking the button or buttons). When a button was selected, it opened port 2346 and

sent commands in the form of a data stream to the server. Before data were sent, a

numeric variable was placed in a character string and transferred as a data stream. Each

button had a different numeric variable for communication. This port was then closed

after all data were transferred.

During the process of data transfer, the text field displayed a message identifying

what action would take place at the server side after the process was complete. The server

received the data stream by opening port 2346, after which the character string underwent

a change. The character string was then converted into an integer. The converted integer

was passed to the switch control structure. The switch control structure evaluated the

value of integer and triggered the appropriate case depending on the value of the integer.

As the case was triggered, it executed a batch file.




When the batch files were executed, the appropriate output signals were sent to

the parallel port on the server. These signals were transmitted through the parallel port to

the relay board to make contacts on the relay. As the relay made a contact, the robot

controller received the signal and instructed the robot to move as specified by the signals.

The end use r could observe the on-site robot’s motion through a web camera. After

successfully executing the C program, the server sent the data stream to the client

program. This integer value was then placed in a character string and returned as a data

stream. The client program, upon receiving the string, displayed the returned data in a

text field as a conformation number. Figure C depicts the operation of the WCS.

2.4 Performance of the System

The system as described in the Hardware Setup section and Figure A was built

and configured with a computer (Pentium 4, 128 Mb RAM) as the server. When the

system was turned on, any other computers could access the server and execute

commands or programs. The working process could be watched on the small window on

the webpage as shown in Figure B. The stepper motor could be controlled either with

manually pressing buttons on the webpage or by sending a program.. The whole system

could be shut off by pressing the “Stop the System” button on the webpage when needed.




With all these evidences, it can be concluded that the system will work and functions as it

designed.

2.5 Conclusion

A WCS was developed in this research to remote control laboratory activities

through Internet. Special features of the WCS allow end users to use a general purpose

personal computer and any World Wide Web browser to carry out the control activities

remotely through Internet. The system also provided feedback to the end users in terms of

visual and text format. Since the configuration of the system as shown in Figure A will

able to serve as a WCS, similar configuration can be applied for other application setups.

As designed, the client/server program written in Java using TCP and Socket

programming made the server accessible through Internet by using a universal browser.

However, due to the unexpected traffic in the Internet, delays of the communication

between the server and the end user may happen. This causes delays on executing

commands and programs and transmitting on-site images.

2.6 Recommendations for future work

The following are a few recommendations that can be implemented to enhance

this online control study in the future:

1. Use high-speed network to reduce the delay time between the transitions

of\streams from client to server.

2. Multiple Cameras can be used to monitor the process from multiple angles to

prevent blind spots.

3. Software that transfers a source code from client computer to the server,

compiles it at the server side, and then executes the program safely needs to be

developed.




4. A proof reading method can be adapted to execute the transferred program

safely within the Robot operating limits. It can be arranged by using Artificial

Intelligence and neural networks. This research can be further enhanced by,

controlling other devices, not merely Robots and PLC.




Chapter 3

Platform Choice

3.1 Software Platform

3.1.1 Why java?

Java is compatible on all the machines ,also its basically internet language so

our project is based on the hardware interfacing control through the internet so we are

going to use the java as development language. Also we are going to use Advance Java

(Eg.Servelets).

3.1.2 Advantages of Java as a Programming Language

It is said that a language is only as good as the applications that can be written in

it. Java scales well to this measure, as is evident by its numerous applications, including

those which are educational. We will introduce some of these later. Advantages of Java

are reflected in its definition:

A simple, object-oriented, distributed, interpreted, robust, secure,

architecturalneutral , portable, high-performance, multithreaded, and dynamic

language.These features have made Java a favorable language for programming on the

WWW.

There are various specific advantages of using Java applets over existing

programming environments:

• Speed: Java applets are accessible on the client-side, hence are faster than

programs running on remote servers.




• Interoperability: Java applets can interface with various forms of media formats

(text , graphics, animation and sound) and languages (such as JavaScript and VRML).

Applets can also interact with other applets, with programs on its host server and with

HTML/XML documents on remote servers.

• User Interaction: Unlike Java, HTML is equipped with a limited set of graphical

user interface (GUI) elements. Java applets can thus provide a better user interaction.

• Platform Dependence And Portability: Multi-platform versions of educational

software are scarce, and often have a strong dependency on the underlying hardware. On

the other hand, users can access a Java applet using different types of architectures and

Java compliant browsers, but still all see the same information in nearly the same format.

• Distributed and Network Computing: Until recently, results from one application

usually could not be shared by remote users in real-time. Java Application Programming

Interface (API) has support for writing distributed and network programs which can

access and share data residing at remote repositories, thus supporting data sport ability.

• Development And Maintenance: Usually, the process of writing an educational

program is:

1. Main program (which does the computations) + graphics (which plots the

results) + user interface,

2. Each of them often in different languages. This can be difficult to extend and

maintain. With the support of Java API, these three components can be integrated into

one unified environment.

Java has a variety of applications we will see it as follows.

3.1.3 Applications of Java?

• Java could be used to provide stand-alone applications (for spreadsheet, word

processing, graphics, CAD, etc.) on a 'pay per use' basis. This will particularly suit the

end user who uses an application only very occasionally. In some such cases, where the

application is fairly expensive, it may work out more cost effective for the user to use the




application on such a metered basis rather than invest a substantial sum of money to buy

it outright. Java could enable such a user to simply connect to the software provider via

the Internet, download a copy of the software for temporary use and be billed for it.

• Java could also provide a means by which a user can upgrade to the latest

version of an application that they already own. The user could simply connect to the

software company via the Internet, download the latest updates and added features which

Java could then integrate into the existing copy, irrespective of the user's platform.

• Java could also be used to program intelligent agents to comb the Internet for

information. The Internet today contains vast amounts of information yet one of its

biggest problems remains that of being able to find a required piece of information. Enter

the intelligent agent. An intelligent agent could be implemented in the Java language,

sent out to cruise around the Internet, hopping from one information database to another,

looking for a given piece of information. Java is ideally suited for the implementation of

such an agent because of its portability and platform-independence. The agent will be

able to access different hardware platforms running databases on different operating

systems, collect data and move on to the next. Because of the security features of Java, an

environment can be provided within which such agents can run without compromising

the security of the host computer.

• Java can be used to provide new capabilities to the Virtual Reality Modelling

Language (VRML). VRML is a file standard for building 3-dimensional worlds for the

Internet. The ultimate goal is for people to be able to interact with each other via the Web

in this 3D world better known as cyberspace. At the time of writing, the VRML is rather

limited in scope in that while it is capable of producing 3D space, the space is static - its

constituent objects have no behavior. Java can be used to provide the interaction required

to bring this static space to live by associating applets with the different objects in the

space. When the space is downloaded to a user's desktop, the applets can then start to

execute bringing the space to live.




3.1.4 Advance Java :

In advance java we are using the following topics for development, which are as

follows

3.1.4.1 Introduction to Applet :

The last few years have seen a rapid emergence and broad acceptance of the

WWW as a global medium for disseminating and processing information that is

accessible in multiple formats (multimedia) and at extremely fast speeds (hypermedia).

This has opened new vistas in education by taking full advantage of our basic "senses" of

learning such as visualizing 3D objects and nonlinear nature of thought processes. Recent

years have also seen the inception and development of Java, a powerful programming

language from SUN Microsystems. This article discusses the interplay of these two

technologies - Java and the WWW - in context of education. In that effort, we address the

following questions from a pedagogical viewpoint:

How can the present computational environment of Java and the WWW be

Integrated in education? In particular, how and where can Java applets be used? What

issues should be considered before and during such a use?

We assume that the user is familiar, at least at an elementary level, with the notion

of Java applets. This article is by no means an introduction to Java; there are many good

tutorials and books available for that purpose.

3.1.4.2 What are Java Applets?

Among the different types of programs that can be written in Java, we are

primarily interested in applets. Java applets are programs written in Java that require a

WWW browser or another Java application to run. (A Java application is a standalone

program that requires the assistance of the Java interpreter, such as the Java Virtual

Machine (JVM), to run.)




3.1.4.3 Advantages of Java Applets

There are various inherent limitations in the current practices of teaching and

learning. Some of these problems can be solved to a large extent via integration of Java

applets. These aspects can be outlined as follows:

o Open Classroom: The use of Java applets can encourage asynchronous distance

learning and thus help overcome the limitations (involving both time and space)

inherent in traditional instructional techniques. (Instruction is asynchronous when

it does not constrain the student to involvement in the learning process at a

specific time, for example, when lectures are presented at a fixed time of the day.

Instruction is distant when it does not constrain the student to be physically

present in a specific location, for example, when lectures are presented only in a

fixed classroom.) Using the WWW, teachers and students can access information

any time and anywhere. In the present educational system, teaching hours

(including the instructor's office hours) are often insufficient for students. Now

that many students have access to the WWW, such facility can be very timely and

convenient for students who wish to study the course material from home in their

own time. The need for physical proximity can thereby be reduced.

o Nature Of Information: There are various concepts and phenomena that

inherently involve:

• Dynamic Information: For example, chemical reaction simulation or rate

of convergence of a numerical method of integration or motion of a

pendulum.

• Multimedia information: For example, any subjects that involves the study

of concepts from graphics, animation or sound.




• Interactive Information: For example, any topic that involves change of

system parameters for understanding.

Such information can usually not be represented, distributed and communicated in

paper form (and even using a blackboard or overhead-projector with transparencies) due

to various limitations. Even though animations can be created using other techniques (for

example, GIF animation tool), they lack interaction. The "mental picture" that a teacher

has is better conveyed to a learner if the information is presented in its appropriate form.

Java applets can complement a lecture and sessions with such information which is

difficult to convey in traditional manner. The use of applets along with desirable

multimedia support, provides a representation that is often better in communicating a

concept than a static Figure (s) or a written description. It also helps learners visualize the

concept relatively easily. Through the multimedia support of the WWW, information can

be represented dynamically and interactively - both of which Java applets are well

equipped with. Applets that have active GUI elements give control in the hands of the

learner, and thus allow the learner to gain experience with the concept.

o Classroom Demonstrations and Connections: Classroom demonstrations are an

essential component of subjects that are practically-oriented. In various such

courses, for example, which are computationally oriented, actual computer

implementations of algorithms that function in real-time are usually not

introduced in the classroom. Also, the classroom and laboratory components are

separated - the lessons are carried out in the classroom while the implementation

of algorithms corresponding to them is carried out in a computer laboratory.

o Teacher's Viewpoint: The teacher, at best, illustrates a static computer program for

an algorithm or a static image of a computer-generated graphical result. This is

often not sufficient. Using Java applets, teachers can perform classroom

demonstrations involving real-time computations, bringing more realism to the

subject matter. They can thus save time in explaining the algorithmic

implementations. The use of hypertext in a WWW document also facilitates




explanation of related concepts (such as an applet performing a computation and a

corresponding lesson). This can bring clarity and continuity to the lecture by

3.1.4.4 Operation Servelet

• Login to server.

• Call Hardware Module.

• Taking user input .

• Give feedback .

Also we are using the JNI (java Native Interface) for interfacing with hardware

module, because java can’t give the access to directly hardware. so it requires to use

JNI .Create DLL file in which functions are there that calls hardware modull,but that

DLL is called by JNI itself.

3.1.4.5 What Is a Servlet?

A servlet is a Java programming language class that is used to extend the

capabilities of servers that host applications access via a request-response programming

model. Although servlets can respond to any type of request, they are commonly used to

extend the applications hosted by web servers. For such applications, Java Servlet

technology defines HTTP-specific servlet classes.

The javax.servlet and javax.servlet.http packages provide interfaces and classes

for writing servlets. All servlets must implement the Servlet interface, 442 JAVA

SERVLET TECHNOLOGY which defines life-cycle methods. When implementing a

generic service, you can use or extend the GenericServlet class provided with the Java

Servlet API. The HttpServlet class provides methods, such as doGet and doPost, for

handling HTTP-specific services. This chapter focuses on writing servlets that generate

responses to HTTP requests.




3.1.4.6 Servlet Life Cycle

The life cycle of a servlet is controlled by the container in which the servlet has

been deployed. When a request is mapped to a servlet, the container performs the

following steps.

1. If an instance of the servlet does not exist, the web container

a. Loads the servlet class.

b. Creates an instance of the servlet class.

c. Initializes the servlet instance by calling the init method. Initialization

is covered in Initializing a Servlet .

2. Invokes the service method, passing request and response objects. Service

methods are discussed in Writing Service Methods .

If the container needs to remove the servlet, it finalizes the servlet by calling the servlet’s

destroy method.

3.1.5 Dynamic Link Library(DLL)

3.1.5.1 Summary

A dynamic-link library (DLL) file is an executable file that allows programs to

share code and other resources necessary to perform particular tasks. Microsoft Windows

provides DLL files that contain functions and resources that allow Windows-based

programs to operate in the Windows environment.

3.1.5.2 More Information

DLLs most often appear as files with a .DLL extension; however, they may also

have an .EXE or other extension. For example, Shell.dll provides the Object Linking and

Embedding (OLE) drag and drop routines that Windows and other programs use.

Kernel.exe, User.exe and Gdi.exe are examples of DLLs with .EXE extensions.

They provide code, data or routines to programs running in the Windows operating

system. For example, one of these files provides the "CreateWindow" function that

programs use when a new window is created on the screen.




In Windows, an installable driver is also a DLL. A program can open, enable,

query, disable and close the driver based on instructions written in the DLL file. DLLs

may be found in the Windows directory, Windows\System directory or in an program's

directory.

If a program is started and one of its DLL files is missing or damaged, you may

receive an error message like: "Cannot find xyz.dll". If a program is started with an

outdated DLL file or mismatched DLL files, the error message "Call to undefined

dynalink" may be displayed. In these situations, the DLL file must be obtained and

placed in the proper directory in order for the program to run correctly.

3.1.6 Java Native Interface (JNI)

3.1.6.1 Summary

The main deficiency Java applications seem to have is that they do not look and

feel like native applications. The reasons behind this are obvious: 100% Pure Java must

support the lowest common denominator, but there are many platform-specific features

and quirks that the users of specific platforms expect, and your application will seem to

be lacking without them.

In today's competitive application arena, these features may be critically

necessary to your application's marketplace success. A competitor's native application

can use these features to beat your Java application every time, producing a product that's

faster, looks and feels right, and works with the operating system and other native

applications as expected.

The solution, of course, is to use Java Native Interface (JNI) extensions. But what

will this mean for Java's cross-platform capabilities? If your application is only 60% Pure

Java, it won't run on other platforms -- so why use Java at all? Admittedly, Java has other

benefits: the language is easy to learn and use, the code is simple to maintain and debug,

and by using it you leave open the possibility of migrating to other platforms in the future

-- if you design your application with such migration in mind.




So, is JNI a compromise? It doesn't have to be. You can have a 100% Pure Java

application in which JNI features are added benefits that appear only on specific

platforms. There will be no loss for those who use the platforms not supported by your

JNI features, and you will compete with native applications on equal terms where needed.

The trick is to design an application that can take advantage of JNI features, but is still

fully operational without them.

3.1.6.2 Bonus features

Start out with a 100% Pure Java application design. Think of the application as

being contained entirely within the virtual machine, which is otherwise platform neutral.

All your features must be based on whatever the Java platform has to offer. When you're

finished, congratulate yourself! Your design will work on any Java Virtual Machine

(JVM) running on any platform.

Next, look at your Java application from a user's point of view. It's probably not

the only application running in his or her environment. What features is your application

lacking that its native neighbors have? Run a few native applications together with yours,

and ask yourself some questions about the differences:

• Do the native apps have special widgets that your application lacks? Tool

tips are common, and so are context menus, but what about collapsing/expanding,

minimizing/maximizing, and showing/hiding? Some GUIs have special popup messages

and automatic behaviors. There's really no limit to what some people think users want.

• Do both types of app handle special mouse and key combinations in the

same way? Java makes no special assumptions about the number of mouse buttons, but

many platforms do. Keyboards are largely standardized, but there are exceptions; some

keyboards (and some platforms) have more specialized keys than others. Native

applications may exhibit special operating system behavior for special key combinations.

• Can your application interoperate with the natives? Can you drag and drop

between them? What types of objects does each accept? Dragging files is common, but

are other objects commonly dragged in or pasted?




• How does your application interact with the desktop? Some platforms

have very cluttered desktops, supporting taskbars, flashing messages, context menus, and

even Web content. Do the native applications use these features? (This article will handle

the taskbar icon feature in Windows, with which you can add application-defined icons to

the desktop taskbar that indicate status without requiring an open window.)

• How does your application interact with the operating system, as

compared to the native applications? Do they handle special OS events, such as

hibernation and input methods, in similar ways? Do they converse with system databases

or registries? Do they write to a system event log?

Look at your list of missing features, and don't underestimate its importance. You

may not like these features, finding them weird and difficult to understand, but that's just

because you're not used to that platform. The average user knows them, uses them, and

will expect to find them in your application. Unless your application provides

functionality that is not available elsewhere, or is extremely cheap, users will always

prefer native options.

But don't go overboard. Some features are so obscure or unpopular that their

absence won't be noticed. Filter such features out, and list only the essentials. Try to think

of these as features you want and not just obstacles to overcome. Thinking positively

always helps.

The most important thing is to treat these features as an added benefit (or an

annoying redundancy, if you prefer) for users of a specific platform, but never as features

essential to the functioning of the application. Your app should be entirely and fully

usable on either the Standard or Micro edition of the Java platform. This is the only way

to protect the application's cross-platform portability -- and considering that portability

was probably why you chose Java as a platform in the first place, it makes sense to

protect it.

3.2 Hardware Platform

3.2.1 Interfacing Parallel Port




The Parallel Port is the most commonly used port for interfacing home made

projects. This port will allow the input of up to 9 bits or the output of 12 bits at any one

given time, thus requiring minimal external circuitry to implement many simpler tasks.

The port is composed of 4 control lines,5 status lines and 8 data lines. It's found

commonly on the back of your PC as a D-Type 25 Pin female connector. There may also

be a D-Type 25 pin male connector. This will be a serial RS-232 port and thus, is a totally

incompatible port.

Newer Parallel Port’s are standardized under the IEEE 1284 standard first

released in 1994.This standard defines 5 modes of operation which are as follows,

1. Compatibility Mode.

2. Nibble Mode. (Protocol not Described in this Document)

3. Byte Mode. (Protocol not Described in this Document)

4. EPP Mode (Enhanced Parallel Port).

5. ECP Mode (Extended Capabilities Port).

The aim was to design new drivers and devices which were compatible with each

other and Interfacing the Standard Parallel Port also backwards compatible with the

Standard Parallel Port (SPP). Compatibility, Nibble & Byte modes use just the standard

hardware available on the original Parallel Port cards while EPP & ECP modes require

additional hardware which can run at faster speeds, while still being downwards

compatible with the Standard Parallel Port.

Compatibility mode or "Centronics Mode" as it is commonly known, can only

send data in the forward direction at a typical speed of 50 kbytes per second but can be as

high as 150+ k bytes a second. In order to receive data, you must change the mode to

either Nibble or Byte mode. Nibble mode can input a nibble (4 bits) in the reverse

direction. E.g. from device to computer. Byte mode uses the Parallel's bi-directional

feature (found only on some cards) to input a byte (8 bits) of data in the reverse direction.




Extended and Enhanced Parallel Ports use additional hardware to generate and

manage handshaking. To output a byte to a printer (or anything in that matter) using

compatibility mode, the software must.

1. Write the byte to the Data Port.

2. Check to see is the printer is busy. If the printer is busy, it will not accept any

data, thus any data which is written will be lost.

3. Take the Strobe (Pin 1) low. This tells the printer that there is the correct data

on the data lines. (Pins 2-9)

4. Put the strobe high again after waiting approximately 5 microseconds after

putting the strobe low. (Step 3)

This limits the speed at which the port can run at. The EPP & ECP ports get

around this by letting the hardware check to see if the printer is busy and generate a

strobe and /or appropriate handshaking. This means only one I/O instruction need to be

performed, thus increasing the speed. These ports can output at around 1-2 megabytes per

second. The ECP port also has the advantage of using DMA channels and FIFO buffers,

thus data can be shifted around without using I/O instructions.

3.2.2 Port Addresses

The Parallel Port has three commonly used base addresses. These are listed in

table 2, below. The 3BCh base address was originally introduced used for Parallel Ports

on early Video Cards. This address then disappeared for a while, when Parallel Ports

were later removed from Video Cards. They has now reappeared as an option for Parallel

Ports integrated onto motherboards, upon which their configuration can be changed using

BIOS.

LPT1 is normally assigned base address 378h, while LPT2 is assigned 278h.

However this may not always be the case as explained later. 378h & 278h have always

been commonly used for Parallel Ports. The lower case h denotes that it is in

hexadecimal. These addresses may change from machine to machine.

Address Notes:




3BCh - 3BFh Used for Parallel Ports which were incorporated in to Video Cards

and now, commonly an option for Ports controlled by BIOS. -

Doesn't support ECP addresses.

378h - 37Fh Usual Address For LPT 1

278h - 27Fh Usual Address For LPT 2

Table - Port Addresses

When the computer is first turned on, BIOS (Basic Input/Output System) will

determine the number of ports you have and assign device labels LPT1, LPT2 & LPT3 to

them. BIOS first looks at address 3BCh. If a Parallel Port is found here, it is assigned as

LPT1, then it searches at location 378h. If a Parallel card is found there, it is assigned the

next free device label. This would be LPT1 if a card wasn't found at 3BCh or LPT2 if a

card was found at 3BCh. The last port of call, is 278h and follows the same procedure

than the other two ports. Therefore it is possible to have a LPT2 which is at 378h and not

at the expected address 278h.

What can make this even confusing, is that some manufacturers of Parallel Port

Cards, have jumpers which allow you to set your Port to LPT1, LPT2, LPT3. Now what

address is LPT1? - On the majority of cards LPT1 is 378h, and LPT2, 278h, but some

will use 3BCh as LPT1, 378h as LPT1 and 278h as LPT2. Life wasn’t meant to be easy.

The assigned devices LPT1, LPT2 & LPT3 should not be a worry to people

wishing to interface devices to their PC's. Most of the time the base address is used to

interface the port rather than LPT1 etc. However should you want to find the address of

LPT1 or any of the Line PrinTer Devices, you can use a lookup table provided by BIOS.

When BIOS assigns addresses to your printer devices, it stores the address at specific

locations in memory, so we can find them.

Start Address Function0000:0408 LPT1's Base Address0000:040A LPT2's Base Address0000:040C LPT3's Base Address0000:040E LPT4's Base Address (Note 1)




Table - LPT Addresses in the BIOS Data Area.

The above table, table 3, shows the address at which we can find the Printer Port's

addresses in the BIOS Data Area. Each address will take up 2 bytes. The following

sample program in C, shows how you can read these locations to obtain the addresses of

your printer ports.

#include <stdio.h>

#include <dos.h>

void main(void)

{

unsigned int far *ptraddr; /* Pointer to location of Port Addresses */

unsigned int address; /* Address of Port */

int a;

ptraddr=(unsigned int far *)0x00000408;

for (a = 0; a < 3; a++)

{

address = *ptraddr;

if (address == 0)

printf("No port found for LPT%d \n",a+1);

else

printf("Address assigned to LPT%d is %Xh\n",a+1,address);

*ptraddr++;

}

3.2.3 Stepper Motor

The below are the most common types of stepper motors that you’l find in the market .




There are two types of stepper motor that normally is used.

1) Unipolar 2) Bipolar

In simple terms they can be thought about like this. In unipolar there are 5 wires.

One common wire and four wires to which power supply has to be given in a serial order

to make it drive. Bipolar (not normally used in robotics) can have 6 wires and pair of

wires is given supply at a time to drive it in steps.

STEP ANGLE:

The angle with which the stepper motor turns for a single pulse if supply tone

wire or a pair is called step angle.




Exact Circuit and Micro C code for stepper motor

The exact circuit to connect the stepper motor to IC 74245 is given below

The Micro C code for running the motor is as below.

void main()

{

TRISB = 0×00;

PORTB = 0×00;

//routine to move in one direction

for (i=0;i<50;i++)// increse i=50 no i=100 to cover double the distance

{

PORTB=0×80;

delay(20ms);




PORTB=0×40;

delay(20ms);

PORTB=0×20;

delay(20ms);

PORTB=0×10;

delay(20ms);

}

//routine to move in the other direction

for (i=0;i<50;i++) // increse i=50 no i=100 to cover double the distance

{

PORTB=0×10;

delay(20ms);

PORTB=0×20;

delay(20ms);

PORTB=0×40;

delay(20ms);

PORTB=0×80;

delay(20ms);

}

}

There are much easier ways to write the above code but this is the best code to run

motor . The line PORTB = 0×80 (1000000)makes 8th pin of the PORT “B” that’s b7 pin

or the 40th pin go high. The next line PORTB = 0×40(01000000) will make the 39th pin

go high and all other low.

Now whenever the pin at the input of the ULN2803 goes high say pin 1 the output

pin 16 drains the current throuh the motor thus completing the circuit from supply 12V

through motor to the ground in that line. When you keep doing this in series, the abcd

pulse the motor will rotate . When your reverse the pulse order the motor rotates in the

other direction. As simple as that. For most robotic application atleast at contest level you




may use this circuit uinless you go for bigger stepper motors that need more current to

drive and is greater than the 500mA that the ULN2803 can sink!!




Chapter 4Software Requirement Specification

4.1 Introduction

4.1.1Purpose

While working everyday diminishes opportunity for on campus study, distance

education becomes a major option and has been accepted widely. Though distance

education works for many fields of study, it is difficult for those fields that require

laboratory activities, such as manufacturing. The advancement of internet technology

tools developed in 1990’s made it possible to access a lab at distance. The internet

technology tools allowed development of the idea of an Online Laboratory. An Online

Laboratory would be maximized by remote control technology through internet.

4.1.2 Document Conventions

VC++ To generate Inout.dll which provides hardware interface with the system

J2EE Java 2 Platform, Enterprise Edition (J2EE) defines the standard for developing component-based multi tier enterprise applications.

J2SE Java 2 Platform, Standard Edition (J2SE) 1.5

Apache Tomcat To upload Commands and download reports

4.1.3 Intended Audience and Reading Suggestions

The expected audience of this document includes unemployed people i.e. fresher of any

faculty, employed but looking for advanced job perspective. Companies which require

recruitment. The companies looking for expertise in particular faculty like (Java, C, Oracle, C#,

etc.).




4.1.4 Project Scope

• Online Dam Control• Online Electrical Equipment Control• Online Tele-Robots• Online Lab Control• Online Medical Surgeries

4.1.5 References

Books:i. Parallel port complete

ii. Serial port completeiii. Microcontroller - Mazdiiv. Vb.NETv. JavaTM Speech API Programmer's Guide

Web:i. http://www.Google.com

ii. http://www.wikepedia.com iii. http://www.beyondlogic.com iv. http://www.boondog.com v. http://Processing.com

4.2 Overall Description

4.2.1 Product Perspective

Self contained product

4.2.2 Product Features

The development of a software model based on an object-oriented concept that

could interact remotely with robot programs with extensive capabilities of JAVA with

transmission control protocol and internet protocol (TCP/IP).

The server machine will be loaded with software that will be controlling a

robotic arm. The hardware module will be interfaced with the PC using a parallel port.

The hardware control software will be initiated by a servelet that will be constantly



http://www.boondog.com/

http://www.beyondlogic.com/

http://www.wikepedia.com/

http://www.Google.com/


monitoring for user commands. The hosting site will provide only authorized users to log

on and monitor the robotic arm. This will be done by proper user authentication during

the login process.

The client machine will log on to the site. If the user has access rights, he

will be given total control of the hardware on the server side. The user will get a feedback

from the server in a data format. Thus a secured communication link will be set between

the client and the server.

The server machine will be controlled by an administrator who will have

sole rights to enroll a user to have access to the hardware. In critical conditions, the

administrator has sole rights to prevent users from using the hardware.

4.2.3 User Classes and Characteristics

See Appendix B.

4.2.4 Operating Environment

Software Environment

• Any Platform• Java Support• Java Enabled Web Browser• Apache Tomcat• VC++/ VB6

Hardware Environment

• Parallel Port Interface• Serial Port Interface• Microcontroller• Stepper Motor• ULN 2803 (Darlington Driver)• Bi-directional Buffer 74LS245• ARM Hardware




4.2.5Design and Implementation Constraints

There will certain rules while implementing this project, which are as follows,

1. The person using the software should be a technical person.

2. If the person is not aware of the software utilities he must be trained and then should

be given the machine to operate.

4.2.6 User Documentation

1. User manual.2. Study Report.3. Online Help.

4.2.7 Assumptions and Dependencies

While implementing this project there would be certain assumption and

dependencies and they are mentioned below.

1. Parallel port interface

2. Serial port interface

3. Interfacing motors via parallel / serial port

4. Software interface which will be Java / .NET to design GUL

5. Tom cat which will be used to upload commands and download the

feedback

4.3 System Features

4.3.1 Login to the server

4.3.1.1 Description and Priority

Administrator will have the highest priority as user than other users like Sub administrator.

4.3.1.2 Stimulus/Response Sequences

• User will login to server.

• Server will validate user.

• If the valid user then server will connect to the application.




• User will be able to see feedback through cameras online.

4.3.1.3 Functional Requirements

This section lists the functional requirements in ranked order. A functional

requirement describes the possible effects of a software system, in other words,

what the system must accomplish.

Easy programming paradigm

The programming paradigm is kept so flexible that even non-technical

personnel can implement complex algorithms with ease. Too many complex

scientific applications can be implemented easily using the language. It allows the

user to pay more attention to the problem at hand rather than the syntax of the

language to be used.

Full High Level Language Support & Integration

Although easy to program also provides a mode in which the user can

utilize the full power of Java programming language and its rich set of API’s to

implement even complex programs that require OOP support apart from the

hardware interfacing architecture.

Portability

The language is highly portable since all that is needed to implement and

run cross platform applications is the native library support. The same programs

that run on a Windows OS can be run on a Linux based OS without changing the

code.

Multiple Hardware Support

The same can be used for interfacing a wide range of hardware profiles.

Hardware domains ranging from Motor control, Electronic Interface, Analog

Interface, Electrical Equipment Control, etc. can be controlled using the same

hardware IO board.




4.4 External Interface Requirements

4.4.1User Interfaces

In this section the Graphical user interface will be provided to the user. So the

user can select the stepper motor operation and capable of changing stepper motor

parameters such as speed and direction. This section will also contain progress bar and it

will also provide the feedback to the user.

4.4.2 Hardware Interfaces

For Server: 1. Pentium 2 Processor 2. 128 MB RAM. 3. 4 GB of hard disk space. 4. Parallel / Serial Port

For Client: 1. Pentium 2 Processor 2. 64 MB RAM. 3. 4 GB of hard disk space. 4. Internet

4.4.3 Software Interfaces

1. Windows 98 and above 2. J2EE 3. Tomcat

4. J2SE 5. Java Enabled Web Browser

4.4.4 Communications Interfaces

In case of communication interface we talk about internet, intranet etc. so for that we will

use Tomcat to provide uploading commands and downloading feedback.




4.5 Other Nonfunctional Requirements

4.5.1 Performance Requirements

In case of performance requirements there will be two sections, which are mentioned as

Software Requirements

4. 5.1.1 Java EE

Java EE also features some specifications unique to Java EE for

components. These include Enterprise Java Beans, servlets, portlets

(following the Java Portlet specification), JavaServer Pages and several

web service technologies. This allows the developer to create an enterprise

application that is portable between platforms and scalable, while

integrating with legacy technologies.

4.5.1.2 Hardware Requirement

Parallel / Serial Port Interface

Incase of hardware we will use VC++ to provide hardware interface to a

system via InOut.DLL. It means we will create a code or module, which

we will import, in our main application and we will use the In/ Out

functions, which are available in InOut.DLL

4.5.2 Safety Requirements

1. The person using the software should be a technical person.

2. If the person is not aware of the software utilities he must be trained and then should

be given the machine to operate.

4.5.3 Security Requirements

For the sake of Security user will require

• Huge Server Backup• Trained user to operate software• A technical Person to check the online hardware.




4.5.4 Software Quality Attributes

Java EEJava Platform, Enterprise Edition or Java EE (formerly known as

Java 2 Platform, Enterprise Edition or J2EE up to version 1.4), is a

programming platform—part of the Java Platform—for developing and

running distributed multitier architecture Java applications, based largely

on modular software components running on an application server.

Java EE also features some specifications unique to Java EE for

components. These include Enterprise Java Beans, servlets, portlets

(following the Java Portlet specification), JavaServer Pages and several

web service technologies. This allows the developer to create an enterprise

application that is portable between platforms and scalable, while

integrating with legacy technologies.

J2ME

For future enhancement we can use J2ME.Java Platform, Micro

Edition or Java ME (formerly referred to as Java 2 Platform, Micro

Edition or J2ME), is a collection of Java APIs for the development of

software for resource constrained devices such as PDAs, cell phones and

other consumer appliances. Java ME is formally a specification, although

the term is frequently used to also refer to the runtime implementations of

the specification.

Sun Microsystems has tended not to provide free binary

implementations of its Java ME runtime environment for mobile devices,

rather relying on third parties to provide their own, in stark contrast to the

numerous binary implementations it provides for the full Java platform

standard on server and workstation machines.




4.6 Other Requirements

Appendix A: Glossary

JNI Java Native InterfaceDLL Dynamic Link LiabraryPLC Programmable Logical CircuitWCS Web-based Controlling SystemHTML Hypertext Markup LanguageOS Operating SystemVQ Server The computer was equipped with server

software called VQ Server.TCP/IP Transmission Control Protocol/Internet

ProtocolWWW World Wide WebGUI Graphical User Interface API Application Programming Interface




Appendix B: Analysis Models







Chapter 5

High Level Design Document

5.1 Introduction

5.1.1 Background

While working everyday diminishes opportunity for on campus study, distance

education becomes a major option and has been accepted widely. Though distance

education works for many fields of study, it is difficult for those fields that require

laboratory activities, such as manufacturing. The advancement of internet technology

tools developed in 1990’s made it possible to access a lab at distance. The internet

technology tools allowed development of the idea of an Online Laboratory. An Online

Laboratory would be maximized by remote control technology through internet.

In any distance remote access control the system is very good beneficial at the

crucial times. Doctors can use to do the distance operation so in such environments

system may function. Below are the technological environments.

Software Environment

• Any Platform

• Java Support

• Java Enabled Web Browser

• Apache Tomcat

• VC++/ VB6

Hardware Environment

• Parallel Port Interface

• Serial Port Interface

• Microcontroller

• Stepper Motor




• ULN 2803 (Darlington Driver)

• Bi-directional Buffer 74LS245

• ARM Hardware

Previous application from our project concept may available but we are going to

overcome all drawbacks of the previous application like fastest feedback of the operatin

on the application.

In our application DAM administrator is main person who will interact with the

application also other can be sub administrator .The benefit to the administrator will be

he can control the dam flow from any where in world by accessing internet only

5.1.2 Design Goals

The basic goal to design such remote application is that the laboratory activities at

distance can be done by accessing internet. So such application can be as follows

• Online Manufacturing,

• Online Dam Control

• Online Electrical Equipment Control

• Online Tele-Robots

• Online Lab Control

• Online Medical Surgeries




5.2 Architecture

5.2.1 Introduction

• The type of the system (client-server)

• On following platform system may work.

• SOFTWARE PLATFORMS:

o Java(Applet)

o Advance java(Servelet)

o JNI(Java Native Interface)

• HARDWARE PLATFPRMS

o Parallel Port Interface

o Serial Port Interface

o Microcontroller

o Stepper Motor

o ULN 2803 (Darlington Driver)

o Bi-directional Buffer 74LS245

o ARM Hardware

The major inputs can be the arm movement status and it can be

Forword,Reverse,Halfstep,Fullstep or the angle(Ex.90 degree). Outputs expected is the

feedback which will be displayed on client side at every time.





The distances between components on the web so it cannot be counted




5.2.2 Data

The database will be required for storing the values for the User ID and its

Password means authentication. It will be the important database required and it will be

the persistent data.

Introduction

The database which is best suited easy and secure for authentication will be used

like ORACLE or Access. Database will be selected for security requirements.

Schema

The above figure will give the details about data type used, number of

fields and the server will authenticate the person if it will be valid user on ID and

Password.




The above figure will show how the data can be stored in database with records.

File and Data Formats

Microsoft Access will be used as a database so the data format is .db for access.

Other file format will be as follow-

For java - .java,. Class

For VC++ - .dll

5.2.3 Communication

Whenever modules will communicate with each other it using TCP/IP protocol

for communication ,this section indicate following.

• Client will interact with the server through TCP/IP protocol using JAVA

and HTML as GUI.

• So the server will receive the connection request and it will initiate the

application.




5.3 Operation

Once the implementation will complete the operation of the application can be as

follows-

• Login to server.

• Call Hardware Module.

• Taking user input .

• Give feedback .

5.3.1 User types

User types for the application are only two

1. Administrator.

2. Sub administrators.

User Interface for both the user are same but the priority is given to the

administrator means if any situation the administrator want to take control on overall

application he will lock the application and took control.





The user(Administrator or Sub administrators)) who knows the application

working can only work on this application so at the time of application planting user

manuals are given to understand the system working so the user can work on it. Only

authenticated persons can only access this application.

No other person can work concurrently on it if anybody working on it only

administrator can take control over the system.




5.3.2 Installation

For installation of the application some are the hardware and software

requirement are as follows .

HARDWARE REQUIREMENTS:

For Server:

1. Pentium 2 Processor

2. 128 MB RAM.

3. 4 GB of hard disk space.

4. Parallel / Serial Port

For Client:

1. Pentium 2 Processor

2. 64 MB RAM.

3. 4 GB of hard disk space.

4. Internet

SOFTWARE REQUIREMENTS

1. Windows 98 and above

2. J2EE

3. Tomcat

4. J2SE

5. Java Enabled Web Browser

Installation can not be done by anyone it requires the system engineer who knows

the installation skill very well. For installing software require CD to load the database on

internet server which is used as web for the application. The installation will require

serial key because it is very important application.

5.3.3 Licensing

Licensing is a very important for any software , in this application licensing will

be available by some internal consistency check at the regular intervals.




5.3.4 Upgrades

After some time of period each and every system needs to be upgraded so in this

application up gradation will be done into newer versions .We have consider following

things for up gradation as follows.

• It should be distributed through internet only.

• Appropriate license will be verified at time of up gradation.

• Only administrator can install the up graded version with or

without any system engineer.

• It will be not complicated to install.

• For hardware up gradation the engineers from our company will

visit the particular site.

• No we have not planned for any demo version before selling.

5.3.5 Uninstall

For this application uninstallation will require the system engineers from the

company, because server installed program and hardware setup can be uninstalled by the

system engineer only if any one try then it will affect on the Dam Window.




5.4 Development

In the development field for these application first needs to collect hardware

resources required build hardware setup, without hardware configuration we cannot

implement software for it. So hardware module will be essential to setup before the

software.

Now need of server machine with domain address will be one of the essential

requirements for development. We are developing this with only single team of four

members, so concurrent developments will not possible .For accessing this domain will

be essential constraint.




5.5 Miscellanea / Appendices

5.5.1 Conformance with standards

Application will be dependent on the internet fully so the IEEE standard will have

to follow. References for the standard will be available on the following links.

1. www.wekipedia.com

2. http://portal.acm.org/

3. Proceedings of the 1997 IEEE 6th International Conference on

Emerging Technologies and Factory Automation, Los Angeles,

September 9-12 1997, Page 825- 832.

5.5.2 Security

For the sake of Security user will require

• Huge Server Backup

• Trained user to operate software

• A technical Person to check the online hardware.

5.5.3 Glossary

VC++ To generate Inout.dll which provides hardware interface with the system

J2EE Java 2 Platform, Enterprise Edition (J2EE) defines the standard for

developing component-based multi tier enterprise applications.J2SE Java 2 Platform, Standard Edition (J2SE) 1.5



http://portal.acm.org/

http://www.wekipedia.com/


5.5.4 Bibliography

Books:

vi. Parallel port complete

vii. Serial port complete

viii. Microcontroller - Mazdi

ix. Vb.NET

x. JavaTM Speech API Programmer's Guide

Web:

vi. http://google.com

vii. http://wikepedia.com

viii. http://beyondlogic.com

ix. http://boondog.com

x. http://processing.com


http://www.processing.com/


http://www.boondog.com/

http://www.beyondlogic.com/

Documents

Controlling Remote Robotic Arm through Internet Report