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. |
Administrator
|
hi matt, sincerely,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?
2013/11/21 MattTaylor <[hidden email]> Hi All, ------------------------------------------------------------------------------ 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 |
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. |
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, ------------------------------------------------------------------------------ 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 |
Free forum by Nabble | Edit this page |