Revision history [back]

Hello sedwards, thank you for replying.

The filters.yaml file should be like this one (in this moment I have not the laptop on which we run ROS, I took this from the stack repository, but I don't remember to have modified it)

service_type: FilterJointTrajectoryWithConstraints filter_chain: - name: unnormalize_trajectory type: UnNormalizeFilterJointTrajectoryWithConstraints - name: cubic_spline_short_cutter_smoother type: CubicSplineShortCutterFilterJointTrajectoryWithConstraints params: {discretization: 0.01}

Also the joints_limits.yaml could play a role in this issue? It is also left as default, however.

Anyway: by now I've wrote a simple workaround (not so efficient, though), I just replan everything if the trajectory filter chain fails. (I tried to do this inside move_arm, before, without success - the filter chain kept failing again and again, so I just do this at an higher level in my code, checking the final result). After a fail, the subsequent trial always go well, so it is acceptable for now. I have a failure every 8-10 requests, I think.

Anyway it would be great to avoid the filter chain failure at all... Removing one of the two filters could solve the issue, but it could also cause worse trajectories, am I right?

I've not investigated the reason which filter fails, and why, maybe there's a solution at that level...