FutureFeatures

Future version changes:

• Integrating joint limits

• Integrating velocity and effort limits.

• actuator element: add the following optional attributes:

  • family (string) Can be used to look up an associated group of physical modules if desired. Defaults to the robot ancestor element's value if not given.
  • name (string) Can be used to look up an associated group of physical modules if desired. Default is empty string.
  • torque_offset (floating point, Nm) Can be used to set a constant torque offset (e.g., to approximate an added spring). Defaults to "0".

• Output element: see proposed element description below. *- Should we allow any "output" elements on a one-output body? Or force the element list / "chain" style here?

• Add the following optional attributes to the robot element: *- family Can be used to look up an associated group of physical modules if desired; this serves as the default value of the family attribute on each actuator element. Default is empty string.

• Define what implementations supporting e.g., 2.0.0 need to support in terms of the "version" string and backwards compatibility.

• Think about changing "rot" and "trans" to "rotation" and "translation"?

• Add support for xyz/rpy format? Beware of Euler Angle hell here...

• Should the "joint"'s "axis" attribute be called "type" for consistency?

• Should we allow some but not all of the override parameters? Should be allow overriding the "output" position of any elements?

• Should we add support for sin(), cos(), and tan() in our floating point description?

• Is the "torque-offset" attribute useful? Should we instead add a real spring element, and try to do something crazier to estimate it's effects on the torque?

• Do we need to support some some of "sub tree reference"? E.g., to load in Edward, the demo code would want to just start with a robot model for each arm. If we pass in a "root body" reference when parsing the file (e.g., find the element with a given family/name), we could then extract just that sub tree (in this case, a pure kinematic chain).

• Extending the above "subtree" idea -- what about "start + end" references?

• If we support 'trees', we should allow for "tree-less" implementation support. In this case, the existence of more than one output interface can be ignored, and any XML files with more than one output interface specified are invalid.

• Have tree branches/outputs have an "ID", so they can be referenced by name in the API.