New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase collision checking interval #337

Merged
merged 1 commit into from Nov 10, 2016

Conversation

Projects
None yet
3 participants
@davetcoleman
Member

davetcoleman commented Oct 31, 2016

I'm trying to improve the reliability of planning requests in the move_group_interface_tutorial as described in this issue. I benchmarked two tests, 100 runs each:

  1. Planning with orientation constraint
  2. Planning around simple cuboid obstacle

I'm finding 3 problems:

  • KPIECE solver is unreliable. Solution: remove projection_evaluator from ompl_planning.yaml (see #197)
  • Planning time is too short. 10 seconds is much better than the 5 used by default for orientation
  • longest_valid_segment_fraction (collision checking resolution) is too small

My results:
collision_checking_peformance

From this I recommend we change the default longest_valid_segment_fraction to 0.005, even though I just recently had a similar PR for this that only went half way: 3c760fe

Another option would be even finer at 0.001, but

  1. that is only necessary for constraint planning and I think that is much less common
  2. that is a much much bigger computational load
  3. in my years of using moveit i've always used 0.005 for various robots (Jaco2, Baxter, PR2, HRP2)

@v4hn v4hn merged commit 20cdd9f into ros-planning:kinetic-devel Nov 10, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@v4hn

This comment has been minimized.

Show comment
Hide comment
@v4hn

v4hn Nov 10, 2016

Member

Ok, this increases default planning time by a lot again, but I guess it's necessary.
Merging

Member

v4hn commented Nov 10, 2016

Ok, this increases default planning time by a lot again, but I guess it's necessary.
Merging

@davetcoleman davetcoleman deleted the davetcoleman:kinetic-valid-segment-fraction branch Nov 10, 2016

@130s

This comment has been minimized.

Show comment
Hide comment
@130s

130s Jan 4, 2017

Member

This doesn't seem to be backported to IJ. Any idea?

Member

130s commented Jan 4, 2017

This doesn't seem to be backported to IJ. Any idea?

@davetcoleman

This comment has been minimized.

Show comment
Hide comment
@davetcoleman

davetcoleman Jan 4, 2017

Member

I do not think it should be ported backwards because it slows down solution time (although it also improves quality of solution)

Member

davetcoleman commented Jan 4, 2017

I do not think it should be ported backwards because it slows down solution time (although it also improves quality of solution)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment