Add wrench format

[aremazeilles]

Fix #22

[aremazeilles]

Ping @alfonsotecnalia @m-lancini What do you think?

As mentioned in #19, I propose a table representation of the information for the file. Looks like more clear to me.

[m-lancini]

are x, y, z relative to the body the sensor is attached to or absolute? I'd say the first, but then we also need to specify the body

[aremazeilles]

I would assume that the force is relative to the sensing point. It is for sure relative to the body it is attached to. But this may not be expressed in the body frame, rather in the sensor frame. Do yo agree?

[alfonsotecnalia]

I agree, it would be relative (to the sensor frame of reference).

What do we do in scenarios which contains multiple force sensors?

• One file per sensor: subject_N_run_R_wrench_sensor_1.csv, subject_N_run_R_wrench_sensor_2.csv, ..., subject_N_run_R_wrench_sensor_S.csv
• One file with fields differentiating the sensor the data come: subject_N_run_R_wrench.csv

time	sensor_1_force_x	sensor_1_force_y	sensor_1_force_z	sensor_1_torque_x	sensor_1_torque_y	sensor_1_torque_z	sensor_2_force_x	sensor_2_force_y	sensor_2_force_z	sensor_2_torque_x	sensor_2_torque_y	sensor_2_torque_z
...	...	...	...	...	...	...	...	...	...	...	...	...
...	...	...	...	...	...	...	...	...	...	...	...	...

or

time	frame	force_x	force_y	force_z	torque_x	torque_y	torque_z	frame	force_x	force_y	force_z	torque_x	torque_y	torque_z
...	sensor_1	...	...	...	...	...	...	sensor_2	...	...	...	...	...	...
...	sensor_1	...	...	...	...	...	...	sensor_1	...	...	...	...	...	...

I would say the first option (one file per sensor) is more general. The second one is used if all the sensors in the tesbed shares the same acquisition interface which it is not quite common (if differet interfaces, then you wouldneed some SW to mix the data).

[aremazeilles]

I would suggest looking at the mutliple sensor aspect aside, in another issue, to avoid mixing topics.

[aremazeilles]

If we are happy with the proposed Wrench Stamped description, then we merge it, deploy the format description per table in all files, and then consider other issues, such as the multiple sensors one.

[m-lancini]

I would assume that the force is relative to the sensing point. It is for sure relative to the body it is attached to. But this may not be expressed in the body frame, rather in the sensor frame. Do yo agree?

I think in most cases the force sensors will be fixed, so it makes little difference, for mobile force sensors (I am thinking about crutches), forces and torques should be expressed in terms of the reference frame of the body (i.e. the object) the sensor is rigidly attached to. It would make inverse dynamic easier.

[m-lancini]

If we are happy with the proposed Wrench Stamped description, then we merge it, deploy the format description per table in all files, and then consider other issues, such as the multiple sensors one.

We are measuring only forces and not torques in our project. Do we skip the torque columns? fill them with 0? or fill them with NaN?

[alfonsotecnalia]

0 could be interpreted as if there was a measuremet but it was 0. I think that NaN is specific to numbers and some fields in other files could contain strings. I would leave them empty/blank.

[alfonsotecnalia]

I would add "empty fields" to issues and merge this request.