Ask Your Question


asked 2011-02-28 03:32:41 -0500

Felix Messmer gravatar image

Dear community,

I have some questions about the trajectory_filter...

First of all, here is how we currently set it all up:

  • cob_arm_navigation/cob3_trajectory_filter.launch (sorry, can't post or attach the file on answers.ros)

  • cob_arm_navigation/filters.yaml (dito)

  • in cob_arm_navigation/cob3_move_arm.launch:
    "trajectory_filter_allowed_time" type="double" value="2.0"

This is actually the configuration that I took from the pr2_arm_navigation tutorials a while ago...adopted to the care-o-bot...but I never looked into it more closely.

When I now do planned motion using the OMPL planner or our own PRMCE planner (which I am currently implementing and testing; for the idea behind it see Leven&Hutchinson: "A Framework for Real-time Path Planning in Changing Environments"), we come across some problems:


Moving from a collision-free position to our home position using OMPL planner, I sometimes (not always) get the following EXCEPTION from the trajectory_filter

Info: LBKPIECE1: Starting with 2 states Info: LBKPIECE1: Created 36 (21 start + 15 goal) states in 32 cells (18 start + 14 goal) But the filtered trajectory does have filled time_from_start and also the movement in visualization does reach the goal. Also, the planned trajectory does already have a duration time_from_start, which starts with 0.0 for the first trajectory point and than adds 10 ms per point (equidistant).

2) BTW, why does the planned trajectory (PATH?) already include time_from_start?

After the trajectory filter they seem to be adjusted and not equidistant anymore. How are these new time_from_start s calculated and where? I guess it's with respect to the distance of the neighboring trajectory points and the max_vel of the arm.

As described in

we also have problems with moving on that filtered trajectory! We first assumed that it has something to do with the dynamic model of the arm, but maybe it's just because the arm can not hold the velocities that derives from these time_from_start s.

Since, when setting the time_from_start to about 2 seconds per trajectory point, it works fine.

I'd be pleased to hear some of your opinions on this! Also, if anybody has suggestions on other/better trajectory_filter configurations, please let me know!!!

As always, if you have questions or need more details, let me know as well!

Thanks! Felix

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2011-02-28 05:44:13 -0500

Sachin Chitta gravatar image

Hi Felix,

Here's the answer to the 2nd part of your question - how does the trajectory filtering work right now?

The trajectory filter takes paths from the planner and "shortcuts" them with cubic splines to try and find a smoother path to the goal. It does this by trying to connect random waypoints on the plan using acceleration and velocity bounded cubic splines. This is why you see the time_from_start change for the waypoints - the trajectory_filter is changing them so that the resultant trajectory obeys velocity and acceleration constraints and is also collision-free.

The reason your arm cannot track these trajectories probably has more to do with your controller. You can decrease the acceleration and velocity limits so you get slower trajectories, here's where those parameters are specified -

The planners are free to give back just paths and leave the time_from_start parameter at 0. OMPL just chooses to specify a nominal time there with the assumption that a post-processing step will take care of the parameterization into a trajectory.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2011-02-28 03:32:41 -0500

Seen: 336 times

Last updated: Feb 28 '11