Best practices to load collision world

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

aPonza
589 ●19 ●30 ●33

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.

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

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

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

Comments

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 ( 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 ( 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 ( 2018-10-01 02:56:53 -0600 )edit

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

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 ( 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 ( 2018-10-29 04:41:46 -0600 )edit

add a comment

Best practices to load collision world

1 Answer

Comments

Question Tools

Stats

Related questions

Best practices to load collision world edit

1 Answer

Comments

Question Tools

Stats

Related questions

Best practices to load collision world