Moveit2 Servo (Real-time Servo-ing) and MotoROS2. #344
Replies: 1 comment 5 replies
-
|
Hello @cboostpverwimp
Any points whose time is not in the "future" will be discarded. So the robot will not attempt to move to that point. However, it looks like the
It is fifo. The last request is appended to the queue.
For real time servoing, I don't think that MotoROS2 (in its current form) is going to work well. In the future, we'd like to add such capability. But it's not there yet. You may want to look at another ROS2 implementation, such as https://github.com/adv4ncr/motoman_ROS2 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the swift response!
That is what I expected to happen but it seems more like the opposite happens: Every update a point with I might be using this service completely wrong, but it gets okay results up to now. If so how would you recommend improving on the timing?
I am sorry, I am not sure what you mean by this. Could you elaborate?
Thanks for the recommendation, I will look into this. |
Beta Was this translation helpful? Give feedback.
-
|
I am confused about the last two entries in that log. There is a loop which takes the points that you provide and breaks those down into This check on the time value should cause it to skip that loop entirely. Then it should move on to the next point you submitted. The intended usage of
Although the current point didn't get broken into increments, it becomes the starting point when processing the next point. |
Beta Was this translation helpful? Give feedback.
-
This is very helpful.
What currently happens is:
This iterates while MoveIt Servo runs. |
Beta Was this translation helpful? Give feedback.
-
@ted-miller already commented on this, but just to emphasise: the It is not a real-time motion interface. There are multiple buffers between the queue appended to and the one internal to the controller's motion controller. The best possible performance would be achieved if subsequent points keep incrementing In your case that might mean basically keeping a 'running counter', and multiplying that by your desired delta-t (which I believe is around 33 ms). This should avoid MotoROS2 assuming new trajectories are started when you send a point with Edit: ok, so in more words what @ted-miller phrased as:
|
Beta Was this translation helpful? Give feedback.
-
|
To perhaps draw (even) more attention to it:
MoveIt Servo supports For Servo specifically, that means it assumes the FJT action server supports online trajectory replacement. That's not true for the FJT action server in MotoROS2. Servo further (implicitly) assumes there is a high-bandwidth, low-latency interface exposed by the robot driver you're trying to use it with. That's because the original/main developers were using robots with such interfaces at the time ( The Given this, I'm not sure the (implicit) assumptions in Servo hold, and I'm wondering whether MotoROS2 can be used with Servo as it's intended to be used. |
Beta Was this translation helpful? Give feedback.
-
Setup
MotoROS2: humble 0.1.3
Controller: YRC1000micro
Robot: Yaskawa Motomini
Situation
What I am trying to achieve is (near) real-time servoing using MoveIt Servo.
MoveIt Servo publishes
JointTrajectoryto a set topic, (in my configuration) usually containing around 6JointTrajectoryPointsfrom the current/joint_statesto a target position.Currently I am calling the
/queue_traj_pointservice to share theJointTrajectoryPointsgenerated by MoveIt Servo.These points contain a
time_from_startfromT=0.0toT=0.165which resets every update (0.033 s). Which causes some issues, jittery motion from time to time, warnings from the controller;Warning: Group 0 - Time difference between endTrajData (0) and startTrajData (0) is 0 or less., and trailing behind the planned motion.I have tried decreasing the amount of
JointTrajectoryPointsto the last 2 generated every update and lowering thetime_from_startto aboutT=0.033andT=0.066which drastically improves the movement, reduces jitter and trailing. Sadly it is not yet at a point where it is reliable and responsive enough for my application. I have noticed that the controller does not move to every calledJointTrajectoryPointbut seems to skip some. Which is beneficial for reaching near real-time speeds, but is is not clear to me how the controller handles theseJointTrajectoryPoints.Current DEBUG looks something like this:
Questions
/queue_traj_pointcalls when thetime_from_startin a new request is smaller than request which are already queued up?JointTrajectoryPointsget deleted from the queue?time_from_startor does the last request get added to the end of the queue?Beta Was this translation helpful? Give feedback.
All reactions