[ros-users] [Discourse.ros.org] [ROS-Industrial] Streaming Motion Interfaces

[gavanderhoorn]

Nice post @Jmeyer.

I believe the way forward here would be `ros_control`, as it seems to directly support the two technical bullets in your list.

Some history first though: the nodes in `industrial_robot_client` (and any OEM specific drivers) were actually supposed to be outfitted with an "on the fly real-time streaming" interface. Right now, only the `/joint_path_command` topic is subscribed to, but the [Motion Control](http://wiki.ros.org/Industrial/Industrial_Robot_Driver_Spec#Industrial.2BAC8-Industrial_Robot_Driver_Spec.2BAC8-hydro.Motion_Control) section of the driver spec also includes a `/joint_command` topic:

>  - 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 is currently not there ([ros-industrial/industrial_core#139](https://github.com/ros-industrial/industrial_core/issues/139)) as at least back then the interfaces to motion controllers were so limited that the impression was that a (semi) downloading approach would always perform better, but the idea seems to at least conceptually correspond to what you have in bullets 1 and 2. Message type would be [trajectory_msgs/JointTrajectoryPoint](http://docs.ros.org/api/trajectory_msgs/html/msg/JointTrajectoryPoint.html).

However, I don't believe it makes sense for us to add that to `industrial_robot_client` or any of the other drivers we have that are IRC based: `ros_control` can already do this, and has one additional advantage: it supports on-line [trajectory replacement](http://wiki.ros.org/joint_trajectory_controller/UnderstandingTrajectoryReplacement) with the [ros_controllers/joint_trajectory_controller](http://wiki.ros.org/joint_trajectory_controller).

Trajectory replacement *can* be a nice way to get both behaviours in a single driver I believe:

 - send a single trajectory and wait for completion: 'traditional' trajectory execution
 - send a trajectory and whenever the need arises send an updated one: blend current and new trajectory in a meaningful way (ie: keep smoothness and continuity)

"in the limit" this can become a single-point streaming interface -- we've almost used it as such here in the lab with a system where we sent the controller very short trajectories (a few hundred ms max each) with three points: `[current_pose; destination_pose; controlled_stop_pose]`. The idea was that if the real-time planner couldn't generate new destination poses within its deadline, the trajectory controller would make the robot do a contolled stop at the last point in the trajectory 'segment'. If everything worked correctly, the robot only moved to `destination_pose` with each update of the trajectory.

The `joint_trajectory_controller` is not perfect (iirc it's not jerk-limited at the moment fi (which is probably the cause of [ros-industrial/kuka_experimental#126](https://github.com/ros-industrial/kuka_experimental/issues/126) and others) so it could use some work, but I believe it could allow us to do what you want with the least amount of work.

The "only" thing we need to do is implement `ros_control` `hardware_interface`s for robots and that's it. And writing such `hardware_interface`s becomes easier and easier now that more and more (industrial) robot controllers provide high-bandwidth external motion interfaces (ABB EGM, KUKA RSI, Mitsubishi MXT, Denso b-CAP, etc, etc).

---

Summarising: I would be very much in favour of having this sort of ROS API for all our supported robots and I believe that most of this is already all there (although some parts could use some work), except for the `hardware_interface`s that we'd need to be able to use `ros_control` for this.

---

Edit: as to the test setup: yes, please. I've had something like that on my list for so long, but never found the time for it. A colleague here in the lab has done some preliminary work based on [floweisshardt/atf](https://github.com/floweisshardt/atf) where robots (or really: their drivers) are made to execute specific motions with all sensor data recorded for later analysis. I'm sure there are other implementations available of this idea that go much further.





---
[Visit Topic](https://discourse.ros.org/t/streaming-motion-interfaces/5858/3) or reply to this email to respond.