Make this a normal cmake package

[thomas-moulard]

urdfdom is not a part of ros anymore, no need for this to be a ROS package

[thomas-moulard]

I abandoned for now this idea. AFAIK resource_retriever will never be a non ROS package so it does not server any purpose to un-rosify this package.
We have first to understand how urdfdom retrieves meshes (IMHO it does not) to see how we can work around thes issues.
Then we have two roads:

1. keep this a ROS package
2. remove all necessity to load the meshes in jrl-dynamics

A 3rd way would of course to make resource_retriever a non ROS package but this requires some discussion with the people from robot_model.

[aclodic]

We (@aclodic @olivier-stasse @florent-lamiraux) have consider the option to "unrosbuild" this package, without really "catkinize" it (ie without inserting catkin macros into CMakelist), the next step will be to insert it into our robotpkg stack.
However, @thomas-moulard tell me that catkin macros are needed to release debian package.
I think @florent-lamiraux point to not "catkinize" it was to be able to use it without catkin. I wonder, if it is really needed. (If yes, I wonder if it is possible to put options into the CMakelist ?)

[thomas-moulard]

Actually the point is the following:

a. If we do not need the meshes, only the kinematic structure. This can (should) be a non ROS package with no catkin in it.

b. If we need the meshes and AFAIK we do (maybe @olivier-stasse can confirm this) and in this case, this has to be a ROS package because meshes URIs are expressed as "package://robot_description/.etc", "http://www.abc.com/etc", etc. and you will need a special tool to access the files. This package is called resource_retriever. This resource_retriever tool is a ROS package. On top of that the "package://" syntax relies on your local ROS_PACKAGE_PATH so you have to setup ROS for this to work.
This leads us to the following conclusion: to load the meshes, you need to have a working ROS environment.
De facto, it forbids us from cutting the ROS dependency.

Catkin is a dependency of resource_retriever, so if you use this package it will have to be installed either way.
Considering this, I do not see any interest in not catkinizing the package. If you need feature from the jrl-cmakemodules it can still be used without any issue and in term of complexity it only adds two lines.

The rule of thumb is as follow: please respect the rules which have been decided by the ROS community for the ROS related packages unless there is a good reason to break them.

In a very practical way: we won't mimic perfectly their catkin tools in jrl-cmakemodules because their evolution is fast which means an additional breakage rate I would rather avoid if this is possible. Especially when the effort to do is add two lines in a file without requiring more dependencies than we already have... ;)

[olivier-stasse]

jrl_dynamics do not need meshes information.
It read them if they are available but do nothing with it.
We should implement an obstacle avoidance controller using the meshes, but AFAIK we do not have a working implementation.

[thomas-moulard]

Then our best option is probably to trim the dependency to resource_retriever, and use this branch as the default from now on.
I think we should store the path to meshes as string and let another module load the meshes if this is required.

[florent-lamiraux]

jrl_dynamics_urdf does not need meshes today, but it is likely to require meshes in the future if we want to implement collision avoidance in the Stack of Tasks.

Tell me if one of the following assertions is wrong:

• catkin handles package dependency using the "package.xml" file but does not strictly require to use catkin macros in the "CMakeLists.txt",
• the benefit of using catkin macros is to be compliant with change in installation policies of ROS in the future.
  If boths assertions are true, I agree with Thomas, it is better to use catkin macros.

[thomas-moulard]

Yes, both are true.

One limitation is that you will have to set the install directories through the Catkin variables.

See the catkin documentation for more information about how to declare the different elements of a Makefile.

[olivier-stasse]

If Metapod is going to take over jrl-dynamics, it will not handle meshes.
IMHO a controller with obstacle avoidance should be realized through a collision detection library handling the proper geometric representation (convex hull, STB-PV, whatever you like) and may use metapod, jrl-dynamics or whatever gives the position of the links. I really doubt that we will do collision detection directly at the level of jrl-dynamics-urdf. But maybe you are referring to a meta-package handling all the properties of the robot loaded through a URDF/SRDF file. This would be interesting but probably not relevant to what is provided by jr-dynamics right now.

[thomas-moulard]

Food for thought:

1. Note that right now meshes are not loaded. They are loaded though in hpp-model-urdf which is similar to this one but much more advanced thanks to @aelkhour efforts.
2. Actually this package really should be jrl-dynamics independent but as algorithms and data structures have been mixed together in abstact-robot-dynamics, this is not that easy. I think there was some kind of abstract factory somewhere? If this is the case we may be able to factor plenty of code between this and hpp-model-urdf.
3. In URDF there is a subtile nuance between geometry and meshes. A mesh is a geometry element but not all geometry elements are not meshes (!). Basic shapes such as spheres, cylinders, etc. are part of URDF. Also Antonio uses a non-standard capsule element as we did not find a better solution.

In the ideal case, I would split the problem into two, one generic loader depending only on abstract-robot-dynamics which do not load the mesh and is not a ROS package while we have another, bigger, package, depending on AssImp and resource_retriever to load the meshes and which requires a working ROS installation.