Open aremazeilles opened 3 years ago
I'd go for the mapping, by specifying in the human model document which angle corresponds to _x, _y, _z. Some of us will be happy to work with xyz (measurement, control, design), others will want adduction (therapists, mds)... so I think it's best to simply add a new label in the joint angle description page with _x _y _z. The jointAngle will still state that angles labels should use _xyz since that concern mostly xyz users. Does that make sense?
I am agree with Matteo regarding the use of _xyz. It is only important to underline in the angle definition that x is always related to the rotation around the sagittal axis, y around the frontal one and z around the transversal one, otherwise no comparisons among different tests would be consistent. In this way we also bypass the problem related to the different naming of the rotations according to the considered joint.
OK, before submitting it, I will list the mapping here. If you could verify it, then I will insert that information within the documentation.
So I would suggest adding the following table at the end of the section on the Angles definition, after 3.10.
Can you double check, and, if possible, look at the comment placed in the unclear
column?
It is accepted to use more compact joint angle names, based on the following correspondances.
joint name | _x |
_y |
_z |
unclear |
---|---|---|---|---|
hip | adduction | flexion | rotation | |
knee | adduction | flexion | rotation | |
ankle | flexion | in doc we only mention the flexion. Is it normal? Should we assign to _x ? |
||
foot | progression | rotation | again, only two mentioned. Do we assign it to x and y ? |
|
shoulder | adduction | flexion | rotation | |
elbow | flexion | same comment as for ankle. Is it normal? Should we assign to _x ? |
||
wrist | adduction | flexion | rotation | |
waist | obliquity | rotation | tilt | in doc, section is named waist, but label is pelvis . Is it normal? |
spine | flexion | lateralFlexion | rotation | |
thorax | obliquity | rotation | tilt | thorax is under section spine in doc. Should we create a section specific to thorax? Is the order good? |
head | obliquity | rotation | tilt | head is under section neck in doc. Should we create a section specific to head? Is the order good? |
neck | flexion | lateral_flexion | rotation | is the order correct? |
Would this be ok (once the unclear points adressed)?
In my experience the unclear points can be solved as follows:
LOWER LIMB For the ankle: _x eversion/inversion, _z rotation Pelvis is more used than waist in gait analysis and clinical UPPER BODY Head and thorax are segments, instead the spine and neck are joints. So the angles for the head and thorax are absolute, instead for the spine and neck are relative. I think that two sections are useful. For thorax and head, I suggest this order _x obliquity, _y tilt and _z rotation (this guarantees the same logic of other angles where _x is rotation in frontal plane, _y in sagittal and _z in transversal). Similar for the waist/pelvis. For the neck: _x and _y should be inverted for the same reason. UPPER LIMB It is not easy the definition of rotation related to the shoulder and elbow because it is not possible to talk about sagittal, frontal and transversal plane. However, it is used to consider the logic you already report _x adduction, _y flexion, _z rotation, (for the shoulder) and _x supination/pronation, _y flexion _z is not considered since supination is a mixed movement in both _x and _z.
For others, I agree with the table.
Il giorno lun 26 ott 2020 alle ore 22:18 Anthony Remazeilles < notifications@github.com> ha scritto:
So I would suggest adding the following table at the end of the section on the Angles definition, after 3.10 https://github.com/aremazeilles/eurobench_documentation/blob/master/model.adoc#neck . Can you double check, and, if possible, look at the comment placed in the unclear column?
It is accepted to use more compact joint angle names, based on the following correspondances. joint name _x _y _z unclear hip adduction flexion rotation knee adduction flexion rotation ankle flexion in doc we only mention the flexion. Is it normal? Should we assign to _x? foot progression rotation again, only two mentioned. Do we assign it to x and y? shoulder adduction flexion rotation elbow flexion same comment as for ankle. Is it normal? Should we assign to _x? wrist adduction flexion rotation waist obliquity rotation tilt in doc, section is named waist, but label is pelvis. Is it normal? spine flexion lateralFlexion rotation thorax obliquity rotation tilt thorax is under section spine in doc. Should we create a section specific to thorax? Is the order good? head obliquity rotation tilt head is under section neck in doc. Should we create a section specific to head? Is the order good? neck flexion lateral_flexion rotation is the order correct?
Would this be ok (once the unclear points adressed)?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aremazeilles/eurobench_documentation/issues/71#issuecomment-716829531, or unsubscribe https://github.com/notifications/unsubscribe-auth/APD2ILK2OCUS5AP6HSNKJ4DSMXRTJANCNFSM4STTWMRQ .
--
Juri TABORRI, PhD Research Fellow juri.taborri@unitus.it juri.taborri@uniroma1.it ’La Tuscia', University of Viterbo Department of Economics, Engineering. Society and Business Organization (DEIM) Largo dell'Università 01100, Viterbo ITALY +39 0761357049 <+39%200761%20357049>
Reviewing the table I found some issues...
The XYZ axis follow the standard biomech definition (Y vertical, X antero-posterior, Z medio lateral), I suppose. The first rotation normally considered (as in VICON) also is Z (perpendicular to Sagittal plane) For upper-lower limbs (wrist, elbow, ankle, and knee, but also shoulder and hip) the first rotation around Z is usually defined as flexion-extension. The second (around X) abd-adduction, while the third (around Y) rotation – internal-external. These movements are easily understandable when we produce one of them starting from the reference anatomical position (standing straight with upper limbs abandoned along the torso and thumbs facing left and right for left and right hands)
According to this scheme, the following tables seem to consider Z as the vertical axis and not the medio lateral one. In other words and in general, I was expecting to find rotations under the Y columns and flexions under the Z one.
I have some doubts for elbow and ankle: Elbow: 2 DoF. along Z: flexion. Along Y: rotation (internal external or prono-supination) – Hinge+Pivot joints Ankle: 2 (3) DoF: main along Z: flexion (dorsal/plantar), along X (inversion, eversion), and slight Y movements. Hinge + gliding joint
First of all, thanks both of you for dedicating time on this, I appreciate it.
Nevertheless, it seems that we are not converging, as far as I could understand your two statements. Am I correct?
I am wondering if it is possible to converge to a model ( and I am pretty sure other people not participating here may argue or have different views, right?). What is your opinion?
A mitigation plan could be to state in the pre-processed format jointAngle file that the labels stated in the model file can be used, but the protocol can specify some specific "x,y,z" conventions that can be used to name any of the angle. In that case, the protocol description should explicitly define to what refer each.
What do you think? I mean I would prefer to get an agreed xyz convention, but I am not sure it is feasible.
I can easily converge to the proposal of Matteo. VICON is the most widespread system for such analysis; so it's ok Y vertical, X antero-posterior, Z medio lateral.
Juri
Il giorno mar 10 nov 2020 alle ore 22:31 Anthony Remazeilles < notifications@github.com> ha scritto:
First of all, thanks both of you for dedicating time on this, I appreciate it.
Nevertheless, it seems that we are not converging, as far as I could understand your two statements. Am I correct?
I am wondering if it is possible to converge to a model ( and I am pretty sure other people not participating here may argue or have different views, right?). What is your opinion?
A mitigation plan could be to state in the pre-processed format jointAngle file that the labels stated in the model file can be used, but the protocol can specify some specific "x,y,z" conventions that can be used to name any of the angle. In that case, the protocol description should explicitly define to what refer each.
What do you think? I mean I would prefer to get an agreed xyz convention, but I am not sure it is feasible.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aremazeilles/eurobench_documentation/issues/71#issuecomment-724978662, or unsubscribe https://github.com/notifications/unsubscribe-auth/APD2ILL5Y2RT2OOI7KIYIMTSPGWKDANCNFSM4STTWMRQ .
--
Juri TABORRI, PhD Research Fellow juri.taborri@unitus.it juri.taborri@uniroma1.it ’La Tuscia', University of Viterbo Department of Economics, Engineering. Society and Business Organization (DEIM) Largo dell'Università 01100, Viterbo ITALY +39 0761357049 <+39%200761%20357049>
thank you Juri, appreciated!
Would it be possible for one of you to provide me the updated version of the correspondence table? If needed, I can pass it to any of you in word document. That would help me a lot...
ping @alfonsotecnalia @m-lancini @juritaborri
This was somehow raised with Juri and the beat code, there
In the jointAngle, we state that angles labels should use
_x
,_y
,_z
. But in the joint angles description page, we do not use these labels_x
,_y
,_z
., but rather_adduction
,_flexion
and_rotation
.Alfonso here suggest some description provided on Vicon pages.
My question would be: should we propose some name mapping in between the labels like
_adduction
,_flexion
and_rotation
. to x, y and z (considering that for some joint we use other names for the angles), or should we rather use the completed label defined in the model page, and change the joint angles tables csv file, so that id does not use the x, y, z, i.e:where
_r_
refer to the right joint, as suggested in that issue