Expose the available TUG metrics to the end user

[mfussi66]

The managerTUG is the software module that supervises and coordinates interaction between other software components involved in the TUG demo. In particular, it commands the motionAnalyzer through RPC commands, by sending messages that start and stop the motion analysis.

At the moment, in the managerTUG it is hardcoded the selection of the step_length as an exposed metric. The metric quantity is exposed in the yarpscope, although all the others (such as step_distance, step_width, cadence...) are computed anyway, but hidden. It is probably useful to expose to the final user all the computed metrics in different scopes, or let them select the desired metric to see. The first option is most likely the most complete one, but it necessitates a small rework of the motionAnalyzer.

[pattacini]

Hi @mfussi66

I think that everything's ok as long as all the metrics will land in the final report; hence, no need for modifying the motionAnalyzer in order to publish the missing metrics in real-time.

Regarding this, did you test the production of the final report? I deem that the final report is an essential tool that collects all the numbers that will be in turn used for comparing against other baselines (e.g., stopwatch, IMU-based outputs...).

[mfussi66]

@pattacini I inspected the report and its generator, and indeed all the TUG quantities are present. The motionAnalyzer saves a .mat file at the end of every experiment, containing the coordinates of the skeleton's keypoints. The report computes them by repeating the logic of the motionAnalyzer code.

I'll test the report (and especially check if it still works) and check if the metrics are plausible as requested 👍

(Maybe it would be more efficient to store in the .mat file the metrics computed by the code instead of computing them a second time, but this is beyond the issue at hand)

[pattacini]

@pattacini I inspected the report and its generator, and indeed all the TUG quantities are present

Cool 🎉

I'll test the report (and especially check if it still works) and check if the metrics are plausible as requested 👍

👍🏻

(Maybe it would be more efficient to store in the .mat file the metrics computed by the code instead of computing them a second time, but this is beyond the issue at hand)

That's true, but also having the original raw data could have some potential. In this latter way, in fact, one could be able to post-process the data and come up with other metrics. At any rate, ya, it's beyond this issue and we can stay with that. Only, let's check that the two results coincide.

[mfussi66]

I think the notebooks for generating the report were created for Python 2. What gives it away is the fact that print is called without brackets, so it's an occasion to keep the report generator up to date.

[mfussi66]

Report is now updated, here is a snippet. I used a dataset that I created just for motion analysis, that's why there is no timing info. We need to be careful with the peak finding function, as it might find some false positives. That can be kind-of solved by adjusting the step threshold, but it should be done for each patient.

I had to align the scripts with the motionAnalyzer changes, but it seems to be working now.

[pattacini]

Great @mfussi66 👍🏻

A few comments:

• I would avoid the scientific notation for numbers in the report; better off sticking to the standard representation.
• The procedure used for finding peaks is actually critical and maybe ill-posed. We should address this problem. Let's discuss how. Also, is the same procedure used online?

[mfussi66]

The procedure used for finding peaks is actually critical and maybe ill-posed. We should address this problem. Let's discuss how. Also, is the same procedure used online?

Well it's tricky, because the Python notebook uses a Scipy function, while the motionAnalyzer uses a more barebones, homemade function.

Scipy's implementation offers many arguments to tune the detection, while our implementation relies on simple thresholding of local maxima. Maybe we could emulate Scipy's code by reimplementing the algorithm (considering only the parameters we need, so it could be pretty manageable), or by generating the equivalent C code with Cython.

[mfussi66]

Closing in favor of https://github.com/robotology/assistive-rehab/issues/340, since we proved in this issue that the gait data can be retrieved.