Fix location of *_foot_* links in iCub3 models and add tests on the location of FT sensors #243
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
traversaro
changed the title
traversaro
changed the title
…g FT frame origins
|
As discussed in icub-tech-iit/ergocub-software#146 (comment), for iCub3 and ergoCub 1.0 the fixes will be done at the software level and not at the CAD level, so at this point I think we can merge this PR, do you agree @Nicogene ? |
Nicogene
approved these changes
Jul 14, 2023
traversaro
added a commit
that referenced
this pull request
Sep 20, 2023
Fix robotology/icub-models#209 . In #243 the location of the frames of the links of the soles ( with names like `(r|l)_foot_(front|back)` ) have been moved to the origin of the FT sensors that connect them with the `(r|l)_ankle_2` link. All the quantities expressed in this frame have been automatically modified to account for its new location by the simmechanics-to-urdf script, except for the location of the assigned collision, that are hardcoded in the .yaml file . This created a regression, has it effectly moved the sole assigned collisions up, so the robot was actually touching the ground with the (r|l)_ankle_2 links, that do not have any contact parameter assigned. This commit fixes the situation by taking the existing z value of the assigned collision origin, and adding the offset with which the other elements (visual, inertial) have been modified (see robotology/icub-models@799ae07#diff-9d811d6ae4a80f936a2466cdc3b852ac4fb6d6e3a4cd40d2c42e794f42d6415aL260), to obtain: newCollisionZ = oldCollisionZ + (newVisualZ - oldVisualZ) = 0.003 + (0.9241470000000105 - 0.9464470000000105 ) = -0.0193
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The test added in the first commit of this PR ensures that the FT sensor frames origin are coincident with the origin of the frames of the child link of the joint to which they are attached, to ensure that they can be correctly simulated in Gazebo (see gazebosim/sdformat#130). To get the test to work I also needed to update iDynTree to version 2.0.0, but that should not influence
See icub-tech-iit/ergocub-software#146 for more details.
Note that the first commit of this PR will fail due to the problem discussed in icub-tech-iit/ergocub-software#146, with error (see https://github.com/robotology/icub-models-generator/actions/runs/5532882398/jobs/10095587053?pr=243):
While the third commit fixes the tests by moving manually the origin of the links:
in the iCub3 simmechanics file, from having the origin aligned with the sole of the robot, to having the origin aligned with the FT sensor frame. Users interesting in getting the location of the sole should use the
l_soleandr_soleframes, as documented in https://icub-tech-iit.github.io/documentation/icub_kinematics/icub-model-naming-conventions/icub-model-naming-conventions/#1-dof-joints .