Polaris Server Code Java Implementation for TINI Andrew

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 www. ndigital. com www. dallassemiconductor. com

Ideal Information Flow Through Polaris Server / Client Outside the Lab In the Lab Ethernet IDL Stub Client IDL Stub TINI Device Jac. Orb Polaris Tracker Server RS-232

Actual Information Flow Through Polaris Server / Client In the Lab Across the Lab TINI Device Actual size Client Completely abstract Ethernet (TCP) Polaris Tracker Not actual size Server RS-232 (Null – Straight)

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. Get. Transformation(tool)- return Quarternian representing translation and rotation of tool, return RMS error. 4. Polaris. Status()– returns status of tools in ports 5. Start/Stop. Tracking() – 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. B. C. 2. Access to TINI – Fulfilled. Access to Polaris – Partially Fulfilled. Jac. ORB ported to TINI – Will Not Be Fulfilled. Internal A. B. C. D. Working Java serial port code – Fulfilled. Basic Polaris server code – Mostly Fulfilled. Distributed Control with TCP – Will Be Fulfilled. 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 1. B. The TINI refuses to allow control of the serial port 1. C. Acquiring ownership of serial port from native TINI control required root access, which was granted by Dr. Koontz The documentation / support for TINI is horrendous—directed toward interest groups. 1. 2. Straight serial cable vs. Null modem cable Nowhere to turn to for quick answers Forced to troll mailing lists Polaris Issues A. Loading passive tools proved too difficult 1. B. Using active tools proved to be simple Access to Polaris was delayed 1. 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 1. I. Minimum: 1. Server code that implements Config(), Load. Tool(tool), Init(), get. Tool. Frame() and get. Tool. Pos() methods 2. A Client that will demonstrate these methods in a distributed environment 3. A single threaded server implementation 2. 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 1. 2. 3. I. Achieved: 1. Single-threaded server code that implements Config(), Init(), get. Tool. Tranformation(), Polaris. Status(); for active markers. 2. Basic serial communications with TINI. II. Will Be Achieved: 1. Server code ported to TINI board. 2. Simple client created to work across network using TCP. III. By the Way-side: 1. Multi-threaded implementation. 2. 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

Original Project Timeline 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 Jac. Orb 26 March: Begin writing server code 15 April: Begin re-writing basic functions, such as set. Config() & get. Tool() in Embedded Java 22 April: Begin writing simple client 30 April: Complete Project (implementation of server and simple client)

Revised Project Timeline 2 – 12 March: 26 March: *3 April: 9 April: *22 April: *29 April: 11 May: Dissect & Study the C++ Tracker Reference Model Define interaction of server IDL and Jac. Orb Begin writing server code Began serial port coding Begin re-writing basic functions, such as set. Config() & get. Tool() in Embedded Java Complete serial port code Begin testing server code on Polaris Device Complete server code Begin writing simple client Complete Project (implementation of server and simple client) Black = done; Blue = future; Red = future & delayed; * = new

Re - Revised Project Timeline 2 – 12 March: 26 March: *3 April: 9 April: Dissect & Study the C++ Tracker Reference Model Define interaction of server IDL and Jac. Orb Begin writing server code Began serial port coding Begin re-writing basic functions, such as set. Config() & get. Tool() 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

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! – 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 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 11 pm. 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.