trajectory_filter
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:
1)
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 http://code.ros.org/lurker/message/20...
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
