Skip to content
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

Added OMPLRangedPlanner class #353

Merged
merged 7 commits into from
Aug 30, 2016
Merged

Added OMPLRangedPlanner class #353

merged 7 commits into from
Aug 30, 2016

Conversation

mkoval
Copy link
Member

@mkoval mkoval commented Aug 29, 2016

This class adds logic for setting a 'range' parameter such that an
integer number of state validity checks will occur per extension. It
improves on the previous RRTConnect class in two ways:

  1. Accepts an optional 'algorithm' parameter, e.g. for PR_RRTConnect.
  2. Allows for more than one state validity checks per extension.

This also fixes #350.

This class adds logic for setting a 'range' parameter such that an
integer number of state validity checks will occur per extension. It
improves on the previous RRTConnect class in two ways:

1. Accepts an optional 'algorithm' parameter, e.g. for PR_RRTConnect.
2. Allows for more than one state validity checks per extension.
"""
def __init__(self, algorithm='RRTConnect', robot_checker_factory=None,
multiplier=1):
if multiplier < 1 or not isinstance(multiplier, int):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit weird to order these checks this way; I would reverse it for clarity.

Copy link
Member

@psigen psigen Aug 29, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, doesn't this mean that a __lt__ or __cmp__ override on multiplier could actually succeed here even if it is not an int?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that's what I was thinking (though the second case would still catch those, it's still a bit confusing).

Copy link
Member

@psigen psigen Aug 29, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it? I thought it would short-circuit the or... oh i see, that's ok.

Copy link
Member

@psigen psigen Aug 29, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, now I'm wondering if we should just not do the isinstance check. If someone wants to pass a dynamically evaluated property or something, I don't see a great reason to shut them down here if it duck-types properly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe replace it with if not multiplier >= 1: to allow such types, still catch the typical non-positive case (which might silently yield borked results), and correctly error if NaN is passed?

@mkoval
Copy link
Member Author

mkoval commented Aug 29, 2016

I think I addressed all your concerns. @cdellin and @psigen please review the changes.


# Duplicate the logic in or_ompl to convert the DOF resolutions to
# a fraction of the longest extent of the state space.
maximum_extent = numpy.max(dof_ranges)
Copy link
Contributor

@cdellin cdellin Aug 29, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, that's not what the maximum extent is ... you should use numpy.linalg.norm instead of numpy.max.

@mkoval
Copy link
Member Author

mkoval commented Aug 29, 2016

@cdellin: I addressed your comments. Could you take another look?

@cdellin
Copy link
Contributor

cdellin commented Aug 29, 2016

Looks great!

@mkoval mkoval merged commit b1902cf into master Aug 30, 2016
@mkoval mkoval deleted the bugfix/OMPLRangedPlanner branch August 30, 2016 00:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update RRTConnect wrapper to support a robot_collision_checker
4 participants