Skip to content
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

Open
YannisLympero opened this issue Apr 21, 2020 · 3 comments
Open

Robot Collision in Descartes not working properly "always" #245

YannisLympero opened this issue Apr 21, 2020 · 3 comments

Comments

@YannisLympero
Copy link

YannisLympero commented Apr 21, 2020

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.

@JeroenDM
Copy link

(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.

@jrgnicho
Copy link
Contributor

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.

@dbdxnuliba
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants