the umi rtx robot: simulated human...

The UMI RTX Robot: Simulated Human Anatomy By; Jaime Zabala and Frank Bejerano

CEN 3213 Embedded Systems Programming Prof. Janusz Zalewski

Florida Gulf Coast University April 21, 2008

Zabala, Bejerano - 2

Table of Contents

1. Introduction .......................................................................................................................3-8

1.1 What is a Robot? ............................................................................................................... 3

1.2 UMI RTX ............................................................................................................................ 4

1.3 Java Original Code ............................................................................................................ 6

2. Problem Specification ..................................................................................................... 8-10

2.1 Web Control Questions ..................................................................................................... 8

2.2 Java Benefits ................................................................................................................... 8

2.3 Procedure to Control Remote Instrument ......................................................................... 9

3. Solution Overview ......................................................................................................... 10-14

3.1 Web Availability .............................................................................................................. 11

3.2 Video Output ................................................................................................................... 11

4. Implementation and Testing ......................................................................................... 14-27

4.1 Is a Remote Session Possible ....................................................................................... 14

4.1.1 Server .................................................................................................................... 14

4.2 How Would a User Control the Robot? ........................................................................... 15

4.2.1 Code Modifications ............................................................................................... 16

4.2.2 Applet in the HTML ............................................................................................... 20

4.2.3 User Procedure ..................................................................................................... 20 4.3 Where Would Our Code Run? ......................................................................................... 22 4.4 How will the user know the robot is working? .................................................................. 24 4.5 Why would a user want to control the robot? ................................................................... 26 5. Conclusion & Future Work ............................................................................................ 27-28

5.1 Why doesn’t the applet work? ......................................................................................... 27

5.2 A Different Approach ...................................................................................................... 27

5.2 Password Protection ...................................................................................................... 28

6. References........................................................................................................................... 29


1. Introduction

1.1 What is a Robot?

A robot is a machine that resembles a human and does mechanical, routine

tasks on command. All robots must be put together in one way or another by a human

first. Programmers give the robot life with coding, telling it what to do. Designers map

out the robots purpose and structure, while assemblers put together the skeleton of the

robot. In our case, we will be dealing with the programming, to maximize the efficiency

of the robotic arm’s design and structure.

Robotic arms are generally used to perform repetitive tasks both efficiently and

quickly. Industrial robots prove more efficient than human workers for certain task

because a robot makes very few mistakes, doesn’t need breaks, and doesn’t tire.

Robotic arms also offer the ability to reach places that are difficult or dangerous for

human access, such a space station or a hostile war zone.

Figure 1.1: CanadArm at ISS in use Figure1.2: SWORDS robot at attention


The SWORDS robot shown in figure 1.2 is currently being used in Iraq to deactivate

bombs and serve as a “first man” through doors (BBC News, 2006). Similarly, the MDA

CanadArm2 seen in figure 1.1 is helping astronauts in the International Space Station

do repairs more safely (MDA Essential Information Solutions, 2006). Robotics is a

developing technology that is constantly changing to match our needs.

1.2 UMI RTX

The Robotic arm that we are using is the UMI RTX Robot figure 1.3, was first

available in 1986, designed with 6 degrees of freedom (Knight, 1999). The number of

DOFs (degrees of freedom) that a manipulator possesses is the number of independent

position variables that would have to be specified in order to locate all parts of the

mechanism. In other words, it refers to the number of different ways in which a robot

arm can move see figure 1.4.

1. Linear- consisting of a simple up and down movement.

2. Shoulder- allows for rotation of arm.

3. Elbow- allows the rotation of the arm.

4. Wrist- control of yaw

5. Wrist – control of pitch

6. Wrist- control of roll


Figure 1.3: UMI RTX

Figure 1.4: The motion of the UMI (Universal Machine Intelligence) RTX is comparable to that of a real

arm.

The UMI RTX was intended to work in a cylindrical workspace, allowing for

simple vertical movements and rotation around its base, it cannot however access

anything on its back. This robot was initially designed to be used with Turbo Pascal

which had libraries to support it. Turbo Pascal was available from 1983 until 1992

(Knight, 1999). Our current code is in the newer Java language and is executed through

the Eclipse editor/compiler/debugger.


Figure 1.5: Serial to RS-232 cable

The computer is connected to the robotic arm through a serial link from the

computer’s Serial port to a RS-232 socket at the connection panel of the robot. Through

this cable seen in figure 1.5 the computer sends binary commands generated by the

java code directly to control the arm.

1.3 Java Original Code

Thanks to the work of prior students Neven Skoro and Jonathan Eren (Skoro &

Eren, 2006), we have the opportunity to work with a Java program that allows for

improved control of the robot. The 6 degrees of freedom can be independently operated

by the robot’s four 65Hz motors, located in the base, elbow, and shoulder. The GUI as

developed by Mr. Skoro and Eren, allows for this independent control, much like only

moving one part of one’s arm. While it can be done, many times a combination of

movements of all parts is necessary to achieve the desired motion.

Figure 1.6: Melvin GUI

The GUI’s design seen in figure 1.6 can be summed up in the three parts.

Set up – “Connect” “ON” “OFF” “Home” all perform actions which either prepare

the robot for use, or end its use.

Input – the bottom row including “ZED” “Shoulder” “Elbow” “Wrist Yaw” “Wrist1”


“Wrist2” “Gripper” must be inputted prior to any desired movement other

than home. ZED here refers to the vertical movement of the unit, achieved

by a band and motor at the base of the robot.

Action – “Move” “Stop” “Exit” are all actions that may be taken by the program or

robot. Move executes all inputs simultaneously and stop stops all

movement.

Figure 1.7: RTX context diagram

The Java RTX program is controlled by the main class which initializes all the motors

and communicates with the user via the Melvin_GUI class. Each motor is controlled by

a separate class. When the user enters the information to the GUI, the GUI calls the

methods in the main class which operates on separate motor objects created.

Additionally, there is also a connect class called “ConCom” which seeks out and makes

a connection to the robot through the com port. Note – without first running the Connect

GUI Class

Shoulder Class

Elbow Class

WristH Class

WristT Class

WristV Class

Gripper Class

Column Class

Main Class

User

Connect Class


Class and making a proper connection, any movement or further communication to the

robot is not available.

2. Problem Specification

2.1 Web Control

While working with the RTX, we will attempt to make it available for operation

over the web. This remote operation will allow a user with internet connectivity to control

the robot from anywhere in the world. A remote machine like the RTX would prove

useful for doctors, soldiers, engineers, and astronauts.

There are a number of questions we must answer in order to achieve remote

connectivity. 1. Is a remote connection possible?

2. How would the user control the robot?

3. Where would our code run from?

4. How will the user know the robot is working?

5. Why would a user want to control the robot?

Since neither of us have ever designed a web based remote program, heavy

research is required on the aforementioned questions. While we do have several server

options available (such as Satnet) capabilities must be determined in accordance to the

robot’s requirements for operation. As of February 27, 2008, we did not still have a fully

functioning machine code. Further development and adaptation for our new needs was

necessary. Also, a suitable location from which to remotely access the server had to be

chosen. High internet integrity and reliability are important in order to minimize the

communication time between the server and user.

2.2 Java Benefits

We are fortunate to be working with a Java program which allows for:

– Platform independence, which allows for understanding of multiple coding

methods.


– Only needs to compile once and may run any number of times thereafter;

handy because the program will run many times with little need for coding

changes.

– Java applet can run on user side via the internet. User has direct access

of a GUI.

– More flexibility, interactivity and immediacy. Connects to servers and com

ports with greater ease than older programs. Also, already has libraries

developed specifically for robot controllers.

– Continuous connection between user and server

– More friendly and easy-to-use user interface(GUI) (FAQ Applet Security,

1995)

2.3 Procedure to Control a Remote Instrument

– We must use an internet browser to connect to the web site where the

instrument is located. This website must be developed.

– We need to create or adapt the current Java applet to allow a web

browser to run it.

– The Java applet must establish a TCP (Transmission Control Protocol)

connection with the server program running on web server. This

connection must be figured out and we must check if there are any

servers that we can use for this purpose.

– The java applet will need to send the desired parameters to the server

based program.

– The server program would need to figure out if the parameters given are

appropriate.


– The server program then will need to generate commands and transfer the

commands to the Lab PC to which the instrument is connected and

controlled.

– The Lab PC will need to execute the commands and acquire output of the

instrument.

– The acquired data will be transferred from the Lab PC through the server

and back to the User PC.

– Verification of the UMI RTX’s movements and accuracy will be done

visually through a webcam.

– To get a new result, the user just needs to change the value of parameters

in the GUI and click the move button.

We will need to find a way to broadcast the movement of the Robotic Arm in real time.

This will also depend greatly on the internet connectivity of the lab pc, server pc, and

user pc. A proper connection will allow for real time control without lag or high latency.

A web enabled camera will be integrated into this part of the operation, possibly one

from a lap top.

3. Solution Overview

In order to achieve control of the UMI RTX robotic arm via remote web access,

we will attempt to use the java GUI provided by Neven Skoro and Jonathan Eren.

However, it seems that we may have to create our own separate applet to make our

web page call a remote session with the lab computer using Remote Assistance. The

current firewall in FGCU may prevent this remote session from occurring, as we have

already experienced problems allowing live streaming video through ports not

authorized by the FGCU computer center. This problem is furthered because of the

restrictions creating private IP addresses for the computers accessing the internet

through wlan-public wireless connection. Since we may not remove the robot from the

RH256 computer lab due to size restrictions, we must find a way around these firewall

issues. If we could control FGCU’s firewall and if the connection is initiated we will have


full control over the Lab computer (computer to which the UMI RTX robotic arm is

connected to). We will run the Java applets from yet to be determined server, to which

the lab pc has access to.

3.1 Web availability

Through our research, we have discovered that in order to access the controls

for the UMI RTX robotic arm through the internet, we need to have a place where our

java applet can be accessed universally. The best solution for this is to place it on a

website that in turn would access a server, then to our lab PC. The website would have

to be java compatible and allow java applets to run, as well as some form of video

feedback. Additionally, we will need a server which also supports java files. The

website will allow the user to access the applet, after a prompt for a username and

password. It must access the server and lab PC with as little response time as possible

to ensure proper movements of the robot. The robot needs a total of 16ms to receive

and return the proper data on movement, so anything more than 8 ms may cause an

error in the motion of the robot (Skoro & Eren, 2006).

For our need, we have looked into JSP. A Java Server Page (JSP) is a servlet

from Java that executes in a Web container (contract specifies a runtime environment

for web components that includes security, concurrency, life-cycle management,

transaction, deployment, and other services). Our server must also have access to the

lab PC, whether it is located at FGCU or elsewhere.

The lab PC may be any computer with an external serial port to which the RS-

232 robot port can be connected. The lab PC does not actually have to contain the

code for the robot movement. Since the code itself will be running on the server and the

graphic user interface will be on the website, all the lab PC has to do is provide a

connection between the robot and the server.

3.2 Video Output

The problem as to how to figure out a successful trial can be solved by one of

two ways. Either a person visually sees the robot and knows what the correct

movements are, or a live video showing the real-time movements of the robot are


streamed as part of the user’s interface. For the sake of over achievement, we will

employ the second option and provide the user with a more complete experience and

instant feedback.

We are currently working with Yahoo Live!, a service that facilitates live video

and audio streaming (Y! LIVE, 2008). Along with the free software provided after

registration by Yahoo Live!, we will require the use of a webcam, a sound card, and

broadband internet connection. Y! live works by running an encoder which gives the

user the option of streaming a live or previously recorded video. When you run the

Encoder and press the 'Live' or 'Archived' button, it appears as if you are broadcasting.

The computer begins listening for incoming connections in order to send the stream out.

This is the same principle as you requesting a page from www.fgcu.com. Yahoo Live!

Works like a server, listening and waiting to send out pages on demand. Our Encoder is

doing exactly that: waiting for the server to come along and pull the stream.

Figure 3.1: Y! live Broadcasting

http://www.fgcu.com/�


Another option in case the firewall issues cannot be resolved in time, would be

the use of instant messenger software such as AIM to take advantage of its “peer to

peer” video conferencing (Aim Instant Messenger). In actuality, AIM runs through a third

party before reaching the receiving computer so would not be as direct as “peer to peer”

sounds. Both users must download the required software and create accounts within

AIM. Knowledge of the account names is necessary as well as webcams for each

computer, and comparable internet connections. A request for video streaming must be

made by either user and accepted by the other before any connection may begin which

again would require a person to oversee the lab PC during execution.

However Yahoo Live! offers a more attractive solution because the user would

not need to sign up with the provider or have to download any additional software to

view the live stream, it would simply be embedded in our webpage. Yahoo Live! also

allows for multiple clients to view the stream simultaneously and AIM does not. Yahoo

Live! operate on its own three servers with little traffic, which allows the streaming

bandwidth to always stay above 500kbps, more than enough for our purpose. More

importantly, Yahoo Live! is a free service and thanks to our humble student budgets, it

is all we can afford.

A solution that we may try to experiment with is connecting to the internet using

a dial-up connection; this should surpass the Florida Gulf Coast’s established firewall

and allow our video feed as well as the server-lab PC connection to be broadcasted. A

dial-up internet connection however may not provide a very responsive video feedback.

While the communications between user/server/lab PC must be fast, the streaming

video will likely have an estimated 2 second delay should we use Yahoo Live!. Worse

yet, with a dial-up connection this lag may increase to nearly 1 minute. If we are unable

to place the video stream on the user website, Yahoo Live! also provides an HTML code

for the stream so the video could easily be integrated into a separate window, though

still in sync with the applet.

4. Answers to Questions (Conclusion)


4.1 Is a Remote Session Possible?

We have discovered that yes; remote sessions are possible, given some specific

circumstances. First and foremost is the issue of the router and FGCU firewalls.

Router/Firewalls – The lab PC that we have been dealing with is behind a router, or

point of access for the internet. All computers in FGCU must go through this router in

order to reach the internet and are thusly connected in a network. The issue here is that

have an “internal IP address” and cannot access it from anywhere outside the network

without first following several procedures. We must discover the routers IP address,

also called the exterior IP of the network. Additionally we must apply to have a port

open to the pc which we need to access. The connection via a browser would look like

http:// <external IP address> : <port number>.

However, due to the unwillingness of the FGCU network administrators to facilitate our

progress, we have been forced to request a computer with an independent IP address.

This means that we would no longer have to go through any FGCU router or firewall in

order to access the web.

4.1.1 Server–

After testing out several options that FGCU had to offer in regards to servers, we

discovered that none either met our needs or allowed us access. Satnet runs on linux

which is not compatible with the Java API since win32dll is used. And after repeated

requests to use ROCK server, we never received back word of approval. A simpler

option of running our own server became our only answer. Abyss Web Server, available

at www.apreilium.com is a free web server that may be run from any pc with Windows

XP or Vista (Help and Support, 2006). Abyss works by running our Lab PC accepting

HTTP requests from the users, which are known as web browsers, and serving them

HTTP responses along with optional data contents, which usually are web pages such

as HTML documents and linked objects (images, applets, etc.). Now, in order to access

our Lab PC/ Server, all we have to do is type in the IP address 150.104.238.130. Along

with the port under which the server is running and a html page in the directory to which

the server is pointing (on the Lab PC) will open. This html page must be named

index.html as the server displays this page first by default. The issue with this access

http://www.apreilium.com/�


method, is that IP addresses and port numbers are very difficult to remember, thus it will

only make the remote use of the robot less attractive. The answer to this issue is to

make a domain name which will connect to our server via the IP address.

www.DYNDNS.org is a company that deals specifically with domain names, and

website development (DynDns, 2009). With the creation of a free account, the allow

access to any one of their services at no cost. Two of their services are appropriate for

our use: IP connection – which actually broadcasts our server on a domain name of our

choice, www.rtxrobot.endofinternet.com and WebHopper – which simply reroutes a user

toward our server, keeping our IP address hidden, when they type in a domain of our

choice.

4.2 How would a user control the robot?

Original Code -

The code, as it existed prior to our project, consisted of a main method in a Grapical

User Interface. Through a Jframe, it creates a window menu used to accessed the other

components of the program through action activated buttons . These buttons call the

InterRob package with 11 class files and 1 GUI class file.

- The “Connect” button refers to the ComCon file which uses

javax.comm.CommPortIdentifier to make a connection with the UMI RTX Robot

via the computers COM ports.

- The “ON” button refers to the interRob file which imports javax.comm.SerialPort .

This is the most important class file since it ties in 7 other class files, making the

robot’s movements possible. Additionally this interRob also contains the method

used to power on the robot, making it the second file to be called by the GUI.

- The “OFF” button refers to the interRob file as well, putting the robot through a

sequence of movements in order to properly calibrate it for its next use. The

movements also serve as a simple demonstration of the robots over all rage of

movement.

- The “HOME” button calibrates the robot’s position into it original intended

position. If any mechanical malfunction of the robot is entered during its prior use,

http://www.dyndns.org/�

http://www.rtxrobot.endofinternet.com/�


this calibration will assure the mechanical position and inner working of its belts

are properly aligned.

- “Move” bottoms are available for each independent movement possible by the

robot. There is also the option of a “move all” option that permits the user to

move several of the axes of motion at the same time.

- “Stop” buttons was intended in this program to terminate the operation of the

robot, in an instance where its movement would be incorrect; however the button

was originally un-operational.

4.2.1 Code Modifications

The original code’s GUI was modified into an Applet to facilitate its use through a Client

browser. This was achieved through the help of both Prof. Zalewski’s and Dr. Guo’s

notes for the COP3003 Object Oriented Programming class (Guo & Zalewski). Since

neither of us has ever created an applet or much less made anything web available, this

is where we had to begin. Our first modification was of the GUI itself. We created a

separate file name JoggleApplet.java which in the end would replace the GUI file named

Melvin_GUI.java.

- Since we were designing an Applet and not a JFrame, we would have to transfer

much of the data in Melvin_GUI into a new format.

Public class Melvin_GUI extends JFrame implements ActionListener

Was changed into

Public class JoggleApplet extends JApplet implements ActionListener

- The first area where these two programs would differ is in their definition of the

Constructor.

Since applets are organized in a different way, we found that rather than a main

method, we would have to use something called an init. Therefore,


Public static void main(String args[]){

Melvin_GUI G1 = new Melvin_GUI();

}

Was changed to

Public void init(){

JoggleApplet G = new JoggleApplet();

}

- Next, we changed the graphical settings. The original GUI was light grey with

orange buttons. We altered these colors to give a better coordination with our

webpage.

HomeBTN.setBackground(Color.orange);

Was changed to

HomeBTN.setBackground(Color.white);

- During execution, we noticed that when a parameter for motion was entered and

its respective move button was pushed, all pending motions would be executed.

This occurred because it was taking all the lines into account when executing the

method for robot movement (InterRob.pushpos)

if( e.getSource() == Zed_MoveBTN)

{

_Zed = Integer.valueOf( Pos_Zed.getText()).intValue();

_Sh= Integer.valueOf( Pos_Sh.getText()).intValue();

_El= Integer.valueOf( Pos_El.getText()).intValue();

_Wy = Integer.valueOf( Pos_WY.getText()).intValue();

_W1 = Integer.valueOf( Pos_W1.getText()).intValue();

_W2 = Integer.valueOf( Pos_W2.getText()).intValue();

_Gr = Integer.valueOf( Pos_GR.getText()).intValue();

inputOk=true;

checkPosition();

if(inputOk){

InterRob.pushPos(


_Zed,_Sh,_El,_Wy,_W1,_W2,_Gr);

}

}

Was changed into

if( e.getSource() == Zed_MoveBTN)

{

_Zed = (int) 35.5 * Integer.valueOf( Pos_Zed.getText()).intValue();

inputOk=true;

checkPosition();

if(inputOk){

InterRob.pushPos(

_Zed,_Sh,_El,_Wy,_W1,_W2,_Gr);

} Additionally, the original code also set arbitrary numbers for limits on the robots

motion.

Ex. Shoulder: 2633 to -2630, Wrist Yaw: 846 to -846 Gripper: 1200 to 0.

In order to keep the integrity but further facilitate the user’s experience with the

applet, we made all movements in the ranges from -100 to +100. By dividing the original

limits by 100, and later using that number to multiply by the input number (between -100

and +100) we return to the original value, however the user still only simple 0 to 100

digits.

Perhaps the most valuable coding change that we did came in the ComCon file. The

issue that arose once our applet had been created was that it could not load files from

the comm.jar file we had.

The exception we kept receiving stated

Java.langNullPointerException: name can’t be null while loading driver

com.sun.commwin32driver.


We managed to fix this problem through a series of try and catch statements. String driverName = "com.sun.comm.Win32Driver";//com.sun.comm.Win32driver

javax.comm.CommDriver driver = null;

try

{

System.loadLibrary("win32com");

System.out.println("Win32Com Library Loaded");

System.out.println("Win32Com Library Loaded");

}

catch (Exception e)

{

System.err.println(e);

}

try

{

CommDriver driver = (javax.comm.CommDriver)Class.forName(driverName).newInstance();

System.out.println("driver loaded! ");

}

catch (Exception e)

{

System.err.println(e);

}

try

{

defaultPorts = new String[8];

defaultPorts[0] = "COM1";






defaultPorts[6] = "/dev/ttyUSB0";


defaultPorts[7] = "/dev/ttyUKSB1";

portList = CommPortIdentifier.getPortIdentifiers();

CommPortIdentifier portid = null;

//find right comport

while(portList.hasMoreElements())

{

4.2.2 Applet in the html –

In order to make our robot available to the masses, we had to first make a webpage in

which we could place our applet. Through the use of Visual Web Developer 2008

Express Edition, we designed a simple but functional layout (Visual Web Developer,

2008). It contains attractive pictures of both developers and of course the applet itself.

Due to security reasons, the user must first consent to the applet’s download and

activate activex, after which the applet will pop-up in the center of the screen. In case

that the user’s browser is unable to load the applet or display it, a message “Your

browser does not support applets” will appear in its place.

<applet code=interRob.JoggleApplet.class ARCHIVE=comm.jar

WIDTH="0" HEIGHT="0" >

Your browser does not support applets

</APPLET>

4.2.3 User Procedure

The client or user side of this project will be very straight forward. The user must

have a fast internet connection, preferably broadband, and be able to access and

download the applet that we have created. The webpage will be located on the student

server and will be available to any FGCU student or staff member. Upon the completion

of the applet’s download, a JFrame style menu will pop up and greet the user.

("Welcome to the R.T.X. Control Applet." '\n');

("Written by: Jaime Zabala and Frank Bejerano" + '\n');

("Press the CONNECT button to start a connection with the COM port" + '\n');


("Press ON to get started!" + '\n');

(“Please HOME the robot to ensure proper execution!” + '\n' +

“Column (-100 to 0) Shoulder (-100 to 100) Elbow (-100 to 100) Wrist Yaw (-100 to 100) Wrist 1 (-100 to

0) Wrist 2 (-100 to 100 ) Gripper (0 to 100) “ + ‘\n’ +

"<-------------------------------------->" + ‘\n’);

The user will be asked to press the connect button to open the lab PC’s COM port for

communications with the UMI Robot. Once the connection has been established, the

user will be prompted to press the “ON RTX” button to turn on and initialize the robot.

The “Home” button takes care of all necessary initialization, since the robot is not

always turned off in the Home position. In these cases, when the robot boots on, it will

consider its present location to be Home and all movements will be relative from this

position. Also, the reason that this initialization is not made mandatory is because

sometimes the home position does not replicate itself exactly and a manual homing

must be performed. Now that the robot is online, the user must input numbers from -

100 to +100, depending on which motion is required. Then the user must press the

appropriate move button, or the one at the top of the page to execute all movements.

The user will receive almost immediate feedback through the image in the center of the

page.


Figure 4.1: UMI RTX control website version 1.0

4.3 Where would our code run from?

• The most logical place from which to run our code is from the Lab PC/ Server

that we have developed. This will allow us to have the robot and robot code on

the same machine, thereby simplifying the connection. The only necessary step

is to point the directory of the server to the folder that contains the compiled robot

code, our libraries, and most importantly, the webpage named index.html. From

this webpage, our applet class is called – interRob.JoggleApplet.class which

accesses the applet and its corresponding classes. The issue which arises from

this is the restrictions set by both Java Sun and Windows to the capabilities of

applets. These limitations include

• No local file system access. Actually, this is not always true - it depends on the

precise SecurityManager in operation. For example, the usual implementation of

the appletrunner, which allows applets to be test-run independently, has

configurable security settings, and so do some browsers. However, many


browsers do not permit any file system access, so it is very unwise to rely on it.

This effectively means that an applet cannot access data files, or store state

information, on the client's file system.

• Network access only to the launching server. Strictly speaking, this need not

be true either, though in practice it usually is. Again it depends on the

environment in which the applet is run, but as with file system access many

environments do not allow this to be configured. This means that the only reliable

source of data and storage for an applet is on its host server.

• Cannot extract important information about client. Not all important

information about a client is only held on the file system - sensitive data is held in

memory as well. Applets should not have access to such information.

(Incidentally, the definition of 'not important' includes things like line and file path

separators, and 'important' includes username, email address etc.)

• No local executables. Applets are not permitted to invoke any local executable

program on the client's machine.


Figure 4.2: Internet Connectivity Chart

So in order to get past these restrictions, there are some loopholes we must travel

through (FAQ Applet Security, 1995). First are the java policy files. Java has a security

folder located in <Java edition>/lib/security which contains all the security rights for

different applications and applet executions. Here we must place a file to allow applets

to engage in procedures they otherwise would be prevented from doing. Jonathan Eren

and Neven Skoro created such a policy file named Java.policy.applet, which grants all

properties to any applet on the machine. Secondly, our code uses javax.comm to open

a com port and “listen” to the robot, and must be included in the ‘lib’ folder. Thirdly, the

extra libraries which we use must be placed in the ‘bin’ folder also within the java folder,

so when the applet access the java codes, these files will be available and allow the

applet to properly execute. As a “just in case” we have also signed and certified our

applet for use on the Lab PC, and both our lab tops. Finally, the line

System.setSecurityManager(null);

has been added to the top of the methods to bypass the restrictions not allowing the

applet to read internal files. If these steps are followed on both client and server

machine (those applicable), this should further ensure proper communication between

robot and applet. A more complete list of applet restrictions may be found at

http://java.sun.com/sfaq/ .

4.4 How will the user know the robot is working?

The plan all along was to allow the user to see the robot in real time, over

streaming live video. Streaming video entails both video and sound. The issue here was

that it was making our website too slow to load, and along with a fairly complex applet,

the browser required nearly a minute to fully load the page. Since we did not really

require sound, it seemed unnecessary to have the said streaming video and perhaps a

better solution could be arrived at, again, through our own web server. The discovery of

Dorgem software opened up a new possibility (Dorgem Webcam Capturer, 2005).

Dorgem is an open source webcam capture program that takes still pictures through a

webcam and places them in a file, repeatedly refreshed every n-th second/minute/hour.

http://java.sun.com/sfaq/�

The problem here was that if we used this approach and placed the image on our

webpage, it would have to be repeatedly refreshed in order to see the movements of the

robot. This in turn would mean waiting for the page to load numerous times and the

presence of multiple applets. The solution was found by incorporating a refresh

sequence into the HTML code under which the image was placed.

<IMG src="rtx.jpg" width="275" height="200" border="1" name="refresh">

<SCRIPT language="JavaScript" type="text/javascript">



</SCRIPT>b

As you can see, the function start is created which calls the refresh of only rtx.jpg

(our captured image which is in turn also refreshed ever 1 second). This code makes it

possible to have a video, albeit slow and disjoint, and a much faster webpage.


4.5 Why would a user want to control the robot?

Figure 4.3: RTX control Site 2.0

While the possible applications of our robot are endless, a simple run of the mill user

would not be performing surgery with it nor deactivating a bomb. We must rely on their

curiosity to drive them to visit the site and engage with the robot. To help keep them at

the site, we developed a simple game that can interact with the user. The children

favorite “Rock, Paper, Scissors” was designed to that a user could play either with

someone present at the lab, “2 player”, or by themselves, “Single player”. For two

player, the user picks one of three options, Rock, Paper, or Scissors. The robot will then

perform the specified action. Up and down twice before performing rock, paper, or

scissors. else if( e.getSource() == ONEP) //One Player Code

{


Random rn = new Random();

int r = rn.nextInt(3);

if (r==0){

///Code for Scissors

}

Else if (r==1){

// Code for Rock

}

Else {

// Code for Paper

}

If the user chooses the Single player option, then he/she will play against the same

three choices, only they will be generated randomly. When the game is done the user

should click EXIT PROGRAM and the applet will close, leaving the web page still open.

5. Conclusion & Future Work 5.1Why doesn’t the applet connect with the robot? –

As we wrote the applet, being our first, we constantly compiled and executed on

the Eclipse software. This software, we believed, would give us an accurate portrayal of

how the applet would behave in a browser. When it came time to actually run the applet

from an existing webpage, we found that although the applet did appear and there was

some functionality from the buttons, there was no connection to the robot. A few probes

were inserted within the JoggleApplet (applet) file, the ComCon (connection) file, and

the InterRob (miscellaneous) file. When the appropriate buttons were pushed, the probe

would trigger an additional window to pop up, containing the probe #. We found that

probes placed at the beginning of the respective methods would execute correctly, that

as files like win32.dll and drivers were initialized (com port driver used to connect to

robot), the applet would hit a brick wall. Again, we compiled and ran the code in Eclipse

and appletviewer, both successfully.

So why does our applet run correctly in all places except browsers?

The issue, as we discovered, has to deal with the restrictions on applets as set

down by many factors, the least of which is exceptions or compiler errors.


Apparently there is a compatibility war between Sun Microsystems and Microsoft

that has left many casualties, us included. The problem lays in the policy and

securities set down by Microsoft for its operating systems and the rights available

to java. Without extensive knowledge in both networking and java, along with a

little luck, it would be impossible to get past this roadblock that we have

experienced.

5.2 A Different Approach

There may be a different way to run the robot remotely. This would be fairly more

complicated than our current implementation, however through a manipulation of the

said restrictions, we may be able to find workable solution, using the same applet

and corresponding code.

1. A new method would have to be added to the existing code, with a loop which

runs during the entirety of execution. It would check for the existence of a file

named appletinput.txt in the same folder as the applet code.

2. During the execution of the applet in the webpage on the user side, the applet is

used as a form, to simply take down the operations.

3. Maintaining a persistent state, the applet writes to a file in the server-side which

is then sought out by the loop which should already be executing.

4. The file is then used by the loop and the numbers from the form are inserted into

a movement sequence, much like that of HOME or the game buttons.

5.3 Password Protection

The addition of a password protection page will help control who can and who can’t

use the robot. The concern is that two or more users will attempt to simultaneously

use the applet to control the robot, causing errors. By prompting any user who

enters the website for a password and username, we may better control the access

of our website to a select few. Although we are not featuring this in our final website,

I did test it out on a simple helloworld.html. The password protection works by

creating a simple html document in VS Web Developer 2008 which will feature

password and username boxes. A series of “if” statements confirming the correct

username and password will link the user to the next page where the robot is

located.


Works Cited Aim Instant Messenger. (n.d.). Retrieved from America On Line: http://dashboard.aim.com/aim BBC News. (2006, November 28). Retrieved February 27, 2008, from BBC.com:

http://news.bbc.co.uk/nolpda/ifs_news/hi/newsid_6189000/6189228.stm Dorgem Webcam Capturer. (2005). Retrieved from Dorgem: http://dorgem.sourceforge.net/ DynDns. (2009). Retrieved from A Dynamic Network Services Website: http://dyndns.org FAQ Applet Security. (1995, December). Retrieved from java Sun: http://java.sun.com/sfaq/ Guo, D., & Zalewski, J. (n.d.). Itech.fgcu.edu. Retrieved from FGCU Faculty Database:

http://itech.fgcu.edu Help and Support. (2006). Retrieved from Aperilium: http://www.aprelium.com/support/ Knight, G. (1999, June 18). UMI ROBOT USER AND PROGRAMMER’S MANUAL. Retrieved

from Computer Systems Design: http://services.eng.uts.edu.au/~carlo/pdf/Hitsquad_Robot_Manual.pdf

MDA Essential Information Solutions. (2006). Retrieved from MDA.com:

http://sm.mdacorporation.com/what_we_do/canadarm2.html Skoro, N., & Eren, J. (2006, April). A Study on Robotics. Retrieved from Florida Gulf Coast

University: http://itech.fgcu.edu/faculty/zalewski/COP4935/RTX-ReportApril06.doc Visual Web Developer. (2008). Retrieved from Microsoft.com:

http://www.microsoft.com/express/vwd/ Y! LIVE. (2008). Retrieved from Yahoo: http://live.yahoo.com

the umi rtx robot: simulated human...

Documents