-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to SDFormat10 #48
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to resolve the joint representation issue first, as discussed.
Cool! I am just glad we have an upgrade in place so the next steps should be pretty straightforward. 🙂 PS also gave me a chance to really understand the SDFormat API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the readme file on the installation of sdformat should also be updated for sdformat9
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested it and it works. Note that the installation for sdformat9 no longer requires brew. You can simply install it with:
sudo apt-get install libsdformat9-dev
Sorry, but no, we should hold off on this. We discussed this in GTDynamics meeting on Monday. |
I think Mac users still require Brew to install SDFormat (osx's apt-get equivalent is Homebrew). |
Homebrew is available for Mac and Linux so using brew should be the default. I also hate how apt-get doesn't give you the choice of version: if only sdformat8 is configured as available, you can't switch to sdformat9 without compiling from source or adding some random PPA which ruins the whole point of apt. |
Yeah that's the main reason I chose SDFormat 8 and not 9 when implementing UniversalRobot v.1. with Yetong. Installing SDFormat 9 on Linux is very tedious, but easier with Brew. |
I just tested out loading a URDF with mesh info (e.g. |
@dellaert can we merge this in soon? I know we discussed making the joint and link representations follow SDFormat better, but that is currently a tangential issue since we can upgrade SDFormat and then later continue on that. Merging this PR doesn't break anything, and since there's no movement happening on the representation update, this PR is sitting in limbo for almost half a year. Currently, this is blocking the CI since |
@dellaert I looked at the changes of this PR and the changes are consistent with the correct understanding of link and joint coordinate frames. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ask for a review again after changes :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Getting there.
|
||
// Get the pose of the joint in the parent or child link's frame depending on | ||
// the value of `frame_name`. | ||
Pose3 lTj = Pose3FromIgnition(sdf_joint.RawPose()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But, it's not lTj. We don't know that yet... Re-read my comments? :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The SDF spec mentions that all joint raw poses are with respect to the parent (or in some cases, the child) link's frame. This depends on what relative_to
is set to for the joint. Here are the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand. So whether it is lTj
is not known yet, hence my comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it is known. It's known from the definition of the SDF file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just need this last one resolved. Should I rename it to raw_pose
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approve module those 3 comments
|
||
// Get the pose of the joint in the parent or child link's frame depending on | ||
// the value of `frame_name`. | ||
Pose3 lTj = Pose3FromIgnition(sdf_joint.RawPose()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand. So whether it is lTj
is not known yet, hence my comment.
Merging this. @dellaert we can discuss the last comment on |
This PR upgrades from the deprecated SDFormat8 to SDFormat9. Closes #36 and #26.
This upgrade had a bunch of breaking changes, but upgrading to SDFormat10 should not have any hassle.
I haven't used SDFormat10 since the docs still seem to be inSDFormat10 has an official release.dev
mode rather than a final release.