University of Florida, IPPD
Integrated Technology Ventures
Dynamic Radiographic Imaging Control System, (DRICS)
System Level Design Review
GatorRay Controllers
December 12, 2005
Table Of Contents
1 PROJECT OVERVIEW ........................................................................................................................... 3
1.1 BACKGROUND INFORMATION ............................................................................................................... 3
1.2 PROJECT PURPOSE AND SCOPE ............................................................................................................. 3
2 CUSTOMER REQUIREMENTS ............................................................................................................ 4
2.1 OVERVIEW ............................................................................................................................................ 4
2.2 CURRENT SYSTEM ................................................................................................................................ 5
2.3 REQUIRED SYSTEM ............................................................................................................................... 6
2.3.1 Central Computer ........................................................................................................................ 6
2.3.2 Robot ............................................................................................................................................ 7
2.3.3 Motion Capture System (MoCap) ................................................................................................ 7
2.3.3 Video ............................................................................................................................................ 8
2.3.4 Safety ............................................................................................................................................ 8
3 GUI OVERVIEW ...................................................................................................................................... 9
3.1 OVERVIEW ............................................................................................................................................ 9
3.2 DETAILED GUI DESCRIPTION ............................................................................................................... 9
4 CONTROL SYSTEM DESIGN DESCRIPTION ..................................................................................13
4.1 OVERVIEW ...........................................................................................................................................13
4.2 ARCHITECTURE....................................................................................................................................14
4.3 INTERFACE BETWEEN SYSTEMS...........................................................................................................17
4.4 VERIFICATION .....................................................................................................................................19
5 BUSINESS CASE .....................................................................................................................................20
5.1 OVERVIEW ...........................................................................................................................................20
5.2 LICENSING PLAN..................................................................................................................................20
5.3 SYSTEM DEMAND ................................................................................................................................20
5.4 ORTHOPEDIC CLINICS ..........................................................................................................................21
5.5 FIRST-TIME COST .................................................................................................................................21
6 PROJECT PLAN......................................................................................................................................22
6.1 DELIVERABLES ....................................................................................................................................22
6.2 PROJECT ASSIGNMENTS AND RISK ASSESSMENTS ...............................................................................24
1 Project Overview
1.1 Background Information
Tens of millions of Americans suffer from joint diseases like osteoarthritis or
traumatic injuries of the joints and spine. Skeletal joints provide the ability to move, yet
there is currently no technology to accurately and routinely examine dynamic joint
motion – instead, doctors diagnose problems by searching for abnormal structures using
static X-ray, computed tomography (CT), and magnetic resonance (MR) technology.
GatorRay is a new technology invented by University of Florida professor Scott
Banks. It is a new imaging platform based on a pair of robot-mounted devices, the X-ray
source and sensor panel, whose motions are coordinated via a real-time motion-capture
system. The product’s function is to track human joints in motion, and obtain highprecision targeted radiographic image sequences, yielding dynamic skeletal imaging and
computed tomography.
The development of this technology would significantly enhance the observation,
diagnosis, treatment and rehabilitation of people suffering from joint disease and injury.
By using real-time motion-capture to track the motion of the subject and coordinating the
motions of robot-mounted X-ray video equipment, detailed images of the moving joints
can be obtained. This is a capability that does not currently exist in medical imaging.
1.2 Project Purpose and Scope
The purpose of the project is to complement and enhance the development of
Integrated Technology Ventures’ GatorRay project, directed by Professor Scott Banks.
By integrating the efforts of a business team, a technical team, and robotics and
tomography researchers, the scientific, hardware, software, and business aspects of the
venture can be developed in parallel. The project’s purpose is to create a system which
uses motion capture data fed to robots to follow the natural movement of patients, and
capture X-ray images of the patient’s area of concern.
The GatorRay system makes use of several different technologies, including realtime motion capture, robot control, X-ray imaging, and computed tomography. The
scope of this project is limited to developing the software and network hardware
necessary to provide an overall control system for the current and future system
components.
This project has two technical goals. The first is to design and develop the
Dynamic Radiographic Imaging Control System (DRICS), a computer network-based
system that centralizes the control of all subsystems. The second goal is to create a userfriendly graphical user interface that demonstrates the potential of the overall system and
can be used to aid researchers in the project.
Although this project will serve as a step towards commercialization of the
GatorRay system in conjunction with ITV, the project will not produce a completely
marketable prototype for the overall system and graphical user interface. Instead, the
control system and graphical user interface will serve as a research tool and a
demonstration of feasibility and potential for the future.
Specifically excluded from the project scope are the following:



Integrating the current components into a single hardware housing.
DRICS will be developed on the distributed architecture of the current
system, with the addition of a single central computer.
Developing software or hardware specifically for an X-ray imaging
subsystem. For this project, a video camera of the same bandwidth as the
proposed X-ray unit will be used in place of an actual X-ray emitter and
receiver.
Developing a graphical user interface (GUI) to serve as a final product.
The GUI will serve as a research tool and as a proof of concept
mechanism. The GUI will incorporate some safety features, but leave full
compliance with federally mandated safety measures for the next
generation of the GatorRay system.
2 Customer Requirements
2.1 Overview
Our project consists of designing and implementing the control system and GUI
for the GatorRay product. As such, our “customers” consists primarily of the operators of
the software and the researches who will use it. However, we cannot simply disregard the
patient. As with any medical procedure, the safety of the product must be a very high
priority. In order to do this the prototype must be designed with a safety-first mentality. A
major requirement of the GUI, therefore, is to have a very simple-to-use built-in
emergency stop mechanism. Additional requirements for the GUI are to provide the user
with all the tools required to set up the patient’s tests and to ensure their accuracy and
readability. Another requirement of the GUI is the proper storage of the X-ray image
sequence and model data. The communication of the control system must allow for an
instantaneous override to be sent to the robotic and X-ray/video subsystems. It must also
provide the coordinate data at a rate of speed that is high enough to keep the robots
centered on their target.
2.2 Current System
Figure 1. A GatorRay system robotic arm.
GatorRay currently consists of one off-the-shelf Mitsubishi robot and a real-time motion
capture system (Figure 1). There is currently no system in place for capturing actual Xray images. However, a digital video camera has recently been purchased to take the
place of X-ray equipment during development.
The robot moves at speeds up to one meter per second on 6 axes. It weighs 70 Kg.
and carries a payload of up to 10 Kg. if the center of gravity of the payload is on the tip of
the robot itself. Therefore the operational payload wight limit is between 6 and 8 Kg.
The robot is currently controlled by commands from a Windows system. Methods to
direct the robot and control its movement have been implemented on the Windows
system in Visual C++ by Chris Lightcap and J. D. Yamakoski. The Windows system
currently has 1 GB of RAM and has a 2.8 GHz Intel Pentium 4 processor.
The motion capture system’s lenses are mounted in a circle surrounding the
robot/patient interaction area so that 3-dimensional coordinates are obtained from LED
markers located on the patient. Such coordinates are obtained from every angle to
provide a highly accurate tracking. The system creates a coordinate plane, using the LED
makers on the patient’s area of interest, to track and plot movements. The motion capture
system is currently interfaced with a Linux system dedicated to it.
The Windows system that controls the robot is connected to the motion capture’s
Linux system by an Ethernet crossover cable. The Windows system currently uses this
connection to make decisions about the trajectory of the robot based on the coordinates
obtained by the motion capture system. As a result, the robot is currently capable of
tracking a patient wearing motion capture markers.
A video camera has been purchased which provides an API to control the camera.
This video camera will be used in place of an actual X-ray system throughout most of
the system’s development. This will facilitate testing through the design process.
2.3 Required System
Figure 2. The Gator System.
Three computers will needed. One is required to control each of the robots, along
with the main control computer, which will handle all communications. There will be a
patient information system with a database in the background that stores all the data on
the patient. Once the patient information is stored, the type of examination to be
performed will be selected. After the exam is selected the motion capture data must be
verified, and then the “Black Box” coordinate data will be used to visually verify that the
data is correct. Next, the X-ray system will be tested and the parameters changed as
necessary. Finally, the system will capture the image sequence and allow the data to be
viewed or stored as required.
The control system requires that the communications be carried out at a very high
data rate, and a high degree of accuracy, to allow real-time coordination of the robot
motion. The requirement of accuracy in tracking left for future developers.
2.3.1 Central Computer
The Central Computer will be running the control system and the GUI that will
interact with the user. The control system will be used for synchronization. It will send
information across an Ethernet cable in less time than the connection time between the
robot and its control box, which is 2ms.
The central computer needs to be capable of reliably running the GUI, written in Visual
C++, while accepting images from the video source. It also will give commands to the
two Dell computers which control the robots, based on the spatial coordinate information
given to it from the motion capture sub-system. The central computer will be capable of
storing the image streams it receives.




The control system will send information across the Ethernet cable in 2ms or less.
The central computer will be capable of running the GUI at an effective rate.
Communication between the Dell computers and the motion capture sub-system
will be verified through scripted scenarios.
DRICS must be capable of storing 30 Videos @ 30 fps, and a minimum
resolution of 1.4M pixels.
2.3.2 Robot
The robots are connected to the robot control system via a proprietary
communication protocol. The time required for the robots to receive commands from the
robot control system is 2ms. That time must not increase for the robots to operate safely.
At calibration time, the motion capture subsystem will record the initial position of the
robots. The robots will base their movements on the 3D position coordinates of the
sensors on the patient. The robot mounted with the X-ray system must remain
approximately 4 inches away from the patient. The robots will be pointing at one another
so that their line of sight goes through the target region on the patient, which is identified
by the markers placed on the patient. As the target moves, the robots will follow in real
time, maintaining a constant viewing angle of the target.


The X-ray source mounted on the robot must remain approximately 4 inches away
from the patient.
The system must ensure that the robots maintain a constant viewing angle of the
target.
2.3.3 Motion Capture System (MoCap)
The MoCap system runs on a Linux platform and be connected to the central
computer via an Ethernet cable. Currently this system transfers information at roughly
the same speed as the robot control system; the overall control system must maintain this
speed. The MoCap system includes 8 remote sensors that create a 360-degree perimeter
around the two robots and the patient. The sensors will track the movement of the patient
and relay the positions of the patient’s markers to the robots.

Sensors will track the movement of the patient and relay the position of the
patient’s marker positions to the robots in real time.
2.3.3 Video
In the final system, GatorRay will use an X-ray device to capture image
sequences of the patient’s bone and joint movement. For this project, the system will be
designed with a video camera instead of an X-ray source. The video camera will be
mounted on one of the robots and will transmit images to a separate receiver that will be
connected to the central computer. The video camera we will use records images at a
resolution of 1.4 mega pixels. The image sequences stored in the control computer will
have a video rate of at least 30 frames per second.
On the GUI, the user will be able to see the image taken by the camera. We
propose that the final system have both the x-ray and the video camera sending images
back to the GUI. The image sequences presented on the GUI do not have to be shown at
at a rate of 30 frames per second.


The GUI will show the user the image sequences taken by the camera.
The GUI will show the images sequences at a video rate less than 30 fps.
2.3.4 Safety
One major concern with the system is the exposure to X-rays. Since the overall
goal is to have a system that takes a dynamic X-ray images, X-ray over-exposure is a
serious potential problem. The X-ray technician will not be able to change the dosage to
an amount above the legal limit. Also, with the integration of an x-ray and video,
exposure will be reduced dramatically because fewer and more accurate shots can be
taken of the patient. In case of emergency, there will be an external shutdown switch.
This will ensure that the X-ray can be shut off even if there is a problem with the control
computer. Another design consideration is that the robot will have to maintain a
minimum distance of 4 inches from the patient, and not come in contact with the patient
at any time.



The system will prevent X-ray dosages above the legal limit (140 KV).
The system will ensure that the robots maintain a minimum distance of 4 inches
from the patient at all times.
The system will include an external emergency shutdown switch that will
immediately halt all X-ray emission, and halt all robot movement within 1 second.
3 GUI Overview
3.1 Overview
The second part of the system is a graphical user interface (GUI) which functions
as the software interface in controlling the robots. Following our sponsor’s wishes, our
GUI will be laid out in a tabbed window format with each of the tabs corresponding to a
specific GUI human-machine interaction. At any time, the operator will only have one
window on the screen with which to control the system, with simple buttons to click and
text fields to fill. The operator of the GUI will not require significant knowledge of
computers to operate the system.
An important goal of the system is to ensure the safety of the patient. In dealing
with X-rays, there is always a potential for excess exposure to radiation. Since the system
will be taking dynamic imaging of a patient, the risk of over exposure is high. The GUI
will thus have a way to stop the process once the X-ray imgae acquisition process has
begun. There will be a large button with distinctive lettering which will stop the system
immediately. The operator will also be able to hit the space bar on the keyboard to stop
the system.
3.2 Detailed GUI Description
The GUI starts out with tab for the operator to enter in the patient’s information,
Figure 3 below shows a screen shot of the first tab. If a patient has already been entered
into the database and the operator would just like to pull up his/her file, all he enters is
the patient’s ID # into the first text box.
If the number is incorrect, the other tabs will not be selectable and “Incomplete
Information” will appear next to the text box in red letters.
If a new patient is being entered into the system, the ID # text area will be left
blank and the rest of the text fields must be filled in. When the date of birth is entered in
correctly, the patient’s age will automatically appear under the word age. After all the
fields are filled, the rest of the tabs may be selected.
Figure 3 – Patient Information Page
The second tab, shown in Figure 4, allows the operator to select the joint of the
patient to be examined. The left section will have a list of the joints that can be accessed
by clicking on the box to the left. The joints are the cervical spine, shoulder, lumbar
spine, hip, knee, and foot/ankle. When a joint is clicked, such as the knee, the operator
may select either the right or left knee, and then can specify other characteristics. When
the operator finally chooses the desired joint, he/she will click “Establish Coordinate
System”. A window (Figure 5) then opens to show any errors in marker placements and
suggestions on which markers should be selected. If there are no errors, the operator
clicks the button again and a stick man appears showing the marker placements.
Figure 4 – Joint Selection
Figure 5 – Markers
In the third tab, the system calibrates the X-ray source, as shown in figure 6. The
left side of the page has parameters for the X-ray. If the values are outside the specified
requirements, they will be set back to the default values. When the values are correct and
the operator hits the “Test” button, a prompt pops up and asks the operator if he or she is
sure they want to continue. After “ok” is pressed, the system takes a single test image of
the patient, and the system displays the image in the screen. If during the test shot the
operator needs to stop the process, he or she can click the “STOP” button on the screen
and the image acquisition will stop.
Figure 6 – X-ray Calibration
The fourth and final tab is where the system displays the entire x-ray sequence. This can
be seen below in Figure 7. The operator starts by clicking “Perform Sequence”. A window will
pop up, showing the progress of the imaging process. Once again, the operator will have the
ability to stop the system, by clicking the large stop button in the window. If the imaging process
concludes uneventfully, the X-ray images will appear. The operator can view the entire sequence
at once, or view a particular segment.
Figure 7 – Video Capture
4 Control System Design Description
4.1 Overview
Figure 8. Software/Block Diagram
There are several different systems that will communicate with each other. The
central control computer will coordinate all communications. The graphical user
interface will be run on the central control computer. Information gathered from the user
concerning the sequence to run will be sent, along with the raw motion capture data, to
the system we refer to as the “Black Box” (Trajectory Generation in figure 8). That
system is out of the scope of our project and is being developed by Scott Banks and his
PhD students. Its purpose is to provide a data structure to the control system, which
contains information about the patient. The central computer then uses this data,
consisting of points on the body, to communicate with the two robot control computers as
well as send a signal to the x-ray indicating that the image would be good if taken. There
will be one computer for each robot arm. The robot-control computers invoke the robot
API. We will write helper programs on these computers, whose purpose is to ensure that
the data is properly transmitted to the robot control software. The two robot-control
computers will be connected to the central control computer via Ethernet cables through a
router. TCP will be used to send information between the systems. The decision was
made to have each robot run on its own computer because of the ports needed operate
them. This configuration, with three computers including one central control computer,
was selected to allow the graphical user interface to run on one machine while
simultaneously communicating with the robots.
4.2 Architecture
The DRICS system-level architecture is shown in figure 9. The central computer
and both robot control computers will be running the Windows operating system. They
will have a minimum of 1 GB of RAM and a 2.8 GHz Intel Pentium 4 processor. These
hardware requirements are needed to provide seamless communication across the
network. The central computer will also allow storage for image sequences. The images
will be viewable through the GUI on the central control computer. There will also be an
ability to stop a capture sequence on demand (emergency stop).
The GatorRay system is being developed, for safety reasons, using a video
camera. The video camera will be connected to the central computer. This decision also
provides the benefit of modularity. One of the requirements of our system is to design
the control system independently of any specific X-ray machine. In the final system the
X-ray emitter and receiver will each be connected the robot control computer for their
robot arm.
Figure 9. DRICS System-level Architecture.
The main purpose of our GUI in relation to the motion capture system is to select
a test from a pre-determined list of tests and verify that the markers the technologist
expects to see are there. Here is an example of the test structure:
1) Cervical Spine
Lateral View
Right Frontal
Left Frontal
2) Shoulder
Left - Scapulothracic Lateral
Left - Glenohumeral Lateral
Left - Superior
Left - Scaption Plane
Left - AP
Right - Scapulothracic Lateral
Right - Glenohumeral Lateral
Right - Superior
Right - Scaption Plane
Right - AP
3) Lumbar Spine
AP
Lateral
4) Hip
Left - Posterior Lateral
Left - Anterior Oblique
Left - AP
Right - Posterior Lateral
Right - Anterior Oblique
Right - AP
5) Knee
Left - Lateral
Left - AP
Left - Sunrise Patella (in contact)
Left - Sunrise Patella (no contact)
Right - Lateral
Right - AP
Right - Sunrise Patella (in contact)
Right - Sunrise Patella (no contact)
6) Foot/Ankle
Left - Lateral
Left - Anterior/Superior
Left - Superior Lateral Oblique
Right - Lateral
Right - Anterior/Superior
Right - Superior Lateral Oblique
The system will receive marker data from the motion capture system. The hexadecimal
identification numbers for each marker found will be shown. Any markers that are
expected and not found will be shown along with any markers found that are not
expected. The technologist can assign the unexpected markers to the positions of the
markers that were not found. After this process, the markers that will be tracked by the
system are defined. This data is given to the “Black Box” system. The output of the
“Black Box” will be a list of cardinal points. One of the points will have a special
denotation as the point in space which the robot arms will be following. The cardinal
points will be identified and their names will be output to the screen. With these points
as input our system will be able to display a basic visual schematic, showing the points
for which the system will keep track, as shown in figure 10.
The technologist will be given the ability to change various different parameters for a
given test.
X-Ray parameters:
Parameter
Limits
Beam Current
Accelerator Voltage
Pulse Fequency
Pulse Width
Maximum duration of Exposure
0.5-4mA
40-120 KV
5-30 s-1
2-30 ms
.5-4.0 s
type
float
int
int
int
float
default
1.0mA
55kVp
30Hz
4 ms
2s
Each test, after it is selected, will have its own default values for each of the parameters
that will be shown to the technologist.
Example
Left Knee – Lateral –
test is selected
Displayed on screen:
Figure 10. Schematic of tracked points.
L-Hip
R-Hip
L-Knee 
R-Knee
L-Ankle
R-Ankle
L-Toe
R-Foot
the arrow denotes that this is the point to be followed
Each of the cardinal points represents a 6-d point that will be output from the “Black
Box.” The cardinal makers are stored as 6 floating-point values. Three of the six
dimensions are the (x, y, z) coordinates of each point. The other three values are angles
of orientation. Our system will output the cardinal marker information to the computers
that control each robotic arm.
4.3 Interface Between Systems
To transfer the information we will use Windows Sockets, and pass a bit stream
containing the 6 floating-point values for each cardinal marker. Each of the two control
computers will be running a client written in Visual C++, and the central computer will
be running server code. We will be using TCP for a stream of reliable information.
Using TCP will allow us to use standard Ethernet cards. TCP was selected over UDP
because it is more reliable in sending packets of information in a specific order. It was
also determined to be better than a publish/subscribe model due to the availability of
implementation tutorials on the web.
The server code will include the following items:
#include <winsock.h>
int nRet = WSAStartup(wVersionRequested, &wsaData);
if (wsaData.wVersion != wVersionRequested)
{
fprintf(stderr,"\n Wrong version\n");
return;
}
winsock.h must be included for any Windoze application that uses sockets. Next, the
WSAStartup() function must be called to initialize WinSock and ensure the correct
version is being used. Below are some of the socket methods.
socket(address family, socket type, protocal)
bind(socket, our address, size of address structure)
listen(bound socket, number of connection request queue)
accept(listening socket, optional client address)
recv(connected client, receive bit array containing cardinal marker
floats, length of buffer, flags)
closesocket(socket)
WSACleanup();
The socket function creates the socket and the bind, listen and accept functions
allow for a connection with the client. The actual information is received in the recv()
command as the receive buffer. It will be large enough to contain the bits of the six
floating-point numbers for each cardinal point. Depending on the test the length of buffer
will be a different size. During each specific test the buffer length will contain the same
number of floats.
The client code will include the following items:
#include <winsock.h>
WSAStartup()
socket(address family, socket type, protocal)
connect(socket, server address, length of server address structure)
send(connected socket, bit array containing cardinal marker floats,
length of data, flags)
closesocket(socket)
WSACleanup();
The connect function connects to the accepting server, and send() sends the data
buffer to recv(). For this application we will also need functions we will require the
port addresses, and we will need to convert it using htons(), which converts a “Host
to Network Short”. Using cardinal marker data received in the data buffer the control
computers will be able to make the robots follow the specified point.
There is free source code available dealing with TCP using Windows sockets.
We plan to modify the code for use with the cardinal marker data. We will also write
code for constant transmissions because the robots must receive the motion capture data
quickly to be able to track the patient in real time.
4.4 Verification
Once the code is completed and implemented it will be tested for performance.
Verifying the connection between each computer will test the integration of the system.
The overall system will be tested to make sure our code receives the information quickly
enough. The socket code will be tested to make sure the correct information is being
passed. A test will be performed using the robot to make sure it can follow a joint
effectively and keep the camera on the correct point in space. The visual images received
from the camera will be tested to make sure a video can be saved at 30 frames per
second. The cardinal marker data will also be checked against the numbers we expect to
see based on the test selected in the GUI.
5 Business Case
5.1 Overview
It is important to first note that our liaison engineer and system inventor, Prof.
Scott Banks, would like our engineering team to concentrate on “demonstrating
feasibility and potential” for the system. The ITV business team holds most of the
responsibility for developing a pricing strategy, monetary estimates, and marketing
considerations for the product.
Within the past several months, the GatorRay engineers and business analysts have made
several key decisions. These are as follows:
1.
2.
3.
4.
A licensing plan should be implemented to allow for the GatorRay system
to be produced by a major radiological distributor.
Market analysis can not be conducted until we have at least a rough
estimate for what the demand for the system will be.
Orthopedic clinics should be our target market.
The cost for building the first GatorRay system will be about $350,000.
5.2 Licensing Plan
The first major resolution that has been made this semester is that the GatorRay system
will be distributed by a major manufacturer, rather than as its own small start-up
company. After examining the radiological manufacturing industry, the business team
has determined that it is controlled by several large players, such as General Electric.
This is a difficult industry for a small start-up company to break into, no matter how
novel their idea might be. This decision has been more important to the business and
legal sides of the project, as they are the ones who will deal mostly with the licensing
issues. However, this decision has caused the GatorRay engineers to realize that our
main job is to prove that the system is a feasible, useful technology.
5.3 System Demand
While the business team would like to begin a market analysis for the GatorRay system,
they will not be able to do so until they have determined who will want this technology
and what they will be willing to pay for it. The next step that the business team will take
will be to visit with as many radiologists, orthopedic clinics, and even sports medicine
facilities as possible. This will allow them to calculate the demand and determine a good
price for the finished system. As of right now, the business team has visited with one
radiologist and one orthopedist.
5.4 Orthopedic Clinics
If the licensing plan goes through as we hope, we will not have to worry about finding
people to sell this system to; the manufacturer would take care of that. However, in order
to get the licensing done at all, we have to prove that there exists a market that will find
this technology useful and is willing to pay to have it. Therefore, we have been
researching different markets and have determined that we should target orthopedic
clinics. It seems that radiologists might feel that they have no use for the system, but Dr.
Moser, the one orthopedist with whom the business team has been in contact, seemed
excited about the system and said that it is something he would definitely buy for his
office when it comes to market. He felt that this would be a powerful tool for pre-surgery
diagnosis and post-surgery rehabilitation, particularly for shoulder injuries. Without this
tool, orthopedists often do not know what exactly is wrong with a patient's shoulder until
surgery has begun.
5.5 First-time Cost
The GatorRay system involves several "off-the-shelf" parts that have a definite fixed cost.
This makes it easier to estimate what the first complete system will cost to produce.
Scott Banks has provided this estimate as follows:
2 Robots
1 X-ray source
1 X-ray detector
1 MoCap system
Glue
Total
$120,000
50,000
80,000
50,000
50,000
$ 350,000
In this estimate, “glue” is anything that ties all of the other pieces together. This is
mainly the DRICS, our project, which includes the control system and the graphical user
interface.
These four key decisions will shape how each of the teams plans out next semester’s
agenda. The business team will concentrate on discovering more about the target market
and demand for the product. The legal team will work on patenting and licensing.
Finally, the engineering team will continue to build on the system, proving that it is a
useful, feasible technology.
6 Project Plan
6.1 Deliverables
Deliverables
Due Date
1. Final Report & Doc.
2. Final Presentation
3. Project Poster
4. Final Project Code
5. Project Poster Draft
6. GUI Prototype 2
7. Code/Unit Test/Build & Integration
8. Prototype 1 Test Results
9. Project Plan & Detailed Design Review
10. GUI Prototype 1
11. System Level Design Report
12. Technical Design Specification Report
13. Comprehensive Test Plan
14. Component Specifications
15. Prototype Plan
16. Product Architecture
17. Preliminary Design Report
18. Configuration Management Plan
4/13/06
4/13/06
4/03/06
3/22/06
3/15/06
2/22/06
2/15/06
1/11/06
1/11/06
12/09/05
12/07/05
11/23/05
11/02/05
11/02/05
10/26/05
10/26/05
10/19/05
10/12/05
Est. Time
(weeks)
4
3
3
5
2
6
4
5
4
6
3
2
2
1
2
2
4
1
Our group will utilize two processes to complete the project. For the network
control system we will follow the traditional waterfall model. The network control
system will connect two robot arms and their control systems with one central computer.
The waterfall model was selected because communication protocols that enable
communication between these systems already exist. The waterfall model also coincides
with many of the deliverables required for our IPPD course.
The GatorRay system is a new technology that does not have a comparable
system in production. Therefore, our GUI will be unique. To develop the GUI it was
decided that rapid prototyping should be used. Rapid prototyping will allow us to receive
quick feedback on the quality of our design. Our prototypes will receive careful review
from Scott Banks, Chris Lightcap, and J.D. Yamokoski along with Radiologists such as
Manuel Arreola and orthopedists at the Shands Health Center. We believe showing our
prototype to the type of professionals that will actually be using this technology is the
best way for us to determine the usefulness of the design, and make improvements. The
first prototype will be developed rapidly in order to receive critiques as soon as possible.
Using the information gathered from the first prototype, a second prototyped will be
developed that will resemble our final system. The second prototype will be finished
with at least four weeks left for review and testing. After a period of comprehensive
testing the final project code will be finished and turned in by March 22nd.
Project Roadmap
System Requirements
And Product Design
Detail Design
And Test Plan
Testing
And Integration
10/1/2005
8/26/2005
9/28/2005
Maintenance
Product Verification
1/1/2006
11/4/2005
12/9/2005
2/22/2006
3/20/2006
8/26/2005 - 9/28/2005
Technical Strategy
8/26/2005 - 9/28/2005
System Requirements
8/26/2005 - 10/5/2005
Product Specifications
9/21/2005 - 11/4/2005
Comprehensive Test Plan
9/28/2005 - 11/23/2005
Product Design
10/27/2005 - 12/9/2005
GUI Prototype 1
11/4/2005 - 12/9/2005
Testing
11/16/2005 - 1/25/2006
Control System Integration
12/9/2005 - 2/22/2006
GUI Prototype 2
12/9/2005 - 2/22/2006
Control System Verification
2/22/2006 - 3/20/2006
Maintenance
Figure 11. Project Roadmap.
The project roadmap is shown in figure 11. The figure shows the five stages in our
development process. During the system requirements and product design phase we
developed our technical strategy along with the system requirements and product
specifications. In the second stage the product has been designed, and development of
the first GUI prototype has begun. A comprehensive test plan will also be constructed.
By the completion of the testing and integration phase the first representation of the GUI
will be completed. During product verification the network control system will be
integrated with the robots, and their verification will begin. The last stage is
maintenance, any problems in the system will be resolved and the final product will be
completed.
6.2 Project Assignments and Risk Assessments
Kim Poor - User Testing and Feedback
Kim is in responsible for testing prototype 1 along with receiving and documenting the
feedback for each implementation of the GUI.
Lucas Hillard and Drew Davis - Network Control System.
They are responsible for developing the visual C++ programs that will be used to
communicate between systems. They are also responsible for the integration,
verification, and maintenance of the network control system.
Blake Sutton, David Cohen and Jonathon Cohen - GUI.
They are responsible for developing the GUI prototypes in visual C++.
Our assessment of risks in this project are summarized in the table below.
Risk
Technical Risks
Inexperience in
visual c++
Probability
Impact
Moderate
Severe
Time built into the
schedule for studying
visual C++
Moderate The network system will
undergo speed testing
David, Luke,
Drew, Blake,
Jon
Drew
Moderate Rigorous testing of the
control system will
uncover problems with
precision.
Severe
Time has been built into
the plan for research in
integration.
Severe
The GUI will be made to
show potential, and for
research purposes
Severe
Safety will be our first
priority
Luke
Inability to meet
speed
requirements
Inability to meet
precision
requirements
Low
Complexity of
Integration
Moderate
Complexity of
GUI
Moderate
Inability to meet
safety
requirements
Schedule Risks:
Insufficient time
for prototypes
Low
Control system
dependency on
Low
Low
Moderate
Solutions
Team member
responsible
David, Luke,
Blake, Drew,
Jon
David, Jon,
Blake
Kim
Moderate The first prototype will
David, Blake,
be developed rapidly in
Jon
order to receive feedback
Moderate Control programs for
Luke, Drew
both robots will be
another robot
Insufficient time Moderate
for review and
feedback
Inability to
Moderate
determine user of
product
similar
Moderate Prototype development
will begin once the first
feedback is received
Low
Our System is developed
for research, with
different users in mind
Kim
Kim