Proceedings of the Multi-Disciplinary Senior Design Conference Page

Proceedings of the Multi-Disciplinary Senior Design Conference Page

Project Number: P16051

The Robotic Eye Motion Simulator

Joshua Long
Mechanical Engineer / Nathan Twichel
Biomedical Engineer
Jordan Blandford
Mechanical Engineer / Amy Zeller
Biomedical Engineer / Peter Cho
Electrical Engineer

Abstract JORDAN

Contemporary 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 AMY

Eye 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 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 JOSH

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.

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 PETER

The 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 Analysis

In 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 NATE

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.

Acknowledgments AMY

We 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 - NATE

Customer 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.