On Mon, Jun 18, 2012 at 2:06 PM, Jack O'Quin <
jack.oquin@gmail.com> wrote:
> On Mon, Jun 18, 2012 at 1:50 PM, Rich Mattes <richmattes@gmail.com> 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