-
Notifications
You must be signed in to change notification settings - Fork 44
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
Should rename the term "Canonical link" in FreeGroup #233
Comments
there's only a few hours left before feature freeze, but this sounds like an API change to me |
It sounds like a good idea to me. As @scpeters pointed out, we're close to feature freeze though. We could open a pull request starting the implementation. One thing to keep in mind is that the existing public |
done in #234 |
Just a reminder that |
Desired behavior
The term "canonical link" in SDFormat refers to a link to which the model frame is attached. That is, there's a coordinate frame called the model frame and it has a constant pose offset from the implicit frame defined by the canonical link. On the other hand, the term "canonical link" in the context of
FreeGroup
refers to a link in the model that has no constraints. For DART, this link would be the root of a kinematic tree and it's parent joint would beFreeJoint
, which has 6DOF. Thus it is possible that the "canonical link" of a model per SDFormat be different from the "canonical link" of theFreeGroup
of the modelFor example:
The canonical link of
M1
per SDFormat is the linkL1
, however the canonical link of the FreeGroup ofM1
isL2
becauseL1
andL2
are constrained by a joint andL2
is the parent.This is also exacerbated by the fact that starting in SDFormat 1.7, the canonical link can be specified by the user to be any link in the model.
Since the term is overloaded, and the Gazebo/SDFormat version of canonical link existed (maybe implicitly) before the
FreeGroup
counterpart, we should come up with a new name forFreeGroup
's canonical link.Implementation suggestion
Rename the FreeGroup "canonical link" to "unconstrained link"
The text was updated successfully, but these errors were encountered: