Our initial proposal was to use the accelerometers to measure position. Based on how fine the position measurements were, we were going to create a keyboard system. Unfortunately, that failed pretty horribly. We encountered many, many problems with integrating the acceleration. We spent almost two weeks trying to get position to work, and it just did not.

Initially, the ADC was being run too fast and the small amount of error inherent in every ADC reading added up to a colossal problem when the integration formulas were used. Even after the ADC read rate was slowed down, we encountered a lot of problems. The problems cropped up early in our integration formulas. The velocity calculations themselves failed. We were able to get velocity to saturate to a steady state value after we move the accelerometers and then stop moving them, but, unfortunately, the velocity did not saturate to 0. Basically, the MCU had a problem with the integration algorithm, and some of the deceleration values were “missed“ and velocity was never reset to 0.

All of our initial theories - drag coefficients, “zero-ing“ functions for velocity, etc. did not work: we were still unable to read reliable velocity, much less position, from the accelerometers. The drift in velocity explains why the accelerometers never return to the same location on the X-axis after it is moved down and moved back up. It also explains the non-repeatability of the position calculations.

Another problem that concerned us was that the accelerometer might be saturating. The low G accelerometer read 3.5V under 1G (which meant limits of about -2 to +2 G). The human finger can, theoretically move faster than that, especially if someone is a fast typer. So we tried to use a 40G accelerometer, which as you would expect, is like trying to swat a fly with a sledge hammer. A lot of acuity is lost in the signal as only the last 3 or 4 bits are ever really changing when the finger moves, and thus we seem to loose even more accuracy this way than with the low G accelerometer.

We tried many different integration formulas, from a simple Euler's approximation to a complex Verlet algorithm, but nothing seemed to work. The integrations were not settling. We had some problems early on where the integrations got so large that there was significant wrap around in the variables, but fixing this did not fix the problem deep down with the integrations: velocity did not return to 0. Any drag coefficients etc. made the position incorrect enough that it could not be used reliably.

Another option was using the differences in G force felt by a 2 axis accelerometer to determine the angle made by the fingers. The fraction of G forces felt by the 2 axes of the accelerometer can be used in conjunction with an arctan formula to calculate the angle. This could be done if one end of the finger is fixed (as it is to the knuckle). If this is the case, we could, with reasonable accuracy, calculate where the finger was in a 2D plane (the 3rd dimension would've required a LOT more mathematical power).

Unfortunately, we abandoned this approach very early on Ð the knuckles, although a stationary point for the finger, moves itself when someone types. Because of this, the position calculations would have been useless.

In conclusion, position from accelerometers is just really, really hard. We would not say it is impossible. Given enough time and resources, we are confident we can solve the problem, but that would require a lot of time and resources that we just did not have for our project. Even Samsung failed in making a keyboard based on accelerometers. They have been trying for nearly 4 years, but have not made anything that can be commercialized yet. So we don't feel too bad that we couldn't get it to work in a month.

Another area where we felt we could improve was in adding wireless capability to our mouse. In today's world, wireless devices are gaining greater popularity, and a wireless device of our kind would be ideal for giving presentations to large audiences. A wireless accelerometer mouse would allow the presenter to roam about freely while maintaining a high degree of interactivy with the PC.

However, in implementing an RF system, we ran into several road-blocks and subtlties. First, RF would have taken a great deal of time to finish. Not only would we have had to build the RF circuitry and software, but we would also have to make great adjustments to assure that bytes were sent in a timely manner to satisfy the PS/2 protocol. Also, we would have had to add another board that required its own power supply such as a battery, complicating matters and increasing price. Also, RF wireless cannot be used in certain areas or scenarios, such as on an airplane.

Ideally, building bluetooth into our system would provide the best wireless solution. Bluetooth operates at a very fast bit rate relieving timing issues and also operates in a safer EM band, allowing for greater usability. Unfortunately, it was too expensive for our project and would have required a gerat deal of time to implement properly.

In developing this device, we relied heavily on the open PS/2 protocol originally developed by IBM. We strictly followed the guildelines for this protocol in terms of electrical interface, clock generation (frequency, etc.), and packet generation. Many of the details can be found in the program design section of this report and in the references listed below.

In implementing our mouse, we used the queue structure created by Luke Hejnar and Sean Leventhal. Along with the structure, they created put and get methods to place and remove items from the queue. Also, since the TAs did not have experience with the PS/2 protocol, we relied heavily on the following websites for understanding the PS/2 protocol and accelerometers:

• Wireless Keyboard
• Adam Chapweske's PS/2 page
• 3D gForce Mouse
• N64 to PS/2 Mouse Translator

In particular, having a look at past groups' code greatly helped in the organization of the code, particularly in the processing of the PS/2 commands. However, the implementation and functionality of all code was orginal aside from the queue implementation.

The IEEE code of ethics is a good guide for any engineer to follow. It outlines in 10 short points the basic code of ethics that any engineering product should follow. During this project, we felt that we were able to closely follow five of the ten codes of ethics outlined by the IEEE society. We go into more detail about each of these points below. Certain ÒcodesÓ were not applicable such as point 4: to reject bribery in all its forms - there were no real briberies floating around in the academic environment of the lab.

1. to accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment.

We do accept reposibility of anyone using our products. That is why anything even close to the user's hands are wrapped tightly in electrical tape to insure nothings happens to the user. We also removed the rubber bands that were used to hold down the accelerometers to the fingers since they did cause quite a bit of discomfort to the user.

3. to be honest and realistic in stating claims or estimates based on available data

We have tried to be as realistic as possible considering the work we have done. Initially we wanted to design a position-based system using accelerometers, but when we realized that it would fail, we were honest with the professor and the TAs and went back to our “Plan B“ project of a tilt mouse. Furthermore, we are realistic about certain limitations of our mouse, as they have been clearly stated throughout this report. For example: we have pointed out that the scrolling ability of our mouse is great, but entering and exiting the scrolling state is a little bit difficult.

5. to improve the understanding of technology, its appropriate application, and potential consequences

The initial goal of this project was to improve on both the current keyboard and mouse interface. We felt that the potential consequences of long term usage of the keyboards and mouse we have now had too high a price to pay - pretty much everyone who use keyboards and mice for many years will develop some sort of tendonitis or Carpal Tunnel Syndrome. By designing this project, putting up our report on the ECE476 website, we hope to show people, at least the people in our class, the possible health risks of using the current keyboards and mice and what options are available to use non-traditional products to avoid these health problems - such as bosswave's ring mouse or maybe even a product similar to ours if it is ever made.

7. to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others

The whole idea of a graded project, with weekly progress reports being emailed to the TA's envelops our project in this code of ethics point. While we work in the lab, we constantly confer with TAs and other students to get feedback on how we can improve our project and, very often, we ask for help when we get stuck on certain portions of the project.

9. to avoid injuring others, their property, reputation, or employment by false or malicious action

Although there have been some proposals to have a special “secret“ button that you can push and the user would get a small jolt of electricity, we refused to implement such an “easter egg“ in our project. We do not believe our product will injure its users, they may feel an amount of discomfort in the beginning as they get used to the new interaction method, but once they get used to it (as we did while we tested our product), it feels a lot easier to use than traditional mice. Furthermore, our project is not destructive - it is not a projectile launcher, or a tazer, etc. It is a passive device - it does not even need a power source (it draws power from the computer itself as normal computer peripherals do).