Tools for the Cleveland State Human Motion and Control Lab

@tvdbogert

In Octave-Matlab-Codes/2D-Inverse-Dynamics/test/rawdata.txt the force and moments are labeled FP1.* where as the markers are R*. The right force plate should be called FP2. I don't think there is an issue with the data, i.e. all the data is from the same side, but the labels are just not consistent. Still haven't found the real issue yet...

I'm having trouble figuring out what the slow down is. One bottleneck is surely the parameter covariance computations in dtk.process.least_squares_variance(), but even when that computation is skipped it still seems to be slow.

The mass and inertia selection/computations were done in the wrong loop, so the same inertial properties were used for each segment. This remedies that by moving the computations into the force/moment loop.

I just discovered that using the TimeStamp column in the mocap module was a bad idea. I new that the TimeStamp column had some anomalies (see http://gait-analysis-toolkit.readthedocs.org/en/latest/motek.html#data-column-descriptions) but none of my test data showed the additional anomalies I've just uncovered. Once I used a new differentiation method in PR #128 these anomalies were exposed, where as the previous differentiation method quietly but incorrectly smoothed them over. This issue is that DFlow receives streaming data from Cortex and it is accessible in the from the mocap module. Cortex likely handles the data stream correctly, i.e. within the 0.01 s sampling period it collects data from all cameras and computes the marker coordinates providing a value that was collected at sometime during the sampling period. Each cortex value is delivered along with the sequential frame number and it must have a mechanism to flag a frame number that has missing marker values. DFlow receives this data over ethernet and time stamps it using the DFlow CPU clock. This issue arises because the data flow comes into the DFlow computer serially and likely asynchronously wrt to time. A FIFO flow is likely used to so data is dropped, but this means that data can "stack up" with respect to the DFlow cpu time and if the TimeStamp column is relied upon, there can be issues.

The following plot shows the same graph from (http://gait-analysis-toolkit.readthedocs.org/en/latest/motek.html#data-column-descriptions) except with a data set (trial 31) that doesn't have as clean a time stamp. This plot shows the difference in the current and subsequent time value: Note that most of the differences are around 0.01 s, but there are some large outliers and notice the values that are close to zero. These correspond to the data stack up wrt to time.

The next plot shows three plots where I've flagged all the values associated with the time stack ups in red. The first plot is TimeStamp vs FrameNumber and the following two show the RGTRO marker coordinate against time and frame number. Notice that there are a fair amount of time stack ups in the data. We can zoom in to one instance to see what is going on: This graph plots the same things but we see how the frames get stacked up wrt to time.

The motek.py module parses the data and uses the TimeStamp column as a reliable value. You can see how this will cause issues when trying to differentiate marker positions with respect to time. The real time differentiator does can differentiate these instance without too much error so it wasn't noticed before. But the values are still wrong. The traditional central differencing methods have major issues with this incorrect data.

Note that this issue is in addition to missing marker values. The DFlowData class needs to be reworked to make use of the FrameNumber instead of the TimeStamp column.

The other issue with this is that synchronizing the mocap module and record module data relies on the time stamp values. I assume that the TimeStamp column from each module is generated from the DFlow cpu time. We'll need to look into the synchronization after the time stamp issues are taken care of to ensure that synchronization still works as expected.

We should put a license with the code so it is clear to people how they can use it. I've been using http://unlicense.org/ lately which makes it public domain (no restrictions). If you all desire some more restrictive (require citation, non-commerical, etc) we should discuss that. Right now the UNLICENSE is in the directory as that is what I had in DynamicisitToolKit.

Added in motek.py

• function to calibrate accelerometers
• function to relabel analog channels to user-defined or sensible defaults

Added in gait.py

• function to find heelstrikes/toeoffs from accel signal
• function to plot gait landmarks

test_motex/test_gait

• tests added to reflect additions

This fixes issue #68. It adds a new field in the meta data in which the user can provide a mappign between the marker names in the raw data files and the desired marker names in the resulting data frames returned by DFlowData methods. It follows the same design pattern as the analog channel relabeling method.

2. I found a typo in gaitanalysis/octave/2d_inverse_dynamics/leg2d.m where interp1 was called interp1q instead.

Now I’m getting the error: /usr/local/lib/python2.7/site-packages/gaitanalysis/gait.pyc in inverse_dynamics_2d(self, left_leg_markers, right_leg_markers, left_leg_forces, right_leg_forces, body_mass, low_pass_cutoff) 240 angles, velocities, moments, forces =
241 octave.leg2d(time, marker_array, normalized_force_array, --> 242 options) 243 244 dynamics = angles, velocities, moments, forces

ValueError: too many values to unpack

It seems leg2d.m only returns its first argument for some reason, the angles.

The speeds up the plots, makes the code a little more efficient, and also adds some arguments to enable the user to plot sections of the data more easily.

I can't reproduce this, so I'm skipping it:

• [ ] The heel strike lines don't always span the entire y range.

@campanawanna Can you check this and see if you think my change is correct and that the test is correct too. I'm not 100% confident that it is doing what I thought it should be doing.

Bumps pyyaml from 3.10 to 5.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

In 2018 this env.yml file worked:

name: gaitanalysis-dev-oldest
channels:
  - defaults
dependencies:
  - python =2.7.*
  - numpy =1.8.2
  - scipy =0.13.3
  - matplotlib =1.3.1
  - pytables =3.1.1
  - pandas =0.13.1
  - pyyaml =3.10
  - nose =1.3.1
  - sphinx =1.2.2
  - coverage
  - mock =1.0.1
  - numpydoc =0.4
  - pip:
    - dynamicisttoolkit==0.4.0
    - oct2py==2.4.2

But apparently the "free" channel was moved from "defaults", so this is now required:

name: gaitanalysis-dev-oldest
channels:
  - free
  - defaults
dependencies:
  - python =2.7.*
  - numpy =1.8.2
  - scipy =0.13.3
  - matplotlib =1.3.1
  - pytables =3.1.1
  - pandas =0.13.1
  - pyyaml =3.10
  - nose =1.3.1
  - sphinx =1.2.2
  - coverage
  - mock =1.0.1
  - numpydoc =0.4
  - pip:
    - dynamicisttoolkit==0.4.0
    - oct2py==2.4.2

conda will resolve the packages in this updated version.

gaitanalysis.tests.test_motek.TestDFlowData.test_extract_processed_data ... /home/moorepants/miniconda3/envs/gaitanalysistoolkit-dev/lib/python2.7/site-packages/numpy/core/fromnumeric.py:51: FutureWarning: 'argmin' is deprecated, use 'idxmin' instead. The behavior of 'argmin'
will be corrected to return the positional minimum in the future.
Use 'series.values.argmin' to get the position of the minimum now.
  return getattr(obj, method)(*args, **kwds)

gaitanalysis.tests.test_gait.test_find_constant_speed ... /home/moorepants/miniconda3/envs/gaitanalysistoolkit-dev/lib/python2.7/site-packages/scipy/signal/_arraytools.py:45: FutureWarning: Using a non-tuple sequence for multidimensional indexing is deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this will be interpreted as an array index, `arr[np.array(seq)]`, which will result either in an error or a different result.
  b = a[a_slice]

/home/moorepants/miniconda3/envs/gaitanalysistoolkit-dev/lib/python2.7/unittest/case.py:393: FutureWarning: get_store is deprecated and be removed in a future version
HDFStore(path, **kwargs) is the replacement
  return self.run(*args, **kwds)

/home/moorepants/src/GaitAnalysisToolKit/gaitanalysis/controlid.py:489: FutureWarning: `rcond` parameter will change to the default of machine precision times ``max(M, N)`` where M and N are the input matrix dimensions.
To use the future default and silence this warning we advise to pass `rcond=None`, to keep using the old, explicitly pass `rcond=-1`.
  x, sum_of_residuals, rank, s = np.linalg.lstsq(A, b)

Relevant warning from the tests:

gaitanalysis.tests.test_controlid.TestSimpleControlSolver.test_compute_estimated_controls ... /home/moorepants/miniconda3/envs/gaitanalysistoolkit-dev/lib/python2.7/site-packages/nose/util.py:471: FutureWarning: 
Panel is deprecated and will be removed in a future version.
The recommended way to represent these types of 3-dimensional data are with a MultiIndex on a DataFrame, via the Panel.to_frame() method
Alternatively, you can use the xarray package http://xarray.pydata.org/en/stable/.
Pandas provides a `.to_xarray()` method to help automate this conversion.

  return func()