Update dynamic properties #195
Conversation
chalongrath
force-pushed
the
update_dynamic_properties
branch
from
9b63c35
to
5f7fd4d
Compare
urrsk
force-pushed
the
update_dynamic_properties
branch
from
5f7fd4d
to
789e258
Compare
|
It could be nice if e.g. @VinDp have time to test them in GZ |
There was a problem hiding this comment.
I rebased this locally to rolling and manually tested a ur3, ur3e, ur5, ur5e, ur10, ur10e, ur16e, ur20, ue30 with gz sim. I can confirm that the robot doesn't explode there and moves as expected.
The inertia look a little funny, especially the orientation of the visualizations of the shoulder and wrist1, wrist2. I am not an expert on simulation / dynamics calculation. Does this look correct to you?
Also, please rebase this branch onto the rolling branch and change the PR's base to rolling. It should be a straightforward backport that we can trigger automatically as soon as it is merged to rolling.
Content-wise I only reviewed the ur10, but the comments there should probably be valid for all models. Please also have a look at the masses as we've just been updating them in #187. For example, this PR currently proposes to change the ur20's wrist_3 mass to the value of the ur30. While I am writing this it seems strange to me, that those should be different. Is that information on https://www.universal-robots.com/articles/ur/application-installation/dh-parameters-for-calculations-of-kinematics-and-dynamics/ correct? Looking at the config files on URSim it indeed seems to be the value you used in this PR. One of them is probably wrong.
|
@fmauch Thank you for testing these in Gazebo sim for me. Very appreciated. I'm not sure how to change to rolling. I was just thinking that we could cherry-pick or merge from humble from rolling. Perhaps, you can guide me once everything is reviewed and accepted. |
I tried that locally and I could simply rebase your branch on rolling without any further modifications. As written, we introduce changes on rolling and then backport to all distros where we want to make that change available, in this case all 4 distributions. I'm happy to assist / do the rebase once everything is done (which I guess it is by now, so I'll take another look) |
| y: 0.0 # model.y | ||
| z: -0.0293 # model.z |
There was a problem hiding this comment.
The online documentation says different about this, as well. Your values match the values in URSim, though.
fmauch
force-pushed
the
update_dynamic_properties
branch
from
590f711
to
e9efbdd
Compare
* Remove unused dh_parameters * Rename prop__wrist_2_cog to prop_wrist_2_cog for consistency * Update mass and cog and use full inertia matrix. * Update max_efforts (torque limits) * Remove code and values that are no longer needed. --------- Co-authored-by: Rune Søe-Knudsen <41109954+urrsk@users.noreply.github.com> (cherry picked from commit 60e6974)
* Remove unused dh_parameters * Rename prop__wrist_2_cog to prop_wrist_2_cog for consistency * Update mass and cog and use full inertia matrix. * Update max_efforts (torque limits) * Remove code and values that are no longer needed. --------- Co-authored-by: Rune Søe-Knudsen <41109954+urrsk@users.noreply.github.com> (cherry picked from commit 60e6974)
* Remove unused dh_parameters * Rename prop__wrist_2_cog to prop_wrist_2_cog for consistency * Update mass and cog and use full inertia matrix. * Update max_efforts (torque limits) * Remove code and values that are no longer needed. --------- Co-authored-by: Rune Søe-Knudsen <41109954+urrsk@users.noreply.github.com>
* Remove unused dh_parameters * Rename prop__wrist_2_cog to prop_wrist_2_cog for consistency * Update mass and cog and use full inertia matrix. * Update max_efforts (torque limits) * Remove code and values that are no longer needed. --------- Co-authored-by: Rune Søe-Knudsen <41109954+urrsk@users.noreply.github.com>
Update some dynamic properties of the robots to reflect the most recent values. Note that the inertia matrices of UR3, UR3e, UR5, and UR5e are generated by the cylindrical inertia, since most of the values provided by UR are zeros and could potentially cause simulation to blow up. Those quantities may be updated later when appropriate values are found.