Closed wlawler45 closed 3 years ago
It sounds as if the packet transmission is slow. Do you have a direct connection to the controller or are you going through an large network with lots of traffic? Noise causing interference on the communication? Another possibility is that you have something else running on the controller that is requiring a lot of CPU. The MotoRos communication and motion parsing tasks are at a normal priority which is lower than the controller core software. Normally that is not a problem but if there is another MotoPlus application or a job that running in a loop without any delay it cause side affect.
It should just be me and the controller on the ethernet switch, but I am running a virtualbox, would that make the difference?
Maybe the virtualbox is causing delay? You might want to do a Wireshark capture of the communication and where the delay is. How often is Ros sending motion message to the controller? How fast is the reply from the controller? Is the controller replying with busy signal?
could I check the busy signal with ros? I'll try that and let you know.
The MotoRos has an internal queue that can accumulate up to 800 ms of trajectory (it usually helps with communication variation). When this is full and it gets more information, it will send back a busy signal. The ROS side should automatically be resending the message until the queue cleared up and the next message is accepted. I'm not sure how to expose that on the ROS side.
Another thing is its not consistently pausing, it pauses at some specific points along the curve, there shouldn't be any singularities or anything there either so I don't know why it's doing that.
Without seeing a trace and/or the trajectories which exhibit this, I would hazard the guess you're using MoveIt and are using the default IPTP for time parameterisation.
That is known to not always result in the most smooth paths.
I would repeat @EricMarcil's request and suggest you create a Wireshark capture so we can see exactly what sort of traffic gets send to the controller. Next to that, capture the trajectory which is the result of "plan with compute cartesian move" and attach that here as well.
I believe it has something to do with the actual motoman ros code
could you substantiate this a bit? There are a lot of parts involved here, so singling this out without more info seems a bit random.
there shouldn't be any singularities or anything there either
as MotoROS only has joint space interfaces singularities do not really affect anything here afaict.
Okay, here is the wireshark capture you asked for, let me know if I did anything incorrectly in capturing this, I'll include the trajectory in a second. motoman_motion_wireshark_capture.pcapng.gz
Here is a Rosbag with the trajectory in it, anything else I can provide just let me know. Thanks again for all the help. 2020-10-30-13-01-13.bag.tar.gz
If it is a moveit time parameterization issue, what would you recommend I use? What planner would give the smoothest time parameterization?
The data transmission looks good. I can see two trajectory being send. The transmission time is shorter than the commanded trajectory time. I can see the initial command being accepted right-away and then once the motion buffer is full reply with busy response. The motion point is repeatedly sent until space frees up and it is accepted.
I don't have a good tool for visualizing the motion but it does look in the 2nd trajectory that speeds are fluctuating up and down. So I would tend to say the problem is on the path generation side.
I've tried another few planners in OMPL but I'm still having the same issues @gavanderhoorn do you have any suggestions to help get a better timed trajectory so I have smoother cartesian motions?
Without knowing exactly what you are doing, I can only provide suggestions. Perhaps using one of the alternative time-parameterisation algorithms helps. The spline based one works OK-ish in most cases. But perhaps TOTG is better.
As I don't know whether you're using computeCartesianPath(..)
or something else ("compute cartesian move" is ambiguous), I can't say whether that's possible or not.
I haven't had time to look at the trajectory yet. ROS messages easily serialise to YAML, so next time please just rostopic echo -n1 /topic/with/the/goal > trajectory.yaml
instead of creating a .bag
.
I'll extract the message and plot it.
Okay, I am using ComputeCartesianPath if that helps, I'll look into the other time-parameterisation algorithms there and see if I can get the real robot moving in a more smooth fashion. I'll keep that in mind in the future, thank you for letting me know.
Here is the trajectory from the bag, which is sent to the trajectory relay:
And here is a plot of the commanded positions, velocities and accelerations per joint:
No derivatives, all values straight from the trajectory.
At this point I'm inclined to believe the driver is doing what is asked of it, and the cause of what you observe would be in the trajectory.
Notice especially the acceleration plots. That's not a very nice trajectory.
And seeing those accelerations almost bounded by +- 1 rad/sec^2
: do you have correct/appropriate/reasonable acceleration values configured in your MoveIt configuration?
If you don't (and by default there will be no acceleration limits configured), MoveIt's time-parameterisation algorithms will use 1 rad/sec^2
for all joints.
@gavanderhoorn wrote:
At this point I'm inclined to believe the driver is doing what is asked of it, and the cause of what you observe would be in the trajectory.
As such, I'm going to close this issue.
If it turns out this is something we need to address here (in motoman_driver
or MotoROS), we can update and re-open.
Feel free to keep commenting on the issue of course.
@gavanderhoorn Thanks for plotting that out and confirming what I was seeing.
@wlawler45 What controller and robot are you using? Are you using a URDF from the repo or one that you created?
@EricMarcil Hello again, so I'm using the YRC1000 and the GP12, and I should be using a URDF from their repo with just an added simple end effector, question as well, if I'm going to use FTP, with the Robodk post processors I need a remote file location on the motoman to save the programs to do you know what that would be? Let me know. Thanks.
@wlawler45: could you please not post off-topic comments here?
This issue tracker is for issues related to ROS, specifically the motoman
packages.
Please use appropriate support channels for other questions.
@wlawler45 You can reach at my Motoman address: eric.marcil@motoman.com
Hello I'm having an issue moving the motoman in a consistent manner, the RViz motion view looks fine when I plan with compute cartesian move, and I've tried a number of methods to try and replan and execute the trajectory correctly and it keeps but the real robot consistently has these jerky motions where it slows almost to a stop in the middle of the trajectory, the application we are working on requires very smooth trajectories, I believe it has something to do with the actual motoman ros code but I'm not sure. Has anyone else experienced this issue? If so what should I do? Any feedback is appreciated.