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

The Hardware

JacOrb Server Client Polaris Tracker IDL Stub TINI Device Ideal Information Flow Through Polaris Server / Client Ethernet RS-232 Outside the LabIn the Lab

Server Client Completely abstract Polaris Tracker Not actual size TINI Device Actual size Actual Information Flow Through Polaris Server / Client Ethernet (TCP) RS-232 (Null – Straight) In the LabAcross 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.External A.Access to TINI – Fulfilled. B.Access to Polaris – Partially Fulfilled. C.JacORB ported to TINI – Will Not Be Fulfilled. 2.Internal A.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 Issues A.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 Technologies Taking 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.