Add support for async streaming ('joint_command')

[gavanderhoorn]

It would seem the generic nodes in industrial_robot_client do not support the joint_command interface as described in section 1.3.3 Motion Control of the ROS-Industrial Robot Driver Specification:

joint_command (trajectory_msgs/JointTrajectoryPoint)

• execute dynamic motion by streaming joint commands on-the-fly
• used by client code to control robot position in "real-time"
  • the robot implementation may use a small buffer to allow smooth motion between successive points
  • the topic publisher is responsible for providing new commands at sufficient rate to keep up with robot motion.
    • denser paths (or faster robot motion) will require higher update rates
  • this node should monitor the topic stream to ensure points are not received out-of-order (e.g. using time_from_start).
    • commands from the past should be dropped.
  • if commands are received faster than the robot can process, behavior may be implementation-dependent:
    • preferred: immediately cancel current motion and begin move to new point. As long as motion remains smooth.
    • alternative: new commands will replace the previous most-recent command on the robot-side command queue.

Support for this interface would make the generic nodes usable in situations where complete definition and/or execution of complete trajectories doesn't work (eg: visual servoing, reactive control), and would probably also make trajectory replacement possible for ros-industrial drivers that are based on simple message.

---

This came up in the March Developer Meeting (@frederickproctor) but has also been discussed before (@MuriloMartins).

[gavanderhoorn]

I realise this is functionality that is going to be difficult to implement in a cross-platform way, but we're getting more and more into the kinds of application areas that would need such an interface.

With the focus on high-bandwidth, low-latency and network based motion interfaces of mfgs lately, I'm also not sure whether doing this in simple message is the right approach: perhaps lifting the interface abstraction up one level (to the ROS API) might make more sense.

[gavanderhoorn]

On the simple message side, this would probably need support for TOPIC type JOINT_TRAJ_PT (or similar) messages. Most drivers assume SERVICE_REQUEST at the moment.

[MuriloMartins]

I've actually made changes to the Staubli driver to add support for TOPIC. I will soon push them into my staubli_experimental fork.

[gavanderhoorn]

Adding the missing-functionality label as industrial_robot_client is supposed to conform to the ROS-I driver spec.

[gavanderhoorn]

melodic-devel...Njima1572:noetic-point-streaming seems to have done this.