Week Twelve: Interface and Application Programming
dance dance R-evolution
Task
Write an application that interfaces with an input &/or output device.
Result
This week I continued to build on my ballroom dance partner peace mediating system from week 9 and week 11. Previously, pressure sensor information was conveyed through LEDs. This week, I tried new ways to visualize and analyze the pressure sensor data using Tkinker and rPy2.
I created two copies of the system in order to display the real life application. A third involving some data analysis is in the works. Here they are in action:
I also got interested in the data and took a look at patterns created by various dances. Here is the "gold standard" data for each dance (collected using this sensor):
Am. Rumba
Salsa
Swing
Int. Rumba
ChachaHere are a few other instances of these dances--see if you can match them visually to the standards!
Files
Here are the code files:
Approach
First I created the pictorial representation of the pressure sensor data by combining and building from the python files from past weeks. My pressure sensor C code was already set up to send data through FTDI. The hello.light.45 python code from past weeks had the basic framework to receive the data and visualize it with Tkinker. I changed the code to better reflect my application, using two ovals to represent feet and creating space for the text and sensor readings on the left hand side. This worked well, though I still haven't gotten a chance to sorted out the variable types in C, so my processed-in-C value doesn't match my processed-in-python value.
With this simple version working, I decided to give the rPy2 package a try. Yay R! Before dealing with receiving data, I worked through some of the basic rPy2 functionality: creating and indexing dataframes, plotting data using lattice and ggplot2, and writing out files. The rPy2 manual had a lot of helpful examples. I then integrated the FTDI code to continuously write to a database as data is received and update a (ggplot2) graph visible to the user. This worked reasonably well, though there must be a better way to create the graph in real time--right now the entire plot redraws which gives it a very flickery feel. But at first glance rPy2 seemed to be set up to only plot an entire plot object, not an addition to an existing plot. I'll have to dig into this more.
All this data tempted me into a statistical black hole. I got interested in pressure sensor data from different ballroom dances. Ideally as you danced the system would plot the dance, determine what dance you were doing, and highlight any deviation from the "ideal" technique. I started with a simplified framework: I aimed to identify the basic steps from five dances done by the same person using one pressure sensor (left foot) with limited variation in speed. I collected the data on two seperate occasions and moved the pressure sensor a bit in the set-up/take-down processes. I collected three data files for each dance--only with n~=2000 and two with n~=1000--using python/rPy2 to write out csvs to work with directly through R. rPy2 is nice, but it was much more efficient to code in R as I figured out my plan of attack.
I hadn't done much time series analysis before, so I played around with a few approaches. Briefly, I looked at: summary stats, linear regression, probit models, time series plots, period estimates, and auto-correlation functions. Each technique was somewhat successful, though not entirely determinant on its own. I think intellegent cominations of these should do a reasonably job though--certainly one sees patterns in the plots, so it's plausible to find the best way to numerically summarize them. I'm sure this sort of thing has been done before so I'll have to take a look in the literature for more informed approaches. Improving the pressure sensors will also help clean up the data.
Trials and Tribulations
The pressure sensor seems to act somewhat differently based on positioning and mode of use. It's aslo a bit slow to turn off--the connection drags even after weight is released from the foot. I'll have to dive into these issues more in future weeks to see what exactly is happening and establish robustness across individuals. I suspect tweaking the sensor design might be the best course of action here.
I want more data! It'd be helpful to get a feel for how much variability there is between people, between time points, between sensors, and between speeds (as a starting point). This is on the list for future weeks.
rPy2 is nice, but I'll probably leave a lot of the data procesing code in an R script to run and return objects to rPy2/python.
I was pleased with my detachable headers and safety pin method from last week. Worse case scenario the clip pops off instead of tearing traces--but it will be nice to go wireless and unchain from the computer!
Many of the coding things from week 9 remain--particularly pulling the difference between the two pressure sensor readings in the ADC process and getting the variable types correct so math in C works as expected. It wasn't the most pressing thing for this weeek so I ventured down the statistical blackhole instead.