On Mon, Jun 18, 2012 at 2:06 PM, Jack O'Quin wrote: > On Mon, Jun 18, 2012 at 1:50 PM, Rich Mattes wrote: >> On 06/18/2012 03:48 AM, Tully Foote wrote: >>> >>> Hi Rich, >>> >>> Due to a long history of interweaved lineage PCL and ROS datatypes >>> collide.  We have not forked PCL as much as applied a patch to make it use >>> our generated messages instead of the stripped down versions built into PCL. >>>  This previously was done inside PCL upstream, however it has proven easier >>> to patch new releases than maintain the functionality within PCL.  Also it >>> does not require PCL to have anything ROS specific inside it's release.  The >>> git-buildpackages repositories allow us to reimport upstream and reapply our >>> patches on top of new releases as they come out.  If there is a patch >>> release to the version we have used we can take it up, and plan to.  We >>> cannot take up major API breaking releases. >>> >>> There has also been an initiative to release renamespaced versions of pcl >>> 1.6 as pcl16 as a backport into Electric.  I'm not sure of the current >>> status of that effort. >>> >>> Tully >> >> >> Hi Tully, >> >> Thanks for the reply.  I guess fork wasn't the best way to describe it, it >> is just a handful of files being added/modified on top of PCL's upstream >> releases. >> >> From a distribution maintainer's perspective, it would be nice to decouple >> the upstream PCL releases from ROS altogether.  Ideally, ROS would build >> against a stand-alone version of PCL without modification.  Since this is >> not an option due to the datatype interdependence, the next best thing would >> be to treat ROS as an optional dependency to PCL (it already partly is: PCL >> looks for ROS to determine whether or not it should use its included copies >> of sensor_msgs and std_msgs, or defer to ROS' copies.)   Since the >> interdependence is already there, it made sense to me to take the next step >> and include the ROS message headers for the point cloud messages as well >> (when USE_ROS was enabled), and that was the path I started to go down. >>  With that, as long as the message definitions don't change too much once a >> PCL release is made, you could lock ROS to depend on a specific version of >> PCL.  You could even going so far as to version the stack's name: pcl-1.5 >> instead of pcl; this would also lend itself to creating explicit >> dependencies on newer backports, and letting API-compatible point-releases >> in without any modification. >> >> I understand that ROS development moves quite fast and isn't necessarially >> tied to anything the PCL guys are doing, so keeping a separate copy with the >> requisite modifications makes it easer to make modifications as ROS evolves. >>  Grabbing the latest changes from the wg repository for distribution >> packaging with ROS isn't the end of the world, and we can do that if it ends >> up being the best solution.  But if the messages and ROS stack info aren't >> changing that often, having PCL optionally treat itself as its own >> self-contained stack might be worth considering. > > Problems with people trying to build PCL from source to run with ROS > are very common on answers.ros.org. > > Their usual motives are: > >  1) getting a more recent version than shipped with the ROS distro > >  2) needing to fulfill the rosdep dependency on some non-Ubuntu system > > We need a clear, well-documented method to accomplish that task. We've been using pcl trunk with fuerte: https://bitbucket.org/bhaskara/perception_pcl_fuerte_unstable It puts the pcl trunk code into a 'pcl16' namespace, so that it can coexist with fuerte's pcl 1.5. Using it basically involves replacing the pcl and pcl_ros namespaces with pcl16 and pcl16_ros respectively. - Bhaskara > -- >  joq > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users -- Bhaskara Marthi Research Scientist Willow Garage Inc. 650-475-2856