API review

Proposer: Stuart Glaser

(All these links are to the OLD doxygen location.) This is a review of the ROS APIs of the following controllers ONLY:

• JointEffortController

• JointVelocityController

• JointPositionController

• CartesianWrenchController

• CartesianTwistController

• CartesianPoseController

Present at review:

• List reviewers

Question / concerns / comments

Enter your thoughts on the API and any questions / concerns you have here. Please sign your name. Anything you want to address in the API review should be marked down here before the start of the meeting.

• Josh
  • CartesianWrench/Twist controllers have no documentation of their ROS API
• Remove all initXML's
• Make clear that only the ROS API is being released.
• Pose controller outputs to the twist controller:
  • Twist over wrench is okay, but still strange
• For simplicity of the user interface, we will make all the (cartesian) controllers standalone.
• Pose controller's gains go directly from pose to joint efforts
• Twist feedforward in the pose controller
  • As part of the ROS interface? Yes
  • Twist also takes in twist and wrench
• Sending a singleton pose feels like the right way to simply command the pose controller.
• It's less clear to send this as a small component of a specified trajectory.
• It would be nice to start THE controller (The Cartesian Controller).
• But having them all in the same controller means that you need to explain what happens when you switch modes.
• But what happens if I start a joint position controller and a joint velocity controller? Their commands compose currently.
• Controllers should share the gains. There should be gains per joint and gains per cartesian-controlled chain).
• Proposal:

  • JointController, CartesianController, and some trajectory controllers separately.

• Can share gains, except for i_clamp
• Want some central storage of kp,ki,kd,i_clamp(both position and velocity) per joint
• Josh really really needs default configurations and launch files for getting certain controllers up. He doesn't want to deal with the configuration step at all.
• Wiki: short list of control options (cartesian control for arms, base, joint trajectories for arms, head, etc...)
• Arm of joint controllers? Just as a launch file? But that doesn't combine the command into one topic (one setpoint).

gains:
  r_shoulder_pan_joint:
    ...
  r_arm:
    kp
    kv
    kpi:
    kpi_clamp:
    that other clamp:

joints:
  r_shoulder_pan_joint:
    gains:
      kp:
      kv:
      kpi:
      (No: kvi it's actually kp)
      kpi_clamp:
      kp_clamp, kvi_clamp???  So, it needs some name, but we're not sure what it is

r_shoulder_velocity:
  type: !JointVelocityController
  joint: r_shoulder_pan_joint (and the gains are found off this, somehow)
  (gains: r_shoulder_pan_joint_gains)

to find the gains, searchparam for joints

r_shoulder_position:
  type: !JointPositionController
  joint: r_shoulder_pan_joint (and it picks out the position gains properly)

r_arm_cartesian_pose:
  type: !CartesianPoseController
  root_name: torso_lift_link
  tip_name: r_hand

• Gain reuse
• All the controllers are "controller/command", which makes it easy to mix up what you're commanding. "command_position", "command_velocity", ...
• We kind of just want to do "goto position". just support move_arm

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