find_gait
The find_gait command-line tool is the second executable stage of the
pipeline. It reads bilateral activity windows from PostgreSQL, retrieves raw
inertial data from InfluxDB, detects effective movement in each leg, derives
bilateral gait episodes, enriches those episodes with GPS-based metrics, and
optionally stores the results in PostgreSQL.
Purpose
This command performs the movement and gait detection stage of the project:
retrieve candidate bilateral windows from
activity_allexpand those windows into one row per leg
fetch raw inertial signals for each leg from InfluxDB
resample the inertial series to a fixed temporal grid
detect
effective_movementfrom spectral and temporal criteriaintersect left and right effective movement to derive
effective_gaitenrich gait intervals with GPS-derived metrics
optionally store
effective_movementandeffective_gait
Input modes
The command supports two retrieval modes.
Explicit ID mode
Provide one or more activity_all IDs with -i / --ids:
python -m ms_monitoring.find_gait \
-c config.yaml \
-i "1,5,10-15" \
--save 1 \
-v 2
Recent-hours mode
If --ids is omitted, the command retrieves candidate windows from the last
N hours:
python -m ms_monitoring.find_gait \
-c config.yaml \
--hours-back 25 \
--save 0 \
-v 1
Arguments
The tool accepts the following arguments:
-c, --config: path toconfig.yaml(required)-i, --ids: range/list ofactivity_allIDs-l, --lang: interface language (esoren)-o, --output: optional XLSX export of raw sensor data-v, --verbose: verbosity level--head-rows: number of preview rows to print--hours-back: fallback time window when--idsis omitted--save: whether to persist results in PostgreSQL (1) or run in dry mode (0)
High-level execution flow
The command performs the following steps:
initialize translations
create a
MovementDetectorretrieve bilateral candidate windows from
activity_allexpand them into one row per leg
detect per-leg
effective_movementoptionally store
effective_movementdetect bilateral
effective_gaitvalidate/enrich gait intervals with GPS-derived metrics
optionally store
effective_gait
Detection details
The inertial stage is based on:
raw accelerometer and gyroscope signals
fixed-rate resampling before analysis
magnitude computation for acceleration and gyroscope
Welch spectral power inside a configurable frequency band
temporal continuity criteria
merging of nearby valid windows
minimum-duration filtering
The gait stage is based on:
temporal overlap between left and right effective-movement intervals
minimum gait-duration filtering
optional GPS enrichment using distance, elapsed time, average speed, and a boolean validation flag
GPS enrichment
Each detected gait interval may be enriched with the following fields:
gps_pointsgps_distance_mgps_elapsed_secgps_avg_speed_m_sgps_validated
These values are derived from the GPS trace associated with the same participant and time interval.
Dry-run mode
When --save 0 is used:
the full detection pipeline is still executed
results are printed for inspection
no rows are written to PostgreSQL
Typical outputs
The command may generate:
per-leg rows in
effective_movementbilateral rows in
effective_gaitenriched with GPS metrics
Implementation notes
timestamps are normalized consistently before querying the databases
inertial data is resampled before windowing to mitigate packet loss and improve temporal alignment
the final partial inertial window can be kept when it is large enough
GPS enrichment is part of the final pipeline before storing
effective_gait
API reference
- class ms_monitoring.find_gait.VAction(option_strings, dest, nargs=None, const=None, default=None, type=None, choices=None, required=False, help=None, metavar=None)[source]
Bases:
ActionCustom argparse Action to handle cumulative verbosity (-v).