BiRRT produces coliding trajectories
Locked
BiRRT produces coliding trajectories
 
|
Hi All,
IF anyone has any thoughts on the following, I would be interested in discussing them. I'm puting this up here to get some feedback and hopefully document a solution so others can find it. I’m getting an interesting problem while using BiRRT to plan an arm movement. It appears that the plan we get back is ignoring geometry collisions. We are seeing this on our viewer (implemented as part of our existing ROV control dashboard, not the qtcoin viewer), and also on the hardware. Both are linearly interpolating* between way-points returned from the planer. What we are seeing is the planner returning an obviously colliding plan (such as folding the arm down into the body of the robot before folding it back out to the goal position). Our geometry includes buffer zones around delicate or optional equipment that can be fitted to the ROV. When running the plans on the physical system, we are consistently seeing the plan colliding between the same two links (not adjacent or declared adjacent). It seems to be these links that are the problem, as the trajectory is clearly planning around the other geometry. I have tried a number of things to try to stop this: 1) I exaggerated the collision zones to stupid size. No change in behaviour. 2) I have checked all the dimensions on the Kino model, and converted it to use meters instead of inches. No change in behaviour. 3) I converted all the geometry in the model to convex shapes. I did this after reading into the ODE Physics collision checking documentation and found that it is unable to detect a collision between a trimesh and Convex Hull. No change in behaviour (although it has simplified the kino model allot). The collision we are seeing repeatedly is (spectacularly illustrated in paint):   The geometry we are using for collusion checking is oversized. The position the arm gets to before physically colliding (as in above QTViewer example) is at a point about 100mm inside the collision geometry. When re-planning from this position, the initial configuration fails due to a collision between the two bodies that are seemingly not detected as colliding during the planning. Thanks for reading this far if you have, I will update if I find out anything more, or get a workable solution. - Matt * The servo drives are not really linearly interpolating, but are moving from way-point 1, stopping, and then moving to way-point 2, stopping, etc. They are doing this at constant velocity with a short acceleration and deceleration phase. |
Re: BiRRT produces coliding trajectories
Administrator
|
Re: BiRRT produces coliding trajectories
|
|
Re: BiRRT produces coliding trajectories
|
Administrator
|
| Free forum by Nabble | Edit this page |