Industrial Robot Client: best practice for implementing JOINT_TRAJ_PT_FULL msg
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:
Members:
- current_traj_ To a std::vector of JointTrajPtFullMessage or the more general SimpleMessage
Functions
- 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?
Thanks
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.
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?
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.
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.