File formats

[aremazeilles]

Looking at the input file information:

emg.csv

entries are prefixed with r_ and l_. @alfonsotecnalia should we then propose this updgrade to the documentation?

jointAngle.csv:

In the documentation, we now refer to this figure

On one side, in the jointAngle file, we suggest using _x, _y, and _z for the three angles (named cardan angles). In your file here, you use flexion, adduction and rotation. Should we permit both, or migrate to a single format? Actually, for some other angles, other terms are used, like obliquity for the head.

Then, I could see pelvic, that we do not have on our figure. I guess we should add it, correct @juritaborri

platform data: We accepted to keep such file, so that people would not generate several input files just to distinguish some info type, in particular if a single device was capturing all this. We won't push to split the content, but I can make some suggestion to improve the clarity of the content (no obligation to follow all). For sure, I hope this file will be extensively detailed in your report.

• protocol_number: as it is constant, it could be actually be a controlled variable, and therefor stored in a yaml file aside.
• kx to kz: what is k?
• cxto cz: simlar comment
• all: all would rather use lower case for all names: like fx or mx
• if fx or mx refer to force and torques, I would suggest follow the same lables as in the documentation
  • @alfonsotecnalia we actually have some inconsistency with the groud reaction force.
  • @juritaborri , since you have after the cop, I would suggets following the format of the ground reaction force
• are the four last columns used in other protocols ? In the first one they were all equal to zero it seems.

[juritaborri]

As regards jointAngle.csv: • I agree to use _x _y and _z rather than flexion, adduction and rotation. It is only important that users know which is the actual physiological meaning of x, y and z. • Pelvic is a little bit different, from a physiological point of view, from hip; thus, it is desirable to add it in the document. As regards PlatformData: • The organization of data in the matrix will be deeply discussed in the manual of the robotic platform, as well the meaning of each column and the sensors in the device that allows recording each data. • k and c represent the stiffness and compliance of the platform, respectively. The exact value of these two parameters are not used in the PI algorithms; however it can be useful to store the information since in some protocols users will have the possibility to select among three different compliance levels (even though in the manual the medium one is ALWAYS the suggested one) and the comparison among different repetitions or subjects can be conducted only if the compliance is the same. • The protocol number is a constant but it is fundamental for launching the exact PI algorithm. If you want and you believe that it is better, we can treat it as a controlled variable but this would mean to change all the PI algos in which we firstly check the number of the protocol to understand which variables have to be used. Are you sure that it is convenient to store it in another file that must become another input of the function? • Ok for the label related to force, torque and center of pressure. • The last four columns are respectively referred to (i) perturbation direction, expressed as integer number ranged from 0 to 9 in step protocols and from 1 to 4 in sinusoidal protocol (each number corresponding to a specific direction), this column is always equal to 0 in the first four protocols; (ii) right stride, expressed as integer number ranged from 0 to 1, where 1 indicate the period in which right foot is in contact with the platform. This column is necessary for analysing data only related to the first two protocol; (iii) perturbation value, expressed as number that represents the amplitude of the perturbation in step and sinusoidal protocols; this column is always equal to 0 in the first four protocols; and, (iv) left side, with the same logic of the right side (ii).

[aremazeilles]

I propose to switch the discussion per topic, to avoid too long discussion.