Polaris Server Code: Java Implementation for TINI Andrew A. Kitchen Kevin Wiehe Computer Integrated...
Transcript of Polaris Server Code: Java Implementation for TINI Andrew A. Kitchen Kevin Wiehe Computer Integrated...
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
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.