1 of 56

paraDocs:

Conceptual Design Review

Team E - Surgical Robot for Orthopedics

2 of 56

Use Case

(Recap)

1

3 of 56

Orthopedic surgeon needs to perform total knee replacement on a patient suffering from severe pain due to osteoarthritis in the right knee.

Our System: Tekkneeca

A robotic system designed to assist a surgeon with total knee replacement surgeries by autonomously drilling into the patient’s bone.

Use Case

4 of 56

What needs to be done

5 of 56

Some definitions

Workbench: the table that holds the patient and the arm mounts
Surgical Site: the exposed patient’s bone, includes femoral condyles and tibial plateau

Source: https://medlineplus.gov/ency/presentations/100088_1.htm

6 of 56

Some definitions

Pre-stored bone models: an STL format mesh model, �representing geometry of bones
Drilling pose: express drilling position using 3D �coordinates and a normal vector, express drilling depth as a scalar
Pre-stored surgical plan: a drilling pose according to pre-stored bone model
Bone movement: the subtle movement of patient’s tibia and femur

Source: https://pubmed.ncbi.nlm.nih.gov/15964770/

7 of 56

8 of 56

System Level Trade Study

9 of 56

Requirements

2

10 of 56

Mandatory Functional & Performance Requirements

Functional Requirement	Performance Requirement
M.F.1 The system shall sense surgical site as a point cloud through a vision-based solution	M.P.1 The system should captured the bones’ point cloud with a density of 0.5 point/mm^3

M.F.2 The system shall sense the surgical site as a point cloud.	M.P.2.1 The system should captured the surgical site’s point cloud with a density of 1 point/cm^3
	M.P.2.2 The point cloud capture shall focus specifically on the area encompassing the surgical site
M.F.3 The system shall register surgical site with the preoperative bone model continuously in real time	M.P.3.1 The system shall demonstrated a registration accuracy of 1.00 ± 0.5 mm (SOTA:0.68 ± 0.22 mm)
	M.P.3.2 The system shall demonstrated a registration frequency of 50 Hz
M.F.4 The system shall obtain desired drilling pose accurately	M.P.4 The system shall decide the drilling position with 1 mm accuracy and orientation with 1.5°
M.F.5 The system shall obtain desired drilling depth accurately	M.P.5 The system shall decide the appropriate depth for the drilling according to surgical pin

Not only did we adjusted the numerical value for each performance requirement to make them closer to all the existing tech, like here the changed MP1,

But also we modified them to better show all the details of our system’s expected performance.

For example, as you can see here, we seperated the mp2 to better illustrate how the workspace capturing process is going on, also we did that to the original MF 4, now the information of our desired coordinates, including the pose and the depth, are set separately.

MF2/MP2:

Feedback: What portion of the workspace does the system have to sense? Is time a consideration?

Portion: Big enough to accommodate the arm and the bones

Time: not a CONSIDERATION

MF4/MP4:

Feedback: What would be a desired drilling pose? Also separate "obtain depth accurately" as a separate requirement.

Drilling pose: a drilling pose would be a 3D coordinates + normal vector on preoperative STL bone model.

Separation: we separate drilling depth as MF5/MP5

11 of 56

Mandatory Functional & Performance Requirements

Functional Requirement	Performance Requirement
M.F.6 The system shall generate a trajectory to direct the end effector to drilling position	M.P.6 The system shall generate a trajectory insures that the end effector approaches the drill position with an accuracy of 0.5 mm and an orientation error of less than 1°
M.F.7 The system shall track surgical site in real time throughout the surgical procedure	M.P.7.1 The system shall track bone movement with a latency of less than 25 milliseconds
	M.P.7.2 The system shall track bone movement with a frame rate of 50 Hz
	M.P.7.3 The system shall track bone movement when displacement exceed 2 mm and orientation exceed 1.5°
M.F.8 The system shall compensate for any bone motion	M.P.8.1 The system shall compensate motion within 25 milliseconds
	M.P.8.2 The system shall ensure the tooltip remains within 1 ± 0.10 mm of the desired surgical position

12 of 56

Mandatory Functional & Performance Requirements

Functional Requirement	Performance Requirement
M.F.9 The system shall drill holes in the bone	M.P.9 The system shall drill the bones according to the plan with positional accuracy of 2 mm and orientation accuracy of 1.5°

M.F.10 The system shall visualize the plan	M.P.10 The system shall visualize the surgical plan with latency less or equal to 150 ms
M.F.11 The system shall give basic commands from UI	M.P.11.1 The system's user interface shall respond to command inputs with a latency of less than 50 milliseconds
	M.P.11.2 The system's user interface shall include at least following functions: (1)Start (2) Pause (3) Home
M.F.12 The system shall avoid obstructions in the surgical site	M.P.12 The system shall detect and recognize any obstructions in the surgical site with a reliability of 99%
M.F.13 The system shall stop procedure in-case of emergency	M.P.13.1 The system shall halt all motions within 500 milliseconds, in the event of an emergency or irregularities
	M.P.13.2 The system shall provide an alert to the surgical team within 2 seconds

Moving forward in our surgical procedure, so for M.F.8. Here, the system takes a proactive role, expertly drilling holes in the bone. But it's not about drilling just any hole. Our commitment, as emphasized in M.P.8.1, is to an unparalleled precision. We strive to drill with a positional accuracy of just 2 mm and an orientation fineness within a mere 1.5°. This ensures that every drilling action is not only precise but also aligned with the overarching surgical plan.

Visuals play a paramount role in surgical procedures. Otherwise the doctor will act as a fool during the whole procedure,right? That's why M.F.9 is pivotal. Before making any move, our system will present the surgical roadmap, allowing for real-time visualization of the plan. And when we say real-time, we genuinely mean it. M.P.9 ensures that the visualization is rendered with a latency of 150 ms or even less, offering clinicians an almost instantaneous view.

Lastly, to ensure our system is not just smart but also user-friendly, M.F.10 focuses on the interaction. Our User Interface (UI) is designed to respond swiftly to commands. As per M.P.10.1, any command input will be processed in less than 50 milliseconds. Furthermore, M.P.10.2 lays down the essential control functions our UI will facilitate: starting the procedure, pausing it if needed, and resetting for a fresh start. This trio ensures a seamless user experience and operational control at every stage

MF 11 further establish the obstacle avoiding algorithms here, and MF12 make sure we could handle any emergency situation, restricted on the latency time and responding time

13 of 56

Desired Functional & Performance Requirements

Functional Requirement	Performance Requirement
D.F.1 The system shall compute the planning algorithm	D.P.1 The system shall generate surgical plan within 3 seconds
D.F.2 The system shall operate without the integration of tracking devices.	D.P.2 The system's performance shall remain consistent irrespective of the presence or absence of tracking devices.

As we transition from the essential to the ideal, let us delve into our Desired Functional Requirements, aiming to push the boundaries of surgical assistance.

Starting with D.F.1, our system is designed to be at the forefront of planning and preparation. The objective is not just to compute but to optimize. Our aspiration, as stated in D.P.1, is to have the surgical plan materialize in a fleeting span of just three seconds. Such rapid computation doesn't merely signify efficiency; it means reducing the window for uncertainties and ensuring that medical professionals have the timely information they require.

Further, D.F.2 emphasizes our drive towards minimalism and precision. By opting for a system devoid of trackers, we are eliminating potential hindrances and potential sources of error. Yet, our commitment doesn't waver. As articulated in D.P.2, regardless of the presence or absence of trackers, the system's performance remains consistent. This consistency ensures that medical professionals can trust the system's outputs, knowing that its functionality is uncompromised, providing a seamless experience

14 of 56

Mandatory Non-Functional Requirements

The system will:

M.N.1 The system will be safe and easy to use for the surgeon
M.N.2 The system will have a procedure time not more than 5-10 mins compared to standard commercial surgery (currently 30-40 mins)
M.N.3 The system will not be an obstruction to the surgeon

15 of 56

Desired Non-Functional Requirements

D.N.1 The system's extendability to other surgical procedures must uphold all relevant safety standards and protocols.
D.N.2 The system's design for extendability should ensure straightforward adaptation and minimal training for different surgical procedures.
D.N.3 The system will follow industrial standards for surgical robot
D.N.4 The system will not be bulky

16 of 56

Functional Architecture

3

17 of 56

18 of 56

Subsystem

Trade Studies

4

19 of 56

Subsystem Level Trade Study : The Cameras

20 of 56

Sensing scenarios

Sense bone shape

Arm mount camera
Close range sensing, high resolution for better point clouds

Sense surroundings

Top-view camera
Avoid collision, large FOV, fast FPS

21 of 56

Subsystem Level Trade Study : Arm Mount Camera

22 of 56

Subsystem Level Trade Study : Top-view camera

23 of 56

Manipulator

KUKA LBR Med 7

Kinova Link6

24 of 56

Very Comprehensive Manipulator Trade Study

Criteria	Weight Factor	Kinova Link 6	KUKA LBR Med 7
Does the robot have “Medical” in its name?	100%	No	Yes
			Winner

25 of 56

Manipulator Trade Study (Real)

Criteria	Weight Factor	Kinova Link 6	KUKA LBR Med7
DoF	20	3	5
Payload	15	3	4
Repeatability	20	4	4
Reach	5	4	3
ROS2 Support	20	1	4
Safety	20	4	4
Cost	0	5	5
		3.05	4.15

26 of 56

Manipulator Trade Study (Real)

Criteria	Weight Factor	Kinova Link 6	KUKA LBR Med7
DoF	20	3	5
Payload	15	3	4
Repeatability	20	4	4
Reach	5	4	3
ROS2 Support	20	1	4
Safety	20	4	4
Cost	0	5	5
		3.05	4.15

0.1mm

27 of 56

Manipulator Trade Study (Real)

28 of 56

KUKA LBR Med 7

Kinova Link6

6dof

7dof

29 of 56

Software Support (ROS2)

KUKA LBR Med 7

Package that supports Med7 - https://github.com/lbr-stack/lbr_fri_ros2_stack
Not official but maintained by Kings College. Seems to be up to date.
It's got URDF/ ROS2 Package/ MoveIt! Config along with some demos.
Alternative Package that supports iiwa/sunrise in general - https://github.com/ICube-Robotics/iiwa_ros2

30 of 56

Software Support (ROS2)

KUKA LBR Med 7

Package that supports Med7 - https://github.com/lbr-stack/lbr_fri_ros2_stack
Not official but maintained by Kings College. Seems to be up to date.
It's got URDF/ ROS2 Package/ MoveIt! Config along with some demos.
Alternative Package that supports iiwa/sunrise in general - https://github.com/ICube-Robotics/iiwa_ros2

31 of 56

Software Support (ROS2)

KUKA LBR Med 7

Package that supports Med7 - https://github.com/lbr-stack/lbr_fri_ros2_stack
Not official but maintained by Kings College. Seems to be up to date.
It's got URDF/ ROS2 Package/ MoveIt! Config along with some demos.
Alternative Package that supports iiwa/sunrise in general - https://github.com/ICube-Robotics/iiwa_ros2

Kinova Link6

There is this official package - https://github.com/Kinovarobotics/ros2_kortex
But it only provides/mentions Gen3 variants.
There is this separate repo for Link 6 - https://github.com/Kinovarobotics/Kortex3 but this is just a Python Interface.
Couldn’t find the URDF / description package for Link6. There are CAD files available on official site so worst case will have to build our own URDF / config.
Hipster also mentioned having issues with the Kortex API.

32 of 56

Cyber-physical Architecture

5

33 of 56

34 of 56

35 of 56

36 of 56

37 of 56

38 of 56

39 of 56

Work Breakdown Structure

6

40 of 56

41 of 56

42 of 56

43 of 56

44 of 56

45 of 56

Schedule & Milestones

7

46 of 56

Milestones

End-to-end

happy flow

SVD

Workspace setup (31 Jan)
End Effector done (28 Feb)
Perception pipeline setup (Mar 15)
Manipulator & Drill controls (Mar 15)
Integration and Testing (April 15)

Optimisations to meet all functional and performance requirements

FVD

Surgeon I/O (Sep 15)
Reach desired accuracy for drill (Oct 20)
Dynamic Compensation and active registration (Oct 20)
Integration and Testing (November 20)

47 of 56

48 of 56

49 of 56

Risk Analysis

8

50 of 56

Risk 1

Risk Title	R1: Cameras are not accurate	Date Submitted	12/3/24
Risk Owner	Kimi	Date Updated	-
Description		Risk Type
The Realsense D435 / D405 are not providing data accurate enough for registration and compensation		Technical

Consequence		Metrics
We can’t properly register the patient’s bone and guide the manipulator.		Likelihood	Consequence
		1	4
Mitigation Plan
Action		Outcome
-Test cameras immediately upon receiving - Re-calibrate cameras - Adjust camera mounts - Brainstorm alternate vision solutions		Ensure better registration and reduce likelihood of camera failure.

R1

51 of 56

Risk 2

Risk Title	R2: MRSD 3D Printer unavailable	Date Submitted	12/3/24
Risk Owner	Li-Wei	Date Updated	-
Description		Risk Type
The 3D printer in the MRSD room does not function, or is not available due to high demand		Technical + Schedule

Consequence		Metrics
We can’t print the parts for camera mount, end effector, drill mount, test bones		Likelihood	Consequence
		4	2
Mitigation Plan
Action		Outcome
- Talk to Tim in the RI shop - Use TechSpark printer - Get a personal 3D printer		Ensures we have alternative options in case of unavailability

R2

52 of 56

Risk 3

Risk Title	R3: Manipulator is damaged	Date Submitted	12/3/24
Risk Owner	Shivangi	Date Updated	-
Description		Risk Type
The manipulator sustains physical damage during transportation or usage		Technical

Consequence		Metrics
Manipulator does not function properly		Likelihood	Consequence
		1	5
Mitigation Plan
Action		Outcome
Follow user manual for safely operating and transporting the arm Store arm in a secure area away from liquids, weather conditions		Reduces likelihood of the manipulator getting damaged

R3

53 of 56

Risk 4

R4

Risk Title	R4: Drilling mechanism insufficient	Date Submitted	12/3/24
Risk Owner	Param	Date Updated	-
Description		Risk Type
Off-the-shelf dremel may not be able to interface with our system/ may not meet our requirements		Technical

Consequence		Metrics
Unable to drill holes in the bone		Likelihood	Consequence
		2	4
Mitigation Plan
Action		Outcome
Purchase drill as soon as semester begins - Test drill on bone model to confirm drill bit and strength - Design a custom drill (a basic literature review has been done for alternatives)		Holes will be drilled in the bones

54 of 56

Risk 5

Risk Title	R5: Drill injures a person	Date Submitted	12/3/24
Risk Owner	Abhishek	Date Updated	-
Description		Risk Type
Accidentally, control to the drill is lost and it injures a person		Technical

Consequence		Metrics
The medical robot does the opposite of its job		Likelihood	Consequence
		1	4
Mitigation Plan
Action		Outcome
- Design and build and extensively test our E-Stop - Follow drill user manual for safe operation - Keep people a safe distance away - Have a first-aid kit ready		Reduces likelihood of injury, and lessens the severity

R5

55 of 56

Thank you and Break a Leg!

Top Risk #6: Li-Wei falls asleep during SVD

Likelihood: 5

Consequence: 5

Li-Wei

Forward Kinematics

56 of 56

CREDITS: This presentation template was created by Slidesgo, and includes icons by Flaticon and infographics & images by Freepik