-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Robot Collision in Descartes not working properly "always" #245
Comments
(Note: I haven't looked at the code in a long time, so some things could be off, but I'm just writing some of my thoughts in the hope it can be helpful.)
Does this mean you can observe collision in the solution sometimes? Descartes checks for collision on discrete points along the path, not in between them. (The point loaded from the CSV file from which the input trajectory points are created.) In some specific cases, the solution path will move through an obstacle. Concerning the last comment:
As far as I know, this is not relevant for Descartes if you are not using 3D sensors. |
One way to do this is to create your own derived class of the MoveIt State Adapter and override the isValid function so that it grabs the most current planning scene which should contains any sensor data fed to it. |
hi ,has you solve the problem |
Dear all,
I am using a transformation of Tutorial 2, to perform trajectory planning with collision avoidance around an .dae workpiece.
Opposite to tutorial 2, my "grinder" is mounted on the robot and the workpiece is fixed at some position in the world-frame. I am following a path around the perimeter of my .dae workpiece - with the tip of my grinder tool, which was the product of an optimization procedure (so fairly complex in terms of mesh).
Descartes is able to follow the path quite smoothly, but does not seem to care for collisions "always". "Always" is important in this context because when I slightly alter the position of the piece or its orientation it might not be able to find a feasible path. Moreover, when I switch the "isStateColliding" to verbose, I can see that collision checking is doing something meaningful because it is able to find conflicts between the workpiece and the grinding tool - but probably not all of them.
My question concerns the implementation of collision check: Is there some sampling of all the interacting meshes defined somewhere? Has anybody observed a similar problem?
UPDATE: I would like to add that I am getting this error when I am launching the scene:
I think octomap could be related to this.
The text was updated successfully, but these errors were encountered: