Unified collision environment

[j-petit]

This PR adapts the visual tools for the unified collision environment as proposed here. It changes getCollisionWorld to the new getCollisionEnv function.

This does not build as the main unified PR has to be merged together with this.

[davetcoleman]

Hmmm... this passes??

[BryceStevenWilley]

Seems like Travis tests the master branch of this repo everytime, not very useful. https://travis-ci.org/ros-planning/moveit_visual_tools/jobs/569762781#L220

[rhaschke]

@BryceStevenWilley, can you elaborate on your previous comment, please? I don't get what is not very useful.

[BryceStevenWilley]

Sorry @rhaschke, I'm definitely not a Travis expert, but these changes depend on moveit/moveit#1584 being merged into master and should fail to build without them, yet Travis somehow passes. I saw the line in the Travis config that said

Testing branch 'master' of 'moveit_visual_tools' on ROS 'melodic'

and thought it was just pull the master branch, not this PR. I didn't look enough above to see that Travis is checking out the right branch (https://travis-ci.org/ros-planning/moveit_visual_tools/jobs/569762778#L178). So, I'm still not sure what's going on.

[rhaschke]

I have the solution: Currently, both code changes are disabled.
So actually, this is an empty PR. I changed the title to WIP...

[davetcoleman]

They are disabled at no fault of @j-petit 's, but probably of some lazy practices of mine when this was my graduate project. I think we can safely merge this and we can worry about collision checking of interactive marker collision checkers in the future.

[BryceStevenWilley]

Ah, I see. Thanks for clearing that up Robert and Dave. I agree with Dave. Jens probably found these through a find-replace, not because it wouldn't compile after the unified change.

[j-petit]

Ah, I see. Thanks for clearing that up Robert and Dave. I agree with Dave. Jens probably found these through a find-replace, not because it wouldn't compile after the unified change.

Yes, I did the changes through find-replace and didn't notice that this is disabled through the preprocessor. But still this should be replaced if #1584 gets merged right?

[davetcoleman]

Right!