Deck of Cards Robot Assisted Biopsy

From IGSTK

Jump to: navigation, search
Deck of Cards Robot Guided Biopsy Procedure Workflow 
  1. Move patient into CT suite and take the CT scans
    • Patient is moved onto the CT table;
    • Take the CT scan for the intervention procedure;
    • The CT image data tranfers to the computer in DICOM format;
  2. Setup Deck of Cards robot
    • Mount the Deck of Cards robot on a table close to the patient and the CT gantry;
    • Mount Z-frame on the Deck of Cards robot's arm;
    • Connect the robot with the computer;
    • Run the robot server (HWServ) in the background;
    • Initialize the server from the HWServ;
    • Start the server from the HWServ;
  3. Registration of Deck of Cards robot
    • Move the robot arm to the CT gantry;
    • Connect the robot from the application;
    • Set the robot arm to home position from the application;
    • Take a single CT slice with the intersection of Z-frame;
    • The application loads and displays this slice;
    • Select 7 intersection z-frame points from the application;
    • Shift the point to the center of the intersection ellipsoid;
    • Perform Z-frame registration;
  4. Path planning
    • Load and show CT images of the patient;
    • Select entry and target points from the 2D section images;
    • Compute the parameters of commands to be sent to robot server (transform the entry/target positions from image coordinates to robot coordinates);
  5. Biopsy and navigation
    • Send commands to the robot to drive the biopsy needle;
    • Or control the robot by joystick and display the real-time position in the 2D/3D views for image guidance;

The procedure 1 and 2 can be switched, depending on whether to put the patient first or setup the robot first.
This workflow is for the case when the robot is mounted on an adjoint table close to CT table. If the robot is mounted on the CT table, the CT scan and that registration slice scan can be simplified to just one whole CT scan. (I prefer this way for it can provide more flexibility to handle the intervention and registration, e.g., we can use multi slices to get a better registration. But this depends on the hardware design. )

Notes
  1. Hardware interface for Deck of Cards robot: Robot, Control Rack and Handheld Control Unit (Joystick).
    1. Robot: a two-deck robot to drive the biopsy needle;
    2. Handheld Control Unit: a joystick for manually controlling the robot with emergent brake;
    3. Control Rack: some hardware boards for the control system, the Robot and Handheld Control Unit are connected to the Control Rack. The Control Rack connects with the server computer using RS232.
  2. Client/Server interface for the robot.
    1. Control Rack is connected with the server computer by RS232;
    2. A control software (HWServ) is run on the server computer to control the robot. It has two version binary programs: Linux/BSD version and Windows version (I can only find windows GUI version now and WITHOUT source code);
      1. Linux/BSD with linux bin compatibility:
        1. Console program
        2. Console program, running as daemon
        3. XWindows program with GUI for supervising the current state and/or for changing and viewing the configuration
      2. Windows:
        1. console program
        2. console program, running as service
        3. Windows program with GUI for supervising the current state and/or for changing and viewing the configuration
    3. Client application communicate with the HWServ by TCP/IP socket API;
  3. Software interface from Heesu's application
Robot Clinical Application
Robot Clinical Application
Deck Robot
Deck Robot
HWServ GUI
HWServ GUI
RABiopsy
RABiopsy
Issues
  1. Need wrap the Deck of Cards robot to a tracker-like server class and a command client class. Since we don't have the source code to control the server, we may only develop a command client class talking with the server daemon.
    1. For server class (if implementable)
      1. States: Initilize Server, Start Server, Stop Server, Shutdown Server;
      2. Hardware configuration: can start server with the configuration from EEPROM from robot or by specifying an INI file. The configuration includes Name, Port, Baudrate, Parity ....;
      3. Server will automatically generate a log file "HWServer.log". (How to make it work with igstkLogger?)
    2. For client command class
      1. Connect commands: Connect/Disconnect server;
      2. Log commands: log in as the active client, supporting for multi-client architecture;
      3. Action commands: Move/Stop to home position, Set the transform (2D/4D);
      4. Request commands: Get the transform, Get system states;
      5. Configuration commands: Get/Set configuration (speed, power, ...);
      6. Emergency commands
  2. We don't have Z-frame for Deck of Cards robot now. We have one for JHU robot. So the registration algorithm should be under discussion. Or maybe simply drive the robot to touch the fiducial? Another choice is Georgetown is developing a new end-effector registration tool.
  3. The way how the robot is mounted on the intervention table will affect the workflow. One way is to mount the robot on the CT table as the JHU robot, this convenient way will allow the patient to move away from the gantry during the intervention after registration. And also in this way, we may only need one CT serie scan (any slice of CT image with z-frame intersection in the data can be used for registration). The second way is to mount the robot on the adjoint table close to the CT table, and this will prohibit the patient move after registration.
Retrieved from "http://public.kitware.com/IGSTKWIKI/index.php/Deck_of_Cards_Robot_Assisted_Biopsy"
Personal tools
TOOLBOX
LANGUAGES