File Format: platform data

[aremazeilles]

From #26:

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 answered:

• 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]

Assuming that you will detail all these fields in the documentation, then that would be fine to me, and if you can adjust the field names of aspects that are detailed in the data format file (like fx, mx), then perfects. So I will just wait for you to make that change.

For the protocol number, you can leave as is. Generally speaking, I don´t think that this information should be placed there, but we can leave with it.

[alfonsotecnalia]

I would use for GroundReactionForce (and PlatformData here) the same labels specified for Wrench (force_x, force_y, force_z, torquex torque_y, torque_z) and rename p_x/py/p_z to cop_x/cop_y/cop_z.

[juritaborri]

I followed the labels suggested by Alfonso and added the modified input data in the branch: FileFormat_PlatformData

[aremazeilles]

There are still some points that could be adjusted (use lower_case labels, use force_x and torque_x instead of Fx and Mx, but I think these are minor issues