Open BrettHemes opened 8 years ago
Thanks for reporting this.
@BrettHemes, what is the expected behavior of the JointTrajectory timestamp?
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.
Thanks Gijs :)
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).
@gavanderhoorn, it seems odd to me that such a "simulation" doesn't already exist as part of the ros_control
package.
Dave's boilerplate contains something like it (sim_hw_interface
), but afaik there is no such thing in ros_control
proper.
@gavanderhoorn @shaun-edwards Do you know of any attempt to integrate ros_control
with ros-industrial
to make trajectory replacement available?
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.
@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!
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?
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 ofjoint_trajectory_controller
are not achievable via the simulator such as the ability to chain trajectories together via preemption using future trajectories.