search

ubi-agni / human_hand

modular, articulated human hand model
Other
31 stars 6 forks source link

Allow taxel.yaml to be in another place #13

Closed guihomework closed 1 year ago

guihomework commented 1 year ago

in PR12 I started to think of splitting the URDF hand part from the tactile part but the concern was raised that this split might not be trivial or hinder future possibilities.

Let suppose we keep URDF hand part and tactile part together, would you mind to allow the taxel.yaml to be loaded from a different package/path ?

The file is almost fully hardcoded to be _human_handdescription/model/taxel.yaml.

https://github.com/ubi-agni/human_hand/blob/0acf44b821b3408c0d909b0d96bb7b6a7273acb9/model/human_hand.urdf.xacro#L142

passing the package property through command line would be one step, but the path would still enforce the taxel.yaml file to be in a model subfolder of the package folder. So maybe passing a taxel_path property is easier, with a default value arg package + "/models"

Our goal is to have all our configuration files (not only taxel.yaml) in a single folder and have adequate launch commands passing the correct files. Hence not requiring to overwrite taxel.yaml of human_hand_description anymore.

What are your thoughts on that ? I think the change can be easy and I could try and provide a PR

rhaschke commented 1 year ago

Sure. This sounds perfectly reasonable. I just noticed that there is also a properties.yaml defining link lengths (and hand synergies). However, the meshes are not scaled correspondingly to varying link lengths, which renders these link length params unusable. Are you aware of this problem?

guihomework commented 1 year ago

I just noticed that there is also a properties.yaml defining link lengths (and hand synergies). However, the meshes are not scaled correspondingly to varying link lengths, which renders these link length params unusable. Are you aware of this problem?

Not aware. Since the meshes should be aligned to the link, one could maybe compute a correct scaling in the correct direction to then make it usable ?

rhaschke commented 1 year ago

Yes, that was my idea as well: one should compute the scaling from the desired link length to the original link length ratio. But this should also consider a potential offset between mesh and joint origin, making it eventually rather complicated...

guihomework commented 1 year ago

I did not double check, but i think I made the mesh origin exactly at the joint origin. When you write about potential offset you think that without offset the part overlapping with the palm at the knuckle might become longer and not look nice, since the scaling would go in both direction (towards fingertip and towards palm/previous link). it is possible that this will occur indeed.

The only way to avoid the complexity, would be to place the origin of the mesh at the bottom of the mesh (no points in Z axis negative for instance), and then add non null offsets to place that bottom of the mesh correctly over the link. I usually did not find that nice to read in URDF, but in such a case were scaling matters, it is the only possibility I see.

rhaschke commented 1 year ago

I recommend keeping the mesh origin identical to the joint origin. Yes that will cause a scaling of the proximal mesh nodes (with negative z-component) w.r.t. the origin. However, usually the joint origin is at the center of some "spherical knuckle object". If you shift the mesh origin to the bottom, you would also shift the equator of that sphere beyond the joint origin, which should be avoided in my opinion.