-
Notifications
You must be signed in to change notification settings - Fork 9
Make this a normal cmake package #2
Comments
This is prototype aiming at solving ticket #2. Remaining issues are the dependencies w.r.t resource_retriever and roscpp. They both can be removed if we accept losing some features.
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.
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. |
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. |
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. Catkin is a dependency of resource_retriever, so if you use this package it will have to be installed either way. 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... ;) |
jrl_dynamics do not need meshes information. |
Then our best option is probably to trim the dependency to resource_retriever, and use this branch as the default from now on. |
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:
|
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. |
If Metapod is going to take over jrl-dynamics, it will not handle meshes. |
Food for thought:
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. |
urdfdom is not a part of ros anymore, no need for this to be a ROS package
The text was updated successfully, but these errors were encountered: