Khronos public bugtracker – Bug 220
articulated_system and children poorly named and awkwardly designed
Last modified: 2014-01-07 10:23:13 PST
The current design for articulated_system permits two variants: articulated_system/kinematics and articulated_system/motion.
The kinematics variant seems to really be about defining a particular serial kinematic chain within an instance of a kinematics model. The motion variant seems to only add some constraints on the speed of motion (and derivatives thereof) of an instance of the kinematics variant.
Why not rename the current "kinematics" child element "serial_chain" (branched, cyclic, and hybrid chains exist as well), and the current "motion" child element "motion_rate_constraints"?
The current names imply overly general concepts relative to what these elements actually do. The same goes for the name of the parent element "articulated_system". It seems that articulated_system is intended to be a container for any kind of construct that can be defined on top of a kinematics_model. Why not call it something like "derived_kinematic_system" then?
Finally, the current implementation of the motion child element is wonky because it must wrap another instance_articulated_system, which ultimately must be a kinematics variant. Thus, it is not possible to use articulated_system/motion to specify motion rate constraints on a single joint axis without first defining a serial chain with an articulated_system/kinematics, in which the frame_origin and frame_tip elements are not optional, but may not have any relevance to the original intent of simply constraining the speed of motion of a joint in a kinematics_model.