API review

Proposer: Wim Meeussen

Present at review:

• List reviewers

Question / concerns / comments

Sachin

• In general, it seems like we should converge on one model for everything - right now it feels like a mix and match of KDL elements and our own

• E.g. model_->robot_model_ where the pointer to a kdl tree is stored inside the ROBOT class as robot_model_. Shouldn't model_ just have all the information we require?

• joint limits come from the joints inside the model whereas all other joint information comes from the KDL tree. It would be good to have one point - Joint - where we could get everything from.
• It should be easier to find "passive" joints in the model.
• Currently, there is no way to figure out if a joint is not actuated but still has an encoder on it
• The list of joints should not contain fixed joints - fixed joints can be accessible in a different way
• It should be easier to initialize Robot from URDF instead of from the robot model
• An accessor method to get a chain based on a "group" name ("right_arm") would be great. Otherwise, you have to remember both the root and tip names every time you need a chain.
• Are we still using these? If not, they should be taken out

• void    propagateEffort ()
  void    propagateEffortBackwards ()
  void    propagateState ()
  void    propagateStateBackwards ()

• It might also be worthwhile to think about representing some of the elements here using messages instead of internal classes to make them easier to pass around, e.g. use the manipulation_msgs/Limits.msg for joint limit specification.

Meeting agenda

To be filled out by proposer based on comments gathered during API review period

Conclusion

Package status change mark change manifest)

• Action items that need to be taken.

• Major issues that need to be resolved