industrial_robot_simulator disregards trajetory header timestamps

[BrettHemes]

As the title states, the industrial_robot_simulator seems to ignore completely the header timestamp in joint trajectories sent via the joint_trajectory_action interface.

Ultimately this results in inconsistent behavior between the simulator behavior (expected) hardware joint_trajectory_controller behavior (see ros_industrial/kuka_experimental/#69). Additionally, other capabilities of joint_trajectory_controller are not achievable via the simulator such as the ability to chain trajectories together via preemption using future trajectories.

[gavanderhoorn]

Thanks for reporting this.

[shaun-edwards]

@BrettHemes, what is the expected behavior of the JointTrajectory timestamp?

[BrettHemes]

The trajectory is supposed to start execution at ros time = header.stamp
with each point's time_from_start relative to that.

I am on my phone now but the joint_trajectory_controller wiki page has a
good write-up and a link to the preemption behaviour that relates well and
has pictures.

[gavanderhoorn]

joint_trajectory_controller - Sending trajectories - Preemption policy and Understanding trajectory replacement.

[BrettHemes]

Thanks Gijs :)

[gavanderhoorn]

I'm not sure how much sense it makes to reimplement all that in the Python script that is the industrial_robot_simulator, especially since that script is supposed to provide a ROS API-level simulation of the ROS-Industrial driver spec. Not of a ros_control compatible joint_trajectory_controller.

Also: the joint_trajectory_controller in industrial_robot_client doesn't support trajectory splicing / replacement, so in a way, the industrial_robot_simulator is providing a faithful simulation working slightly better than the real thing as it doesn't error out :).

If we really want this (trajectory replacement), it might be an idea to implement a simulation hardware_interface so that we can run a normal ros_control stack on top of that. That would get us all of this 'for free' (as we'd be simply making use of the support ros_control has for this).

[shaun-edwards]

@gavanderhoorn, it seems odd to me that such a "simulation" doesn't already exist as part of the ros_control package.

[gavanderhoorn]

Dave's boilerplate contains something like it (sim_hw_interface), but afaik there is no such thing in ros_control proper.

[rsinnet]

@gavanderhoorn @shaun-edwards Do you know of any attempt to integrate ros_control with ros-industrial to make trajectory replacement available?

[gavanderhoorn]

I'm not aware of anyone having implemented a simple_message/industrial_robot_client compatible ros_control hw interface, unfortunately.

If you'd be interested to work on one, that would be great. I would recommend we discuss possible approaches first though, as there are some assumptions in industrial_robot_client nodes that server implementations (ie: robot drivers running on controllers) depend on.

[rsinnet]

@gavanderhoorn I want to do an implementation for the FANUC LR Mate 200iD. Any information on assumptions I need to be aware of would be very much appreciated. Thanks!

[gavanderhoorn]

I'm slightly confused: any implementation wouldshould work with all streaming/downloading server implementations, not just for a single robot variant.

As to Fanuc: as long as you don't expect it to improve trajectory execution performance. Fanuc has one of the worst motion interfaces.

Let's not hijack this issue any further. Could you open a new issue where we can discuss a potential simple_message_hw_interface implementation?