Section 5
Results and Evaluation
Just as the implementation of the Snap! system without applying it to a specific sensor networking problem would have failed to demonstrate its usefulness, so the creation of the Skiing With Advanced Technology (SWAT) system would fail to demonstrate the success of Snap! without field testing. SWAT underwent two rounds of testing. The first round occurred in late February, 2000, in Iceland. After analyzing the results of this trip, the knowledge gained went into revising and enhancing SWAT. The second SWAT system was tested in mid-March, 2000. The previous section describes the SWAT systems in detail.
After correcting the bugs, the last two sessions were conducted. The first test session was a short, ten-minute jaunt to verify that SWAT was successfully recording data. The second session was a 2 hour 15 minute trek covering about 5 kilometers. The trail was unbroken, but the instrumented skier did not break trail.
Of the sensors that made up the first implementation of SWAT, only two produced data that were both valid and useful: the accelerometers and the heart rate monitor (figures 16 and 17). The rest of the sensors had either hardware or software errors that were revealed during the field test. The data from the barometric pressure and temperature sensors lacked the most significant byte of a two-byte value, rendering their readings meaningless. The wires connecting the transducers in the boot to their node became damaged before any readings could be recorded from them. The amplifier for the toe angle was not optimally tuned. This led to values that indicated whether the boot was off the ski or on it. The ski orientation node was originally included to provide auxiliary data for a GPS receiver. The data from the ski orientation sensor appears to be valid. Without a GPS receiver, however, and configured to report only a single sample every 30 seconds, the data collected from the node could not lead to any conclusions about the ski dynamics.
The data collected from the accelerometers revealed another deficiency in the system. The input/output modules on the first SWAT system were restricted to the RAM available on the 16F876. This limited the amount of data that the modules could collect and transmit in single sample session. The sampling frequency was insufficient for the rate at which acceleration and the boot angle were changing. Thus, while general characteristics of the ski stride are visible, such as when the skier began or finished a stride, more detailed analysis, such as slippage or distance traveled, is inconceivable.
Finally, a significant limitation of the first version of SWAT was that only one ski was monitored. This meant that very basic information about the skier's stride was not certain, such as if he was following the classic diagonal style, double poling, or skating. The skier's balance and distribution of effort could not be assessed. Overall, the data collected from the single-ski SWAT system was inadequate to provide anything more than a superficial description of the action of the skier and his equipment.
|
| FIGURE 15: Accelerometer directions The accelerometers recorded three orthogonal axes as labeled here. |
 |
| FIGURE 16: Iceland SWAT system acceleration The Iceland SWAT system successfully recorded these acceleration data during one sample session, illustrating one stride. The low sampling rate and short sample session time make produce a low resolution graph. |
 |
| FIGURE 17: Iceland SWAT system heart rate The heart rate graph shows that Professor Hawley alternated between rest and the target aerobic heart rate zone for his age. |
The data collected from the accelerometers are not completely without merit. Figure 16 shows one sample group taken from the final test session. The large increase in lengthwise acceleration indicates that the skier began his stride with a rapid forward push. The deceleration as the ski came to rest was not as significant. The change is acceleration in the vertical direction is very slight. This indicates that the skier was most likely not planting the ski sufficiently or that snow conditions were such that a hard plant was unnecessary. A graph of heel pressure would have helped draw the conclusion that the latter conclusion was probably correct: the freshly fallen snow and near-melting temperatures made the snow rather sticky for the depicted sample session.
The heart rate graph in figure 17 gives an indication of when the group took breaks from skiing to either observe and document the surroundings or verify the correct operation of the equipment. The high end of the heart rate is around 135 beats per minute, or 75% of the skier's maximum heart rate1. This rate, within the aerobic conditioning zone for Professor Hawley, indicates that the pace was appropriate for a short workout but not for three hours of sustained tour skiing. This may explain the frequency and duration of the rest stops.
Mounting sensors in proximity to snow presents several challenges, such as providing a waterproof case that also allows wires to pass through and keeping the electronics within their operating temperature range. The first SWAT system successfully met these challenges. The box containing the electronics was so bulky, however, that it was uncomfortable for the skier and occupied more space than necessary. Additionally, the wires forming the sensor network proved to be cumbersome to connect and disconnect. They were uncomfortable for the skier and required extra care to prevent breakage. This discomfort and vulnerability to failure provided motivation for developing a wireless network for the revision of SWAT.
On the entirely I2C system, problems with the cable between the boot flex and heel pressure transducer on one boot prevented collecting any valid information from that node. Additionally, the wire connecting one of the toe angle transducers to its input/output module severed.
The wireless system had a different set of problems. Analysis of the log files indicates that each of the local networks communicated successfully. Also, the networks on the skis and boots communicated among each other, as the packet used to synchronize the sampling sensors on the skis and boots was successfully received by the nodes. However, the distance to the backpack transceiver as well as skier's body being placed in the communication path prevented the data being received by the wireless node in the backpack. Since the logger was in the backpack, the data from the skis was not logged.
Finally, the second version of SWAT featured nodes were enhanced with an addition EEPROM chip. For nodes that sampled their transducers, this allowed a higher sampling rate and a greater number of recorded samples. The larger number of data, in turn, allowed finer analysis of the information returned from these sensors. On the other hand, analysis of the data reveals that the sensors were still under-sampled. The sensors sampled at 20 Hz. Figure 22 shows the data collected from the length and height accelerometers. The waveforms appear choppy; the data from the height axis seems to show a frequency of about 10 Hz. The Nyquist criterion requires a sampling frequency of twice the signal being sampled for accurate reconstruction. The 20 Hz frequency just meets the criterion. To observe the more subtle details of the data, a sampling rate of 50 Hz should have been used. Whether the input/output and network modules would be capable of handling this rate is unknown.
A cursory analysis of the results from the two systems suggests that the SWAT system using the wired network, which managed to log the majority of its data, is the correct choice for future systems. In reality, improvements in the wireless network design are likely to render the wired system unnecessary. The wired system is vulnerable to a variety of physical assaults: water, snow, dirt, and dust clog connectors; a sudden fall may sever or dislodge the wires; the cables generally interfere with a complete range of movement. Thus, even the limited success of the wireless system well indicates that the wired system may eventually be discarded.
 |
| FIGURE 18: SWAT browser The application shown here allowed browsing of the data collected during the Norway field test. The background shows the path taken by the skier, as recorded by the GPS receiver. Choosing a point activates the foreground display, which shows graphs of the accelerometer, toe angle, boot flex, and heel pressure, as well as the single value time, heart rate, ski direction, barometric pressure, and temperature. |
This discussion concerns the data from the point shown in figure 18. The same analysis can be applied to any of the points for which data was collected.
 |
| FIGURE 19: Ski measurements The ski and boot sensors measured toe angle, boot flex, and heel pressure as depicted here. |
 |
| FIGURE 20: Skier stride as shown by toe angle The alternating left and right toe angles indicate the rate of the skier's stride. |
Figure 20 shows the toe angle over a 3.75 second sampling session. As can be expected, the toe angles alternate between the times they each reach their maximum values. The maximum value of toe angle occurs when the striding leg is completely extended and the skier shifts his weight to the other ski. This weight shift allows the extended ski to lift up and the skier brings it forward. The stride rate can be determined by measuring the time between the two successive peaks from the ski. This particular sample shows that the strides are evenly spaced. However, the skier does not reach the same maximum value in each of the strides indicating that he may lack consistency in stride length.
 |
| FIGURE 21: Stride analysis with toe angle and boot flex The graphs shows the time relation between maximum boot flex and toe angle. Perhaps a quicker return to a straight foot would result in a faster forward stride. |
Figure 21 shows the relation between toe angle and boot flex from a single foot. As the skier extends his rear leg, the boot and foot begin to bend before there is an angle at the toe. This demonstrates the heel being lifted from the ski earlier as well. The boot flex also lags behind the toe angle somewhat after the front of the foot is flattened again. Further study of this graph, in combination with a video analysis, could help the skier optimize the length of his stride. Also, combining this graph with heel pressure could reveal if the skier is transferring his weight in the most effective way.
 |
| FIGURE 22: Ski motion through acceleration The acceleration data can be integrated to determine efficiency. The dashed lines demarcate the vertical resonation present as the skier lifts the ski to move it forward. |
Figure 22 depicts the accelerometer data taken from the left ski during a single sample session. The large values correspond to the lengthwise movement of the ski. These correspond timewise to slightly after the maximum toe angle; after the leg is fully extended, it is brought swiftly forward during the stride. Velocity and position measurements can be computed by integrating the lengthwise curve. Both would be helpful in determining the amount of backwards slip the ski undergoes, an indication of a flaw either in waxing technique, choice of wax, or in the weight distribution of the skier.
The other two values are not perfectly constant. Acceleration along the width of the ski indicates that there is wobble or force being exerted other than in the intended direction of motion. Excessive movement in this direction, not indicated here, would indicate that the skier was wasting energy with an inefficient stride.
The final vector to consider is height. The acceleration due to gravity causes the constant offset that is seen in this direction. These data are especially interesting for two reasons. Most importantly to the technique of the skier, it indicates the force and timing of the lifting of the ski as it is brought forward. At the end of the forward movement, it also demonstrates the planting of the ski. Any upward force exerted while the ski is on the ground could lead to slippage in the lengthwise direction.
The series is also useful to the ski designer. As the ski is picked up, it begins to resonate. This is demonstrated by the fixed frequency of the waveform present in the height graph while there is any acceleration in the lengthwise direction. When the lengthwise acceleration is constant, so is the vertical acceleration. The ski designer can use the information about vibration to choose appropriate materials or evaluate different designs.
The collected data and the analysis presented illustrate the success of the SWAT system in accomplishing the purpose for which it was designed. It is possible to analyze stride components using time-synchronized videotape. However, the quantitative results obtained by the Snap!-enabled SWAT system previously required a customized measurement system. The ski vibration data and the possibility of precise slippage calculation demonstrate some of the value that the SWAT system presents to skiers and ski manufacturers.
In reality, the use of ASCII seemed to cause more harm than good. Good engineering practice dictates debugging components separately, then combining them and debugging the system. Thus, a designer should be able to debug the network, ensuring that the network modules are communicating successfully. Then, he can plug the input/output modules into the network modules and test the system again. The choice of ASCII attempted to create a short cut. Instead, the code on the input/output modules became unreasonably complicated. For instance, the data from the orientation sensor for the Iceland SWAT system was encoded in ASCII. In order to store sufficient samples on the input/output module for transmission, as well as perform calculations on the values, the data was converted to integer values and stored. Then, to comply with the Snap! specification, the stored values were converted to ASCII again before transmitting them. A large percentage of code space was used for the conversion functions.
As has already been mentioned, the value of the report field can be used to carry binary data. Another alternative could be to expand the packet definition to include typing of the data in the report payload fields. This would allow the input/output module to report data in the format that is most natural for it, while still allowing other modules to interpret the data.
Nevertheless, it must be reemphasized here that Snap! for prototyping different sensor networks quickly. Thus, a user can place the nodes into several different configurations to determine which is the best for a particular application. If the designer then needs a more permanent specialized solution, he can design a custom solution to the problem. Further application of Snap! will reveal if its flexibility is an asset or a liability.
One of the most significant changes to the Snap! implementation is the inclusion of the Find opcode. The Find opcode is included in the description of the Snap! architecture in section 3. Allowing nodes to query the network to discover nodes of certain types or properties potentiates the building of more intelligent systems. Systems with self-discovery can be capable of dynamically reconfiguring themselves or altering their behavior based on their composition.
The addition of the Find opcode and the refinement of its definition reside in a broad area of research. Both Sun Microsystems's Jini [citation][www site] and the MIT Media Lab's Hive [citation][www site] include methods for discovering the behavior of nodes on a network. Work in this area would not only affect Snap! but would likely impact networks generally.
A long-distance communication, or gateway, node would allow a Snap! network to communicate with other types of networks. One example is a cellular modem that sends the packets to a host on the Internet. Once received, the host could publish them on the World Wide Web for real-time viewing. The gateway should be bi-directional, allowing viewers to communicate to the Snap! network. Thus, a Snap! weather station in a remote location could indicate that its batteries were running low. Remote users could then decide whether to activate a secondary power source remotely or actually visit the station to assess conditions. Coaches monitoring athletic performance could send feedback on how the athlete could best modify his tactics given current physiological conditions.
A Configurator node could be based upon a Personal Digital Assistant (PDA). The Configurator would attach to the Snap! network whenever its designer wished to view its current state. The Configurator would have the ability to access the variables of each node and display them. The Configurator could also download new behaviors in whatever language is appropriate for the Snap! implementation. Attachment could occur when first applying power to verify that all nodes are working correctly or during operation to determine the current readings reported by the sensors. The Configurator could also be left attached for a greater duration, serving as a general-purpose display to a network user or wearer.
Additionally, other input/output modules may require more computation power, such as one that interfaces to a digital still or video camera. Furthermore, a designer who wishes to explore the ability to use mobile code or emergent behaviors of the network modules may wish to use a behavior language that is more complicated than one capable of being implemented on a PIC.
Snap! is designed to be flexible yet powerful enough to be implemented on a variety of hardware systems. Implementing a second, more computationally powerful version of Snap! would provide a further test of the design, while also enhancing the collection of nodes available to network creators.
Section 4 - A First Implementation
Send comments to the author