Add TranslationalJoint2D

[jslee02]

TranslationalJoint2D is a 2d version of TranslationalJoint or PlanarJoint without the rotational axis.

---

Before creating a pull request

• Document new methods and classes

Before merging a pull request

• Set version target by selecting a milestone on the right side
• Summarize this change in CHANGELOG.md
• Add unit test(s) for this change (need tests for SkelParser)

[codecov]

Codecov Report

Merging #1003 into release-6.4 will decrease coverage by 0.19%.
The diff coverage is 30.05%.

@@              Coverage Diff               @@
##           release-6.4    #1003     +/-   ##
==============================================
- Coverage        56.81%   56.62%   -0.2%     
==============================================
  Files              310      314      +4     
  Lines            24117    24298    +181     
==============================================
+ Hits             13703    13758     +55     
- Misses           10414    10540    +126

Impacted Files	Coverage Δ
dart/dynamics/TranslationalJoint2D.hpp	100% <100%> (ø)
dart/utils/SkelParser.cpp	67.01% <2.43%> (-2.74%)	⬇️
...art/dynamics/detail/TranslationalJoint2DAspect.cpp	35.41% <35.41%> (ø)
dart/dynamics/TranslationalJoint2D.cpp	37.5% <37.5%> (ø)
...art/dynamics/detail/TranslationalJoint2DAspect.hpp	60% <60%> (ø)

[mxgrey]

I should have some time tonight to give this a review.

[mxgrey]

I left a suggestion regarding TranslationalJoint2dUniqueProperties, but nothing too significant. A few higher level thoughts below:

1. I wonder if we should consider naming the joint TranslationalJoint2D, since 2d might look awfully similar to Eigen's convention, where the lowercase d refers to double rather than Dimension.

2. This PR is making me realize just how much silly boilerplate is still required to implement a new joint type correctly. Ideally, we should just be able to define the unique properties, and then define the relative transform behavior and the Jacobian behavior. I think that could be achieved through a policy-based design scheme. But that's far outside the scope of this PR.

[mxgrey]

Since we've gone through the trouble of making the member functions, I feel that it would make sense to make these member variables private. That would ensure that this member data always remains sane. I think the mild inconvenience of not being able to set these values directly is heavily outweighed by the importance of keeping the values sane and consistent.

[mxgrey]

Since we've gone through the trouble of making all the member function, I feel like it would make sense to have these member variables be private. That way, we can rely on the member functions to keep the values sane and consistent. I think the inconvenience of not having direct access to the members is heavily outweighed by the value of guaranteeing sanity and consistency.

[mxgrey]

Okay, apparently if you leave a review comment, accidentally close the webpage, and come back to continue reviewing, Github will (sometimes) pretend that you didn't leave the review comment at all....

[mxgrey]

If we do make the member variables private, we'll need to tweak the implementation of this parser to store these parameters and then pass them into the member functions of properties.

[jslee02]

This PR is making me realize just how much silly boilerplate is still required to implement a new joint type correctly. Ideally, we should just be able to define the unique properties, and then define the relative transform behavior and the Jacobian behavior.

Agreed. This is one of the reasons GenericJoint was introduced with the configuration space classes (e.g., RealVectorSpace and SO3Space). I intended to generalize the joint behavior using GenericJoint and define the concrete behaviors (e.g., Jacobian computations specific to the concrete configuration types) using geometric computations that are also templatized to the configuration spaces (e.g., integratePosition() in math/ConfigurationSpace.hpp) so that we only require minimum effort to add new joint types of new configuration spaces and furthermore any compositions of the current joint spaces. Since there are more rooms to improve the current implementation, we might want to revisit this at some point.

[mxgrey]

Looks like a member variable of TranslationalJoint2DUniqueProperties was left behind.

[mxgrey]

We would also want this member variable to be private.

I would also suggest changing this from a struct to a class since it's no longer a POD.