P15051: Robotic Eye for Eye Tracker

Transcription

1 P15051: Robotic Eye for Eye Tracker Andrew Drogalis Mechanical Engineer Tim O Hearn Mechanical Engineer Katie Hardy Daniel Webster Jorge Gonzalez Abstract: A robotic eye was constructed for the purpose of testing eye trackers. A human eye replica was provided and will be the object to be robotically controlled. The robotic eye is built to move in a combination of vertical and horizontal rotations. The rotations match the range of motion of a normal human eye. A hybrid gimbal design allows simultaneous rotations in both planes. Linear actuators are used to move the hybrid gimbal. The actuators chosen limit the velocity and precision of the device. In the future, the linear actuators will be upgraded. Introduction: There is currently no standardized test method for evaluating the quality of the data collected by human eye tracking devices. Consumers need to know what kind of data quality to expect when considering a purchase. Researchers using eye tracking data need to know if the data is reliable and need to quantify uncertainties. Manufacturers need a standard set of specifications to compare their products with those of their competitors. The solution to these problems is to create a robotic eye model with known inputs and predictable movement. Phase 3: Paper Outline 1 10/14/15

2 The goal of this project is to create such a robotic eye which can mimic the movement characteristics of the human eye and address the concerns of our stake holders. This robotic eye will be free from biological variance. This will reduce the number of variables in our system. The project will focus on creating a programmable robotic eye capable of smooth pursuit as well as slow saccade. It will be programmable in a sequence or individual movements and shall retain a small footprint appropriate for use in a laboratory environment. The project will seek to minimize the cost to manufacture, maintain, and operate such a device without sacrificing high repeatability and ease of operation. Process: Mechanical: The hybrid gimbal design was chosen because it had the lowest moment of inertia. High speed and high precision was required so a low moment of inertia is critical for high acceleration. Two motors were needed to control the robotic eye with the hybrid gimbal design. A linear actuator was used to drive the vertical motion because it would keep the motor off of the hybrid gimbal, therefore lowering the moment of inertia. A linear actuator was chosen for the horizontal motion, because it allowed for the same model motor to be used and it kept the control theory the same. In order to meet the engineering requirements a high velocity and high precision linear actuator was necessary. A voice coil linear actuator was specified that meet all of the engineering requirements. The total price was out of budget so a cheaper linear actuator was chosen. The goal of the mechanical design was to create a robust and repeatable system so that in the future the linear actuators can be upgraded. The mechanical system should not be the limiting factor in the precision of the device. Magnetic rod ends were chosen to translate the linear motion into rotational motion. Electrical: At the beginning of the project the electrical equipment was picked such that it could be versatile enough to allow for variations of the initial design. Some of the different components we needed to consider were: Power supply, controller, and communication systems. When we considered the use case of being used in a laboratory setting it made more sense for us to use a wall outlet

3 rather than creating the need for replaceable batteries. In terms of the controller that we would use there were many variable to consider. The basics were programming language, manufacturer, and type of storage. As a group we had decided that the manufacturer wasn t very important as long as all of the specifications were met. When it came to the programming language we found we could be a little flexible since the customer wanted it to be able to communicate with python, but the language didn t need to be python. This lead to narrow down the choices to Arduino and C since these were widely available and we had previous experience with these languages. Finally when considering the type of memory we did some initial calculations in order to determine approximately how much storage space we would need in order to hold the program, the motor commands, and the feedback. We based our calculations off of a five minute run time and used the result to determine the minimum specifications needed for memory storage on the controller. The way this influenced our choice of controller is it eliminated any controller which did not meet the requirement, and did not have any means of adding additional memory. From these determinations and the specifications given, along with wanting to be able to accommodate at least two motors we narrowed the search down to four controllers. We were able to pick the Firgelli L12 motors. Once the motors were decided on we were able to officially decide that we could use the Teensy 3.1 as the controller. We decided on this controller due to its clock speed, number of motors it was able to run, its low required voltage for operation and finally because it s small form factor would make it ideal for a small packaged final product. The option of the motor determined the method of control and the different features it would have. We chose the option that would allow us to have speed control, as well as some feedback on the position of the motor. The plan for the control scheme was that the Teensy would control the motor and its speed, then it would also read the feedback from it in order to record the motors location. Then using the feedback we could represent where the motor actually traveled too rather than just where it was told to go. Using this control scheme we would then add in some linear adjustments that would be able to adjust for any discrepancies in how the motor was operating versus how it was supposed to operate. Another feature of the control scheme which was talked about during MSD 1 was the use of a calibration program so that the motors and controller could be calibrated before running like most lab equipment.

4 The next implementation for the motor control was of the same theory, but used an H-bridge chip instead. This chip used standard five volt logic in order to tie a given pin to ground our Vcc2, which was tied to the motor supply voltage. By using an inverter and and gate we were able to make a control system which allowed for the Teensy s low voltage signal to control the motor, and keep it from ever entering a state where both sides of the motor were tied to the motor power supply. The next challenge of the control system was in implementing the speed control. As a result of the motor we picked the speed control would have to be done by varying the amount of voltage supplied to the motors. So our first design used to implement this was a digital potentiometer. The potentiometer was set up such that the teensy would control where the wiper of the potentiometer was located. Then by tying one side of the potentiometer to the motor supply volage and the other to ground we were able to pull a variable voltage from the output of the wiper. The way that the wiper worked was that by sending an address using the Teensys control pins. This address would set where the wiper would be, and the resistance across the digital potentiometer could be used as a varying voltage divider that would depend on where the wiper was located. After some testing we were able to get the voltage output working, but found that when we tried to supply the H-bridge s Vcc2 pin with it the voltage would drop drastically. What we found was that the potentiometer was unable to drive a load of lower resistance, and since the motors themselves are of relatively low resistance this option became unviable. The next idea we had for the speed control was to use a PWM control signal along with a mosfet in order to control the duty cycle of the motor. Due to the inductance of the motor we would be able to control the voltage it saw by varying the duty cycle of the PWM signal. After further research it was discovered that we could use this same PWM control method, but instead of using a mosfet we could tie the PWM signal to the enable pin of the H-bridge. In doing this we were able to eliminate the need for the and gate chip, the mosfet, as well as the second H-bridge. Throughout Senior Design I and II there have been many design choices throughout the project that influenced the overall power design. After several specification changes and optimization, the final power supply is very simple compared to the initial design. The final design incorporates a wall plug to step down a wall voltage from 120V AC, 60Hz down to 12V DC, 3A. This wall plug has a male barrel plug connector which was incorporated into the design by using a female barrel plug which can be plugged into a breadboard and protoboard as needed. To regulate the voltage for the other components in the circuit, there are two voltage regulators: a

5 3.3V regulator, and a 5V regulator. The 3.3V regulator is used as an input to the teensy while the 5V regulator is used to power all the logic and integrated circuits on the board. Both regulators use the TO-220 package due to familiarity, what was on hand, and the ability to attach a heat sink to the regulators as needed. For this project, compact heat sinks were acquired to attach to the regulators which each sink being ¾ in by ¾ in to adequately sink the heat if needed. RESULTS AND DISCUSSION 1.1. Electrical Katie, Jorge Power Controls Code 1.2. Mechanical Andrew Design Structure Material Component Selection Motors CONCLUSIONS AND RECOMMENDATIONS 1.3. Electrical Daniel Testing Results Improvements for P Mechanical Andrew Testing Results Improvements for P16051 REFERENCES ACKNOWLEDGEMENTS - Dr. Jeff Pelz - Ms. Dong Wang - Mr. Edward Hanzlik