9 ms·

Custom Processor Speeds Up Robot Motion Planning

narrator 10y ago
This could be used in reverse as a robot trainer for fencers by setting it to find a way to make a collision with objects instead of avoiding them.
- jmcmahon443 10y ago
  This is a much easier problem to solve. There are certainly different ways in which objects can collide though, so that would make the problem more interesting and complex.
- dmoy 10y ago
  Better would be a robot for practicing footwork distance. Probably easier to implement and more beneficial for training. Bladework is less important.
joe_the_user 10y ago
I would like to know what about motion planning makes it more suitable for a FPGA than a GPU. Wasn't able find any scholarly papers on this particular project searching the various references. Can any supply some more information?
- colechristensen 10y ago
  When concerned with robotics, several obvious ones come to mind around power and footprint.
- cbames89 10y ago
  Here's the original paper: http://people.ee.duke.edu/~sorin/papers/rss16_chip.pdf http://people.ee.duke.edu/~sorin/papers/rss16_chip.pdf In short: collision detection checking across all of the edges in a PRM graph takes 99% of planning time and can be done compeletely independently.
- dr_zoidberg 10y ago
  It's very easy to go from FPGA "source code" to a foundry and get a chip with exactly the same thing implemented, and at a cheap price if your scale is large enough.
  - IshKebab 10y ago
    Yeah but why can't you do it on a normal CPU or GPU?
    - douglasfshearer 10y ago
      You can do both CPU and GPU, but time and power consumption are both order-of-magnitude worse than using dedicated hardware. The robotic arms are also used untethered in factories, where having a computer near them is inconvenient. The article describes results for using a Xeon CPU. The linked paper cites other papers where a GPU was used.
  - trsohmers 10y ago
    I said the same thing a year ago when I had FPGA synthesized verilog and decided to go get a real chip made. Closing timing along with optimizing for PPA for an ASIC vs an FPGA is a royal PITA. And that's just on the front end design work... A core on a FPGA gives you no real idea when it comes to placement or all of the other hurdles of the backend flow of a real ASIC! We ended up re doing everything (which overall was a good thing, as we made a lot better decisions from the beginning by redesigning), but that's show biz.
    - jhallenworld 10y ago
      This used to be Altera's "Hardcopy" advantage: an easy gate-array version of their FPGAs could (in theory) be made because: 1. the gate array uses the same gates as the FPGA, just the interconnect is customized. 2. Use Primetime compatible timing constraints for the FPGA design to begin with.
      - trsohmers 10y ago
- p1esk 10y ago
  For this task, I think a GPU should be faster than an FPGA in the same price range, but it will be less power efficient. Source: I looked at CPU vs GPU vs FPGA vs ASIC for deep learning algorithms.
mooneater 10y ago
The slowness of this arm makes it hard/impossible to highlight planning speed.
- Pica_soO 10y ago
  Yep, industrial robots this is about 5 % of the usual speed.
- iandanforth 10y ago
  This is incorrect. There is usually a huge delay before any motion happens. The speed of that motion is independent of the planning speed. If you have to replan during a move then yes the two can become intermingled, but if you watch most ROS based planning today what you see is a good 30 seconds of compute before the robot moves at all. Sometimes it can be multiple minutes!
Rodeoclash 10y ago
I think we'll look back at movies like "The Terminator" and its slow lurching robots with a wry sense of humour. Instead the future is going to give us robots that can move so fast that they're just visual blurs. As part of Mr. Lee's good neighbor policy, all Rat Things are programmed never to break the sound barrier in a populated area. But Fido's in too much of a hurry to worry about the good neighbor policy. Jack the sound barrier. Bring the noise.
gradstudent 10y ago
Here's my interpretation of the result (posted in the hope that it will aid others): The authors are interested in solving motion planning problems with both fixed and dynamic obstacles. They do this using a combination of offline pre-processing and online search. During pre-processing a general-purpose PRM (read: state-space graph) is constructed using only information about the movement capabilities of the robot and the location of fixed obstacles in the robot's environment. At run-time the location of dynamic obstacles is detected and all edges from the PRM which would result in a collision with these dynamic obstacles are pruned away. The remaining problem is easy: just find a shortest path in the remaining graph, from the start location to the goal position. Anyway, it's this online collision checking operation which they implement in and parallelise with custom hardware. Neat. I wonder if in their experiments with software-only planners they also made a distinction between off-line preprocessing and online search? The paper doesn't seem to say. I would hope the comparison is apples-to-apples.
- gradstudent 10y ago
  If I've said something wrong in the above I would appreciate a comment rather than an anonymous down vote.
scribu 10y ago
The Boston Dynamics robots seem to have realtime motion planning that works in unfamiliar environments, which seems to make pre-processing impossible. Would anyone with experience in robotics hazard a guess on how they implement that?

This could be used in reverse as a robot trainer for fencers by setting it to find a way to make a collision with objects instead of avoiding them.

jmcmahon443 10y ago
This is a much easier problem to solve. There are certainly different ways in which objects can collide though, so that would make the problem more interesting and complex.
dmoy 10y ago
Better would be a robot for practicing footwork distance. Probably easier to implement and more beneficial for training. Bladework is less important.

joe_the_user 10y ago

I would like to know what about motion planning makes it more suitable for a FPGA than a GPU. Wasn't able find any scholarly papers on this particular project searching the various references. Can any supply some more information?

colechristensen 10y ago
When concerned with robotics, several obvious ones come to mind around power and footprint.
cbames89 10y ago
Here's the original paper: http://people.ee.duke.edu/~sorin/papers/rss16_chip.pdf http://people.ee.duke.edu/~sorin/papers/rss16_chip.pdf In short: collision detection checking across all of the edges in a PRM graph takes 99% of planning time and can be done compeletely independently.
dr_zoidberg 10y ago
It's very easy to go from FPGA "source code" to a foundry and get a chip with exactly the same thing implemented, and at a cheap price if your scale is large enough.
- IshKebab 10y ago
  Yeah but why can't you do it on a normal CPU or GPU?
  - douglasfshearer 10y ago
    You can do both CPU and GPU, but time and power consumption are both order-of-magnitude worse than using dedicated hardware. The robotic arms are also used untethered in factories, where having a computer near them is inconvenient. The article describes results for using a Xeon CPU. The linked paper cites other papers where a GPU was used.
- trsohmers 10y ago
  I said the same thing a year ago when I had FPGA synthesized verilog and decided to go get a real chip made. Closing timing along with optimizing for PPA for an ASIC vs an FPGA is a royal PITA. And that's just on the front end design work... A core on a FPGA gives you no real idea when it comes to placement or all of the other hurdles of the backend flow of a real ASIC! We ended up re doing everything (which overall was a good thing, as we made a lot better decisions from the beginning by redesigning), but that's show biz.
  - jhallenworld 10y ago
    This used to be Altera's "Hardcopy" advantage: an easy gate-array version of their FPGAs could (in theory) be made because: 1. the gate array uses the same gates as the FPGA, just the interconnect is customized. 2. Use Primetime compatible timing constraints for the FPGA design to begin with.
    - trsohmers 10y ago
p1esk 10y ago
For this task, I think a GPU should be faster than an FPGA in the same price range, but it will be less power efficient. Source: I looked at CPU vs GPU vs FPGA vs ASIC for deep learning algorithms.

mooneater 10y ago

The slowness of this arm makes it hard/impossible to highlight planning speed.

Pica_soO 10y ago
Yep, industrial robots this is about 5 % of the usual speed.
iandanforth 10y ago
This is incorrect. There is usually a huge delay before any motion happens. The speed of that motion is independent of the planning speed. If you have to replan during a move then yes the two can become intermingled, but if you watch most ROS based planning today what you see is a good 30 seconds of compute before the robot moves at all. Sometimes it can be multiple minutes!

Rodeoclash 10y ago

I think we'll look back at movies like "The Terminator" and its slow lurching robots with a wry sense of humour. Instead the future is going to give us robots that can move so fast that they're just visual blurs. As part of Mr. Lee's good neighbor policy, all Rat Things are programmed never to break the sound barrier in a populated area. But Fido's in too much of a hurry to worry about the good neighbor policy. Jack the sound barrier. Bring the noise.

gradstudent 10y ago

Here's my interpretation of the result (posted in the hope that it will aid others): The authors are interested in solving motion planning problems with both fixed and dynamic obstacles. They do this using a combination of offline pre-processing and online search. During pre-processing a general-purpose PRM (read: state-space graph) is constructed using only information about the movement capabilities of the robot and the location of fixed obstacles in the robot's environment. At run-time the location of dynamic obstacles is detected and all edges from the PRM which would result in a collision with these dynamic obstacles are pruned away. The remaining problem is easy: just find a shortest path in the remaining graph, from the start location to the goal position. Anyway, it's this online collision checking operation which they implement in and parallelise with custom hardware. Neat. I wonder if in their experiments with software-only planners they also made a distinction between off-line preprocessing and online search? The paper doesn't seem to say. I would hope the comparison is apples-to-apples.

gradstudent 10y ago
If I've said something wrong in the above I would appreciate a comment rather than an anonymous down vote.

scribu 10y ago

The Boston Dynamics robots seem to have realtime motion planning that works in unfamiliar environments, which seems to make pre-processing impossible. Would anyone with experience in robotics hazard a guess on how they implement that?