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

Pulled out the changes to rigid body, rigid body system, and rigid body tree from PR #2253. #2303

Merged

Conversation

liangfok
Copy link
Contributor

@liangfok liangfok commented May 10, 2016

This PR is a subset of PR #2253, which only contains the changes to RigidBody, RigidBodyTree, and RigidBodySystem.

Closes #2315

@jwnimmer-tri: can you serve as both feature and platform reviewer?


This change is Reviewable   Multiple assignees: @amcastro-tri amcastro-tri, @jwnimmer-tri jwnimmer-tri

@sammy-tri
Copy link
Contributor

Review status: 0 of 5 files reviewed at latest revision, 1 unresolved discussion.


drake/systems/plants/RigidBody.cpp, line 33 [r1] (raw file):

    return (*joint);
  } else {
    if (linkname == "world")

(Sorry to jump into a random review...)

It looks like "world" is used frequently as a magic constant in RigidBody_. Would it be safer to define this as a const char_ kConstant somewhere so that the compiler can check for potential misspellings or other errors? (as this pattern was not introduced in this PR, I have no objection to merging it without fixing this)


Comments from Reviewable

@liangfok
Copy link
Contributor Author

Review status: 0 of 5 files reviewed at latest revision, 1 unresolved discussion.


drake/systems/plants/RigidBody.cpp, line 33 [r1] (raw file):

Previously, sammy-tri wrote…

(Sorry to jump into a random review...)

It looks like "world" is used frequently as a magic constant in RigidBody_. Would it be safer to define this as a const char_ kConstant somewhere so that the compiler can check for potential misspellings or other errors? (as this pattern was not introduced in this PR, I have no objection to merging it without fixing this)


Good point. Yes, let's make it a constant. I shall make the change.


Comments from Reviewable

@sherm1
Copy link
Member

sherm1 commented May 10, 2016

How about @amcastro-tri for feature review since he is familiar with this code?

Previously, liangfok (Chien-Liang Fok) wrote…

Pulled out the changes to rigid body, rigid body system, and rigid body tree from PR #2253.

This PR is a subset of PR #2253, which only contains the changes to RigidBody, RigidBodyTree, and RigidBodySystem.

@jwnimmer-tri: can you serve as both feature and platform reviewer?


Review status: 0 of 5 files reviewed at latest revision, 2 unresolved discussions.


drake/systems/plants/RigidBodyTree.cpp, line 152 [r1] (raw file):

  }

  // Counts the number of position and velocitie there are in this rigid body

typo


Comments from Reviewable

@liangfok
Copy link
Contributor Author

Good idea.

+@amcastro-tri can you be a feature reviewer?

Previously, sherm1 (Michael Sherman) wrote…

How about @amcastro-tri for feature review since he is familiar with this code?


Review status: 0 of 5 files reviewed at latest revision, 1 unresolved discussion.


Comments from Reviewable

@jwnimmer-tri
Copy link
Collaborator

Reviewed 5 of 5 files at r1.
Review status: all files reviewed at latest revision, 13 unresolved discussions.


drake/systems/plants/RigidBody.cpp, line 36 [r1] (raw file):

      throw runtime_error(
          "ERROR: Attempted to get the world link's joint. "
          "The world link does not have a joint!");

Multi-line conditional statement requires braces per cppguide.


drake/systems/plants/RigidBody.cpp, line 39 [r1] (raw file):

    else
      throw runtime_error("Joint of link " + linkname + " in model " +
                          model_name + " is not initialized");

Multi-line conditional statement requires braces per cppguide.


drake/systems/plants/RigidBody.h, line 22 [r1] (raw file):

  RigidBody();

  const std::string& GetName() const;

Missing doxygen.


drake/systems/plants/RigidBody.h, line 22 [r1] (raw file):

  RigidBody();

  const std::string& GetName() const;

Missing #include <string>.


drake/systems/plants/RigidBody.h, line 24 [r1] (raw file):

  const std::string& GetName() const;

  const std::string& GetModelName() const;

Missing doxygen.


drake/systems/plants/RigidBodySystem.cpp, line 592 [r1] (raw file):

bool RigidBodyDepthSensor::is_vertical_scanner() const {
  return min_pitch != 0 || max_pitch != 0;

Isn't there an invariant that ((min_pitch != 0) || (max_pitch != 0)) == (num_pixel_rows != 0) that this assumes, but isn't checked anywhere (including the constructor)?


drake/systems/plants/RigidBodySystem.cpp, line 596 [r1] (raw file):

bool RigidBodyDepthSensor::is_horizontal_scanner() const {
  return min_yaw != 0 || max_yaw != 0;

Isn't there an invariant that ((min_yaw != 0) || (max_yaw != 0)) == (num_pixel_cols != 0) that this assumes, but isn't checked anywhere (including the constructor)?


drake/systems/plants/RigidBodySystem.cpp, line 831 [r1] (raw file):

}

}  // namespace Drake

Missing newline at end of file.


drake/systems/plants/RigidBodySystem.h, line 198 [r1] (raw file):

   * Returns the number of joint states in this rigid body system. This includes
   * joint position and velocity values.
   */

This API doc mostly just repeats the content from the System concept that it is implementing. Citing the concept API would be a better approach (using doxygen block comments is one approach). Repeating the documentation of an "overridden" method is brittle.

The only clarification this particular comment adds is that RBS's state is both position and velocity values, which would be better documented a class overview (for example), and cited here with a // comment if needed.


drake/systems/plants/RigidBodySystem.h, line 203 [r1] (raw file):

  /**
   * Returns the total number of inputs to this rigid body system.
   */

This API doc directly repeats the content from the System concept that it is implementing. Citing the concept API would be a better approach (using doxygen block comments is one approach). Repeating the documentation of an "overridden" method is brittle.


drake/systems/plants/RigidBodySystem.h, line 209 [r1] (raw file):

   * Returns the total number of outputs of this rigid body system. This
   * includes both the number of joint states and the number of sensor states.
   */

This API doc mostly just repeats the content from the System concept that it is implementing. Citing the concept API would be a better approach (using doxygen block comments is one approach). Repeating the documentation of an "overridden" method is brittle.

The only clarification this particular comment adds is that RBS's output also includes sensor values, which would be better documented a class overview (for example), and cited here with a // comment if needed.


drake/systems/plants/RigidBodySystem.h, line 256 [r1] (raw file):

   * system.
   */
  const std::vector<std::shared_ptr<RigidBodySensor>>& GetSensors() const;

This return type exposes non-const RigidBodySensor objects that callers can thus modify, and allows callers to increment the sensors' reference counts. A better return type would be std::vector<const RigidBodySensor*> though other solutions are possible.


drake/systems/plants/RigidBodySystem.h, line 484 [r1] (raw file):

  size_t getNumOutputs() const override;

  virtual size_t get_num_pixel_rows() const;

Missing doxygen (for all of these methods).

Perhaps the implementation comments on their meaning just need to be relocated here?


Comments from Reviewable

@jwnimmer-tri
Copy link
Collaborator

Review status: all files reviewed at latest revision, 18 unresolved discussions, some commit checks failed.


drake/systems/plants/RigidBodySystem.cpp, line 527 [r1] (raw file):

  cacheRaycastEndpoints();
}

I am not super-well spun up on RBS, but does this method have good enough unit test coverage? (It relates to the new getters that this PR adds.)


drake/systems/plants/RigidBodySystem.cpp, line 592 [r1] (raw file):

bool RigidBodyDepthSensor::is_vertical_scanner() const {
  return min_pitch != 0 || max_pitch != 0;

I am not super-well spun up on RBS, but does this method have good enough unit test coverage?


drake/systems/plants/RigidBodySystem.cpp, line 596 [r1] (raw file):

bool RigidBodyDepthSensor::is_horizontal_scanner() const {
  return min_yaw != 0 || max_yaw != 0;

I am not super-well spun up on RBS, but does this method have good enough unit test coverage?


drake/systems/plants/RigidBodySystem.cpp, line 658 [r1] (raw file):

        joint_name + ".");
  }
}

I am not super-well spun up on RBS, but does this method have good enough unit test coverage?


Comments from Reviewable

@liangfok
Copy link
Contributor Author

I've addressed all comments from previous round of review. PTAL.

Previously, liangfok (Chien-Liang Fok) wrote…

Good idea.

+@amcastro-tri can you be a feature reviewer?


Review status: 0 of 11 files reviewed at latest revision, 19 unresolved discussions.


drake/systems/plants/RigidBody.cpp, line 33 [r1] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

Good point. Yes, let's make it a constant. I shall make the change.


Done.


drake/systems/plants/RigidBody.cpp, line 36 [r1] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Multi-line conditional statement requires braces per cppguide.


Fixed.


drake/systems/plants/RigidBody.cpp, line 39 [r1] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Multi-line conditional statement requires braces per cppguide.


Fixed.


drake/systems/plants/RigidBody.h, line 22 [r1] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Missing doxygen.


Done.


drake/systems/plants/RigidBody.h, line 22 [r1] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Missing #include <string>.


Done.


drake/systems/plants/RigidBody.h, line 24 [r1] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Missing doxygen.


Done.


drake/systems/plants/RigidBodySystem.cpp, line 527 [r1] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

I am not super-well spun up on RBS, but does this method have good enough unit test coverage? (It relates to the new getters that this PR adds.)


I believe this method is covered by the following unit test:

[drake-distro]/drake/systems/plants/test/lidarTest.cpp
``

---

*[drake/systems/plants/RigidBodySystem.cpp, line 592 \[r1\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2303#-KHQLORkHOUCJp4zkbfe:-KHQrdonx_hpgAEucalj:-1225064676) ([raw file](https://github.com/robotlocomotion/drake/blob/2e588a6a6200c33f7c50c6f2a86827f8cef01baf/drake/systems/plants/RigidBodySystem.cpp#L592)):*
<details><summary><i>Previously, jwnimmer-tri (Jeremy Nimmer) wrote…</i></summary>
> Isn't there an invariant that `((min_pitch != 0) || (max_pitch != 0)) == (num_pixel_rows != 0)` that this assumes, but isn't checked anywhere (including the constructor)?</details>
I think you're right, but this class is about to be generalized to support 3D point cloud sensors like that provided by the Microsoft Kinect, so I would punt on adding this check.

For more details, see:
https://github.com/RobotLocomotion/drake/issues/2208

---

*[drake/systems/plants/RigidBodySystem.cpp, line 592 \[r1\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2303#-KHQi_KoG_F8Q_HxJW5e:-KHQrvbOXgrl5Ra7Y_kF:820110012) ([raw file](https://github.com/robotlocomotion/drake/blob/2e588a6a6200c33f7c50c6f2a86827f8cef01baf/drake/systems/plants/RigidBodySystem.cpp#L592)):*
<details><summary><i>Previously, jwnimmer-tri (Jeremy Nimmer) wrote…</i></summary>
> I am not super-well spun up on RBS, but does this method have good enough unit test coverage?</details>
I believe this method is covered by the following unit test:

[drake-distro]/drake/systems/plants/test/lidarTest.cpp
``


drake/systems/plants/RigidBodySystem.cpp, line 596 [r1] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Isn't there an invariant that ((min_yaw != 0) || (max_yaw != 0)) == (num_pixel_cols != 0) that this assumes, but isn't checked anywhere (including the constructor)?


I think you're right, but this class is about to be generalized to support 3D point cloud sensors like that provided by the Microsoft Kinect, so I would punt on adding this check.

For more details, see:
#2208


drake/systems/plants/RigidBodySystem.cpp, line 596 [r1] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

I am not super-well spun up on RBS, but does this method have good enough unit test coverage?


I believe this method is covered by the following unit test:

[drake-distro]/drake/systems/plants/test/lidarTest.cpp
``

---

*[drake/systems/plants/RigidBodySystem.cpp, line 658 \[r1\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2303#-KHQilXnmXHjmdXRX77G:-KHQs224U5gCn5uOTXIk:177817796) ([raw file](https://github.com/robotlocomotion/drake/blob/2e588a6a6200c33f7c50c6f2a86827f8cef01baf/drake/systems/plants/RigidBodySystem.cpp#L658)):*
<details><summary><i>Previously, jwnimmer-tri (Jeremy Nimmer) wrote…</i></summary>
> I am not super-well spun up on RBS, but does this method have good enough unit test coverage?</details>
I believe this is covered by the `compareRigidBody` unit tests. See:

[drake distro]/drake/systems/plants/test/CMakeLists.txt


---

*[drake/systems/plants/RigidBodySystem.cpp, line 831 \[r1\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2303#-KHQK00QRTlmG0slDfhL:-KHQsKb8qFNSyWBuH1po:1758359711) ([raw file](https://github.com/robotlocomotion/drake/blob/2e588a6a6200c33f7c50c6f2a86827f8cef01baf/drake/systems/plants/RigidBodySystem.cpp#L831)):*
<details><summary><i>Previously, jwnimmer-tri (Jeremy Nimmer) wrote…</i></summary>
> Missing newline at end of file.
> </details>
Fixed.

---

*[drake/systems/plants/RigidBodySystem.h, line 198 \[r1\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2303#-KHQI2mABcFBG3XZsoPv:-KHQt-vveLpoGC7m1otU:-499146009) ([raw file](https://github.com/robotlocomotion/drake/blob/2e588a6a6200c33f7c50c6f2a86827f8cef01baf/drake/systems/plants/RigidBodySystem.h#L198)):*
<details><summary><i>Previously, jwnimmer-tri (Jeremy Nimmer) wrote…</i></summary>
> This API doc mostly just repeats the content from the System concept that it is implementing.  Citing the concept API would be a better approach (using doxygen block comments is one approach).  Repeating the documentation of an "overridden" method is brittle.
> 
> The only clarification this particular comment adds is that RBS's state is both position and velocity values, which would be better documented a class overview (for example), and cited here with a `//` comment if needed.</details>
Done.

---

*[drake/systems/plants/RigidBodySystem.h, line 203 \[r1\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2303#-KHQHnox78Pws7KN2N9a:-KHQt3RARjD5sQg-cAJ9:-499146009) ([raw file](https://github.com/robotlocomotion/drake/blob/2e588a6a6200c33f7c50c6f2a86827f8cef01baf/drake/systems/plants/RigidBodySystem.h#L203)):*
<details><summary><i>Previously, jwnimmer-tri (Jeremy Nimmer) wrote…</i></summary>
> This API doc directly repeats the content from the System concept that it is implementing.  Citing the concept API would be a better approach (using doxygen block comments is one approach).  Repeating the documentation of an "overridden" method is brittle.</details>
Done.

---

*[drake/systems/plants/RigidBodySystem.h, line 209 \[r1\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2303#-KHQIU4d-BIeEp2TOd5T:-KHQtZNdqBBpVhcKzGCV:-499146009) ([raw file](https://github.com/robotlocomotion/drake/blob/2e588a6a6200c33f7c50c6f2a86827f8cef01baf/drake/systems/plants/RigidBodySystem.h#L209)):*
<details><summary><i>Previously, jwnimmer-tri (Jeremy Nimmer) wrote…</i></summary>
> This API doc mostly just repeats the content from the System concept that it is implementing.  Citing the concept API would be a better approach (using doxygen block comments is one approach).  Repeating the documentation of an "overridden" method is brittle.
> 
> The only clarification this particular comment adds is that RBS's output also includes sensor values, which would be better documented a class overview (for example), and cited here with a `//` comment if needed.</details>
Done.

---

*[drake/systems/plants/RigidBodySystem.h, line 256 \[r1\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2303#-KHQIsiB_4c3v1GQ9Heg:-KHQxT_D6xnASj-JSTmB:-499146009) ([raw file](https://github.com/robotlocomotion/drake/blob/2e588a6a6200c33f7c50c6f2a86827f8cef01baf/drake/systems/plants/RigidBodySystem.h#L256)):*
<details><summary><i>Previously, jwnimmer-tri (Jeremy Nimmer) wrote…</i></summary>
> This return type exposes non-const `RigidBodySensor` objects that callers can thus modify, and allows callers to increment the sensors' reference counts.  A better return type would be `std::vector<const RigidBodySensor*>` though other solutions are possible.</details>
Done.

---

*[drake/systems/plants/RigidBodySystem.h, line 484 \[r1\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2303#-KHQK_2yDgvXheaEVmZK:-KHQxMinzEsE6dKUlGX9:-499146009) ([raw file](https://github.com/robotlocomotion/drake/blob/2e588a6a6200c33f7c50c6f2a86827f8cef01baf/drake/systems/plants/RigidBodySystem.h#L484)):*
<details><summary><i>Previously, jwnimmer-tri (Jeremy Nimmer) wrote…</i></summary>
> Missing doxygen (for all of these methods).
> 
> Perhaps the implementation comments on their meaning just need to be relocated here?</details>
Done.

---

*[drake/systems/plants/RigidBodyTree.cpp, line 152 \[r1\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2303#-KHQBz1gMUfEJEHBg28S:-KHQxt_1x6yDEhvs-tOw:-499146009) ([raw file](https://github.com/robotlocomotion/drake/blob/2e588a6a6200c33f7c50c6f2a86827f8cef01baf/drake/systems/plants/RigidBodyTree.cpp#L152)):*
<details><summary><i>Previously, sherm1 (Michael Sherman) wrote…</i></summary>
> typo</details>
Done.

---


*Comments from [Reviewable](https://reviewable.io:443/reviews/robotlocomotion/drake/2303#-:-KHQxVjJ_XYTlbes3enS:215747427)*
<!-- Sent from Reviewable.io -->

@jwnimmer-tri
Copy link
Collaborator

Updated review of diffs is posted below. Still have to do some research on the testing discussions; will follow up a bit later.

Previously, liangfok (Chien-Liang Fok) wrote…

I've addressed all comments from previous round of review. PTAL.


Reviewed 10 of 11 files at r2, 1 of 1 files at r3.
Review status: all files reviewed at latest revision, 12 unresolved discussions.


drake/examples/Cars/car_sim_lcm.cpp, line 161 [r3] (raw file):

}  // namespace drake

int main(int argc, const char* argv[]) { return drake::do_main(argc, argv); }

I assert that this makes the code less readable. What is the motivation here?


drake/systems/plants/RigidBody.h, line 17 [r3] (raw file):

class DRAKERBM_EXPORT RigidBody {
 public:
  static const std::string kWorldLinkName;

Unfortunately, non-trivial types likestd::string cannot be used as a static constant per cppguide. You'll need to use const char* const.


drake/systems/plants/RigidBodySystem.h, line 131 [r3] (raw file):

/**
 * Implements Drake's System concept where state is both joint position

I think its defective to place supplementary doxygen ahead of the @brief summary (the brief should always be first).


drake/systems/plants/RigidBodyTree.cpp, line 50 [r3] (raw file):

    const DrakeJoint::FloatingBaseType floating_base_type)
    : collision_model(DrakeCollision::newModel()) {
  init();

The more conventional de-duplication technique would be for this constructor to delegate to the default constructor first (which would retain the member initialization), and then just call addRobot.... This has the additional advantage of also de-duplicating the collision_model item in the initializer list.


drake/systems/plants/RigidBodyTree.h, line 826 [r3] (raw file):

   * and the rigid body representing the world.
   */
  void init(void);

Don't say 'void' as the parameter (non-standard); just leave it out.


Comments from Reviewable

@jwnimmer-tri
Copy link
Collaborator

Review status: all files reviewed at latest revision, 12 unresolved discussions.


drake/systems/plants/RigidBodySystem.cpp, line 527 [r1] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

I believe this method is covered by the following unit test:

[drake-distro]/drake/systems/plants/test/lidarTest.cpp
``</details>
That partially covers horizontal sensors, but is a relatively poor test.  If the RBDepthSensor returns a null vector, the test passes.  For the purposes of this PR, would you be willing to add valuecheck coverage to that program of the new RBDepthSensor getters added in this PR (which I think also gets you RBSystem:GetSensors() API coverage)?

drake/systems/plants/RigidBodySystem.cpp, line 592 [r1] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

I think you're right, but this class is about to be generalized to support 3D point cloud sensors like that provided by the Microsoft Kinect, so I would punt on adding this check.

For more details, see:
#2208


Actually I wonder if is_vertical_scanner doxygen could be clearer here. Instead of just whether this scans vertically, perhaps some way to indicate that being "vertical" doesn't rule out being "horizontal" as well (which I think it doesn't, either now or later?).

Aside from that, I don't really see how #2208 comes into play here. If we parse an sdf that has non-zero min/max pitch, but zero rows, isn't that an error in both current-code and future-code?


drake/systems/plants/RigidBodySystem.cpp, line 592 [r1] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

I believe this method is covered by the following unit test:

[drake-distro]/drake/systems/plants/test/lidarTest.cpp
``</details>
I am not seeing where that test calls (even indirectly) into `is_vertical_scanner`?

drake/systems/plants/RigidBodySystem.cpp, line 596 [r1] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

I think you're right, but this class is about to be generalized to support 3D point cloud sensors like that provided by the Microsoft Kinect, so I would punt on adding this check.

For more details, see:
#2208


(Heh, I'll just let this conversation track the pitch/rows comment, instead of repeating everything here.)


drake/systems/plants/RigidBodySystem.cpp, line 596 [r1] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

I believe this method is covered by the following unit test:

[drake-distro]/drake/systems/plants/test/lidarTest.cpp
``</details>
I am not seeing where that test calls (even indirectly) into `is_horizontal_scanner`?

drake/systems/plants/RigidBodySystem.cpp, line 658 [r1] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

I believe this is covered by the compareRigidBody unit tests. See:

[drake distro]/drake/systems/plants/test/CMakeLists.txt
```</details>
I see.  It runs compareRigidBodySystems on Acrobot.sdf, which has joints, but no sensors, which proves that sensor-less joint parsing does not hit this exception.  It doesn't not test that the exception is generated when we cannot full a sensor request, but supporting that is a work in progress, so proving that it fails with a good error message currently is not useful.  WFM.  Marking resolved.

Comments from Reviewable

@amcastro-tri
Copy link
Contributor

Review status: all files reviewed at latest revision, 35 unresolved discussions.


drake/examples/Cars/car_sim_lcm.cpp, line 51 [r3] (raw file):

      aligned_allocator<RigidBodyFrame>(),
      // Weld the model to the world link.
      RigidBody::kWorldLinkName,

I personally think that something like kWorldLinkName should live in RigidBodyTree, not RigidBody. RigidBody should not even know if it belongs to a tree or not (now it sort of does but that will change).
Too much to ask changing to RigdiBodyTree::kWorldLinkName?


drake/systems/plants/RigidBody.cpp, line 33 [r1] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

Done.


I don't like this idea since the concept of "world" will be taken out of RigidBodyTree in the future (a class MultibodyDyanamicsWorld could be the perfect palceholder for all the dynamics engine objects and algorithms). In any case this is an ok hack for now but I'd place it in the RigidBodyTree since the concept of "world" right now resides in the RigidBodyTree


drake/systems/plants/RigidBody.cpp, line 34 [r1] (raw file):

  } else {
    if (linkname == "world")
      throw runtime_error(

std::runtime_error


drake/systems/plants/RigidBody.cpp, line 38 [r1] (raw file):

          "The world link does not have a joint!");
    else
      throw runtime_error("Joint of link " + linkname + " in model " +

std::runtime_error


drake/systems/plants/RigidBody.cpp, line 8 [r3] (raw file):

using namespace Eigen;

const string RigidBody::kWorldLinkName = "world";

As above. I would move this to RigidBodyTree


drake/systems/plants/RigidBody.cpp, line 23 [r3] (raw file):

}

const std::string& RigidBody::GetName() const { return linkname; }

Two comments:

  1. Call it get_name(). simple cheap accessor. I actually prefer the simple version name(), I never put the get_ in front of getters. Probably we should all agree on a convention. I do use however things like set_ for setters.
  2. Why not return std::string? RVO should do the right thing here if performance is what you are worried about.

drake/systems/plants/RigidBody.cpp, line 25 [r3] (raw file):

const std::string& RigidBody::GetName() const { return linkname; }

const std::string& RigidBody::GetModelName() const { return model_name; }

This should not be part of the RigidBody API. The RigidBody concept should not know if attached to a RigidBodyTree at all. For something like this I would prefer the API to read something like:

RigidBody body;
body.parent_tree().name();

and therefore yes, RigidBody contains a RigidBodyTree* parent_tree_ member. In the future all this "tree connectivity" information will be moved to a class RBTBody (meaning Rigid Body Tree Body which will inherit from RigidBody, not necessarily attached to a RigidBodyTree which in turns will inherit from Body which might not be rigid, but soft).


drake/systems/plants/RigidBody.h, line 17 [r3] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Unfortunately, non-trivial types likestd::string cannot be used as a static constant per cppguide. You'll need to use const char* const.


Move to RigidBodyTree, where the concept of "world" resides right now


drake/systems/plants/RigidBody.h, line 28 [r3] (raw file):

  /**
   * An accessor for the name of the link that this rigid body reprsents.

Change to a more general description like @brief Name of the body. Once in the proper namespace (like drake:physics::multibody_dynamics a user of might not be interested at all in robotics but just on simulation. I would prefer using a more general description ignoring words like "link" that come from URDF/SDF specifications.


drake/systems/plants/RigidBody.h, line 32 [r3] (raw file):

   * @return The name of the link that's modeled by this rigid body.
   */
  const std::string& GetName() const;

See my notes in the cpp


drake/systems/plants/RigidBody.h, line 35 [r3] (raw file):

  /**
   * An accessor for the name of the model or robot that this rigid body is

As commented in the cpp. The model (in our case the RigidBodyTree) should return its name. A rigid body should return a reference to the parent model (the tree)


drake/systems/plants/RigidBody.h, line 40 [r3] (raw file):

   * @return The name of the model that this rigid body belongs to.
   */
  const std::string& GetModelName() const;

See my notes in the cpp


drake/systems/plants/RigidBody.h, line 45 [r3] (raw file):

   * Sets the parent joint through which this rigid body connects to the
   * rest of the rigid body tree.
   *

Reword to something like: "Set the parent joint through which this rigid body connects to its parent RigidBody"


drake/systems/plants/RigidBody.h, line 49 [r3] (raw file):

   * rigid body assumes ownership of this joint.
   */
  void setJoint(std::unique_ptr<DrakeJoint> joint);

This is just a side note, not your fault. But DrakeJoint's should belong to the RigidBodyTree, not to the RigidBody's!!


drake/systems/plants/RigidBody.h, line 53 [r3] (raw file):

  /**
   * An accessor to this rigid body's parent joint. By "parent joint" we
   * mean the joint through which this rigid body connects to the rest

as before I'd prefer something like "...through which it connects to its parent RigidBody in the tree"


drake/systems/plants/RigidBodySystem.cpp, line 592 [r1] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Actually I wonder if is_vertical_scanner doxygen could be clearer here. Instead of just whether this scans vertically, perhaps some way to indicate that being "vertical" doesn't rule out being "horizontal" as well (which I think it doesn't, either now or later?).

Aside from that, I don't really see how #2208 comes into play here. If we parse an sdf that has non-zero min/max pitch, but zero rows, isn't that an error in both current-code and future-code?


If we generalize this to 3D depth sensors then we should just have a class DepthSensor2D and DepthSensor3D (and maybe with an inheritance diagram like Sensor <-- DepthSensor <-- DepthSensor2D/3D).


drake/systems/plants/RigidBodySystem.cpp, line 16 [r3] (raw file):

using namespace tinyxml2;

size_t RigidBodySystem::getNumStates() const {

This method will belong to System and then RigidBodySystem will inherit that interface. So this will go away when System 2.0 kicks in.
For now however use RigidBodySystem::number_of_states() (no get, all lower case, underscore between words, cheap)


drake/systems/plants/RigidBodySystem.cpp, line 17 [r3] (raw file):

size_t RigidBodySystem::getNumStates() const {
  return tree->num_positions + tree->num_velocities;

What for sure would remain is RigidBodyTree::number_of_positions() (same for velocities). Maybe worth implementing those?. Also would it be posible to refactor num_positions (num_velocities) to num_positions_ (num_velocities_) ? and make them private?


drake/systems/plants/RigidBodySystem.cpp, line 582 [r3] (raw file):

}

size_t RigidBodyDepthSensor::getNumOutputs() const {

number_of_outputs. Again, systems will inherit this from System 2.0 so just a comment.


drake/systems/plants/RigidBodySystem.cpp, line 586 [r3] (raw file):

}

size_t RigidBodyDepthSensor::get_num_pixel_rows() const {

RigidBodyDepthSensor::num_pixel_rows() (no get). Refactor RigidBodyDepthSensor::num_pixel_rows to RigidBodyDepthSensor::num_pixel_rows_ (and make private)


drake/systems/plants/RigidBodySystem.cpp, line 590 [r3] (raw file):

}

size_t RigidBodyDepthSensor::get_num_pixel_cols() const {

same as for RigidBodyDepthSensor::num_pixel_rows()


drake/systems/plants/RigidBodySystem.cpp, line 602 [r3] (raw file):

}

double RigidBodyDepthSensor::get_min_pitch() const { return min_pitch; }

If you add the accessors call them RigidBodyDepthSensor::min_pitch() and refactor member to RigidBodyDepthSensor::min_pitch_ (and make private)


drake/systems/plants/RigidBodySystem.cpp, line 604 [r3] (raw file):

double RigidBodyDepthSensor::get_min_pitch() const { return min_pitch; }

double RigidBodyDepthSensor::get_max_pitch() const { return max_pitch; }

as above.


drake/systems/plants/RigidBodySystem.cpp, line 606 [r3] (raw file):

double RigidBodyDepthSensor::get_max_pitch() const { return max_pitch; }

double RigidBodyDepthSensor::get_min_yaw() const { return min_yaw; }

as above.


drake/systems/plants/RigidBodySystem.cpp, line 608 [r3] (raw file):

double RigidBodyDepthSensor::get_min_yaw() const { return min_yaw; }

double RigidBodyDepthSensor::get_max_yaw() const { return max_yaw; }

as above.


drake/systems/plants/RigidBodySystem.cpp, line 610 [r3] (raw file):

double RigidBodyDepthSensor::get_max_yaw() const { return max_yaw; }

double RigidBodyDepthSensor::get_min_range() const { return min_range; }

as above.


drake/systems/plants/RigidBodySystem.cpp, line 612 [r3] (raw file):

double RigidBodyDepthSensor::get_min_range() const { return min_range; }

double RigidBodyDepthSensor::get_max_range() const { return max_range; }

as above.


Comments from Reviewable

@amcastro-tri
Copy link
Contributor

Review status: all files reviewed at latest revision, 43 unresolved discussions.


drake/systems/plants/RigidBodySystem.cpp, line 650 [r3] (raw file):

                   PoseMap& pose_map) {
  // Obtains the name of the joint.
  const char* attr = node->Attribute("name");

memory leak? who deallocates attr?


drake/systems/plants/RigidBodySystem.cpp, line 652 [r3] (raw file):

  const char* attr = node->Attribute("name");
  if (!attr) throw runtime_error("ERROR: joint tag is missing name attribute");
  string joint_name(attr);

std::string


drake/systems/plants/RigidBodySystem.cpp, line 656 [r3] (raw file):

  if (node->FirstChildElement("sensor") != nullptr) {
    // TODO(liangfok): Add support for sensors on joints.
    throw runtime_error(

std::runtime_error


drake/systems/plants/RigidBodySystem.cpp, line 818 [r3] (raw file):

Eigen::VectorXd spatialForceInFrameToJointTorque(
    const RigidBodyTree* tree, const KinematicsCache<double>& rigid_body_state,
    const RigidBodyFrame* frame, const Eigen::Matrix<double, 6, 1>& force) {

Replace "force" --> "wrench". A force is a 3D vector.


drake/systems/plants/RigidBodySystem.cpp, line 819 [r3] (raw file):

    const RigidBodyTree* tree, const KinematicsCache<double>& rigid_body_state,
    const RigidBodyFrame* frame, const Eigen::Matrix<double, 6, 1>& force) {
  auto T_frame_to_world =

@sherm1, how should we call these? time to introduce your notation. I don't like it is inverted. I'd prefere T_world_from_frame so that things like v_world = T_world_from_frame * v_frame can be read from left to right with minimum effort.


drake/systems/plants/RigidBodySystem.cpp, line 828 [r3] (raw file):

  for (int i = 0; i < v_indices.size(); i++) {
    tau(v_indices[i]) = J.col(i).dot(force_in_world);
    //      std::cout << " f_" << tree->getVelocityName(v_indices[i]) << " = "

Remove commented out code used for debugging.


drake/systems/plants/RigidBodySystem.h, line 278 [r3] (raw file):

};

/** spatialForceInFrameToJointTorque

Why not to follow the TODO and move it now to RigidBodyTree as part of this PR? That is what makes sense. @liangfok, remember that changes in system most likely will go away with the arrival of System 2.0. This is actually a change that if you move to the RBT (which makes sense) it will remain even after System 2.0


drake/systems/plants/RigidBodySystem.h, line 303 [r3] (raw file):

 * RigidBodyTree?
 */
Eigen::VectorXd spatialForceInFrameToJointTorque(

We need proper Doxygen documentation here. My try:
"Given a wrench described in the given RigidBodyFrame frame, return the (scalar) generalized force at each joint required to achieve this wrench".
@sherm1. What do you think?, because if a joint is prismatic (and if I understand correctly) the value of tau will be that of the (scalar) force along the axis of action. Therefore, the name of this method is misleading. It should contain the term "generalized force", not "torque".
My try: rename to CoputeGeneralizedJointForcesFromWrenchOnRigidBodyFrame.


Comments from Reviewable

@amcastro-tri
Copy link
Contributor

I finished with my first pass. I hope it is useful.

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Updated review of diffs is posted below. Still have to do some research on the testing discussions; will follow up a bit later.


Review status: all files reviewed at latest revision, 43 unresolved discussions.


Comments from Reviewable

@@ -18,6 +20,10 @@ RigidBody::RigidBody()
I << Matrix<double, TWIST_SIZE, TWIST_SIZE>::Zero();
}

const std::string& RigidBody::GetName() const { return linkname; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very minor. There is a style inconsistency between linkname and model_name.

@david-german-tri
Copy link
Contributor

@nkoenig FYI, Drake recently switched from the built-in GitHub UI to reviewable.io for code reviews. Among other nice features, Reviewable will batch your comments for you, decreasing email volume.

@@ -641,7 +699,7 @@ void parseSDFLink(RigidBodySystem& sys, string model_name, XMLElement* node,
transform_link_to_model);
}

if (type.compare("ray") == 0) {
if (type == "ray") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to add an else clause that outputs some warning or error about not handling sensors than than 'ray'?

@sherm1
Copy link
Member

sherm1 commented May 10, 2016

Review status: all files reviewed at latest revision, 47 unresolved discussions, some commit checks failed.


drake/systems/plants/RigidBody.cpp, line 23 [r3] (raw file):

Previously, amcastro-tri (Alejandro Castro) wrote…

Two comments:

  1. Call it get_name(). simple cheap accessor. I actually prefer the simple version name(), I never put the get_ in front of getters. Probably we should all agree on a convention. I do use however things like set_ for setters.
  2. Why not return std::string? RVO should do the right thing here if performance is what you are worried about.

RVO won't always work here because linkname is not a local temp. If the return result gets used directly (e.g. passed to a function that takes a const std::string&) then an extra heap-allocated copy would have to get made.

drake/systems/plants/RigidBody.cpp, line 35 [r3] (raw file):

Previously, nkoenig (Nate Koenig) wrote…

It shouldn't be necessary to construct a std::string temporary from kWorldLinkName, right?


Assuming kWorldLinkName is a char*, I'm not sure how that can be avoided.


drake/systems/plants/RigidBodySystem.cpp, line 819 [r3] (raw file):

Previously, amcastro-tri (Alejandro Castro) wrote…

@sherm1, how should we call these? time to introduce your notation. I don't like it is inverted. I'd prefere T_world_from_frame so that things like v_world = T_world_from_frame * v_frame can be read from left to right with minimum effort.


Agreed, but I think reversing here would be asking for trouble since the current ordering is more-or-less a Drake convention. Changing to v_W=T_WF*v_F would be less confusing since it wouldn't look like the old convention, but I think it is only good if it is used consistently throughout this code. I think notation changes to existing code (if done at all) should be done in their own PRs that do nothing else so we can make sure no frames get flipped.


Comments from Reviewable

@nkoenig
Copy link
Contributor

nkoenig commented May 10, 2016

Review status: all files reviewed at latest revision, 47 unresolved discussions, some commit checks failed.


drake/systems/plants/RigidBody.cpp, line 35 [r3] (raw file):

Previously, sherm1 (Michael Sherman) wrote…

Assuming kWorldLinkName is a char*, I'm not sure how that can be avoided.


Isn't kWorldLinkName defined as a std::string?


Comments from Reviewable

@jwnimmer-tri
Copy link
Collaborator

Review status: all files reviewed at latest revision, 46 unresolved discussions, some commit checks failed.


drake/systems/plants/RigidBody.cpp, line 34 [r1] (raw file):

Previously, amcastro-tri (Alejandro Castro) wrote…

std::runtime_error


Incorrect. It is not required to say std::runtime_error.


drake/systems/plants/RigidBodySystem.cpp, line 652 [r3] (raw file):

Previously, amcastro-tri (Alejandro Castro) wrote…

std::string


Nope. Not required.


drake/systems/plants/RigidBodySystem.cpp, line 656 [r3] (raw file):

Previously, amcastro-tri (Alejandro Castro) wrote…

std::runtime_error


Nope. Not required.


Comments from Reviewable

@liangfok
Copy link
Contributor Author

Review status: 66 of 71 files reviewed at latest revision, 17 unresolved discussions.


drake/systems/plants/test/lidarTest.cpp, line 124 [r6] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

My reviewable isn't seeing this change as being pushed? Has it made it into github yet?


Sorry for the long latency. I meant to push right away but then got distracted by another matter. It should be there now. I guess from now on the best practice is to push then publish to Reviewable.


Comments from Reviewable

@jwnimmer-tri
Copy link
Collaborator

Reviewed 3 of 3 files at r7.
Review status: 69 of 71 files reviewed at latest revision, 16 unresolved discussions.


Comments from Reviewable

@amcastro-tri
Copy link
Contributor

Review status: 69 of 71 files reviewed at latest revision, 9 unresolved discussions.


drake/systems/plants/test/lidarTest.cpp, line 16 [r6] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

It's to avoid needing to include a bunch of using Drake::Foo; lines in the code.


Is that our "good practice"?


drake/systems/plants/test/lidarTest.cpp, line 83 [r6] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

Done.


Somehow the change didn't make it through. It still reads as TODO(amcastro): Get rid of the .05 in my screen.


Comments from Reviewable

@liangfok
Copy link
Contributor Author

Review status: 68 of 71 files reviewed at latest revision, 9 unresolved discussions.


drake/systems/plants/test/lidarTest.cpp, line 16 [r6] (raw file):

Previously, amcastro-tri (Alejandro Castro) wrote…

Is that our "good practice"?


Yes, there was also a comment on slack about how having 10,000 lines of code in a main method is bad b/c it can't be easily unit tested 😄


drake/systems/plants/test/lidarTest.cpp, line 83 [r6] (raw file):

Previously, amcastro-tri (Alejandro Castro) wrote…

Somehow the change didn't make it through. It still reads as TODO(amcastro): Get rid of the .05 in my screen.


That's weird. I've fixed it now. PTAL.


Comments from Reviewable

@liangfok
Copy link
Contributor Author

This PR passed CI Build 1396. Thus, I believe it is ready for platform review. @jwnimmer-tri will you serve as platform reviewer?

Previously, liangfok (Chien-Liang Fok) wrote…

Dear reviewers, I believe I've addressed all of your comments. PTAL.

I am still working on verifying Drake+Matlab still works and debugging it if it does not.


Review status: 57 of 71 files reviewed at latest revision, 9 unresolved discussions.


drake/systems/plants/RigidBody.cpp, line 33 [r1] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

Done.


@sammy-tri, if appropriate, can you mark this thread as "resolved"?


drake/systems/plants/RigidBodySystem.cpp, line 702 [r3] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

Done. I modified the code to throw an exception with an appropriate message.


@nkoenig, if appropriate, can you mark this thread as "resolved"?


drake/systems/plants/RigidBodySystem.h, line 303 [r3] (raw file):

Previously, liangfok (Chien-Liang Fok) wrote…

I've updated #2323 to include the new potential name and assigned the issue to @amcastro-tri since it seems like more discussions are in order regarding exactly what this method's API should be, i.e., whether to mix body frame vs. world frame semantics.


@sherm1, if appropriate, can you mark this thread as "resolved"?


Comments from Reviewable

@amcastro-tri
Copy link
Contributor

Review status: 57 of 71 files reviewed at latest revision, 7 unresolved discussions, some commit checks failed.


drake/systems/plants/RigidBodyTree.h, line 666 [r8] (raw file):

  void warnOnce(const std::string& id, const std::string& msg);

  RigidBody* findLink(std::string link_name, int robot) const;

I believe find/replace here changed something you did not want to change? It doesn't break anything in this case but for sure not needed.


Comments from Reviewable

@liangfok
Copy link
Contributor Author

Oops. I forgot to update the CHANGELOG. Will update that soon.

Previously, liangfok (Chien-Liang Fok) wrote…

This PR passed CI Build 1396. Thus, I believe it is ready for platform review. @jwnimmer-tri will you serve as platform reviewer?


Review status: 57 of 71 files reviewed at latest revision, 6 unresolved discussions, some commit checks failed.


Comments from Reviewable

@jwnimmer-tri
Copy link
Collaborator

Reviewed 2 of 12 files at r6, 12 of 12 files at r8.
Review status: all files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.


drake/systems/controllers/QPCommon.h, line 4 [r8] (raw file):

#include <Eigen/Core>
#include <vector>

This include is out of order now.


drake/systems/plants/test/urdfManipulatorDynamicsTest.cpp, line 3 [r8] (raw file):

#include <Eigen/Dense>
#include <iostream>

This include is in the wrong order now, but was correct previously.


Comments from Reviewable

Chien-Liang Fok added 3 commits May 12, 2016 21:16
# Conflicts:
#	drake/systems/plants/constraint/RigidBodyConstraint.cpp
@liangfok
Copy link
Contributor Author

I resolved the most recent round of reviewer comments, updated the CHANGELOG, and resolved the conflicts from #2325. Now waiting to verify that the latest revision passes CI.

Previously, liangfok (Chien-Liang Fok) wrote…

Oops. I forgot to update the CHANGELOG. Will update that soon.


Review status: 66 of 72 files reviewed at latest revision, 8 unresolved discussions.


drake/systems/controllers/QPCommon.h, line 4 [r8] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

This include is out of order now.


Fixed. Thanks.


drake/systems/plants/test/urdfManipulatorDynamicsTest.cpp, line 3 [r8] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

This include is in the wrong order now, but was correct previously.


Fixed. Thanks.


Comments from Reviewable

@jwnimmer-tri
Copy link
Collaborator

👍 from me on all the code. Just a few changelog comments. If you want, you can wait for CI to finish and then I can still override-merge any changelog fixes even without waiting for CI again; just need one clean run first.

:lgtm: on plaform; still need final ack's and lgtm from @amcastro-tri before merge, too.

Previously, liangfok (Chien-Liang Fok) wrote…

I resolved the most recent round of reviewer comments, updated the CHANGELOG, and resolved the conflicts from #2325. Now waiting to verify that the latest revision passes CI.


Reviewed 6 of 6 files at r9.
Review status: all files reviewed at latest revision, 9 unresolved discussions.


CHANGELOG.md, line 24 [r9] (raw file):

### Changed

 - [#2303][] Added accessors `RigidBody::name()`, `RigidBody::model_name()`, `RigidBodyTree:number_of_positions()`, `RigidBodySystem::number_of_velocitie()`, `RigidBodySystem::number_of_positions()`, `RigidBodySystem::number_of_velocities()`, and `RigidBodySystem::GetSensors()`. Added numerous accessors to `RigidBodyDepthSensor`. Removed direct access to some member variables that are now accessible via the aforementioned accessors. Added static constant `RigidBodyTree:kWorldLinkName`.

Typo 'velocitie'.


CHANGELOG.md, line 24 [r9] (raw file):

### Changed

 - [#2303][] Added accessors `RigidBody::name()`, `RigidBody::model_name()`, `RigidBodyTree:number_of_positions()`, `RigidBodySystem::number_of_velocitie()`, `RigidBodySystem::number_of_positions()`, `RigidBodySystem::number_of_velocities()`, and `RigidBodySystem::GetSensors()`. Added numerous accessors to `RigidBodyDepthSensor`. Removed direct access to some member variables that are now accessible via the aforementioned accessors. Added static constant `RigidBodyTree:kWorldLinkName`.

Consider: This is the only entry in past tense. I can't remember if verb tense is required here, but perhaps be consistent.


CHANGELOG.md, line 24 [r9] (raw file):

### Changed

 - [#2303][] Added accessors `RigidBody::name()`, `RigidBody::model_name()`, `RigidBodyTree:number_of_positions()`, `RigidBodySystem::number_of_velocitie()`, `RigidBodySystem::number_of_positions()`, `RigidBodySystem::number_of_velocities()`, and `RigidBodySystem::GetSensors()`. Added numerous accessors to `RigidBodyDepthSensor`. Removed direct access to some member variables that are now accessible via the aforementioned accessors. Added static constant `RigidBodyTree:kWorldLinkName`.

Consider: It would be okay by me (as in 2018 below) to be briefer here, and just mention the classes that changed. The only super-important part is that fields are no longer public; the fact of which new methods were added is likely less interesting?


Comments from Reviewable

@jwnimmer-tri
Copy link
Collaborator

Wow, the #2325 merge is really messing with this PR. Sorry! If I had realized that would be the case, I would definitely have let this PR make it to master first.

@liangfok
Copy link
Contributor Author

No worries. I do not mind resolving the conflicts in this PR.

Oops. CI Build 1401 is all red b/c I forgot to commit some code. Oh well, I'm about to push some changes that should trigger another round of CI.

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Wow, the #2325 merge is really messing with this PR. Sorry! If I had realized that would be the case, I would definitely have let this PR make it to master first.


Review status: all files reviewed at latest revision, 9 unresolved discussions, some commit checks failed.


CHANGELOG.md, line 24 [r9] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Typo 'velocitie'.


Fixed. Thanks.


CHANGELOG.md, line 24 [r9] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Consider: This is the only entry in past tense. I can't remember if verb tense is required here, but perhaps be consistent.


I modified it to be in present tense.


CHANGELOG.md, line 24 [r9] (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Consider: It would be okay by me (as in 2018 below) to be briefer here, and just mention the classes that changed. The only super-important part is that fields are no longer public; the fact of which new methods were added is likely less interesting?


Agreed. I updated the CHANGELOG entry and also added an entry for #2325.


Comments from Reviewable

@amcastro-tri
Copy link
Contributor

Awesome job @liangfok! you went through the revision process as a real gent

Previously, liangfok (Chien-Liang Fok) wrote…

No worries. I do not mind resolving the conflicts in this PR.

Oops. CI Build 1401 is all red b/c I forgot to commit some code. Oh well, I'm about to push some changes that should trigger another round of CI.


Review status: 70 of 72 files reviewed at latest revision, 9 unresolved discussions.


Comments from Reviewable

@amcastro-tri
Copy link
Contributor

:lgtm:

Previously, amcastro-tri (Alejandro Castro) wrote…

Awesome job @liangfok! you went through the revision process as a real gent


Review status: 70 of 72 files reviewed at latest revision, 9 unresolved discussions.


Comments from Reviewable

@liangfok
Copy link
Contributor Author

Thanks @amcastro-tri. This PR passed CI build 1402. It is thus ready for another round of review or merge.

Previously, amcastro-tri (Alejandro Castro) wrote…

:lgtm:


Review status: 70 of 72 files reviewed at latest revision, 9 unresolved discussions.


Comments from Reviewable

@jwnimmer-tri
Copy link
Collaborator

:lgtm:

Previously, liangfok (Chien-Liang Fok) wrote…

Thanks @amcastro-tri. This PR passed CI build 1402. It is thus ready for another round of review or merge.


Reviewed 2 of 2 files at r10.
Review status: all files reviewed at latest revision, 5 unresolved discussions.


Comments from Reviewable

@jwnimmer-tri
Copy link
Collaborator

I looked through the 5 reviewable discussions that were unresolved, and am making a judgement call that their concerns have been met, so I've overridden them all to be satisfied.

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

:lgtm:


Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.


Comments from Reviewable

@jwnimmer-tri
Copy link
Collaborator

Using override-merge due to "out of date with master".

@jwnimmer-tri jwnimmer-tri merged commit aa17908 into RobotLocomotion:master May 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants