• Home
• Team
• Meeting Minutes
• Notes and Data
• Proposal

• Deliverables
• Source Code
• Internal Documents

Notes and Data

• Notebook, Page 1 - Very early in the semester, we wanted to discuss our project goals with Dr. Picone, especially since we had a major design choice to make. Ultimately we went against his advice and changed the design because we believed we could overcome the technical challenges and make significant gains in cost and power consumption with a modified design. This proved to be more difficult than we had imagined, but in the end we realized the benefits we had intended and created a working design. Given the chance to go back to this point in January, we may have followed Dr. Picone's advice, but the challenge was just too exciting at the time.



• Notebook, Page 2 - This meeting with Joe Fanguy was when we pretty much decided a design modification would be the best route. At this stage, we were already discussing LED-switching and hardware minimization. We also began talking about a switch to infrared. Later this same day, we began considering a way to power the entire system directly from the PC serial port and eliminate the need for batteries or other external power sources entirely.



• Notebook, Page 3 - These diagrams are from the previous meeting. The top-most drawing shows a proposed circuit that would allow us to power the glove and all its systems directly from the PC serial port. This idea is never touched again, however, once we discover that the PC serial port is limited to 10mA of current, a full ten-fold reduction from the original prototype. We decided that was an unreasonable objective and went back to battery power. The second diagram shows the LED-to-photodetector coupling scheme, which eventually found its way into the final product. The only difference between this sketch and the current model is that there are three LEDs and four photodetectors (the five-fibers-to-one-LED coupling was impossible). This hardware reduction saved us a significant amount of power dissipation. The final section of this page shows how the LED switching could be realized in firmware. This is not how the final firmware implemented LED switching.



• Notebook, Page 4 - This page shows some calculations of instruction execution time, analog-to-digital conversion time, and RS-232 data transfer time. The objective was to determine if the switching times for the LEDs and photodetectors (found in the datasheets, below) would cause a problem with our sample rate. It was quickly determined that the very fast switching times would not interfere at all, and the necessary "settling" delays were already built into the firmware.



• Notebook, Page 5 - These notes were taken during a brief meeting in the lab, with further discussion of hardware reduction and component switching. Additionally, we began serious work on designing a PCB, which began with a consideration of surface-mount components. The decision on whether or not to go to surface-mount components was not made for nearly a month.



• Notebook, Page 6 - At this point, we began to get serious about switching to infrared. Mr. Fanguy pointed out that infrared components would be less susceptible to ambient light interference, and also that infrared was a more mature technology which would probably mean reduced costs. We also began looking at whether or not our coupling plan (from page 3) would work, and concluded that it would not. However, up to four fibers could be coupled to a single LED, so we decided to use 3 LEDs and 4 photodetectors. At this time, we had not settled on an LED or photodetector, so we were not sure how coupling would work.



• Notebook, Page 7 - We continued our experiments with coupling multiple fibers to a single component, looking for a method that was secure and usable. Also, we began checking the sensitivity to infrared of several photodetectors we already had available by building a sample sensor network. By swapping out LEDs and photodetectors in our sample network, we were able to determine which pairs of components produced the best results. However, we did not use any of these components in our final design. We also began discussing alternative coupling options. At this time, Mr. Fanguy found LED and photodetectors designed specifically to be coupled to optical fiber. The next time we met with Mr. Fanguy at DIAL, we tested the new LEDs and photodetectors. The results for the "blue dot" LED are shown here, where the straight-fiber and bent-fiber voltages for each photodetector ("white dot" phototransistor, "red dot" photodarlington, and "orange dot" photodiode) are shown. We were very surprised by the poor performance of the photodarlington, but we hypothesized that the photodarlington is so sensitive, the amount of light reaching it when the fiber is bent is still enough to nearly saturate it. Also shown here is a schematic of the circuit setup, so we could reproduce it on the final model.



• Test Data - This page shows the results of the tests described on page 7 (the early "sample sensor network"). We did not know anything about the detector at the time of the tests except that it was 43 cents. The far-right column shows the joints being tested, 2 and 3, or the first index-finger joint and the second index-finger joint. This test was conducted after the optimal component pair was found, and was used to show that we could loop the fiber and thus put both the LED and photodetector on the same side of the hand. The specifics on the components are listed at the bottom of the page, after we found out what they were.



• Notebook, Page 8 - The remaining LED/photodetector test data is shown here. These results are for the "silver dot" LED. Note that the color of the dot refers to the color of a small dot located on the side of the component. These results show the greatest voltage change with the "blue dot" LED and the "orange dot" photodiode. This component combination is still used in the final design. Also at this meeting, we discussed using a spectrometer to gather more test data. However, the DIAL optics lab did not have an infrared spectrometer at the time, but one was on the way. Ultimately, it was decided that we did not need spectrometer data.



• Notebook, Page 9 - This page just shows the circuit diagram for the MAX232 chip and the oscillator, along with a small diagram explaining the necessity of a diode in our final PCB. The MAX232 and oscillator diagrams were drawn directly from the original prototype to make sure that we would have no trouble with them on the PCB. As for the diode, it is necessary for In-Circuit Serial Programming (ICSP), a feature in PICs that allows them to be programmed after they have been placed in the circuit. The diode is needed because the RESET pin is driven to +13 volts during programming, but is normally tied to VDD, which is 5 volts. The diode prevents this +13 volts from getting to the rest of the PIC and the rest of the circuit.



• Notebook, Page 10 - We designed a PCB around surface-mount components, but because we were still unsure about ICSP, we decided not to send off the design just yet. We met briefly with Dr. Reese to talk about ICSP. Within a few days, we concluded that we could not guarantee that ICSP would work with our PCB design and were not sure that we could access an ICSP programmer anyway, so we decided to go back to a DIP package for the PIC. On closer inspection, we realized that the DIP package would not increase the size of the PCB at all. Also on this page is a small diagram displaying current draw in a sensor network. For some reason, the values were never filled in.



• First Calibration Data Set and Test - This spreadsheet begins with the raw data captured by the DataGlove API. One thing we quickly noticed was a large amount of "noise," which could easily account for the wild fluctuations we were seeing in the visualization application. The second graph in this spreadsheet shows the direct linear interpolation method used in the first prototype. This data is extremely "dirty" and bears out our concerns that noisy raw data could cause serious problems with the final calibrated data. The third graph shows an amplified and filtered version of the raw data. The amplification is really unnecessary, but at the time it acted as proof that even the dirty data could be converted into something usable. The next graph is direct linear interpolation from the filtered data, and the final graph shows the linear interpolation with a small amount of averaging added in to help smooth the graph. In this early test, the averaging was simplistic and resulted in negligible change. (The raw data in this spreadsheet is the only data captured directly from the glove. All other data was calculated by a PHP script as we attempted to understand how our calibration algorithm should work. Ultimately, the algorithm was designed and first implemented in PHP. It was then ported to C++ for use in the API.)



• Second Calibration Data Set and Test - The first graph here is a new set of raw data, captured over a longer period of time. It is difficult to tell from this graph, but at two times, the joint used for testing was bent half-way. This fact will become important. The second graph is the amplified and filtered version of the raw data. The third graph is linear interpolation using averaging, but this time it also includes what we termed "sine compression." This little piece of the overall algorithm pushed values that were close-to-center even closer to the center. It was meant to combat the apparent drift of these values to the extremes, and seemed to produce better results that somewhat more clearly showed the half-bend. Eventually it was realized that the "sine compression" was combatting an error caused by a typo and was therefore removed after the typo was fixed. (Unfortunately, the spreadsheet showing the results without the typo and "sine compression" has gone missing.)



• Third Calibration Data Set and Test -
All of the data in this test set was captured directly from the DataGlove API. The filtering function, used to obtain the data in the second graph, is not as clean as we had previously observed in the PHP implementation of the algorithm, and we cannot explain this. It is possible that the key to this difference is in how the algorithm was implemented in each case - in the API, the calibration had to occur in real-time and could only use past values for averaging, but the PHP implementation could "see the future" and used future values in its averaging functions. Whatever the cause of the difference, the averaging and smoothing functions used in the API implementation were modifiedto produce a very smooth calibrated graph. The major problem with this calibrated data, however, is that it changes too slowly. The averaging produces a sort of lagging effect which causes the data to slowly change from "fully bent" to "fully straight" rather than doing it quickly. The averaging methods have been further modified in the final version of the API - some smoothness has been traded for faster response. The fourth graph here shows the max and min values over the full capture time. This was the first time we used a max/min averaging function and it produced outstanding results. We realized that the spikes in the filtered data were causing the max value to be set too high, which prevented "fully straight" from ever reaching anything close to 64. We had not seen this problem previously because the PHP implementations had filtered out more of the spikes than the C++ version. However, we concluded that if we employed averaging, we could dramatically reduce the effect of those unfiltered spikes and thus keep our max value in a reasonable range. It worked very well, as can be seen in the calibrated data graph (third in this file) where the data ranges in value from 0 to 64 over the entire data capture period. The final graph is simply an overlay of the raw data and the filtered data, which shows how much cleaner the filtered data really is.

At this point, we felt we understood how to manipulate the algorithm well enough to begin using it in the final API. All further testing was conducted using the visualization application, which can be interpretted in real-time very easily, but data capture becomes much more difficult, so no further data has been captured.


• Datasheet, "Blue Dot" LED



• Datasheet, "Orange Dot" Photodiode



• Datasheet, "White Dot" Phototransistor