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

osrf-migration · 2018-11-02T15:15:37Z

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

The text was updated successfully, but these errors were encountered:

osrf-migration · 2018-11-02T15:17:23Z

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

Edited issue description

osrf-migration · 2018-11-02T15:17:51Z

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

Edited issue description

scpeters · 2020-05-18T23:28:24Z

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

section 1.2.2: http://sdformat.org/tutorials?tut=composition_proposal&cat=pose_semantics_docs&#1-2-interface-elements

EricCousineau-TRI · 2020-05-21T19:11:09Z

Suggested route:

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

scpeters · 2020-06-17T01:46:33Z

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

scpeters · 2020-06-18T07:30:47Z

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.

Replace checkJointParentChildLinkNames with checkJointParentChildNames. Closes gazebosim#204. Signed-off-by: Steve Peters <[email protected]>

scpeters · 2020-06-18T07:50:23Z

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 · 2020-06-18T07:53:38Z

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 · 2020-06-18T17:35:53Z

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 · 2020-06-18T17:48:07Z

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 · 2020-06-18T18:14:46Z

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 · 2020-06-18T18:48:45Z

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 · 2020-06-18T18:52:24Z

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.

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]>

Signed-off-by: Steve Peters <[email protected]>

scpeters · 2020-06-24T02:31:26Z

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.

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]>

Signed-off-by: Steve Peters <[email protected]>

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]>

osrf-migration added minor enhancement New feature or request labels Apr 11, 2020

EricCousineau-TRI mentioned this issue May 19, 2020

[epic] proposal: Should provide better composition behavior #278

Closed

17 tasks

scpeters added this to the SDFormat 1.8 / libsdformat10 milestone May 22, 2020

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

parser.hh: deprecate function *ChildLinkNames

3921bc8

Replace checkJointParentChildLinkNames with checkJointParentChildNames. Closes gazebosim#204. Signed-off-by: Steve Peters <[email protected]>

scpeters mentioned this issue Jun 18, 2020

sdf 1.8: support specifying frames as joint child/parent #300

Closed

scpeters mentioned this issue Jun 24, 2020

sdf 1.8: support specifying frames as joint child/parent #304

Merged

scpeters added a commit to scpeters/sdformat that referenced this issue Jun 24, 2020

Migration guide: add link to gazebosim#204

4fd00c7

Signed-off-by: Steve Peters <[email protected]>

scpeters added a commit to scpeters/sdformat that referenced this issue Jul 2, 2020

Migration guide: add link to gazebosim#204

977f33d

Signed-off-by: Steve Peters <[email protected]>

scpeters closed this as completed in #304 Jul 16, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

osrf-migration commented Nov 2, 2018

osrf-migration commented Nov 2, 2018

osrf-migration commented Nov 2, 2018

scpeters commented May 18, 2020

EricCousineau-TRI commented May 21, 2020

scpeters commented Jun 17, 2020

scpeters commented Jun 18, 2020

scpeters commented Jun 18, 2020

scpeters commented Jun 18, 2020

EricCousineau-TRI commented Jun 18, 2020 •

edited

Loading

scpeters commented Jun 18, 2020

scpeters commented Jun 18, 2020

EricCousineau-TRI commented Jun 18, 2020 •

edited

Loading

EricCousineau-TRI commented Jun 18, 2020 •

edited

Loading

scpeters commented Jun 24, 2020

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

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

Comments

osrf-migration commented Nov 2, 2018

Summary

Motivation

Describe alternatives you've considered

Additional context

osrf-migration commented Nov 2, 2018

osrf-migration commented Nov 2, 2018

scpeters commented May 18, 2020

EricCousineau-TRI commented May 21, 2020

scpeters commented Jun 17, 2020

scpeters commented Jun 18, 2020

scpeters commented Jun 18, 2020

scpeters commented Jun 18, 2020

EricCousineau-TRI commented Jun 18, 2020 • edited Loading

scpeters commented Jun 18, 2020

scpeters commented Jun 18, 2020

EricCousineau-TRI commented Jun 18, 2020 • edited Loading

EricCousineau-TRI commented Jun 18, 2020 • edited Loading

scpeters commented Jun 24, 2020

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

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

EricCousineau-TRI commented Jun 18, 2020 •

edited

Loading

EricCousineau-TRI commented Jun 18, 2020 •

edited

Loading

EricCousineau-TRI commented Jun 18, 2020 •

edited

Loading