Testbed collected data

[aremazeilles]

Some testbeds may include several sensing data (like a chair: 2 force sensors on the handrest, one proximity sensor in the backrest, ....)

If we stick to a file per data type, we can have to handle quite a lot of files.

In Protocol with multiple but similar sensors, we consider the possibility to gather data in a common files.

I would like to extend this for multiple sensing devices, and enable the use of a platformData.csv that could gather all sensing data collected by an instrumented device. Under the condition that:

• all gathered data follow the same timestamp
• inserted data follow individually the format defined in this document
• similar sensors data follow the distinction suggestion we already proposed

A complex question would be then: what is part of the instrumented device? A first guess could be:

• A set of equipments that are assembled together (like an instrumented_wheelchair, or a sensorized crutch)

I would try to distinguish other equipment that could be added to the testbed (like a motion capture, even a force platform plaed on the floor). These could be provided through additional files (i.e "platformData.csv", "jointAngle.csv" and "grf.csv"

I know the limit is very tiny, but i think that could make our life much easier. And actually, several protocols propose considering such file.

Any opinon @alfonsotecnalia @m-lancini ?

[alfonsotecnalia]

The unique file in which all device shares timestamp would be generated setting the rate to the fastest device and replicating the info for the slowest devices. That file could be easily interpreted by the PI which has proposed the file/structure (it will have the rates for the devices harcoded internally so proper filtering could be done for example) but other PIs trying to use the experiment dataset would miss that information. I think that at least the rate for all the devices forming a platform should be placed anywhere.

But I am not totally sure having such unique file is good (as it does not suppose other advantages as reducing the number of files).

[aremazeilles]

setting the rate to the fastest device and replicating the info for the slowest devices

That is one way to do it effectively, but i think other resampling strategies could / should be used.

Such information should be maybe documented, but for me it is a constraint / pre-processing request getting to the data collection and preparation for the PI benchmarking (i.e not on our side).

I could see several protocols suggesting a platform datafile. I see relevance when they have a single code gathering all data from several devices.

If they prefer having different frequency I hope they would maintain different files.

But here the objective is not to enforce it, but to state the conditions to accept it.
As we accept a file with two similar force sensors (where we request a common timestamp)

[m-lancini]

We have two cructches, each producing force (so I'd go with the WRENCH) format and gait status (SWING/STANCE).
In my opinion either we used an ad-hoc format (Crutches_data) or we go for a combination of more file formats into a single csv... the only issue is: how do we specify it? (which column is which)

[aremazeilles]

Your question is unclear to me. Do you refer to differentiating from crutches 1 and 2?

In the spirit of what is defined in 2.3.1, you could either go for one file per crutch, or a file combining the two crutches information, using a tag to differentiate the two crutches.

So we could get either:

• one file per crutch:
  • file crutch_left.csv with force_x; force_y; force_z; gait_status
  • file crutch_right.csv with force_x; force_y; force_z; gait_status
• one single file, crutch.csv, or testbed.csv, with left_force_x; left_force_y; left_force_z; left_gait_status; right_force_x; right_force_y; right_force_z; right_gait_status

Does it make sense ?

[m-lancini]

Your question is unclear to me. Do you refer to differentiating from crutches 1 and 2?

not only, the main issue is that each has two different outputs (gait status and load) that, as of now, are based on two different formats

In the spirit of what is defined in [2.3.1]

• one single file, crutch.csv, or testbed.csv, with left_force_x; left_force_y; left_force_z; left_gait_status; right_force_x; right_force_y; right_force_z; right_gait_status

In this case we should update the wrench definition (to include gait_status) or have a separate format for the crutches.
Or use two separate files (one for the two crutches FORCE output, one for the two crutches GAIT output)

[aremazeilles]

This is a bit why I propose considering input data files like platformData.csv ( I made a mistake in my previous comment, I should have used platformData, and not testbed), which would enable to combine in a common file information from different devices and / or from different types. I think this should be acceptable, as long as the information contains in it refers to some atomic data format already defined.

Creating a crutch format would make sense if it is a common data information extracted from crutches (forces and gait status). If it is not the case, but correspond to an had-hoc structure you need for your device, then I would consider it as a platform data, considering your crutche(s) as a platform.

Then one could argue whether we have a format defined for the gait status, as atomic information. We have a gait status format defined, but it is a yaml file, which would make sense if we just want to store the transitions.
In your case, it seems that the status is defined at each instant (being the current status).

In that issue I suggested the addition of a timestamped event, where events can be anything. Would it make sense to associate such format for your gait status?

Note that this would be a theoretical reasoning, as I would still suggest using one of the two solutions I proposed here, but at least in the documentation you could mention that the crutch(es) / platformData format is a combination of the wrench format and of the time-stamped event format.

[m-lancini]

I agree with timestamped events, and I believe that platformData could be a solution, so I went with that in the documentation. I believe that in this way, however, we are under-using the device: it's more accurate to have a stance/swing indication than a gait event, so maybe we could produce both to allow users choose whichever format is more convenient. (wrench+events, or [forces+status])

[aremazeilles]

If we go for a timestamp events, then we would have force_x; force_y; force_z; event. Then you could fill event with whatever makes sense for the protocol you consider. It could be events, or status depending on what the protocol expects?

[m-lancini]

would it be something like this?
force_x; force_y; force_z; event
0;0;0;heel_contact
0;1;0;
0;0;1;
0;1;2;toe_off

[aremazeilles]

The only constraint we put in csv files is to have no empty areas, meaning that we would need some information for lines 3 and 4.
If you want to keep it as an event (i.e keep only transition) it should be in a separate files. If we have a status for each line, then we can put it in the same file.

[m-lancini]

ok, so we're talking more about a status than a event.
works for me