P16051: Robotic Eye Motion Simulator 2

Preliminary Detailed Design

Table of Contents

Team Vision for Preliminary Detailed Design Phase

In carrying on from Subsystem Design, further design choices were made which elaborated upon the options available in the previous design phases. A rotational motor was chosen for moving the eye in 1-dimension in order to meet engineering specs and cost limitations.

Further analysis and design were performed in order to satisfy the small details and ensure that the customer goals would be met.

Drawings, Schematics, and Prototypes

The finalized design decision made for this review was modeled in CAD and several analyses were performed on it as shown in the next section. The overview of schematics and drawings of our design is shown below.

In designing the model, several aspects of the design were considered.

Front View

public/Photo%20Gallery/Front View.png

Side View

public/Photo%20Gallery/Side View.png

Isometric View

public/Photo%20Gallery/Corner View.png

National Instruments LabVIEW was selected as the interface of choice in controlling both the motor and motor controller. This decision was made based upon the fact that National Instruments and Maxon have a partnership and thus have software libraries available to use. A prototype of the GUI that will be used was made in LabVIEW and is shown below.

public/Photo%20Gallery/GUI Prototype.png

Despite the program being made in LabVIEW, the finished product will not require LabVIEW for operation. LabVIEW Professional has software such as the Application Builder which allows the programs built in LabVIEW to be compiled and exported as a standalone executable with the proper libraries for operation.

Additional Features - Concepts

With rotation limited to one axis, ideas were developed in order to bring at least diagonal movement into light. Several concepts were explored as shown in the drawings below. Ultimately, the device will be mounted on a tripod and rotated to the desired angle.

public/Photo%20Gallery/Diagonal Drawings.png

The additional feature of blinking was developed into a feasible idea. Due to the nature of the motor and its torque limitations, mounting a motor to the gimbal itself for blinking was not feasible. However, the act of blinking; momentary loss of eye vision, was able to be replicated from the eye tracker's perspective by having an object temporarily block vision by swinging in the way. The idea was modeled in CAD and shown below. The concept for blinking isn't practical for the goals of this project and is limited by practicality as well as cost.


The design that we have chosen consists of sensitive parts which would benefit from not having tampering hands or dust build up from damaging or obstructing components. In addition to this, active electronics are stationed within the device and would pose a safety hazard. To address this, a polycarbonate protective casing would be enveloped around the I-beam containing these components. The concept was modeled in CAD and shown below.


Calibration Plan

Calibration will have to be performed on the robot once functional. The plan is to show exactly where the eye is pointed using a laser pointer. The concept decided upon consists of an outer mold of the front of the OEMI-7 model eye, with an embedded laser pointer in the center of the front surface. The mold will be 3D printed. Three prongs will be inserted through holes in the clamp ring and secured in place from the rear side.


Analysis and Simulation

Several different types of analyses were performed during this phase of the project. The feasibility of the design needed to be tested in a variety of ways, especially so due to our tight accuracy requirements.

Heat Analysis

A Comsol analysis was performed in determining if the heat output of the motor and motor controller would affect the I-beam. No significant heat exchange took place which would affect either the structural integrity of the I-beam or accuracy. In addition to this, the motor controller was analyzed via its specs.


Following through with the Comsol analysis, hand calculations were performed in determining if the heat output of the motor controller would contribute to a hotter-than-necessary environment within the device.

public/Photo%20Gallery/Heat Analysis.png

Stress analysis was performed in order to measure any noticeable change of shape if a force of 10lbs were applied to the top of of the I-beam on a stable surface. In addition to this, the torque stress on the driveshaft of the motor was analyzed.

Inertia Calculations

With the updated design, the inertia of the moving parts had to be re-calculated in order to maintain accurate values. The updated calculations of inertia are shown below.



Structural Analysis

public/Photo%20Gallery/Stress Analysis.png

public/Photo%20Gallery/Stress Simulation.png

public/Photo%20Gallery/Deflection Simulation.png

I-beam structural simulations

public/Photo%20Gallery/Torque Simulation.png

Motor shaft structural simulation

Although this shouldn't be necessary with our design, a simple eye offset calculation was performed to determine where the eye would be looking if it were offset from the y-axis of rotation.

public/Photo%20Gallery/Eye Offset.png

Bill of Material (BOM)


Output and Destination

Completed BoM and Budget

Design and Flowcharts

The flowchart from the previous design phase is shown below. In terms of the 3 options, Option 3 is directly applicable to the approach being taken at this moment. The microcontroller has been bypassed in favor of directly connecting the motor controller to a computer via USB.

public/Subsystem Design Documents/Electrical/EE.png

Risk Assessment

In mitigating the risks involved with this project, several attributes which were most relevant were carried over from the previous design phases. The table below shows the risks which are still applicable to the project.

The highest risk items at the moment are not meeting the accuracy specifications given to us. Due to the extremely tight spec and the limited tolerances of the device being designed, this is the most likely risk which will occur. In addition to this, the software is unable to be coded due to the lack of a motor controller. Any preliminary coding other than making the GUI will be unable to be tested until the motor controller is in hand.

public/Photo%20Gallery/Risk Mitigation Detailed Design.png

Design Review Materials

Links for:

Plans for next phase

3 week plan here!

Subject Matter Experts

Who We Met With What We Talked About

Machine Shop Staff

Dr. Kempski

Dr. Bodeo

Touched base about the machinability of our design.

Discussed mechanical time constant.

Discussed motor/drive shaft connection, and gear backlash.

We would like to acknowledge the time taken out of each Subject Matter Expert's busy schedule to talk to us, thank you.

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Subsystem Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Integrated System Build & Test with Customer Demo | Verification & Validation | Final Gate Review