Skip to content
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

joint: should support specifying frames in <child> and <parent> #204

Closed
osrf-migration opened this issue Nov 2, 2018 · 14 comments · Fixed by #304
Closed

joint: should support specifying frames in <child> and <parent> #204

osrf-migration opened this issue Nov 2, 2018 · 14 comments · Fixed by #304
Labels
enhancement New feature or request minor

Comments

@osrf-migration
Copy link

Original report (archived issue) by Eric Cousineau (Bitbucket: eacousineau, GitHub: EricCousineau-TRI).


Summary

At present, the <child> and <parent> elements of <joint> are constrained to be links:
http://sdformat.org/spec?ver=1.6&elem=joint#joint_parent

It would be excellent if the specification permitted using frames. Per #200, if a link creates an implicit frame, then this change will be backwards-compatible at a specification level.

Motivation

When specifying a world in SDF, it would be nice to specify joints with more semantics than just a link and an offset; e.g. if I want to weld a mug to the top of a table, I can specify two frames (completely invariant of the model frames) on the mug and table, and then just weld those two frames together. For a robot with revolute joints, you can embed better semantics when assembling the robot.

I am willing to provide a draft change to the spec, and possibly to the API as well to accommodate this change while considering backwards compatibility.

Describe alternatives you've considered

TTBOMK, the alternative is to use the present state, which is to manually compute the kinematics; while feasible, this is brittle due to numerics. Xacros / ruby templates shouldn't be necessary for conveniently joining things.

Additional context

If this proposal is accepted, I would like to ensure that this feature is implemented in Drake here:
https://drake.mit.edu/doxygen_cxx/namespacedrake_1_1multibody_1_1parsing.html#a3e9bff0197c6c7f86f9ff6f8854def53
https://drake.mit.edu/pydrake/pydrake.multibody.multibody_tree.parsing.html#pydrake.multibody.multibody_tree.parsing.AddModelFromSdfFile
Downstream issue: RobotLocomotion/drake#9910

\cc @nkoenig

@osrf-migration
Copy link
Author

Original comment by Eric Cousineau (Bitbucket: eacousineau, GitHub: EricCousineau-TRI).


  • Edited issue description

1 similar comment
@osrf-migration
Copy link
Author

Original comment by Eric Cousineau (Bitbucket: eacousineau, GitHub: EricCousineau-TRI).


  • Edited issue description

@osrf-migration osrf-migration added minor enhancement New feature or request labels Apr 11, 2020
@scpeters
Copy link
Member

this is part of the current draft of the composition proposal:

@EricCousineau-TRI
Copy link
Collaborator

Suggested route:

  • Make parsing use frames, and resolve to links and poses
  • Keep public API the same (only expose link + relative pose)

@scpeters scpeters added this to the SDFormat 1.8 / libsdformat10 milestone May 22, 2020
@scpeters
Copy link
Member

I have a branch that updates the proposed SDFormat 1.8 parsing stages with this change: gazebosim/sdf_tutorials@add2975

@scpeters
Copy link
Member

I have a branch with a prototype implementation of this change. The kernel of the change is in cf095f3, which modifies how the FrameAttachedToGraph and PoseRelativeToGraph are built. It ensures that all vertices are added to the graph before adding any edges connecting a joint with its child and removes assumptions that joint child must be a link.

@scpeters scpeters changed the title joint: Support specifying frames in <child> and <parent> joint: should support specifying frames in <child> and <parent> Jun 18, 2020
scpeters added a commit to scpeters/sdformat that referenced this issue Jun 18, 2020
Replace checkJointParentChildLinkNames with
checkJointParentChildNames.

Closes gazebosim#204.

Signed-off-by: Steve Peters <[email protected]>
@scpeters
Copy link
Member

I updated the documentation of parsing stages a bit further based on the observation that all vertices need to be added to the graph before adding any joint edges: gazebosim/sdf_tutorials@77b0db1

@scpeters
Copy link
Member

In order to figure out which are actually the parent and child links of a joint now, I think we should add Joint::ResolveParentBody and Joint::ResolveChildBody as analogs of Frame::ResolveAttachedToBody

@EricCousineau-TRI
Copy link
Collaborator

EricCousineau-TRI commented Jun 18, 2020

In order to figure out which are actually the parent and child links of a joint now, I think we should add Joint::ResolveParentBody and Joint::ResolveChildBody as analogs of Frame::ResolveAttachedToBody [...]

I'm actually not sure why this is necessary... Is it just sugar?
Why can't you just do Joint.ResolveParentFrame().ResolveAttachedToBody()?

@scpeters
Copy link
Member

In order to figure out which are actually the parent and child links of a joint now, I think we should add Joint::ResolveParentBody and Joint::ResolveChildBody as analogs of Frame::ResolveAttachedToBody [...]

I'm actually not sure why this is necessary... Is it just sugar?
Why can't you just do Joint.ResolveParentFrame().ResolveAttachedToBody()?

only the Frame class has a ResolveAttachedToBody method, so I'm not sure how this would work. We aren't using inheritance for the Link, Joint, and Frame classes, so what kind of object would be returned from Joint.ResolveParentFrame()?

perhaps we should consider another class like SemanticPose that provides the interface to resolving FrameAttachedToGraph queries?

@scpeters
Copy link
Member

perhaps we should consider another class like SemanticPose that provides the interface to resolving FrameAttachedToGraph queries?

it looks like this discussion is being addressed in gazebosim/sdf_tutorials#3

@EricCousineau-TRI
Copy link
Collaborator

EricCousineau-TRI commented Jun 18, 2020

Per VC, we stick to philosophy that SemanticPose is a temporary view into an immutable graph, we can just pass it attached_to at construction time.

Will post about different resolution for gazebosim/sdf_tutorials#3 in that thread

@EricCousineau-TRI
Copy link
Collaborator

EricCousineau-TRI commented Jun 18, 2020

From @azeey: Should aim towards using Link, not Body; e.g. ResolveAttachedToBody.

From @scpeters: Reason is that the attached_to can be either a link, sibling model, or "world".
So "body" is an attempt to generalize...
Should resolve to endpoint / grounded frame.

Still need to resolve terminology.

scpeters added a commit to scpeters/sdformat that referenced this issue Jun 23, 2020
The `//joint/child` and `//joint/parent` elements now accept any
valid frame name instead of only link names.
The migration guide is updated as well.

Closes gazebosim#204.

Signed-off-by: Steve Peters <[email protected]>
scpeters added a commit to scpeters/sdformat that referenced this issue Jun 24, 2020
@scpeters
Copy link
Member

after discussing today with @azeey, we reached consensus on Joint::ResolveChildLink and Joint::ResolveParentLink, and I've incorporated this into #304. I closed the draft PR #300 because the deprecations were too noisy for a PR adding functionality. We can rename the API's in a follow-up PR.

scpeters added a commit to scpeters/sdformat that referenced this issue Jul 2, 2020
The `//joint/child` and `//joint/parent` elements now accept any
valid frame name instead of only link names.
The migration guide is updated as well.

Closes gazebosim#204.

Signed-off-by: Steve Peters <[email protected]>
scpeters added a commit to scpeters/sdformat that referenced this issue Jul 2, 2020
scpeters added a commit that referenced this issue Jul 16, 2020
The `//joint/child` and `//joint/parent` elements now accept any
valid frame name instead of only link names.

Closes #204.

* Add sdf test models
* parser: update joint check function, add tests
* FrameSemantics: joint parent/child as frames

buildFrameAttachedToGraph: don't create edges from joint to child
until all joint and frame vertices are added, in case the child
is not a link.

buildPoseRelativeToGraph: if //joint/pose/@relative_to is not
specified, don't create edges from joint to child until all joint
and frame vertices are added to the graph, in case the child is
not a link.

* Joint: add ResolveChildLink, ResolveParentLink

These methods use the FrameAttachedToGraph to resolve the name
of the parent and child links of a joint, similar to
Frame::ResolveAttachedToBody.

Return early from ResolveParentLink if "world" is specified
as a joint's parent frame, since "world" is not in a Model's
FrameAttachedToGraph.

* Check that resolved parent and child frames differ

Add test world in which a joint's child frame resolves to the
same value as the parent, which is invalid.
Check for this case in `ign sdf --check`.

Signed-off-by: Steve Peters <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request minor
Projects
None yet
3 participants