Open YannisLympero opened 4 years ago
(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.)
Descartes is able to follow the path quite smoothly, but does not seem to care for collisions "always".
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. Could this be related to your problem?
Concerning the last comment:
UPDATE: I would like to add that I am getting this error when I am launching the scene:
[ERROR] [1587480392.874001997]: Failed to find 3D sensor plugin parameters for octomap generation
I think octomap could be related to this.
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.
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.
[1587479728.883469670]: Found a contact between 'static_piece_frame' (type 'Robot link') and 'part' (type 'Robot link'), which constitutes a collision. Contact information is not stored.
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:
[ERROR] [1587480392.874001997]: Failed to find 3D sensor plugin parameters for octomap generation
I think octomap could be related to this.
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.