P13061: Periodontal Measurement Test System
/public/

Systems Design

Table of Contents

Concept Development

The chart found below was used as brainstorming for the first round of concept generation. It breaks the project down into functions and then solutions for each function are listed. The cells highlighted in blue are "sky high" ideas, or ideas that would perform the function but are not feasible. The cells in green indicate the ideas that the team believes would perform the function the best, given the constraints of time and budget. These same ideas for performing each function are laid out in the Functional Decomposition below. Combinations are not shown here or in the Functional Decomposition, both tools simply lay out all of the solutions brainstormed for each individual function. The top solutions are combined later in the Pugh Matrix to assist the team in selecting the best combination of solutions for each function, thus creating the best system design possible.

Functional Decomposition Chart

Functional Decomposition

The functional decomposition shown below translates the chart above into a visual aid. The terms in each branch (excluding the possible solutions) are expressed in the form of verb, noun. This provides a simple, structured way to answer the questions of "How will each function be performed?" and "Why will each function be performed?".

Working from the left of the chart to the right

Working from the left of the chart to the right means that with each level of the functional decomposition the question "how will the previous function be performed?" is answered. Therefore, the left of the functional decomposition exhibits the overall function required: Measure Sulcus. The next level over represents how the sulcus will be measured. For example, "Position probe". The next level right represents how the probe will be positioned, such as "Position accurately". How will the probe be positioned accurately? The answer lies in the subsequent branch, "Constrain motion". Finally, the last branch answers the question "how will the motion be constrained?", with one option being an electric motor.

Working from the right of the chart to the left

Working from the right of the chart to the left means that with each level of the functional decomposition the question "why will this function be performed?" is answered. Therefore, the right of the chart exhibits a possible solution, such as "clamp". Why is a clamp being used? This question is answered in the branch to the left, "Hold probe". To answer the question "Why is the probe being held?" the branch to the left must be considered. Here it is shown that the probe is being held in order to "Position probe". Why is the probe being positioned? So the sulcus can be measured.

Functional Decomposition

Pugh Matrix

The Pugh Matrix is used to compare combinations of solutions for each function to a datum. Eventually, the Pugh Matrix will lead the team to choose the best solution for each function, creating the ideal system design. This process requires that a "good" datum be selected. If every concept listed scores better than the datum, a new datum should be selected. The process of constructing a Pugh Matrix is inherently iterative, meaning that the datum may change multiple times and that countless combinations of solutions should be considered and compared for each function.

To score each concept against the datum, each function is considered individually. The solution for function A is considered against the datum and is scored better (+), worse (-) or the same as (s) the datum. The +'s, -'s and s's are then totaled, providing insight into whether a solution is an improvement upon the datum, or not. This also allows the team to analyze what functions have solid solutions and what functions need better ones, thus generating more combinations of system solutions.

First Iteration

The team agreed to use the current sulcus measurement technique as the datum for the first iteration of the Pugh Matrix. As seen in the chart below, every concept is in fact better than the datum. This indicates that a new datum should be selected for the next iteration. Also, new concepts should be formed by combining the best method for completing each function from each of these concepts.

Second Iteration

This iteration incorporates a new datum, as every single combination scored better than the previous datum. New concepts were also generated by combining some facets of each of the previous ideas. This iteration indicates that no single method scores significantly better than the datum. Therefore, for the next iteration the datum will remain constant and new concepts will be generated using each method that scores a (+) in each criteria.

Third Iteration

For this iteration of the Pugh Matrix the datum remained the same. New concepts were generated using mostly methods that scored a (s) or a (+) for each criteria during the last iteration. Through this iteration, two concepts remain better than or the same as the datum, concepts 14 and 16 (as seen by the green boxes in the "score" section). The only differences between these concepts lie in criteria C and G (highlighted in yellow). Neither of the methods compared in these criteria is superior regarding performance; therefore, ease of assembly, manufacturing, etc. must be considered. This allows the team some flexibility in the method chosen to hold the probe and present the feedback.

Systems Architecture

Interface Definition

The graphic shown below illustrates the subsystems involved with measuring the sulcus and the interfaces between them. The four main subsystems are the probe fixture, tooth fixture, test specimen and data acquisition/feedback software. The interfaces between these subsystems can be found in the yellow ovals.

The interface between the probe fixture and the tooth fixture is the Labview program which will be used to move the fixture relative to one another. The interface between the tooth fixture and the test specimen will be the socket in which the phantom tooth is place on the turn table that is the tooth fixture. The interface between the test specimen and the data acquisition/feedback software is the probe itself as this will transmit signals measured on the tooth to the computer program in use. Lastly, the interface between the data acquisition/feedback software and the probe fixture movement is the UI, or user interface. This represents the program the user will use to activate the measurements and view the results when the test is complete.

Block Diagram

The block diagram shown below illustrates the top level view of the overall system interface and the connections between each part. The main subsystems are the Tooth and Probe fixture, the power supply powering the motors for movement, and outside of these two are the Ultrasound Pulser/Receiver unit, Oscilloscope, and computer interfacing with the main fixture.

The computer controls both the Ultrasound unit and the control unit of the tooth and probe fixtures. The oscilloscope receives its data through the Ultrasound unit and sends it to the computer. The Ultrasound unit activates the probe and receives the information it obtains from the tooth phantom. The control unit controls the movements of the 5 motors that move the tooth and probe fixtures, and the motors are powered by 12 V and 9 V supplies.

Tooth Phantom Design

The sketch below represents an idea for the construction of the phantom tooth. The geometry of the dentin and the enamel are not entirely representative of a human tooth, as certain areas of these components are not important for the measurement. It is proposed that the base of the tooth be square to facilitate a simple interface with the holding fixture. This will also allow for ease of creating a tight fit between the two while maintaining a simple assembly/disassembly for interchanging the tooth as necessary.

Some possible materials that can be used for the tooth are listed in the table below. The top choices of materials are highlighted in green. These materials were chosen due to their similarity to a human tooth and ease of manipulation. The materials being considered were eventually changed, details regarding the decision process can be found on the Detailed Design page.

Fixture Design

The picture below shows the overall design concept to be used for the fixture. This 5 axis positioning system utilizes power screws for the movement of the 3 linear axes, a turntable for yaw, and a directly mounted motor onto the probe fixture for pitch. The tooth or phantom tooth would be placed on the appropriate spot on the turntable, and testing would begin.

The photo below shows a close up view of the probe pitch joint. The probe holding fixture will also be mounted to the shaft, in between the ears of this fixture. This allows a motor to be directly (or indirectly) mounted to the shaft to control the pitch of the probe.

The photo below shows a preliminary sketch of the top view of the probe pitch joint with the probe holding fixture and probe attached.

The photo below shows a close up view of the probe holding fixture. The roughly cylindrical probe would sit in the groove in this fixture and be clamped down to secure it. Also, a shoulder could be added to the groove once the geometry of the probe is known to positively locate the probe along the length of the fixture. The photo below shows some initial ideas of how to actuate the probe in the "pitch" direction. While both of these ideas shown using a mechanical linkage of some sort between the motor and probe fixture are possible, the clevis pin style of movement shown above offers the greatest amount of radial movement, and is the most simple design.

The photo below shows an initial design to capture yaw movement of the probe. This design utilizes a double clevis pin design by simply adding another fixture similar to the pitch joint, but indexing it by 90 degrees. After some consideration it was decided to split up the 5 axes of movement so that yaw would be captured by a turn table that the tooth rests on, instead of attempting to have all axes of movement at the probe.

Stepper Motor Feedback System

Due to the usage of several stepper motors, a feedback system is necessary in order to maintain control during operation of the motors and ensure that no harm or collision occurs within the fully assembled fixture. Two concepts were explored in order to achieve this: Tripwire Sensors and Potentiometers. Listed below are various sensors and pots explored for the stepper motors feedback system. The decision choices regarding this system are detailed on the Detailed Design page.

Tripwire Sensors

Maxbotix LV-MaxSonar-EZ0

Image:Photo Gallery/Maxbotix_Image.jpg

Ultrasonic range finder. Datasheet can be found here.

Sharp GP2Y0A21YK

Image:Photo Gallery/Sharp_Image.jpg

IR proximity sensor. Datasheet can be found here.

QRD1114 IR Emitted / Phototransistor

Image:Photo Gallery/QRD1114.jpg

IR transmitter and photoresistor. Datasheet can be found here.

QRE1113 Line Sensor Breakout

Image:Photo Gallery/QRE1113.jpg

Line sensor IR emitted / phototransistor. Datasheet can be found here.

Potentiometers

Bourns 3048L-4-502

Image:Photo Gallery/LinearPot_Image.jpg

Linear motion potentiometer. Datasheet can be found here.

ALPS Slide Potentiometers RS60112A600N

Image:Photo Gallery/SlidePot_Image.jpg

Slide potentiometer. Datasheet can be found here.

User Interface/System Control

Below are some preliminary examples of user interface, Pass/Fail output, and some debugging setup for troubleshooting the motors.

public/Photo Gallery/User_GUI.png

This is the user GUI. For debug purposes I have more options than the finished product. The finished product should only have the selection for board type, COM port, and GPIB port for the O-Scope.

public/Photo Gallery/Pass_Fail.png

Examples of our Pass Fail banner, ideally for the finished product we would like to see an individual comparison of each test ran. The Pass/Fail is more for an overall result at the end.

public/Photo Gallery/Servo.jpg

This is a picture of the Arduino set up for practice with some Servo's interfaced through my laptop to Labview.

For Configuration information for Arduino and LabVIEW click on the following link. Configuration for Arduino and LabVIEW

System Design Review

Preliminary System Design Review Documentation

The presentation for the preliminary system design review held on Friday, December 21, 2012 can be found here: Preliminary System Design Review Presentation.

The meeting minutes from the preliminary system design review can be found here: Preliminary System Design Review Meeting Minutes.

System Design Review Documentation

The system design review was held on Friday, January 11, 2013. Unfortunately, the team was not able to muster any faculty experts to be present at the review. Therefore, team members will need to meet with faculty & professors individually to fill them in on the project and ask for their input. It is imperative that some faculty members from each area of the project attend the review during week 9. The systems design review presentation can be found below, as well as meeting minutes from the review.

The presentation for the system design review held on Friday, January 11, 2013 can be found here: System Design Review Presentation.

The meeting minutes from the system design review can be found here: System Design Review Meeting Minutes.

Home | Planning & Execution | Detailed Design | Build, Test, Document | Project Review | Photo Gallery