ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Best practices to load collision world

asked 2018-09-27 09:49:52 -0600

aPonza gravatar image

ROS kinetic, Ubuntu 16.04, kernel 4.8.15-rt10

Since finishing the Move Group C++ tutorial, I have created a node that adds the collision objects for my own robotic arm setup to avoid collisions when planning (e.g. with the table the arm is mounted on). At the moment I don't have sensors to create an octomap and such, so this is an acceptable starting point.

What are the best practices be to load default collision objects (not temporary ones, visible from sensors)?

E.g. I'm imagining it could be possible to have the very same node I wrote be roslaunch-ed together with controllers at startup, but wouldn't it be better to have somehow just a method in the main routine that loads a generic collision object from within a folder? Maybe have a folder containing a file with the laboratory/shop floor setup (or a file per object)? This way the code could be reused with a toggle for the environment the robot is being tested in.

This might be a bit more philosophical/design-oriented than it should be, but I feel I don't understand ROS enough yet to not pose the question.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2018-09-27 10:28:36 -0600

gvdhoorn gravatar image

updated 2018-09-27 10:35:40 -0600

Personally, if I don't have a need to programmatically generate a collision scene I just write a URDF with my static objects.

It's (all subjective of course) easy to visualise, easy to edit and easy to version (it's just a bunch of text / xml).

Conditional inclusion of objects is also possible (xacro supports conditionals, entire Python expressions in fact).

Having to read lines of C++ or Python and to have to make a mental model of what the resulting scene looks like sounds like an arduous thing to have to do compared to just looking at RViz (click the collision checkbox of the Robot Model display).

I can't find it right now, but I remember there being at least one project that programmatically generated URDF snippets with a Python based DSL and then combined those into proper whole URDFs. That could be a hybrid between completely programmatic and completely based on markup.

edit flag offensive delete link more


What about this though: "The URDF is intended to only represent the actual robot's properties, and not collisions used for external things like controller collision checking."

aPonza gravatar image aPonza  ( 2018-09-27 10:59:19 -0600 )edit

That comment applies / is accurate, but we must always keep in mind that everything is essentially a trade-off and I believe it tries to "warn" users against modelling their complete environment (down to the last detail) in their URDF. For 'static' setups (ie: an arm in an environment), so ..

gvdhoorn gravatar image gvdhoorn  ( 2018-10-01 02:56:00 -0600 )edit

.. not for mobile robots, adding collision geometry for objects in the immediate vicinity of the robot makes a lot of sense to me. But for mobile robots (such as TBs or any mobile base) it doesn't scale and should be avoided.

gvdhoorn gravatar image gvdhoorn  ( 2018-10-01 02:56:53 -0600 )edit

Oh, sure, had not thought of that, this makes sense. Thanks!

aPonza gravatar image aPonza  ( 2018-10-01 04:29:50 -0600 )edit

one project that programmatically generated URDF snippets with a Python based DSL and then combined those into proper whole URDFs

@gvdhoorn were you referring to this?

aPonza gravatar image aPonza  ( 2018-10-29 03:39:50 -0600 )edit

@aPonza: yes, that is it.

It's a nice approach, but the author is a bit opinionated though:

This allows a natural integration into python code for calculation and is just nicer to work with than XML and XACRO.

gvdhoorn gravatar image gvdhoorn  ( 2018-10-29 04:41:46 -0600 )edit

Question Tools

1 follower


Asked: 2018-09-27 09:49:52 -0600

Seen: 516 times

Last updated: Sep 27 '18