concept

for this week's assignment i wanted to work with processing: it's a language i've not had much experience with but have been meaning to get into more. i thought it would be cool to work with my capacitive graphite sensor from week 9--the plan was to read the capacitive value from the sensor, send it over serial, and display it graphically by scaling an image.

however, i have had an absurd week, so i didn't have time to implement my idea for this week's project. i got as far as looking through some examples (processing's example pages and arduino's "working with processing" tutorials)and writing some sketch code, but didn't have a change to test it out. i have, however, done some interface programming in the past--nothing taking data from a physical input device, but i took plenty of user input and read data in from files, so it's pretty much the same concept. unfortunately a lot of the details of my project were NDA'd, but i can share the basic concept. you can also find information about it on my website, here.

the general idea was this: field testing is inefficient because there's no good way to quickly process the data collected while in the field without sending it back to a team at headquarters for analysis. another problem is that data analysis tends to be either very slow or fairly coding-intensive; since none of the engineers i was working with were comfortable enough to write or interact with code, i had to design a user-friendly interface (graphical, lots of buttons and menus to set options). it had to be intuitive, customizable, and fast.

roadblocks

this project was challenging for several reasons. one of the main issues was forward-compatibility: many of the metrics that were important for the field testers had unstable naming conventions. for example, the logs they collected in 2012 might name a variable "VAR" but logs from 2013 might have the same variable named "VRBL." these conventions were something they were all familiar with, but were somewhat difficult to implement in code. i solved this problem by allowing users to define a text document that assigned variable names to various keywords (this also allowed them to add and subtract keywords as new variables became important). it might look something like

VariableA: VARA

VariableB: VB

and so on. these parameters could be changed and reloaded without restarting the software; i stored variable definitions as class attributes and included an option for reloading that particular class at any time. i was pretty pleased with this; it worked out quite well for them.

unfortunately most of the nice interface stuff i coded up contains proprietary information and i had to blank a lot of it out, but i've included what images i can (including some images of the output it produces).