API review

Proposer: Wim Meeussen

Present at review:

Question / concerns / comments

Top level:

I'm assuming this is for control. So the KDL model includes kinematic information. As well as dynamic of the mechanism? The Joint class then focuses on one joint?
What is the transmission model/assumptions? Is one motor attached to one joint? Any cross-coupling? I would argue that in general we can't assume one motor connects only to one joint.
Is there any notion of lumping joints together? arms/head/sub groups? Especially if motors cross-couple between joints.
Is Joint the JointParameters?

Specific:

joint_damping and friction_coeff? Are these part of the dynamic model of the robot? Why live here? And/or why not have mass of motor/joint?
Is joint_limit the position_limit?
Can we add a velocity filter bandwidth? Should this be per joint, per motor (I think yes).
What is safety limit? Effort limit? Why on joint and not the motor?
What is the reference_position
What is the type? If the kinematic info is in the KDL data, should that already contain this info? For a joint PD controller (or the like) it doesn't matter whether you are revolute or prismatic? And planar types (with 2 dof) would need an array of positions??
Are the safety-torque-limiters (Eric's code?) initialized from here? Or are they separate?

These comments were discussed as part of the pr2 controller manager api review

Package status change mark change manifest)

Add an actuator model to allow lower level modeling/control.
Need a more full dynamic model, specifying in joint space might not be right.
Might need to look at allowing control at the motor level instead of joints.
A filtered velocity output might be useful for some cases.
Add better effort limit compatibility verification/warning (eg warn if user efforts exceed hardware limits)