BiRRT produces coliding trajectories

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

BiRRT produces coliding trajectories

MattTaylor
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):
Collision

Example of geometry


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.
Reply | Threaded
Open this post in threaded view
|

Re: BiRRT produces coliding trajectories

Rosen Diankov
Administrator
hi matt,

are you interpolating the original waypoints of the trajectory? if so, then that's not going to work because the trajectory is most likely using parabolic interpolation.

instead you should sample your trajectory at 2ms-10ms intervals and then linearly interpolate.

just curious, when you ask openrave to execute the trajrectory via robot.GetController().SetPath(traj), do you see it colliding?

sincerely,


2013/11/21 MattTaylor <[hidden email]>
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):
<http://openrave-users-list.185357.n3.nabble.com/file/n4026842/1.png>

<http://openrave-users-list.185357.n3.nabble.com/file/n4026842/2.png>


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.



--
View this message in context: http://openrave-users-list.185357.n3.nabble.com/BiRRT-produces-coliding-trajectories-tp4026842.html
Sent from the OpenRAVE Users List mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users


------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: BiRRT produces coliding trajectories

MattTaylor
Thanks for your reply Rosen,

that makes sense, because one of the the prototypes I originality worked on worked OK using sub-sampling rather than waypoint-to-waypoint movement.

Is there a BiRRT planner that will use linear interpolation between the waypoints, or a planner that will re-time the parabolic trajectory to a linear one?

See my other post about running the trajectory in the viewer. I am unable to use the viewer on the embedded target, and so much of the software is hardware dependant on that target that I have to make so many modifications to run the software on a PC with a viewer that it renders any conclusions drawn useless.
Reply | Threaded
Open this post in threaded view
|

Re: BiRRT produces coliding trajectories

Rosen Diankov
Administrator
the smother planners that run at the end of a RRT are responsible for the parabolic/linear retiming. currently the default is "parabolicsmoother", you can try "linearsmoother". Set the PlannerParameters::_sPostProcessingPlanner field to the smoother you want.

best,



2013/11/21 MattTaylor <[hidden email]>
Thanks for your reply Rosen,

that makes sense, because one of the the prototypes I originality worked on
worked OK using sub-sampling rather than waypoint-to-waypoint movement.

Is there a BiRRT planner that will use linear interpolation between the
waypoints, or a planner that will re-time the parabolic trajectory to a
linear one?

See my  other post
<http://openrave-users-list.185357.n3.nabble.com/Connect-Environment-to-remove-viewer-td4026840.html>
about running the trajectory in the viewer. I am unable to use the viewer on
the embedded target, and so much of the software is hardware dependant on
that target that I have to make so many modifications to run the software on
a PC with a viewer that it renders any conclusions drawn useless.



--
View this message in context: http://openrave-users-list.185357.n3.nabble.com/BiRRT-produces-coliding-trajectories-tp4026842p4026845.html
Sent from the OpenRAVE Users List mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users


------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users