search

ros-industrial-consortium / descartes

ROS-Industrial Special Project: Cartesian Path Planner
Apache License 2.0
126 stars 92 forks source link

Made findStart/EndVertices public and const #169

Closed davetcoleman closed 8 years ago

davetcoleman commented 8 years ago

Once a Descartes planning graph is created, I need a way to get the enumerated start and goal vertices from my external program

jrgnicho commented 8 years ago

I have no objection to this change.

shaun-edwards commented 8 years ago

I realize you just made existing functions public, but I'm curious ( @jrgnicho or @Jmeyer1292 ), how does these methods not return deadends (in either direction) in the middle of the graph?

jrgnicho commented 8 years ago

@shaun-edwards , it looks like the points are checked to see if their closest neighbors hold a valid ID, when an null ID is found then it is assumed that one end of the graph has been reached.

davetcoleman commented 8 years ago

@shaun-edwards I agree I had that same thought but didn't look to deeply into it because its how the planner currently searches the graph so I assumed it had been tested enough

Jmeyer1292 commented 8 years ago

@shaun-edwards These functions essentially return all of the IK solutions associated with the very first and very last user input point to Descartes. This association between input points and the joint solutions at that point is maintained through a separate map that is being searched when these are called.

The whole system is kind of convoluted and indirect. I've been toying with ideas to fix it.

Jmeyer1292 commented 8 years ago

Also recalculateJointVertexMap really needs to be rethought. This function is actually kind of expensive and we do it every time we want to do anything with the graph (add point, remove point, build graph, search graph, etc).

davetcoleman commented 8 years ago

I was surprised to see recalculateJointVertexMap() was recalculated every time, also

Agreed on somewhat convoluted