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

mmoerdijk's profile - activity

2021-10-20 13:27:36 -0500 answered a question async/await in subscriber callback

In the call back you should use run_coroutine_threadsafe See: https://docs.python.org/3/library/asyncio-task.html#schedu

2017-09-23 02:03:21 -0500 received badge  Famous Question (source)
2017-02-28 13:08:46 -0500 received badge  Famous Question (source)
2016-11-08 12:20:59 -0500 received badge  Notable Question (source)
2016-11-08 02:59:56 -0500 answered a question Industrial Robot Client: best practice for implementing JOINT_TRAJ_PT_FULL msg

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

2016-11-08 02:58:38 -0500 received badge  Popular Question (source)
2016-10-20 05:31:01 -0500 received badge  Student (source)
2016-10-19 06:34:09 -0500 commented question Industrial Robot Client: best practice for implementing JOINT_TRAJ_PT_FULL msg

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?

2016-10-19 02:05:50 -0500 asked a question 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

2016-10-14 00:58:33 -0500 received badge  Notable Question (source)
2016-10-13 02:49:45 -0500 received badge  Supporter (source)
2016-10-13 02:49:35 -0500 received badge  Scholar (source)
2016-10-13 02:49:33 -0500 commented answer Industrial robot client : Are start and end sequence numbers not genenrated by default ?

I don't know how I could miss that comment. Thank you for creating the issue and answering my question.

2016-10-13 02:39:52 -0500 received badge  Popular Question (source)
2016-10-13 00:38:31 -0500 commented question Industrial robot client : Are start and end sequence numbers not genenrated by default ?

Yes would have been better, but I started out 3 weeks ago with ROS and did really know where to start asking :-). What would have been the right place to ask for a few pointers on implementing a "industrial robot server" it seems to me that it is a too general question for answers.ros.org .

2016-10-12 14:21:45 -0500 commented question Industrial robot client : Are start and end sequence numbers not genenrated by default ?

Thanks, didn't know that document, could have saved me some time if I had know about it before :-). Was actually thinking about writing a similar document myself. Is there by any change more documentation about adding non standard messages? I'm now looking at the motoman rep to see how they did it.

2016-10-12 09:37:09 -0500 asked a question Industrial robot client : Are start and end sequence numbers not genenrated by default ?

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 I'm now stuck on the detection of the start and end of an trajectory. This page http://wiki.ros.org/Industrial/Tutori... states the following:

SEQ_NUMBER – The sequence number is the number assigned by ROS to each of the points (i.e. this is always 0 or positive). A value of -1 indicates the end of a trajectory, a value of -2 indicates a stop (in both cases the controller stops, joint data is not valid for these special types)

And from: https://github.com/ros-industrial/ind...

I get that there are a few more "special" sequence numbers:

START_TRAJECTORY_DOWNLOAD  = -1, ///< Downloading drivers only: signal start of trajectory
START_TRAJECOTRY_STREAMING = -2, ///< deprecated, please use START_TRAJECTORY_STREAMING instead
START_TRAJECTORY_STREAMING = -2, ///< Streaming drivers only: signal start of trajectory
END_TRAJECTORY  = -3, ///< Downloading drivers only: signal end of trajectory
STOP_TRAJECTORY = -4  ///< Server should stop the current motion (if any) as soon as possible

However if I use Wireshark to look at the messages that are send to the robot I can see 18 messages been send but don't see the special sequence numbers -2 (START_TRAJECOTRY_STREAMING )or -3 (END_TRAJECTORY). However if I manually stop the trajectory the -4 (STOP_TRAJECTORY) is generated.

Could someone give me a few pointer as to where the special sequence numbers are generated, and why the are not generated in my case?

I'm using ros Jade on Ubuntu 14.04 LTS with kernel 4.2.0.42 with all the latest packages installed from: http://packages.ros.org/ros/ubuntu repository.

2016-09-28 07:59:34 -0500 received badge  Enthusiast