Robot API motion

Table of Contents generated with DocToc

• General concepts
  • Types of motion
    • servo
    • interp
    • move
  • Naming convention
    • Query commands
    • Motion commands
• Detailed API
  • Query commands
    • measured_js, measured joint state
    • measured_cp, measured cartesian position
    • servoed_js, current joint goal for low-level controller

General concepts

Types of motion

We identified the following basic types of motions for collaborative robotics:

servo

Direct access to the low-level controller:

• Use case: User has a smooth trajectory coming from a master arm, recorded trajectory and can send commands at a high rate.
• Space: These commands can be defined either in the cartesian or joint space.
• Type: These commands can be either position, velocity or effort based. Positions can be provided as increments from the latest commanded position.
• Continuity: Users must send continuous commands. The low-level controller is not required to generate intermediate goals to ensure that the command is feasible (i.e. goal must be closed to current state).
• Time: Users are expected to send commands periodically at a rate close to the low-level rate. These commands commands are preemptive.

interp

Simple interpolation:

• Use case: User has a smooth trajectory coming from a master arm, recorded trajectory and but can't send commands at a high rate (e.g. 50Hz visual tracking, remote tele-operation).
• Space: These commands can be defined either in the cartesian or joint space.
• Type: These commands are position based, either absolute or incremental.
• Continuity: Users must send continuous commands. The low-level controller will compute intermediary positions to smooth the motion.
• Time: Users are expected to send commands periodically at a rate lower than the low-level controller. The velocity of the motion is defined by the user commands. These commands commands are preemptive.

move

Move with trajectory generation:

• Use case: User wants to move to a given position and stop there (e.g. home position, pick and place)
• Space: These commands can be defined either in the cartesian or joint space.
• Type: These commands are position based, either absolute or incremental.
• Continuity: Users must send feasible commands. The low-level controller will compute a complete trajectory to move from the current state (position and velocity) to the desired goal.
• Time: Users are expected to send a single command and wait for completion before sending a new one. Time of execution is defined by the trajectory generation parameters (acceleration and velocity).

Naming convention

Command names are based on the space, type and control level. The prefix identifies the control mode, it is followed by an underscore (_) and two letters identifying the space and type. For example, servo_cp is a "servo" command with a cartesian (c) position (p) goal.

Query commands

• Space: j (joint), c (cartesian)
• Type:
  • Joint: s (state: position, velocity and effort)
  • Cartesian: p (pose), v (twist), i (incremental pose), f (wrench)
• Measured: measured (physical measure from sensors)
• Control level: servoed (last servo received), commanded (last interp or move received)

Motion commands

• Space: j (joint), c (cartesian)
• Type: p (position or pose), v (velocity or twist), i (incremental position or pose), f (force, wrench or effort)
• Control level: servo (low-level), interp (basic interpolation), move (full trajectory planning)

Overview

---

Detailed API

Query commands

measured_js, measured joint state

• Payload: sensor_msgs/JointState
• Specification:
  • time Header.stamp: time of measurement [required]
  • string name[]: array of joint names [required]
  • float64 position[]: array of measured joint positions [required]
  • float64 velocity[]: array of measured joint velocities [optional]
  • float64 effort[]: array of measured joint efforts [optional]
• Notes:
  • The low-level controller can set all vectors sizes to zero to indicate an invalid joint state (e.g. robot not yet calibrated or powered).
  • velocity should be provided if the low-level controller has the ability to perform velocity estimation.
  • effort should be provided if the low-level controller has torque sensors or current feedback per joints.
  • Size of all non-empty vectors must match.

measured_cp, measured cartesian position

• Payload: geometry_msgs/TransformStamped
• Specification:
  • time Header.stamp: time of measurement, if the measured cartesian position is based on a measured joint position, the time stamp should be the same as measured_js [required]
  • string Header.frame_id: reference frame [required]
  • string frame_id: moving frame [required]
  • Transform transform: translation and rotation for the measured cartesian position (e.g. forward kinematics based on measured joint position) [required]
• Notes:
  • The low-level controller can set the transform.rotation quaternion to zero to indicate an invalid cartesian position.

measured_cv, measured cartesian velocity (twist)

measured_cf, measured cartesian force (wrench)

servoed_js, joint goal (low-level controller)

• Payload: sensor_msgs/JointState
• Specification:
  • time Header.stamp: time associated to last servo command. This can be defined by a direct servo command or an intermediary set point calculated by interp or move.
  • string name[]: array of joint names [required]
  • float64 position[]: array of goal joint positions [required iff the last command was position based]
  • float64 velocity[]: array of goal joint velocities [required iff the last command was velocity based]
  • float64 effort[]: array of goal joint efforts [required iff the last command was effort based]
• Notes:
  • All vectors position, velocity and effort must be empty except the one corresponding to the last servo command.
  • Size of all non-empty vectors must match.

servoed_cp, cartesian position goal (low-level controller)

servoed_cv, cartesian velocity goal (low-level controller)

servoed_cf, cartesian force goal (low-level controller)

commanded_js, joint goal (mid-level controller)

? should we provide velocity and/or acceleration used for interpolation or trajectory generation ?

commanded_cp, cartesian position goal (mid-level controller)

commanded_cv, cartesian position goal (mid-level controller)

? velocity based on interp and/or trajectory generator ?

Motion commands