Multi device testbeds

[aremazeilles]

From Nevio: What about testbeds including more than one device? Example: The BenchBalance testbed (to assess recovery from perturbed balance) includes: i) a perturbator in the form of a sensorized push stick, used by the experimenter; ii) a smart garment, worn by the tester. Are these two devices different sub-testbeds. How are they labeled in the file name format?

[aremazeilles]

ping @NevioTag @FraCampus @m-lancini @alfonsotecnalia @flxalr @DavidPintoFernandez

This is related to a comment done in the old google documentation, here

I would look at it thinking of the protocol and experiment description.

In the protocol description (look at table 4, testbed), I can imagine that we can mention that the protocol involves several equipments. If so we could mention, as Nevio was suggesting, a list like:

• sensorized push stick
• smart garment
• eventually some motion capture system

For the two first, I would suggest not detailing in more detail in the protocol table the sensors/actuators embedded into these equipments, but rather point to a specific documentation detailing all hardware in it. But at least at the documentation level the reader sees that three different components are needed.

Then, when uploading an experiment, I would assume we have a single testbed configuration file, as it is suggested in branch file_class.

That file should contain all the configuration item that may be needed to define the current configuration used in the associated set of runs.

I would furthermore put this in relation with the protocol template table related to the "controlled variables" (look the protocol sheet, table controlled variables). The variables indicated there are in my opinion the values we are expected to find in the testbed configuration file.

Matteo was suggesting using nested definition, i.e. something like:

push_tick:
  param_1: 3.14
  param_2: 0
garment:
  param_i : [15, 46]
  param_j: 2

At long term, that could be the best, in particular if we imagine providing dedicated pages and description of each testbed, in which we could indicate indeed each of the parameters associated to each device.

But to start smaller and simpler, I would suggest starting with a flat structure, like:

push_tick_param_1: 3.14
push_tick_param_2: 0
garment_param_i : [15, 46]
garment_param_j: 2

assuming that in the protocol description the table controlled variables indicates the presence of these 4 controlled parameters, like:

Name	Definition	type	range	unit
push_tick_param_1	stuff X of the push stick	float	[0; 2pi]	rad
push_tick_param_2	stuff Y of the push stick	boolean	[0,1]	boolean
garment_param_i	configuration i of the garment	vector	?	?
garment_param_j	configuration j of the garment	int	>0	level

Later on we can consider going to nested structure, but at short term, it eases the relation in between the controlled variables table of the protocol, and the testbed file content.

Another point in favour of using a single file for all parameters of all devices involved in the experiment, is that in some protocols we are likely to change some configuration parameters within a same experimental set. If this is done, I would imagine that we would upload: subject_1_testbed_1.yaml, subject_1_testbed_2.yaml, subject_1_testbed_3.yaml, in which we could have for example a change on the value of parameter, like exo_skeleton_support_level that could change from [no_exo, 1, 2,3]. Then for each testbed configuration we would expect to get the set of input files like: subject_1_cond_i_run_R_joint_angles.csv, with i in [1,2,3].

If we consider multiple testbed files, we multiply the files even more, and I am not sure it is wise to do so.

We could also consider putting all testbed configuration in a single file, using nesting structure, but again, I would rather keep it as an option for later, if we see the need to compress even more the data submitted by the system user.

To conclude, the suggestion is to:

• consider a single testbed configuration file per experiment
• use parameter name to differentiate the different equipment in the test bed
• for experiment involving parameter change, use multiple file to do so.

Any opinion on this (long) point of view?

I think this is also suggesting answer to issue #3

[m-lancini]

The only issue I see is that every device should know its name to properly access these information e.g. "right_crutch_length" instead of "length", so these are also to be defined. Are those defined yet?

[aremazeilles]

I am thinking of it at the level of PI computation, so that there is no more notion of device.

Such file does not need to be the one used during the data collection. The point you highlight relate to how to generate the configuration file, form the test-bed environment.
I think that should be something to look from the data collection environment. It should not be complex to prepare a tool for this, if a tool is needed.

[m-lancini]

ok, I get your point.

[aremazeilles]

@alfonsotecnalia any comment?

[alfonsotecnalia]

I found nested structure easiest to read/follow but we can start with the simple approach. I agree with the rest of the conclusions: single configuration file for all the equipments in the testbed, multiple files for experiments changing conditions and the combination of devicename_paramname to differentiate params.