Move construction of PoseRelativeToGraph and FrameAttachedToGraph to sdf::Root

[azeey]

This builds on top of gazebosim#381 and simplifies the creation of PoseRelativeTo and FrameAttachedTo graphs by moving them to one place instead of being in sdf::World and sdf::Model. It also simplifies the logic of determining if a model is a standalone model that needs its own graph or a nested model that adds to an existing graph.

This PR also changes the pointer held by ScopedGraph from a std::weak_ptr to a std::shared_ptr. This means that a DOM object, such as sdf::Model, can have its poses resolved even if the containing sdf::Root or sdf::World has gone out of scope.

A couple more notes:

• When copying any DOM object with the exception of sdf::Root, there is no need to call SetPoseRelativeToGraph or SetFrameAttachedToGraphon child elements because the copy constructors of those child elements copy the ScopedGraph from the corresponding child element from the copied-from object. Since a new graph is never created, the child elements should be pointing to the graph of the copied-from object when their copy constructor is finished.

• When copying from sdf::Root, we have to decide whether we want a deep copy of the graph or not. If we do a shallow copy, the constructor that simply copies the dataPtr is sufficient. Otherwise, we have to allocate new memory, make a copy of the graph and call SetPoseRelativeToGraph and SetFrameAttachedToGraph on all child elements of sdf::Root.

---

This change is 

[azeey]

/cc @scpeters, @EricCousineau-TRI

[EricCousineau-TRI]

at the high-level, with some follow-up questions

Reviewed 8 of 8 files at r1.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @azeey)

---

src/Root.cc, line 120 at r1 (raw file):

  : dataPtr(new RootPrivate(*_root.dataPtr))
{
  // TODO(addisu) Do we need to make deep copies of the graphs?

Er, when does this copy constructor get called in the first place?
And does it expect deep or shallow copies in those contexts?

My gut says, yeah, this seems like it should be a deep copy, if the original object can be mutated, and thus violate any invariants / synchronization.

However, that seems like more effort than it's worth.

So to really ask the question:
Who really needs the copy constructor?
Can we just get rid of the copy constructor / copy assignment, and just rely instead on move assignments and unique_ptr / shared_ptr?

---

src/World.cc, line 624 at r1 (raw file):

  for (auto &light : this->dataPtr->lights)
  {
    light.SetXmlParentName("world");

nit This has a funny smell to it.

Can you justify this choice?

[codecov-io]

Codecov Report

Merging #1 into drill_down will increase coverage by 0.13%.
The diff coverage is 94.66%.

@@              Coverage Diff               @@
##           drill_down       #1      +/-   ##
==============================================
+ Coverage       87.59%   87.72%   +0.13%     
==============================================
  Files              61       61              
  Lines            9502     9467      -35     
==============================================
- Hits             8323     8305      -18     
+ Misses           1179     1162      -17     

Impacted Files	Coverage Δ
src/Model.cc	89.56% <ø> (+3.20%)	⬆️
src/Root.cc	94.30% <91.11%> (-1.35%)	⬇️
src/ScopedGraph.hh	98.76% <100.00%> (-0.06%)	⬇️
src/World.cc	96.26% <100.00%> (+1.58%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f4def9c...75f4b12. Read the comment docs.

[azeey]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @EricCousineau-TRI)

---

src/Root.cc, line 120 at r1 (raw file):

Previously, EricCousineau-TRI (Eric Cousineau) wrote…

Er, when does this copy constructor get called in the first place?
And does it expect deep or shallow copies in those contexts?

My gut says, yeah, this seems like it should be a deep copy, if the original object can be mutated, and thus violate any invariants / synchronization.

However, that seems like more effort than it's worth.

So to really ask the question:
Who really needs the copy constructor?
Can we just get rid of the copy constructor / copy assignment, and just rely instead on move assignments and unique_ptr / shared_ptr?

Since there is no public API to mutate the graphs, a shallow copy would be okay. That's what I'm doing in this PR for sdf::World and sdf::Model. But if we want to allow mutation of the graph down the road, a deep copy would be needed. In that case it should happen in sdf::Root only since this is now equivalent to the __root__ vertex in the graph. Making a copy of a sub-graph , eg. in sdf::Model, might be too complicated.

I haven't seen the copy constructor for sdf::Root used anywhere yet so I would be okay with explicitly deleting the copy constructor. However, I think it would be the only DOM object without one, so it will be a departure from our pattern.

---

src/World.cc, line 624 at r1 (raw file):

Previously, EricCousineau-TRI (Eric Cousineau) wrote…

nit This has a funny smell to it.

Can you justify this choice?

This is nothing new. It was taken from https://github.com/osrf/sdformat/blob/144f82cf8b994abd2a566a7bbe6ae873a9d92403/src/World.cc#L166. sdf::Light can exist both as //world/light and //link/light (https://github.com/osrf/sdformat/blob/144f82cf8b994abd2a566a7bbe6ae873a9d92403/src/Link.cc#L390), so it needs to know what it should resolve to in the absence of a resolveTo argument.

[scpeters]

Reviewed 8 of 8 files at r1.
Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @azeey and @EricCousineau-TRI)

---

src/Root.cc, line 94 at r1 (raw file):

/////////////////////////////////////////////////
template <typename T>
ScopedGraph<PoseRelativeToGraph> addPoseRealtiveToGraph(

change Realtive to Relative in function name

---

src/Root_TEST.cc, line 289 at r1 (raw file):

    root2 = root1;
    testFrame1(root1);
    testFrame1(root2);

nit: you could test both before the copy:

testFrame1(root1);
testFrame2(root2);

// root1 is copied into root2 via the assignment operator
root2 = root1;
testFrame1(root2);

---

src/Root_TEST.cc, line 312 at r1 (raw file):

    // root1 is moved into root2 via the move assignment operator.
    root2 = std::move(root1);
    testFrame1(root2);

nit: you could test both before the move:

testFrame1(root1);
testFrame2(root2);

// root1 is moved into root2 via the move assignment operator.
root2 = std::move(root1);
testFrame1(root2);

[azeey]

Reviewable status: 3 of 8 files reviewed, 3 unresolved discussions (waiting on @EricCousineau-TRI and @scpeters)

---

src/Root.cc, line 94 at r1 (raw file):

Previously, scpeters (Steve Peters) wrote…

change Realtive to Relative in function name

Done 4997432.

---

src/Root_TEST.cc, line 289 at r1 (raw file):

Previously, scpeters (Steve Peters) wrote…

nit: you could test both before the copy:

testFrame1(root1);
testFrame2(root2);

// root1 is copied into root2 via the assignment operator
root2 = root1;
testFrame1(root2);

Done in 033cada

---

src/Root_TEST.cc, line 312 at r1 (raw file):

Previously, scpeters (Steve Peters) wrote…

nit: you could test both before the move:

testFrame1(root1);
testFrame2(root2);

// root1 is moved into root2 via the move assignment operator.
root2 = std::move(root1);
testFrame1(root2);

Done in 033cada.

[EricCousineau-TRI]

Reviewed 5 of 5 files at r2.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @azeey and @scpeters)

---

src/Root.cc, line 120 at r1 (raw file):

Previously, azeey (Addisu Z. Taddese) wrote…

Since there is no public API to mutate the graphs, a shallow copy would be okay. That's what I'm doing in this PR for sdf::World and sdf::Model. But if we want to allow mutation of the graph down the road, a deep copy would be needed. In that case it should happen in sdf::Root only since this is now equivalent to the __root__ vertex in the graph. Making a copy of a sub-graph , eg. in sdf::Model, might be too complicated.

I haven't seen the copy constructor for sdf::Root used anywhere yet so I would be okay with explicitly deleting the copy constructor. However, I think it would be the only DOM object without one, so it will be a departure from our pattern.

I think it's a pretty unique DOM object, so I'm A-OK with departing from that for now.

Can you delete the copy ctor?

---

src/World.cc, line 624 at r1 (raw file):

Previously, azeey (Addisu Z. Taddese) wrote…

This is nothing new. It was taken from https://github.com/osrf/sdformat/blob/144f82cf8b994abd2a566a7bbe6ae873a9d92403/src/World.cc#L166. sdf::Light can exist both as //world/light and //link/light (https://github.com/osrf/sdformat/blob/144f82cf8b994abd2a566a7bbe6ae873a9d92403/src/Link.cc#L390), so it needs to know what it should resolve to in the absence of a resolveTo argument.

Hm... I guess that validates by means of precedent. But it still feels dirty.

Can there be some "lightly" actionable takeaway, like a TODO or an issue?

[scpeters]

Reviewed 5 of 5 files at r2.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @azeey and @EricCousineau-TRI)

---

src/World.cc, line 624 at r1 (raw file):

Previously, EricCousineau-TRI (Eric Cousineau) wrote…

Hm... I guess that validates by means of precedent. But it still feels dirty.

Can there be some "lightly" actionable takeaway, like a TODO or an issue?

it's the same thing we do for all DOM objects that provide a SemanticPose() API but aren't frames in the graph (see Link::SetPoseRelativeToGraph which calls SetXmlParentName on Collision, Light, Sensor, and Visual)

it doesn't "smell" to me, so you may have to suggest some wording for the TODO / issue because I'm not sure what I would write

[azeey]

Reviewable status: 5 of 8 files reviewed, 2 unresolved discussions (waiting on @azeey, @EricCousineau-TRI, and @scpeters)

---

src/Root.cc, line 120 at r1 (raw file):

Previously, EricCousineau-TRI (Eric Cousineau) wrote…

I think it's a pretty unique DOM object, so I'm A-OK with departing from that for now.

Can you delete the copy ctor?

Done in d5e405a.

[scpeters]

Reviewed 3 of 3 files at r3.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @azeey and @EricCousineau-TRI)

[EricCousineau-TRI]

Reviewed 2 of 3 files at r3, 3 of 3 files at r4.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @azeey)

---

src/World.cc, line 624 at r1 (raw file):

Previously, scpeters (Steve Peters) wrote…

it's the same thing we do for all DOM objects that provide a SemanticPose() API but aren't frames in the graph (see Link::SetPoseRelativeToGraph which calls SetXmlParentName on Collision, Light, Sensor, and Visual)

it doesn't "smell" to me, so you may have to suggest some wording for the TODO / issue because I'm not sure what I would write

OK I only have a high-level comment atm, which is "see what's necessary to avoid awkward plumbing.", but I'm fine with it not being encoded as a TODO just yet.

Thanks!

[scpeters]

Reviewed 3 of 3 files at r4.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @azeey)