Polaris Server Code: Java Implementation for TINI Andrew A. Kitchen Kevin Wiehe Computer Integrated Surgery 11 May 2001.

Polaris Server Code: Java Implementation for TINI

Andrew A. Kitchen

Kevin Wiehe

Computer Integrated Surgery

11 May 2001

Presentation Outline

• Project Overview

• Problems and Dependencies

• Deliverables

• Schedule

• What we’ve learned

• The Near and Distant Future

Polaris Server Code: Java Implementation for TINI

Creation of Server (and Client) code for distributed control of a Polaris Tracker device—in Java

for the TINI device

www.ndigital.com

www.dallassemiconductor.com

The Hardware

JacOrb ServerClient

Polaris Tracker

IDL

Stu

b

IDL

Stu

b

TINI Device

Ideal Information Flow Through Polaris Server / Client

Ethernet

RS-232

Outside the Lab In the Lab

ServerClientCompletely abstract

Polaris TrackerNot actual size

TINI DeviceActual size

Actual Information Flow Through Polaris Server / Client

Ethernet (TCP)

RS-232(Null – Straight)

In the Lab Across the Lab

Java Polaris Tracker Class

1. Init() – send serial break to reset Polaris and initialize

2. Config() – set Communication baud rate, number of bytes sent, etc.

3. GetTransformation(tool)- return Quarternian representing translation and rotation of tool, return RMS error.

4. PolarisStatus()– returns status of tools in ports

5. Start/StopTracking() – begin or end tracking mode

Presentation Outline

• Project Overview

• Problems and Dependencies

• Deliverables

• Schedule

• What we’ve learned

• The Near and Distant Future

Dependencies

1. ExternalA. Access to TINI – Fulfilled.

B. Access to Polaris – Partially Fulfilled.

C. JacORB ported to TINI – Will Not Be Fulfilled.

2. InternalA. Working Java serial port code – Fulfilled.

B. Basic Polaris server code – Mostly Fulfilled.

C. Distributed Control with TCP – Will Be Fulfilled.

D. Client code – Will Be Fulfilled.

What’s the Problem?1. Controlling the TINI serial port

A. The TINI won’t send data across the serial port• Straight serial cable vs. Null modem cable

B. The TINI refuses to allow control of the serial port• Acquiring ownership of serial port from native TINI control

required root access, which was granted by Dr. Koontz

C. The documentation / support for TINI is horrendous—directed toward interest groups.

• Nowhere to turn to for quick answers • Forced to troll mailing lists

2. Polaris IssuesA. Loading passive tools proved too difficult

• Using active tools proved to be simple

B. Access to Polaris was delayed• Complete and unfettered access to Polaris since 27 April

Presentation Outline

• Project Overview

• Problems and Dependencies

• Deliverables

• Schedule

• What we’ve learned

• The Near and Distant Future

Projected Deliverables

I. Minimum:• Server code that implements Config(), LoadTool(tool), Init(),

getToolFrame() and getToolPos() methods

• A Client that will demonstrate these methods in a distributed environment

• A single threaded server implementation

II. Maximum:I. Server code that implements all Polaris functions (loading and tracking multiple tools,

tracking both passively and actively, etc.)

II. A multi-threaded implementation of the server code

III. Ability to scale well with multiple clients (multi-threaded implementation?)

Actual Deliverables

I. Achieved:• Single-threaded server code that implements Config(), Init(), getToolTranformation(),

PolarisStatus(); for active markers.

• Basic serial communications with TINI.

II. Will Be Achieved:• Server code ported to TINI board.

• Simple client created to work across network using TCP.

III. By the Way-side:• Multi-threaded implementation.

• Client – Server communication using CORBA (either on TINI or on a PC).

Presentation Outline

• Project Overview

• Problems and Dependencies

• Deliverables

• Schedule

• What we’ve learned

• The Near and Distant Future

2 – 12 March: Dissect & Study the C++ Tracker Reference Model 12 March: Begin Porting C++ Tracker Reference Model to

Embedded Java 12 March: Define interaction of server IDL and JacOrb 26 March: Begin writing server code 15 April: Begin re-writing basic functions, such as setConfig()

& getTool() in Embedded Java 22 April: Begin writing simple client 30 April: Complete Project (implementation of server and

simple client)

Original Project Timeline

2 – 12 March: Dissect & Study the C++ Tracker Reference Model 12 March: Define interaction of server IDL and JacOrb 26 March: Begin writing server code *3 April: Began serial port coding 9 April: Begin re-writing basic functions, such as setConfig()

& getTool() in Embedded Java *22 April: Complete serial port code *22 April: Begin testing server code on Polaris Device *29 April: Complete server code 29 April: Begin writing simple client 11 May: Complete Project (implementation of server and

simple client)

Black = done; Blue = future; Red = future & delayed; * = new

Revised Project Timeline

2 – 12 March: Dissect & Study the C++ Tracker Reference Model 12 March: Define interaction of server IDL and JacOrb 26 March: Begin writing server code *3 April: Began serial port coding 9 April: Begin re-writing basic functions, such as setConfig()

& getTool() in Embedded Java 22 April: Complete serial port code 27 April: Begin testing server code on Polaris Device 8 May: Complete server code 13 May: Begin writing simple client 17 May: Complete Project (implementation of server and

simple client)

Black = done; Red = future & delayed

Re - Revised Project Timeline

Presentation Outline

• Project Overview

• Problems and Dependencies

• Deliverables

• Schedule

• What we’ve learned

• The Near and Distant Future

What We’ve Learned – Technical

• More Java & Embedded Java than we thought existed

• Serial cable communications• Server – client relationships• Intimately acquainted with Polaris interface• Enough CORBA to become intrigued by it

What We’ve Learned – Logistical

• Project Management– Communicate all the time!

– Checkpoints! Checkpoints! Checkpoints!

– Be a pessimist! • “Expect the best; but be prepared for the worst.”—Kevin

• “All hope abandon, ye who enter here”—Drew

• Murphy’s Law– Something is always missing / there are always setbacks

What We’ve Learned – ERC Style

• Always have root access to your server.• Your mentor(s) will always be busy.

– If he leaves for the APL, make him come back for meetings– If his thesis is due, give him room, but he will always be in the lab!

• Don’t be afraid to ask other students for help.• Speak-up! People will listen and help if you do.• Try to get a CIS computer account—it saves lots of trouble.• The ERC is busiest at night—after 11pm.• Pizza on Wednesdays! Lectures too.• It pays to have a soldering champ as a friend. (Thank you Darius!)

Presentation Outline

• Project Overview

• Problems and Dependencies

• Deliverables

• Schedule

• What we’ve learned

• The Near and Distant Future

Future TechnologiesTaking it the extra step

• Distributed control using CORBA– CORBA appears to be the cutting edge technology that promises

the most in terms of future development. It claims to be easy to use and to integrate into existing programs and to make client-server communications using objects much easier than they currently are. Unfortunately, this doesn’t seem to be the case today.

• Hot-swappable and universal standards of communication– This would make it easier to work interfacing various devices. It

would make using an intermediary such as TINI obsolete; devices could be connected directly to a network.

In the very near future

We will deliver the ERC a client program that

logs into a server on a TINI that controls a

Polaris remotely.