Robotic Motion Planning in Real-Time | Hacker News Reader

Robotic Motion Planning in Real-Time

pratt.duke.edu

71 pointscbames8912 comments

Looks like this is the actual paper, doesn't seem to be linked in the article: http://people.ee.duke.edu/~sorin/papers/rss16_chip.pdf

Yes! That's the paper, sorry about it not being included.

This could be very very useful. A 7 DOF arm operating in an unconstrained space is a seriously intensive task to plan. The only concern I have for them as a company is if rnn based learning catches up quickly to the much more established search based planning. If they had a standard pci board we could test tomorrow that worked with a URDF and a stream of depth data, we'd almost certainly request one.

RNNs with their inexplicable output are impossible to justify in case something goes wrong. I'm not sure how secure their reliabilty is.

Finding an optimal solution is much more computationally intensive than verifying that the solution is good enough (no collisions). If you don't really trust the RNN's work, then you can use a second algorithm just to check for collisions in the proposed plan.

It does indeed work off of URDFs and streamed sensor data right now. I'd recommend contacting Sean they might be able to accomodate your request.

I was going to say that motion planning isn't a field that's standardized enough to benefit from hardware implementations. But collision checking, collision checking is something that's straightforward and very expensive so this seems like an excellent idea. Right now we think carefully about our workspaces and planning to make sure we don't have to do collision checking but that's not something you could get away with in unstructured environments.

Perhaps, but I was under the impression GPUs have greater power efficiency than general purpose processors at least some of them have physics support (collisions, etc.) these days. Since the problems are primarily spatial, shouldn't even GPUs without dedicated collision detection in hardware easily support reasonable speed prediction? (eg. Simple CSG[1]-style union?) Is this purely about power consumption, as suggested in the article? (Surely a low-res approach with area-of-interest identification for potential collisions to suggest higher-res calculation could speed things up, in the same way "I've got a bad feeling about this" makes us think twice? Perhaps someone with more knowledge of the algorithms could clarify?)

[1] https://en.wikipedia.org/wiki/Constructive_solid_geometry

There certainly has been research into the application of GPUs to motion planning. However, the paper presented is faster, and results in power consumption, approximately 10% of the power consumption of the GPU for the same task.

Now that the paper has been posted, it does seem it's not just about power consumption but also parallelism. Although these factors were discussed in the conclusion with reference to their suggestion for future R&D with a hardware-based approach, the reality for implementors now is that commercial availability, cost and solution development time probably do heavily favour usible mobile GPUs. The biggest drawback in the paper seems to be that if the robot's physical configuration changes (for example, an arm is bent or it picks up a large object) the planning circuitry may no longer be accurate.

Finally, I couldn't help but think of this quote: Sin #3 - Picking the low-hanging fruit: It is unsurprising that it is easy to beat a general system by specializing it. Few researchers comment on the composability of their solutions. - Schwarzkopf et al, 'The seven deadly sins of cloud computing research' (2014) https://github.com/globalcitizen/taoup

I suspect this could also benefit path planning for autonomous ground vehicles (e.g. self-driving cars).

It can help in the region immediately surrounding the vehicle. The PRM graph that is developed is built with reference to the robot, so if the robot moves around so does its capability to plan.

Reply on news.ycombinator.com