- Tue 03 September 2013
- notebook
- Jason K. Moore
- #notebook, #d-flow, #data processing, #opensim, #walking model
Today's task list:
- [x] Work on parsing the walking data
- [] Read Sandy's report
- [] Work on BMD papers
- [] Book hotel for BMD
- [] Post update about BMD copyright
- [] Finish reading the van der Kooij paper
- [] See if our controller can drive an OpenSim model or Ton's 2D model
- [~] Sit down with Ton to learn how to wrap the HBM
- [] Duplicate website backups on a S3 bucket
- [] Work on the website theme
- [] Make generic settings on the lab website
- [] Review the TODO items on the Yeadon paper
- [] Do CITI course
- [] Do FERPA course
- [] Write up database proposal
- [] Try out CSympy with some mechanics problems
Walking System Identification
I've been using Pandas DataFrames to manage the walking time series data and it generally seems to be working well. But I had a bug that's been holding me up on parsing the data. Turns out it was related to the fact that D-Flow returns data at variable sample rates, even if you try to pull in the data "directly" from the Cortex mocap software. The hideously huge csv files that D-Flow spits out have a column for a time stamp and a frame number, along with columns for each of the time series you ask it to output. All of the columns except frame number (it's an integer) are fixed point floats with 6 digits after the decimal regardless of the measurement. So the time stamp is given to microsecond precision. If you record data through the mocap module in D-Flow it should respect Cortex's 100 hz sample rate, but the period between time stamps hovers around one hundredth of a second. The following plot shows the variation in period between samples (which also has an interesting pattern):
I've never dealt with a data acquisition system (yet alone a half a million dollar one) that gives you fishy results like this. And this doesn't even mention the fact that if you use D-Flow's record module you get really huge variability in the sample rate because it is tied to D-Flow's computations which include 3D graphical rendering at each time step. This may be fine and dandy for clinicians but for researchers I'd expect more control and precision in the output data. This tied with the fact that they write missing values as 0.000000 instead of an identifier like NA or Nan is really annoying for data processing. I think any good DAQ should provide you with data in this form:
data array = [1.2e-16, 1.3e-16, 1.4e-16, NA, 1.5e-16, 1.6e-16, NA, 1.7e-16] sample rate = 100 # hz
Then there is no ambiguity in the data that you have. You know the fixed period, the data values are floating point, and missing values have a clear indicator. There should also be some reported accuracy of the measured values.
Human Body Model
Ton sent me his C code for the Human Body Model, which I'm going to work on wrapping with both Matlab and Python so that we can use it in data processing without being tied to D-Flow and running it real time. It should be relatively simple to wrap the code.
2D Walking Model
Ton also sent me a 2D walking model which has a foot contact model that we can use to test out controllers on. He presented it in a tutorial and the dynamic walking conference in 2011 and the software can be downloaded here:
http://www.dynamicwalking.uni-jena.de/node/48
It also looks like Open Sim has some simple 2D models that we can test out. Chris is helping me get familiar with OpenSim. The OpenSim models are here:
http://simtk-confluence.stanford.edu:8080/display/OpenSim/Musculoskeletal+Models
Opensim has also moved their repo to github so hopefully contributions will ramp up like other projects that move to git and github: