moorepants / bicycledataprocessor Goto Github PK

• Split runs with multiple perturbations
• The time sync didn't work on run 466-470
• The lateral force is not always centered at zero, for example # 486, need a
  way to fix that
• 158, 159, 162, 163, 167, 168 should be "Balance"
• I'm missing videos 295-325
• The knee does not seem to come off in Run 309, change the note
• Run 584 Charlie forgot to hold his knees in, it is a nice demo of how much we
  move our knees laterally
• Check the time syncrhonization on runs 194, 195, 196, 197, 198, 433, 436,
  437, 439, 451
• run 316 may have a bad torque signal in the middle of the run

here's the output from ipython:

In [1]: import bicycledataprocessor
/usr/lib/pymodules/python2.7/mpl_toolkits/init.py:2: UserWarning: Module dtk was already imported from /home/biosport/Documents/Packages/DynamicistToolKit/dtk/init.pyc, but /usr/local/lib/python2.7/dist-packages/yeadon-0.9-py2.7.egg is being added to sys.path
import('pkg_resources').declare_namespace(name)

The bicycle parameters code gives this:

Calculating the human configuration.
Left arm's actual position does not match its desired position on the bike's handlebar. Left arm actual position:
[[ 0.76204482]
[-0.27266064]
[-1.10340464]] .
Left arm desired position:
[[ 0.68981424]
[-0.2675 ]
[-1.1186071 ]]
Left arm base to end distance: 0.581688096145 , Left arm D: 0.518569971695
Right arm's actual position does not match its desired position on the bike's handrebar. Right arm actual position: [[ 0.76204481]
[ 0.27266071]
[-1.10340466]] .
Right arm desired position:
[[ 0.68981424]
[ 0.2675 ]
[-1.1186071 ]] .
Right arm base to end distance: 0.581688096145 , Right arm D: 0.518569971695

It would nice if the endpoints on the filtered data were managed better, so that they are at extreme unrealistic values.

The h5 file needs to have a taskTable in it or generates it automatically at the beginning.

The mappings dictionary doesn't work if you don't have all signals computed. Some runs only have calibrated signals availables and Run.plot() needs to be aware of this.

Peter did this in his code:

https://github.com/moorepants/RiderID/blob/master/functions/davisdat.m#L55

to negate the lateral force for that run. So something may be wrong. Should check it out.

To be in accordance with the coordinates that I've chosen.

BicycleDataProcessor has a simple filter method for each signal and the Run class can filter all included signals at the same low pass cutoff frequency. Peter is working with the data right now and we noticed that we shouldn't blindly use the filtering option of the Run class. I now realize that the lateral force in my analysis in my dissertation was attenuated a bit too much. See the attached figure. Just something to keep in my when playing with the data.

For example: the Run.verify_time_sync() fails if the run is loaded from the task table instead of being recalculated. One fix would be to call the calibrate_signals() and truncate_signals() methods in verify_time_sync if the data was loaded from processed. Probably need to know which

This issue is currently on the store-processed branch.

get_row_num() fails if you try a run number larger than the number of runs in the run table

The function should be changed to always find the row number for the supplied runid