edge.rit.eduedge.rit.edu/edge/p16051/public/integrated system buil… · web viewour most...

Multidisciplinary Senior Design ConferenceKate Gleason College of Engineering

Rochester Institute of TechnologyRochester, New York 14623

Project Number: P16051

THE ROBOTIC EYE MOTION SIMULATOR

Joshua LongMechanical Engineer

Nathan TwichelBiomedical Engineer

Jordan BlandfordMechanical Engineer

Amy ZellerBiomedical Engineer

Peter ChoElectrical Engineer

ABSTRACT JORDANContemporary eye trackers have no industry standard, various eye tracker manufacturers have mostly

proprietary and arbitrary standards that they measure and report their products statistics against. The Chester F. Carlson Center for Imaging Science at RIT gave our team the challenge of creating a robotic eye that was accurate, repeatable, and easy to manufacture; with the idea that this robotic eye could help to form a standard that the industry could adopt.

Our most important requirement was to simulate quick eye movement of the eye (saccade) in one axis with very accurate, controllable, and repeatable dynamics. We also needed to simulate smooth pursuit of an object without jitter; at the end of a test the eye needed to have followed a pre-programmed trajectory or produce results as to where it was at a specific time, so that data from the eye tracker and data from our eye could be compared.

(RESULTS SECTION TO BE WRITTEN)

NOMENCLATURE AMY

Eye Tracker - A device that tracks human eye movement and estimates gaze position.Saccade - The quickest eye movement. Normally performed when moving in between fixation points.Smooth Pursuit - The slowest eye movement. Normally performed when tracking a moving object.

INTRODUCTION AMYEye trackers have long been used in psychology research, visual systems research, marketing, and, recently,

as an input device for human-computer interaction. The quality of the data eye trackers output is a fundamental aspect for any research based on eye tracking. Data quality can be influenced by both eye tracker-specific properties

Copyright © 2016 Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Senior Design Conference

such as the camera, the illuminator, sampling frequency and latency, as well as biological properties of participants such as eye color, pupil size and eye makeup.

There is currently no standardized test method for evaluating the quality of data collected from eye trackers. The lack of standard may lead to research being based on unreliable data. Different manufacturers measure quality using their own methods and researchers either measure it again using different methods or simply report whatever numbers the manufacturer provides. In order to investigate the tracker-related issues only, a set of artificial eyes are needed to eliminate biological variance. Ideally, eye models that can perform real eye movements with high repeatability are needed so that the same movements can be recorded on different eye trackers. The COGAIN (Communication by Gaze Interaction) association, which is supported by eye tracking researchers, including the MVRL (Multi-Disciplinary Vision Research Lab) at RIT and eye-tracker manufacturers around the world, has been putting effort into developing such a set of artificial eyes. Progress has been made to establish a static eye model that mimics human eye structure. Now we need to automate the movement of this.

The objective of this project is to develop a robotic eye that mimics human eye movement to standardize eye tracker testing. The first objective was to develop a robotic eye that is programmable and performs repeatable movements. A previous MSD team delivered hardware and software capable of demonstrating smooth pursuit. The current MSD team is targeting having the model eye perform eye movements including both smooth pursuit and saccade. Another goal of this project is to make the robotic eye affordable since eye tracker manufacturers and eye tracking researchers have expressed their interest in purchasing these devices.

PROCESS JOSHThis section should describe the theoretical underpinnings for your project, assumptions made, methods used

and experiments performed, along with an overview of the design process utilized – eg. customer requirements, engineering requirements, constraints, concepts, evaluation, analysis, building and testing. Be sure to explicitly call out applicable engineering standards.

The design for this project ultimately began with a list of customer requirements (see Appendix A). This list was built from the previous team’s customer requirements list, along with some additional measures specific to this particular project. From the customer requirements, another list was made of engineering requirements (see Appendix B). The distinction of the engineering requirements is that these are more specific and most of them have numerical values to use as goals, while the customer requirements were more subjective, with specifications that the device achieves “saccade” or has “accurate and precise positioning.” Some additional constraints were taken into consideration as well, including that the device had to be at most the size of a human head.

The most important engineering requirements for this project were that it could achieve the acceleration and velocity of a human saccade while maintaining high accuracy and precision. The ideal values for the positioning requirements were that the device could meet a resolution of 0.0075 degrees, with an accuracy of 0.015 degrees, or double the resolution. These specifications were put in place due to the claimed accuracy values of popular eye trackers, and the goal was for this device to beat the accuracy that the eye tracker manufacturers claim. A human eye can perform a saccade at an angular velocity of 500 degrees/s, and an angular acceleration of 20,000 degrees/s2. These numbers were also essential for the project to be successful. Each of these figures can also be found in Appendix B.

The specifications needed for the motor to drive the system at the required velocity and acceleration were difficult to find at an affordable price. The motor specifications that were evaluated during benchmarking of motor options included a torque of 0.05 N-m, resolution of at most 0.0075 degrees, accuracy of 0.015 degrees, maximum speed of at least 500 degrees/s, acceleration of at least 20,000 degrees/s, mechanical time constant of at most 5.48 ms, and a size small enough that the whole device could be at a maximum the same size as a human head. The ideal motor choice would meet all these requirements while resulting in a total project cost estimate of $2,000 at the very most.The motor of choice ended up being the Clearpath from Teknic Motors, as shown in Figure 1 below. The



Teknic Clearpath met the specifications for speed, accuracy, torque, mechanical time constant, and cost, but lacked the resolution and accuracy to be ideal. The proposed remedy was to improve resolution by using a gear ratio in a belt and pulley system.

Figure 1: ClearPath Motor from Teknic Motors

The belt drive system was proposed to use products from Gates, a manufacturer of timing belts and pulleys. Gates was chosen for their reputation of high quality belt drive products, including belts with a small pitch, but wide enough to resist significant stretching. The goal of the belt drive system was to use parts with the smallest pitch available, while still having a sufficient belt width. The belt and pulley system of choice included a pitch of 3mm, and a belt width of 15mm. There was a choice of a 2-mm pitch, but the widest belt available in that size was 9mm, and it was decided that the slightly larger pitch was an acceptable tradeoff for having a wider belt. The pulleys were selected in order to obtain a gear ratio of approximately 3:1. However, the smaller pulley (attached to the motor), was recommended to have a pitch diameter of at least 1 inch, so the pulleys chosen had pitch diameters of 1.053 inch and 3.384 inches. These pulleys contained 28 and 90 teeth, respectively, which result in a gear ratio of approximately 3.21:1. An idler pulley was added to the system to maintain sufficient tension in the belt during operation. The position of the idler would be adjustable to allow for the belt to be easily installed or removed, if necessary.

***JOSH TALK ABOUT OVERALL SYSTEM DESIGN



RESULTS AND DISCUSSION PETERThe final prototype consists of the Teknic Clearpath motor, the gimbal containing the OEMI-7 model eye, and a

belt and pulley system using Gates products all controlled by an Arduino Uno microcontroller. In operating the motor via our software and testing the device after it was assembled, there was higher system error than what was theoretically expected.

The motor itself contains the motor and controller integrated into one unit. It is a 12,800 post-quad encoder count device with 6,400 of them being controllable. This gives a commandable motor resolution of 0.056 degrees per count. The motor itself has an accuracy of +/- 1 encoder counts per movement post-quad. This means that the motor is capable of moving 0.056 degrees per count +/- 0.028 degrees. The belt and pulley system from Gates uses 28 teeth and 90 teeth pulleys creating a 3.21:1 gear ratio. When properly tensioned, the estimated backlash from the belt and pulley system was 1 to 2 thousandths of a degree which was negligible in terms of the total system error. With this gear ratio applied, however, the assembled device would allow for a theoretical resolution of 0.018 degrees per count +/- 0.009 degrees on the gimbal shaft assuming all else was perfect.

While designing and testing the device even in preliminary stages, it was obvious that the theoretical expectations were not realistic and there would be sources of system error contributed by both the Arduino software and the mechanical system itself. The Arduino Uno microcontroller operates on a 16MHz processor and allows for the pulse width modulation (PWM) of its digital output pins to operate up to 8MHz at 50% duty cycle. With this project, the Arduino operated the PWM at 500kHz in order for the motor to have a high input resolution (25,600 counts per revolution) to minimize potential errors when commanding the motor to different locations. Despite this, the software and hardware aren’t perfect and thus the motor can be a few counts off when being commanded to a certain position. These errors are cumulative when the user sends a large amount of inputs and the motor can slowly lose its zero and begin to have an offset. This behavior was tested with a variety of scripts and different numbers of commands in order to find a relationship between how many movements it takes to cause an encoder count error.

A test script was created in order to simulate the device being commanded to a variety of positions. The script involved traversing from a positive angle to a negative angle as it eventually reached 0 degrees. At 0 degrees, the motor was set so that it corresponded to 0 encoder counts. By repeating this script and re-zeroing the motor each time, the motor error offset, if any, was documented.

Table 1: Offset Analysis Test Script

The test script was run a total of 25 times at a speed profile “0” of 900 rpm and speed profile “1” of 100 rpm. Acceleration was set to 100,000 rpm/s. The data was processed and the results held 3 occurrences of no offset, 12 occurrences of +/- 1 count, 6 occurrences of +/- 2 counts, 2 occurrences of +/- 3 counts, and 2 occurrences of +/- 4 counts. The mean expected value was found to be 1.52 counts with a standard deviation of 1.89 and a standard error of 0.38.



Figure 3: Offset AnalysisIn conclusion of testing the motor response and accuracy performance, it can be said that the user may expect

+/- 2 encoder counts of error after sending a string of commands up to 13 commands long. This correlates to 0.112 degrees of error on the motor shaft itself. In order to avoid further error, it is recommended that the user use the GUI to re-zero the device back to true home position after performing a series of commands in order for best performance.

CONCLUSIONS AND RECOMMENDATIONS NATEThis section should include a critical evaluation of project successes and failures, and what you would do

differently if you could repeat the project. It’s also important to provide recommendations for future work.

ACKNOWLEDGMENTS AMYWe would first like to acknowledge our customers Jeff Pelz and Dong Wang from RITs Chester F. Carlson

Center for Imaging Science. We would also like to thank the Kate Gleason College of Engineering for its support with this project. As well as our guide Susan Farnard, and all topic specialists we consulted with during this project.

APPENDIX - NATECustomer Requirements

Engineering Requirements



Bill of Materials

ABSTRACT – USE STYLE “ABSTRACT CLAUSE TITLE”A brief summary (often <200 words). The primary purpose of the abstract is to provide a concise summary of

the paper so that readers can decide whether or not the full text is of interest to them. The abstract should articulate project objective, scope, and results

NOMENCLATURE – USE STYLE “NOMENCLATURE CLAUSE TITLE”Most teams will be able to integrate nomenclature within the body of the paper. If you have significant

nomenclature to define, you may want to create a distinct Nomenclature section. Nomenclature should follow customary usage. For reference, consult American National Standards Institute (ANSI) recommendations. The nomenclature list should be in alphabetical order (capital letters first, followed by lowercase letters), followed by any Greek symbols, with subscripts and superscripts last, identified with headings

INTRODUCTION (OR BACKGROUND) – USE STYLE “TEXT HEADING 1”This section should articulate the design objective, the scope and motivation for the overall effort, along with a

historical context for the project. The introduction may take the form of a literature review, review of prior projects, benchmarking survey, or a combination of these. Note: As you write the paper, you don’t need to adjust the spacing between paragraphs or between headings and text. If you use the styles indicated for headings, and use “Body Text Indent” for all standard text, you will not need to add extra carriage returns or change paragraph spacing.



PROCESS (OR METHODOLOGY) – USE STYLE “TEXT HEADING 1”This section should describe the theoretical underpinnings for your project, assumptions made, methods used

and experiments performed, along with an overview of the design process utilized – eg. customer requirements, engineering requirements, constraints, concepts, evaluation, analysis, building and testing. Be sure to explicitly call out applicable engineering standards.

RESULTS AND DISCUSSION – USE STYLE “TEXT HEADING 1”This section should describe your final prototype (product or process), whether it met specs (results of testing),

and how you evaluated its success. Most conference papers include enough information for your work to be reproducible.

CONCLUSIONS AND RECOMMENDATIONS – USE STYLE “TEXT HEADING 1”This section should include a critical evaluation of project successes and failures, and what you would do

differently if you could repeat the project. It’s also important to provide recommendations for future work.

REFERENCES – USE STYLE “REFERENCES CLAUSE TITLE”Within the text, references should be cited in numerical order, by order of appearance. The numbered reference

should be enclosed in brackets. For example: “It was shown by Prusa [1] that the width of the plume decreases under these conditions.” In the case of two citations, the numbers should be separated by a comma [1,2]. In the case of more than two references, the numbers should be separated by a dash [5-7].

References to original sources should be listed together at the end of the paper, and should include papers,

technical reports, books, prior team projects, personal discussions, websites (not Wikipedia), and software. References should be arranged in numerical order according to the sequence of citations within the text. Each reference should include the last name of each author followed by his or her initials.

(1) References to journal articles and papers in serial publications should include: last name of each author followed by their initials, year, full title of the article in quotes, full name of the publication (abbreviated), volume number (if any) in bold (do not include the abbreviation, "Vol."), issue number (if any) in parentheses (do not include the abbreviation, "No."), inclusive page numbers using “pp.".

(2) Reference to textbooks and monographs should include: last name of each author followed by their initials, year of publication, full title of the publication in italics, publisher, city of publication, inclusive page numbers using "pp.", chapter number (if any) at the end of the citation following the abbreviation, "Chap."

(3) Reference to individual conference papers, papers in compiled conference proceedings, or any other collection of works by numerous authors should include: last name of each author followed by their initials, year of publication, full title of the cited paper in quotes, individual paper number (if any), full title of the publication in italics initials followed by last name of editors (if any) followed by the abbreviation, "eds.", city of publication, volume number (if any) in boldface – include, "Vol." if part of larger identifier (e.g., "PVP-Vol. 254") – inclusive page numbers of using "pp.".

(4) Reference to theses and technical reports should include: last name of each author followed by their initials, year of publication, full title in quotes, report number (if any), publisher or institution name, city.

Example References:[1] Ning, X., and Lovell, M. R., 2002, "On the Sliding Friction Characteristics of Unidirectional Continuous FRP

Composites," ASME J. Tribol., 124(1), pp. 5-13.[2] Barnes, M., 2001, "Stresses in Solenoids," J. Appl. Phys., 48(5), pp. 2000–2008.[3] Jones, J., 2000, Contact Mechanics, Cambridge University Press, Cambridge, UK, Chap. 6.[4] Lee, Y., Korpela, S. A., and Horne, R. N., 1982, "Structure of Multi-Cellular Natural Convection in a Tall

Vertical Annulus," Proc. 7th International Heat Transfer Conference, U. Grigul et al., eds., Hemisphere, Washington, DC, 2, pp. 221–226.



[5] Hashish, M., 2000, "600 MPa Waterjet Technology Development," High Pressure Technology, PVP-Vol. 406, pp. 135-140.

[6] Watson, D. W., 1997, "Thermodynamic Analysis," ASME Paper No. 97-GT-288.[7] Tung, C. Y., 1982, "Evaporative Heat Transfer in the Contact Line of a Mixture," Ph.D. thesis, Rensselaer

Polytechnic Institute, Troy, NY.[8] Kwon, O. K., and Pletcher, R. H., 1981, "Prediction of the Incompressible Flow Over A Rearward-Facing

Step," Technical Report No. HTL-26, CFD-4, Iowa State Univ., Ames, IA.

ACKNOWLEDGMENTS – USE STYLE “ACKNOWLEDGMENTS CLAUSE TITLE”Be sure to acknowledge your sponsor and customer as well as other individuals who have significantly helped

your team throughout the project. Acknowledgments may be made to individuals or institutions.



Requirements and Advice

Construct an outlineA proper outline is the framework upon which a good paper is readily written. In the process of making the outline, ideas are classified and thoughts are ordered into a logical sequence that is readily transformed into complete sentences. In outline form, the sequence of the various items and the progression of thought can easily be adjusted and readjusted until the desired order is obtained.

LengthYour paper should not exceed 8 printed pages, all inclusive!

Style. The chief purpose of the paper is to convey information to others, many of whom may be less familiar with the general subject than the author. Care should be taken, therefore, to use simple terms and expressions and to make statements as concise as possible. If highly technical terms or phraseology are necessary, they should be adequately explained and defined. The use of the first person and reference to individuals should be made in a manner that avoids personal bias. Company names should be mentioned only in the acknowledgments.

Papers should be concise. Long quotations should be avoided by referring to sources. Illustrations and tables are desirable but they should be kept to a reasonable level, especially considering the 8-page maximum length. Detailed drawings, lengthy test data and calculations, and photographs that may be interesting but which are not integral to the understanding of the subject, should be omitted. Equations should be kept to a reasonable level.

OriginalityOnly original contributions are accepted for publication. Under certain circumstances, reviews, collations, or analyses of information previously published may be acceptable.

AccuracyAll technical, scientific, and mathematical information contained in the paper should be carefully checked. SI units of measurement should be used. When U.S. customary units are given preference, the SI equivalent should be provided in parentheses or in a supplementary table. Similarly, when preference is given to SI units, the U.S. customary units should be provided in parentheses or in a supplementary table.

HeadingsHeadings and subheadings should appear throughout the paper to divide the subject matter into logical parts. Headings assist the reader in following your thought process and in forming a mental picture of the points of chief importance.

Tabulations/EnumerationsIt is often advantageous to put related items in tabular or enumerative form, one after the other, rather than simply running them into the text. This arrangement, in addition to emphasizing the items, creates a graphic impression that aids the reader in accessing the information. It is customary to identify the individual items as (1), (2), (3), etc., or as (a), (b), (c), etc. Although inclusion of such elements makes the text livelier, care should be taken not to use this scheme too frequently, as it can make the reading choppy.

MathematicsEquations should be numbered consecutively beginning with (1) and including any appendices. The number should



be enclosed in parentheses and placed on the right-hand-side of the equation. It is this number that should be referenced within the text. An example is shown below in Eq. (1).

(1)Formulas and equations should be created to clearly distinguish capital letters from lowercase letters. Care should be taken to avoid confusion between the lowercase "l"(el) and the numeral one, or between zero and the lowercase "o." All subscripts, superscripts, Greek letters, and other symbols should be clearly indicated.

In all mathematical expressions and analyses, any symbols (and the units in which they are measured) not previously defined in nomenclature should be explained. If the paper is highly mathematical in nature, it may be advisable to develop equations and formulas in appendices rather than in the body of the paper.

FiguresAll figures (graphs, line drawings, photographs, etc.) should be numbered consecutively and have a caption consisting of the figure number and a brief title or description. The caption should be centered under the figure, using style “Figure Caption” This number should be used when referring to the figure in text. Figures should be referenced within the text as "Fig. 1." When a reference begins a sentence the abbreviation "Fig." should be spelled out (e.g., “Figure 1”). You may use single column figures or, if needed, the figure may span both columns.

Figures should be embedded electronically into your paper. Be sure to include the actual figure and not a link to another file. We will produce your paper from the electronic format that you provide. All photographs should be submitted as good quality jpeg or tiff files embedded in the Word file.

TablesAll tables should be numbered consecutively and have a caption consisting of the table number and a brief title. The caption should be centered above the table, using style “Table Caption”. The table number should be used when referring to the table in text.

Tables may be inserted as part of the text, or included on a separate page immediately following or as close as possible to its first reference, with the exception tables included in an appendix.

Format Papers must be submitted in Microsoft Word format. Your paper will be printed and prepared directly from your electronic media. Do not assume that any additional layout work will be performed, although we do reserve the right to make layout changes and editorial changes as needed to meet the publication turn-around time.

Check all page headings to be sure that dates and paper numbers are current. Also:● Math expressions must be created using the Equation Editor supplied with Microsoft Word. Otherwise, the

integrity of these special characters will be lost. ● All graphics should be embedded in the text file. Make sure the image is INCLUDED in the paper – not

hyperlinked to a separate file.● All Tables must be created using the Table utility provided with Microsoft Word. Tables created by use of the

tab keys will not convert properly. ● No styling is necessary. However, inclusion of italics and roman script is necessary to indicate math and other

special characters. ● Label the electronic file clearly as “Pxxxxx project name” and submit it to the program office.

Copyright The copyright statement at the bottom of the first page allows RIT (the MSD program) to print your paper and make it available electronically. The authors maintain the right to submit the paper for publication elsewhere. You will be



asked to sign an “offer of a technical paper” document which grants RIT rights under Copyright law. If this document is not signed, your technical paper cannot be published.


edge.rit.eduedge.rit.edu/edge/p16051/public/integrated system buil… · web viewour most...

Documents