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

No robot self-collision check #67

Closed
bsaund opened this issue Mar 14, 2018 · 9 comments
Closed

No robot self-collision check #67

bsaund opened this issue Mar 14, 2018 · 9 comments

Comments

@bsaund
Copy link
Contributor

bsaund commented Mar 14, 2018

Currently I have not found a nice way to do self-collisions using gpu_voxels. This seems challenging because

  1. Adjacent links may occupy the same voxels due to discretization, yet this should not count as a collision
  2. It is inefficient and cumbersome to store separate maps for each link and selectively collide the relevant links that may cause self collisions.

Any suggestions?

@Squelsh
Copy link
Contributor

Squelsh commented Mar 14, 2018

Hi Brad,
unfortunately you are right: Currently the situation is all but optimal. We had that feature in one of the very early versions of GPU-Voxels but it got lost again.

What you would have to do is to write an insertion kernel which uses Bitvector Voxels to represent the robot, and then identify each part of your robot through an individual ID. And while inserting, you have to check for already occupied voxels. Through the IDs you could mask and ignore the collisions which are OK (between successive parts of your kinematic chain).

I could try to add that feature to the robot class of GPU Voxels.

Cheers,
Andreas

@bsaund
Copy link
Contributor Author

bsaund commented Mar 14, 2018

I will need self-collision checking eventually, and preferably in gpu_voxels rather than duplicating work in a different architecture.
I'd be happy if this functionally appeared.

Side note:
Currently my robot is actually stored in a probab map, partially because conversion, insertion, subtraction, etc. between map types is not all implemented. It makes sense to do the self-collision checking in the preferred map type then implement these additional operations across map types.

@Squelsh
Copy link
Contributor

Squelsh commented Mar 14, 2018

Hm, the self collision detection can not be implemented in a probabilistic map, if you want to be able to mask out some collision pairs.
But subtraction and other operations could also be implemented with BitvectorVoxels in the future.

@Squelsh
Copy link
Contributor

Squelsh commented Mar 22, 2018

I have the implementation finished. Just adding some auto-testcases before I open a pull request.
Hopefully tomorrow.

@Squelsh
Copy link
Contributor

Squelsh commented Mar 28, 2018

Sry, tests discovered some weak points I missed previously. Still on it.

@Squelsh
Copy link
Contributor

Squelsh commented Mar 30, 2018

Finally...
The implementation can be found here:
This also contains an example and an automated testcase.
#68

I am happy to read your feedback.

@bsaund
Copy link
Contributor Author

bsaund commented Apr 3, 2018 via email

@bsaund
Copy link
Contributor Author

bsaund commented May 1, 2018

Sorry, I'm pushing for the ISER deadline. I'll take a look at this next week

@cjue
Copy link
Contributor

cjue commented May 1, 2018

Self-Collision checks have been added in PR #68.

We are looking forward to feedback on the new functionality!

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

3 participants