Model specification

[m-lancini]

A lot of information regarding the general model used to represent the human pilot are split in different section and this could lead to inconsistencies. I propose to prepare a separate part or document detailing the model and its standards.

for instance:

Figure 2 depicts a model, the same does figure 3. Table 3 instead adds a segment: trunk (either is missing or is incorrectly named neck).
Moreover, table 3 seems to implicitly introduce multijoint bodies not listed (while the figures limit the model to lines): the shoulder terminates on the sternoclaviar joint, which is not a starting point for any other segment... to what is the shoulder segment attached to? do you foresee a solid body linking C7 (and/or T12) to the sternoclaviar joints? in fig. 2 fig.3 and table 3 the pelvis is made by three segments, while in 3.9 is treated like a rigid body

[aremazeilles]

ping @DavidPintoFernandez could you check the consistencies aspects mentioned by @m-lancini ?

@m-lancini you suggest to split the document to distinguish models used and data file structure, is that correct?

[m-lancini]

Yes, I'd like to have a general description of the model, that could also be used as reference independent of the data format. In this document we shall describe the reference system, the segments/bodies/joints name and specifics and so on. While the data format shall only concern format specifications.

[aremazeilles]

Trying to understand how to do this. I could generate another file, model.md, in which we could gather all figures relate to the human model, i.e joint centers (figure 2), the segment names (figure 3), the angle definitions (section 5).

would this be ok?

There is also this other issue related the angle definition.

I mean, I can prepare the separate file, but I would need support to fill these files. If the file format, I am happy to convert any document in the adoc format if this is an issue.

[m-lancini]

We can help with the model. If you'll prepare the separate file with the pieces already in the other documents, I'll try to work with the .md file. I'll ask you for help if I get stuck with the format.

[aremazeilles]

You can have a look at the branch https://github.com/aremazeilles/eurobench_documentation/tree/model_apart, that now contains a specific file https://github.com/aremazeilles/eurobench_documentation/blob/model_apart/model.adoc.

[aremazeilles]

Some references that could be worth taking into account here: related and comparable database existing:

• [https://motion-database.humanoids.kit.edu/](KIT database). It provides description of the anthropometric table, and the marker set used,
• [https://www.sim.informatik.tu-darmstadt.de/download/ds/HuMoD/Documentation/Documentation.pdf](HUMOD doc), which also describes the kinematic model, on page 7
• [https://koroibot-motion-database.humanoids.kit.edu/](the Koroibot database), which use similar marker set and anthropmetric table as the KIT database (similar people involved)

@DavidPintoFernandez , in these database, the placement of markers for Motion capture is described. I think we should do something similar (even if we decide to go for the same marker placement). A similar discussion could be also considered for EMG sensor placement. What do you think? Could you propose something on that aspect ?

[aremazeilles]

@m-lancini , just ping me if you need support for anything

[aremazeilles]

Wondering how this is going. Do you need support?

[m-lancini]

Having some doubts: for specific changes in the model shall I put them directly in the document or raise them independently? e.g. the shoulder link and the trunk one do not meet at all (one ends in T12, the other on the sternum)

[aremazeilles]

Is it a change in a figure? If yes, we can look at it directly through this discussion place (you can drag images here).

I guess you can change them directly in that branch. But to validate I would hope that @DavidPintoFernandez and / or @flxalr can check it with you

[m-lancini]

Not just the figure, but the model underlying. the segments definitions have errors to deriving from the same issue. I'll try to explain it with this image (hope it's clear) drawn using the definitions in the document. the main issues: -two separate segment links are formed: one linking the upper limbs and the other the rest of the human body. Shoulders and trunk are not connected. -the joint between trunk and abdomen is unclear in the first description -data is really difficult to be found about the shoulder mass, inertia etc, especially since a clear cut between was is supposed to be "shoulder" and what is the rest of the trunk is missing. is it really useful? -the pelvis is defined as three links (I suppose to compensate it being multi-jointed) but pelvis_w should have a null mass to get correct information about the left and right side of the pelvis (usually the pelvis is a whole rigid body, we can split it in half, but if in three I need to know how or have a null-mass body).

I presume that this derives from the confusion between links and bodies.. the urdf use the term link to define a rigid body, that can have more dimensions and joints, here is used to define only lengths.

please note: I exaggerated some distances to make my point clearer

[aremazeilles]

ping @diegotorricelli, I'll try to spend time to look at that, but your opinion is for sure relevant .

[DavidPintoFernandez]

• I agree with Matteo on the idea of splitting documents, or at least we should dedicate a unified section to define the model. As it is now in the master branch, the definition of the model is split into different sections and this could lead to difficulties in understanding the model.

• I also agree that it presents several inconsistencies. We must restructure this section and solve them. These inconsistencies come from trying to merge the anthropometric measurements present at the KITs database with the Plug-in-gait model from VICON.

• These days I will work in a more consistent version based on your figure, @m-lancini, and the already existing model. I will let you know when I'm done.

• About including a marker placement: For sure we can add a marker placement figure. Even though, I think that we have to be sensor independent, so we should advise that, if someone wants to use a different marker placement it is ok if they respect our model.

• Same with the EMG placement

[m-lancini]

just one note, my picture was to highlight the inconsistencies, not a proposal.. I am drafting a proposal, but the key point is that we need to split the definition of dimensions (link lengths) from the definition of segments. Would that work for everyone?

[m-lancini]

just one note, my picture was to highlight the inconsistencies, not a proposal.. I am drafting a proposal, but the key point is that we need to split the definition of dimensions (link lengths) from the definition of segments. Would that work for everyone?

[DavidPintoFernandez]

Ok, I will wait then for your proposal and we can work from it. I did not get your last point, what do you mean by split the definition of dimensions and segments?

[m-lancini]

Most of the inconsistencies stem from the fact that each segment is represented by a single-dimension link... I think to define the variables to be stored in the files. Instead we have segments with more than one dimension (hip, trunk, abdomen) and segment with more than 2 joints (trunk, hip).

[DavidPintoFernandez]

ok, now it is clear what you meant and I agree.

[m-lancini]

@aremazeilles could you please convert .adoc to .doc for me to edit? I tried to edit the adoc but I'm having difficulties and I surrendered. Thanks

[aremazeilles]

Under linux, I used the following command (from here).

INPUT_ADOC=pi_spec.adoc 
asciidoctor --backend docbook --out-file - $INPUT_ADOC| \
pandoc --from docbook --to docx --output $INPUT_ADOC.docx

• data_format.adoc.docx
• pi_spec.adoc.docx
• template.adoc.docx

[m-lancini]

It works but I miss the figures. I'll try to make up a word doc with the images from the adoc and then ask you to convert it back.

[m-lancini]

I tried to update at least the definition of the segments. Now it seems to me it's more coherent. The only issue is the definition of the "w" key labels. Why is that a suffix and "r" and "l_" are prefixes?

[aremazeilles]

I'll duplicate your last comment within the PR, to centralize all related discussions there.