Project Synopsis for Tracking Visor

Teammates: Nick Sorenson, Adam Thompson

Project Purpose: One of the key functions of technology is to perform tasks that are either unpleasant or unsafe; thus both time and human lives are spared. For this reason, congress has passed an initiative that by 2015 one third of armed forces vehicle should be entirely autonomous. As a result, the air force has implemented predator drones, and continues to research other autonomous vehicles and virtual reality technology. Miners and marine biologists also attach cameras to robots to explore distant or dangerous areas. Similarly, biomedical technology firms are implementing robotic arms and cameras to allow surgeons to operate on patients who are thousands of miles away. Precise control of remote vehicles is essential, particularly in the case of a remote surgeon. Because the mental demands of surgery are already extreme, interaction with the remote device should be entirely intuitive. The device should also provide doctors with a level of emersion that will allow them to feel as if they are directly operating on the patient. For our senior project, therefore, we will create a visor that will track the users head movement. When this visor is combined with a small head mounted display (here after referred to as a HMD), the user will be able to move his/her head to change the position of a remote camera or cursor.

Project Overview: Our solution will track the motion of the users head with accelerometer sensors. The output of the accelerometers will then be interfaced with a simple microcontroller. The microcontroller will perform the calculations necessary for determining the position of the device; such as, how far the user moved their head and in what direction. Since the range of motion of any user is likely unique, the visor will include a “re-center” button to set the various limits (left, right, center, etc.). Also, every users head has less than a 360 degree turning radius. Thus, it is impossible for the user to turn the camera completely around. If this turn radius is not extended then a probe would be able to move forward, but never be able to return to the launch site. Thus, our solution will include a “free look” button to allow the user to set horizontal limits that will allow panning. This will allow the user to set a range where the camera or cursor tracks the head movement directly. Once the extreme edges of the range are met, then panning occurs. The microcontroller will record the specific user’s limitations and use them in its calculations. The processed information will then be transmitted out of the microcontroller. Then the device can be interfaced with the desired application; either to a console, or to a remote probe. The computer connection will be through either a USB cable or through the game port. Initially, the microcontroller output will mimic a known device, such as the Microsoft Sidewinder. Once this base line is met, we will begin writing our own device driver to directly interface with the computer. The device driver will then be able to take the visor’s output and put it to use in the software program. Should this device driver prove simple, we may entirely remove the microcontroller, and thus allow the more powerful computer to perform the necessary calculations. As an alternative to computer interfacing, we also considered mounting a camera on a tripod. The motion of the tripod would be controlled by the tracking HMD via three servos. While we will likely still create the tripod as a hardware test for the accelerometer, attaching the camera and tripod to a RC car seems unnecessarily expensive.

Risks The risks that we have been able to identify for our project so far are as follows: power, mounting the accelerometers to the visor, other accelerometer issues (such as their sensitivity and how are used in circuits), price, vendors, and writing the computer drivers for our system. Several components in our system are likely to require external power. These are the microcontroller, the accelerometers, and the visor’s screen. There are at least three ways that we can power our system. We can use a standard AC outlet, a battery, or we might be able to use power from the USB port on the computer. Each of the components, unfortunately, has slightly different power requirements. Ideally, the whole system should share one power source. Regulating proper power dispersal, therefore, could become quite frustrating. Another frustration could come from finding a way to safely attach the accelerometers to the HMD. The HMD that we will purchase will be a “complete” product. Thus unlike a computer case, there will not be convenient slots for expansion of function. We will, therefore, purchase some sort of mounting brace with the accelerometers. The accelerometers are also sensitive, and consequently, somewhat fragile. We must design some additional protective casing for the completed system. Unfortunately, neither of us has worked with accelerometers before, so we will have to figure out how they work. We will need to learn their basic interfacing, and how to use them in a circuit. We are also uncertain of how sensitive they are. Thus we are uncertain if the ones we have selected are sensitive enough for use in our application. With so many unknown about our parts, such as the sensitivity of accelerometers, the cost of the project could well exceed our expectations. Already we must purchase a simple head mounted display at a cost of $150. Thus, if we burn out our microcontroller several times, the project could easily exceed $200-$250. While this is relatively cheap compared to the cost of a semester’s tuition, it is still a significant amount of money. Similar to the subject of price, there is also an inherent risk in the selection of parts due to the vendors. A vendor could “sell” us on a part that doesn’t really meet our goals. This is particularly possible since the head mounted display will likely be purchased though EBay. While there is some recourse should the vendor prove false, the time loss in acquiring parts could be prohibitively high. Interfacing our project with a computer will require some sort of device driver. With neither of us having experience writing drivers, we are unsure of how this is done. Thus we will need to carefully budget both how much time we spend writing the driver, and how much time we spend leaning how to write the diver. This is another area of our project that will require further research.

Interfacing Issues Our project contains several components that must be interfaced with one another. These are as follows, the accelerometers, the microcontroller, the RC car, and a computer. One of the first issues will be interfacing the accelerometers with the microcontroller. The accelerometer’s output will likely be run through an analog to digital converter then enter the microcontroller. We will need to determine the standards that the accelerometers follow (i.e. when it’s experiencing a given acceleration, what is its output). The next interfacing task will be to interface the microcontroller with the remote controlled car. This step could be thought of as a hardware test of the accelerometers. Thus, the microcontroller could be bypassed with the analog output of the accelerometers being directly fed to control potentiometers in the servos. This direct link is likely unworkable, so digital to analog converters may once again be needed. Finally, we will need to interface to the computer via either the accelerometers directly, or through the microcontroller. Should we choose to directly interface the output of the accelerometers to the computer, we must write a comprehensive device driver compatible with at least one type of computer. Otherwise, we must create output from the microcontroller that will mimic the functionality of an existing product, like the Microsoft Sidewinder joystick. We would like to use a USB connection if possible, but we may use a serial game port, as this seems a more logical choice. Tasking and Scheduling: The following table lists our preliminary schedule and “task leader”. Thus, the blue segments will be accomplished by both of us, but with primary responsibility falling on Adam. Nick, conversely, will be the leader of the segments that are red. Since we are such a small team, there is a good chance that the whole team will have equal input on each section of the project. Also, the schedule was prepared to accommodate the summer months as waiting time for vendor parts. Thus, before the summer, we will both choose and order all the necessary parts. Ideally, therefore, the hardware would be completed by the end of summer, leaving the remaining semester to interface, debug, and write code.

June July August September October November December

Physical Placement of Microcontroller

Programming Microcontroller

Programming Device Driver

Physical Placement of Accelerometers

Function of Accelerometers Legend Adam

DAC and ADC Nick

Servos and Tripod Bill of Materials

The following section will

Part Type Number and description Vendor and contact Accelerometer Microcontroller Servo HMD DAC Buttons/switches R’s C’s and L’s etc. Power supply

We are going to use the M68HC11 Microcontroller in our project. Several factors led us to selecting this microcontroller. First, we already own one from taking the ECE 3720 class. This means we don’t have to spend time or money purchasing one and waiting for it to arrive. Also, since we have both used this microcontroller before, we won’t have to spend much time learning how to program and use it. And finally, we chose this microcontroller because it appears that it will be able to meet the interfacing and computational demands of our project.