ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Industrial Robot Client: best practice for implementing JOINT_TRAJ_PT_FULL msg

asked 2016-10-19 02:05:50 -0500

mmoerdijk gravatar image

I'm currently working on implementing an custom Industrial Robot Server that talks with the default industrial robot client using the trajectory streamer interface. I got the communication between the robot and the robot client working, but now I want the robot client to send JOINT_TRAJ_PT_FULL messages instead of JOINT_TRAJ_PT messages.

As far as I know the only robot driver that implements this types of messages is the motoman driver. I've been looking at the source code for this driver and the code for the default robot_client. As far as I can see the motoman driver duplicates a lot of code, basically to replace JointTrajectoryPoint with JointTrajPtFull and JointTrajPtMessage with JointTrajPtFullMessage (of course they implement some other stuff as well, but I'm only interested in the JOINT_TRAJ_PT_FULL message part).

As far as I can see I would at least need to adapt the following parts of the JointTrajectoryStreamer class:


  • current_traj_ To a std::vector of JointTrajPtFullMessage or the more general SimpleMessage


  • jointTrajectoryCB
  • trajectory_to_msgs
  • send_to_robot()
  • create_message
  • trajectoryStop (Although not really necessary)

This seems not very efficient to me, is this the intended way of implementing JOINT_TRAJ_PT_FULL messages? If so why is the JointTrajPtMessage part of the general SM protocol and not a motoman specific message type?


edit retag flag offensive close merge delete


I'll post an actual answer later, but if you are interested in adding multigroup support, then it might make more sense to implement an IRCv2 server. I've sent you an email off-list. Let's discuss things there.

gvdhoorn gravatar image gvdhoorn  ( 2016-10-19 04:19:01 -0500 )edit

At the moment I'm not interested in multigroup support, but maybe in the future. The only info I could find on the IRCv2 is REP I0001. Is there an implementation available, or do I need to implement this from scratch?

mmoerdijk gravatar image mmoerdijk  ( 2016-10-19 06:34:09 -0500 )edit

There is an implementation, but it's not released as such. I'd suggest you contact us through the mailing list (preferred) and / or personal email to discuss this. For new drivers, I think actually starting with IRCv2 would be preferable.

gvdhoorn gravatar image gvdhoorn  ( 2016-10-19 07:06:08 -0500 )edit

Btw, the IRCv2 does not only do multi-group, but it supports dynamic msg structures as well. This means that the max nr of joints is essentially the twos-complement max of a 32bit signed integer. And mapping between joint names and msg indices is done much nicer as well.

gvdhoorn gravatar image gvdhoorn  ( 2016-10-20 04:55:32 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2016-11-08 02:59:56 -0500

mmoerdijk gravatar image

Also to Answer my own question: the best practice for new IRS would be to go with the IRCv2

edit flag offensive delete link more


I just want to add that IRCv2 means - industrial ROS core version 2. And you can find the source code here:

ManMan88 gravatar image ManMan88  ( 2017-11-30 10:00:57 -0500 )edit

Question Tools



Asked: 2016-10-19 02:05:50 -0500

Seen: 146 times

Last updated: Nov 08 '16