-
Notifications
You must be signed in to change notification settings - Fork 30
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
Refactor VFP with new Planner API #426
Conversation
This is blocking on #429 right now. Once that gets merged, I'll rebase the actual Planner API changes from this PR on top of that one, and we should be good! 😄 |
auto metaskeletonStateSpace | ||
= std::dynamic_pointer_cast<const MetaSkeletonStateSpace>(mStateSpace); | ||
if (!metaskeletonStateSpace) | ||
throw std::invalid_argument("mStateSpace is not MetaSkeletonStateSpace!"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is better to check this in the constructor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For sure! My thinking is that this would require two casts: one in the constructor to check, and one when it's actually used. Are we OK with this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NVM, this is moot with the discussion below since the type is enforced by the constructor argument now.
/// \param[out] result Information about success or failure. | ||
/// \return Trajectory or \c nullptr if planning failed. | ||
/// \throw If \c problem is not ConfigurationToEndEffectorOffset. | ||
/// \throw If \c result is not ConfigurationToEndEffectorOffset::Result. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that these two validations are not yet added in the implementation.
|
||
#include "aikido/planner/ConfigurationToEndEffectorOffset.hpp" | ||
#include "aikido/planner/ConfigurationToEndEffectorOffsetPlanner.hpp" | ||
#include "aikido/planner/vectorfield/VectorFieldPlanner.hpp" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: It's not necessary to include this header here. Please move to the source.
/// | ||
/// \param[in] stateSpace State space that this planner associated with. | ||
explicit ConfigurationToEndEffectorOffsetPlanner( | ||
statespace::ConstStateSpacePtr stateSpace); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This planner only works for MetaSkeletonStateSpace
. Please change this class to:
- take
ConstMetaSkeletonStateSpace
in the constructor - have a getter
getMetaSkeletonStateSpace()
that returns theConstStatespacePtr
by static-casting it toConstMetaSkeletonStateSpacePtr
.
to prevent passing incorrect state space in compile time.
/// checking. | ||
/// \param[in] timelimit timeout in seconds. | ||
VectorFieldConfigurationToEndEffectorOffsetPlanner( | ||
statespace::ConstStateSpacePtr stateSpace, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please change to take ConstMetaSkeletonStateSpacePtr
for the same reason above.
double initialStepSize, | ||
double jointLimitTolerance, | ||
double constraintCheckResolution, | ||
std::chrono::duration<double> timelimit); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Parameters that are not planner specific parameters should move to the problem class. @dqyi11 Could you verify all the parameters are planner specific?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the current scope of parameters defined in the problem class, which is consistent with the design in prpy
. https://github.com/personalrobotics/prpy/blob/master/tests/planning/methods/PlanToEndEffectorOffset.py
All these parameters are planner-specific. Though some of them are used in both vector field planner
and CRRT planner
, they can be set very differently (for example constraintCheckResolution
). distanceTolerance
, positionTolerance
and angularTolerance
are also not strictly aligned in planning end-effector offset between using vector field planner and CRRT planner.
Codecov Report
@@ Coverage Diff @@
## master #426 +/- ##
==========================================
+ Coverage 79.76% 80.03% +0.27%
==========================================
Files 231 235 +4
Lines 5986 6002 +16
==========================================
+ Hits 4775 4804 +29
+ Misses 1211 1198 -13
|
I think the start state should be the last thing to figure out now. @jslee02 I had to use a |
problem.getConstraint(), | ||
problem.getDirection(), | ||
// TODO: Need to handle case when negative. | ||
problem.getDistance() - mDistanceTolerance, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is better to check whether that problem.getDistance() - mDistanceTolerance
and problem.getDistance() + mDistanceTolerance
have the same sign...
…teSpace instance variable to prvent expensive dynamic casting.
I've handled the I've also made the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
This PR has changes that use the new Planner API to refactor VFP.
Right now I've only refactored
planToEndEffectorOffset
by creating the newVectorFieldConfigurationToEndEffectorOffsetPlanner
class. While these changes are looked over, I'll refactorplanToEndEffectorPose
as well.Summary of changes
Create new
ConfigurationToEndEffectorOffsetPlanner
class for theConfigurationToEndEffectorOffset
Problem.Create
VectorFieldConfigurationToEndEffectorOffsetPlanner
class that extends the above and calls the oldplanToEndEffectorOffset
method inVectorFieldPlanner
.TODOs
We need to figure out to handle the
startState
provided byConfigurationToEndEffectorOffset
. The old VFP code gets the current configuration from the metaSkeleton, so right now I just ignore this instance variable.The old VFP code took
minDistance
andmaxDistance
forplanToEndEffectorOffset
. I provide these by taking a tolerance around thesignedDistance
provided byConfigurationToEndEffectorOffset
, but we should discuss whether this is appropriate (I also need to handle the negative case).Before creating a pull request
make format
Before merging a pull request
CHANGELOG.md