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.
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.
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?)
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
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.
