FutureFeatures - HebiRobotics/hebi-hrdf GitHub Wiki

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.