This PR removes planToConfiguration() from robot/util, and updates the corresponding function in ConcreteRobot to use a snap planner.
We actually don't remove the method completely from robot/util, just the header: it's needed elsewhere in the .cpp file.
TODO/WIP:
Should we use the normal ConfigurationToConfiguration planner, or the DART version? Both work fine here and the normal version requires less cruft, so I've gone with that. LMK your thoughts!
Should we construct the planner in ConcreteRobot -> planToConfiguration, or have a planner member var in ConcreteRobot? The reason I didn't do this is because the MetaSkeleton passed to the planner constructor(s) may not match the metaSkeleton argument of planToConfiguration().
Before creating a pull request
[ ] Document new methods and classes
[ ] Format code with make format
Before merging a pull request
[ ] Set version target by selecting a milestone on the right side
This PR removes
planToConfiguration()
fromrobot/util
, and updates the corresponding function inConcreteRobot
to use a snap planner.We actually don't remove the method completely from
robot/util
, just the header: it's needed elsewhere in the.cpp
file.TODO/WIP:
ConfigurationToConfiguration
planner, or the DART version? Both work fine here and the normal version requires less cruft, so I've gone with that. LMK your thoughts!ConcreteRobot -> planToConfiguration
, or have a planner member var inConcreteRobot
? The reason I didn't do this is because theMetaSkeleton
passed to the planner constructor(s) may not match themetaSkeleton
argument ofplanToConfiguration()
.Before creating a pull request
make format
Before merging a pull request
CHANGELOG.md