Skip to content

Latest commit

 

History

History
137 lines (124 loc) · 7.64 KB

plan.org

File metadata and controls

137 lines (124 loc) · 7.64 KB
Raw

Wish list from Ola & co

Resultat av rörelseanalys för NVG-studien. Dvs rörelseanalys med guld-standardtekniken (Qualisys motion-capture system). De variabler som vi är intresserade av är de som du nämner nedan + minimal foot clearence och armpendlingar, dvs.

[DONE] stegfrekvens och även variabilitet av stegfrekvens/längd

Implementation: db.get_cycle_frequency

[DONE] rörelseomfång i knäet

Implementation: db.range_decorator(db.get_angle_between_segments)

Validering: get_angle_between_segments_markers

Problem: Good standing reference missing. Using data from just before trial

gives result which differ (too much) between left and right leg, probably due to person standing with either foot in front of the other. Use local x-axis instead of direction at (assumed) standing ref? Or could the problem be caused by difference definition of angles in in left and right imus? Update 2017-11-21: Seems to be OK, but differences exists between legs and between IMU and marker data calculations.

[DONE] vertikal lyft av foten (maxlyft)

Implementation: db.range_decorator(db.get_vertical_displacement)

Validering: db.get_vertical_displacement_markers

vertikal clearance av foten (minlyft)

Tolkar som minsta höjden i svängfasen. Fast ankeln visar ingen dip. Funkar interp1d

Implementation: If LA: db.minmax_decorator(db.get_vertical_displacement,

start=0.5, end=0.9)

Implementation: If RA: db.minmax_decorator(db.get_vertical_displacement,

start=0.1, end=0.4) *** Validering: db.get_vertical_displacement_markers

[DONE] vertikala förflyttningen av tyngdpunkten

Implementation: db.range_decorator(db.get_vertical_displacement, IMU=”B”)

Validering: db.get_vertical_displacement_markers

bålens sagittala rörelsesomfång

Implementation: db.range_decorator(db.get_angle_to_vertical), IMU=”N”

armpendelrörelse (ex. frekvens och vinkelomfång i axel).

Inte säker på vad som menas med frekvesn. För Range-of-motion:

Implementation: db.range_decorator(db.get_angle_to_vertical), IMU=”LH” och “RH”

[DONE] Transparent use of marker data to calculate

The user experience should be something like this

  1. Decide on the analysis to make. The available analyses you can run on a single trial are
    1. Angle to vertical of single segment (IMU)
    2. Range-of-motion over a gait cycle of angle to vertical
    3. Planar (sagittal plane) angle between segments
    4. Range-of-motion of said angle
    5. Horizontal and vertical (again in sagittal plane) displacement of a segment (origin of the IMU)
    6. Range-of-motion of said displacements
    7. Step length / Step frequency
  2. Decide on which subjects and which trials for which to run the analysis. These are represented by lists, i.e. subj=[‘S4, S5’], trials=[‘N’,’B’]
  3. Run the analysis the call is something like this res = db.apply_to_all_trials(db.get_RoM_angle_to_vertical, {‘imu’:’N’}, subjlist=[‘S2’, ‘S3’], triallist=[‘B’, ‘N’]) Whatever is returned from the function is collected in a dict indexed by the tuple (subject, trial).
  4. Create summary statistics from the results returned. The function make_boxplot does this. *** [TODO] Text files generated by make_boxplot to contain subj number

*

[TODO] Associate marker data to IMU data

IMU data are referenced by name of IMU. Must determine association of marker data to IMU. Since we work with planar motion, we need two markers Proximal and distal. Only left side of body has markers. Marker names are HEAD ELBOW WRIST ACR C7 SACRUM LPSIS HIP THIGH KNEE ANKLE DECISION: Define the following proximal and distal markers for the IMUs

  • LA (left ankle) upper:”KNEE”, lower:”ANKLE”, closest:”ANKLE”
  • LT (left thigh) upper:”HIP”, lower:”KNEE”, closest:”THIGH”
  • N (neck) upper:”C7”, lower:”SACRUM”, closest:”C7”
  • LH (left hand) upper:”ELBOW”, lower:”WRIST”, closest:”WRIST”

[TODO] Handle non-existence of marker data for specific trial

[TODO] Visualize comparison between results from marker data and IMU data

[DONE] Decide: Should marker data be included in the hdf db? NO

I don’t think so, in order for the database not to be too big. Instead, the marker validation data should be a separate database. Either as a lump of files with a table (dictionary) to get the correct data. The module compare_to_mocap uses a list of triplets (subj, trial, filename). In order to make the use of the marker data transparent, there should be a flag that is used in each analysis function which is False by default (useMarkerData=False). If true, then in an easy way the proximal and distal marker trajectories for the particular IMU and for the part of the trial to analyze should be loaded, and a particular function be called. Or have separate functions for marker data that have same calling signature as for the IMU data. That leaves the question of comparison. This can be done on a pair of dictionaries as returned by apply_to_all_trials. This comparison function should be able to handle both results in the form of sets of single data (RoM for instance) and sets of timeseries (angles over gait cycle).

[TODO] Refactor code

  • [TODO] move all marker data related code into new module
  • [TODO] More transparent handling of start of cycle data. The start and end of cycles are defined by the packet number (PN) of the LA imu. To get the PNs of cycles for other IMUs, the difference in the PN at the sync pulse is added: PN at start cycle = PN at start cycle LA - PN at sync LA + PN at sync IMU
  • [TODO] Exactly how to use interchangable function objects. Right now there are two parallell solutions. Attributes self.rotationEstimator and self.displacementEstimator. But also, the function get_angle_to_vertical takes a callable as an optional argument. This overrides the default estimator. I moved all these callable objects to kinematics.py. The callables that estimate orientation all take (tvec, gyro, acc, mag) as arguments, and it is assumed that the data is for a single cycle only. All other arguments that are specific for the algorithm is set in the constructor when the callable is instantiated. The problem now is that these arguments may be necessary to set for each particular subject and imu…
    • [TODO] Decision: Change the calling interface of the orientation estimators to also take optional arguments (accref, gyroref, magref)
    • [TODO] Decision: The return values should also be the same for all callables, or otherwise the objects will not be interchangable. The return values should be (q, phi) where q is a QuaternionArray giving the orientation with respect to the orientation at the first data sample. phi is the angle to the vertical or None if not provided.

[TODO] Decision: Should the kinematics calculation always assume a single cycle of data is provided?

  • In favour
    • Powerful assumption. Can eliminate drift
  • Against
    • Utilize correlations between cycles
  • Decision Correclation between cycles is rather week. The only algorithm that could utilize this is the Fourier-series method.

[TODO] Write results to excel file.

Single excel file with statistics for single result variable. One row per subject. Title gives name of variable. Columns: For each of the conditions “N”, “B”, “M”, “D” : Mean, Standard deviation, Min, Q1, Q2, Q3, maximum.