search

ros-industrial / industrial_core

ROS-Industrial core communication packages (http://wiki.ros.org/industrial_core)
154 stars 181 forks source link

Add support for async streaming ('joint_command') #139

Open gavanderhoorn opened 8 years ago

gavanderhoorn commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

gavanderhoorn commented 3 years ago

https://github.com/ros-industrial/industrial_core/compare/melodic-devel...Njima1572:noetic-point-streaming seems to have done this.