Transcript Distributed Architectures for Medical Systems

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
JacOrb
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. 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.
B.
C.
2.
Access to TINI – Fulfilled.
Access to Polaris – Partially Fulfilled.
JacORB 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
•
B.
The TINI refuses to allow control of the serial port
•
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.
•
•
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
•
B.
Using active tools proved to be simple
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
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 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)
Revised Project Timeline
2 – 12 March:
12 March:
26 March:
*3 April:
9 April:
*22 April:
*22 April:
*29 April:
29 April:
11 May:
Dissect & Study the C++ Tracker Reference Model
Define interaction of server IDL and JacOrb
Begin writing server code
Began serial port coding
Begin re-writing basic functions, such as setConfig()
& getTool() 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:
12 March:
26 March:
*3 April:
9 April:
Dissect & Study the C++ Tracker Reference Model
Define interaction of server IDL and JacOrb
Begin writing server code
Began serial port coding
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
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.