mxgrey
commented
6 years ago DART treats all joints as joints, including fixed joints. If DART is told that something is a joint, it will be a joint. In the case of a fixed joint, it's a Joint with no degrees of freedom which constrains two bodies to be rigidly attached to each other.
If someone wants an efficiency improvement by merging two bodies that are connected by a fixed joint, they are welcome to do so by either modifying their model file (.urdf, .sdf, or .skel) or by modifying the Skeleton programmatically (you can change joint types and body properties at runtime through the DART API, which includes deleting Joints and BodyNodes).
To understand why we refuse to use the technique you've described, it would be impertinent of us to change the number of joints or the number of bodies to be different than the model that a user explicitly loaded. Imagine someone's confusion if they ask for 6 bodies, but we only give them 5. Or they end up with one fewer joint than they requested.
There are any number of reasons that a user might specify two bodies connected by a fixed joint instead of one body. Maybe they want to be able to adjust the inertia properties of the two bodies independently of each other. Maybe they want to use each body as a separate frame of reference.
If a user actually wants one body instead of two, they are welcome to create a model that specifies one body instead of two. That's not for us to decide.
Granted, sometimes a fixed joint is used for convenience when writing a model file, and the user doesn't actually care about having the final number of bodies and joints match the original specification. We could consider putting an optional element in the skel format for WeldJoint, maybe called something like <merge> which would explicitly tell the parser to merge the two bodies together. We might also be able to add that sort of element to our sdf parser, and maybe the urdf parser.
That seems like a very low priority feature, though, since I expect it will mostly just live in obscurity.
junhyeokahn
Hello, I have a small questions on how dart handles fixed joint. I realized several of dynamics libraries (e.g. RBDL) just connect fixed link to its parent's link and handle as a one combined link by adjusting mechanical properties. For example, if the tree structure seems, j1 -- l1 -- j2 -- l2 where j2 is fixed joint, RBDL just removes j2 and handle both link together l_new = (l1+l2) : j1 -- l_new. Also, every mechanical properties are adjusted as well. For example, when I require the mass property, it returns m_new = m1+m2, and so on.
I am not sure if it is general way to handle multibody object including fixed joints, but does dart handle fixed joints as similar to above? If so, where does dart trace them? I found
DegreeOfFreedom::getChildBodyNode(), but it only returns the exact child body node regardless of the next joint type of child node.I think in the case of computing properties which require iterative process through every BodyNodes (e.g. centroid dynamics property), aforementioned schemes could show some efficiency.