robotics February 2013

robotics@lists.fedoraproject.org

1 participants
2 discussions

Installing ROS on Fedora 18, and "the pcl issue" -- is there any hope?
by Mary Ellen Foster 25 Mar '13

25 Mar '13

Hello all, Some students have developed some code using ROS that I would like to make use of. The obvious, easy solution is to install Ubuntu on a computer and use it that way, but I've been trying to see how much of a hassle it would be to set things up on my Fedora 18 desktop. I've had some success following the instructions at http://www.ros.org/wiki/fuerte/Installation/Fedora and making use of the packages from http://rmattes.fedorapeople.org/rospackages/. As far as I can recall -- wasn't taking notes, unfortunately -- the following are the things I had to modify from the instructions given on that page: - installed python-rosinstall, python-rospkg and python-rosdep (and ros-release) from the fedorapeople repo instead of using python-pip - downloaded http://ros.org/rosinstalls/fuerte-ros-full.rosinstall and changed the path for actionlib to refer to ros-gbp instead of wg-debs - created an appropriate rosdep-fedora.yaml file as described here ( https://code.ros.org/trac/ros/ticket/3929) - edited CMakeCache.txt after running cmake to set SETUPTOOLS_ARG_EXTRA to an empty string before running "make install" (SETUPTOOLS_DEB_LAYOUT seems not to work quite right) - created a symlink dist-packages -> site-packages inside /opt/ros/fuerte/lib/python2.7, again because the deb layout seemed to be getting in the way - added "set (PythonLibs_FIND_VERSION 2)" before all "find_package (PythonLibs)" calls in all CMakeLists.txt files (in the underlay and the actual OS) so that it finds Python 2 instead of Python 3 - added "rosbuild_link_boost ($executable system)" to various CMakeLists.txt files -- with Boost 1.50.0, you have to explicitly link against the system lib or else you get undefined references to symbols like '_ZN5boost6system15system_categoryEv' But now, unfortunately, I've hit "the pcl issue" ( http://lists.fedoraproject.org/pipermail/robotics/2012/000671.html). The specific symptom is as follows (in the middle of "rosmake -a"): [rosbuild] Building package costmap_2d Failed to invoke /opt/ros/fuerte/bin/rospack deps-manifests costmap_2d [rospack] Error: package/stack costmap_2d depends on non-existent package pcl I do have pcl-devel-1.6.0-2.fc18.x86_64 installed but it doesn't seem to help. I tried rebuilding the pcl srpm with the patch from http://dev.pointclouds.org/issues/699 (it applied with minimal fuzz), but the rpmbuild pretty much brought my fairly beefy desktop machine to its knees and I'm not sure if it will help in any case. Should I persevere with that? Any other suggestions for getting this working? As a fallback, I can just install Ubuntu on our demo laptop, but it would be nice to have this working. All the best, MEF -- Mary Ellen Foster -- http://www.macs.hw.ac.uk/~mef3/ Interaction Lab -- http://www.macs.hw.ac.uk/InteractionLab School of Mathematical and Computer Sciences, Heriot-Watt University Heriot-Watt University is a Scottish charity registered under charity number SC000278

3 13

ROS Packaging Roadmap
by Rich Mattes 18 Mar '13

18 Mar '13

Hi all, It's been a little while since our last discussion about ROS packaging. I know I got bogged down with real life and dropped the ball with respect to the f18 feature process work, but there has been some progress on that front. I've got the four ROS Utilities on the ROS_Packaging[1] wiki page done, and I'm currently working through the 12 ROS Core packages. I've been stashing them on my fedorapeople page [2]. I think we can get at least the core packages for ROS Fuerte done for f18 and then update them all to Groovy once it comes out. There are a few issues I wanted to discuss: 1) ROS package naming and other packaging guidelines: Right now we're using the name ros-%{rosdistro}-packagename based on Tom's initial packaging efforts. Would it make sense to have a ros macro file that defines things like %{rosdistro} vs declaring it in each package? Additionally, since a lot of the ROS packages that come from github have very similar structure, perhaps we can create a ROS package template, and lay out guidelines for which virtual Provides to add to each package and document where we deviate from the core ROS stacks (for example, i've moved /usr/etc/langs to /etc/ros-langs for the message generation subsystem) 2) Packaging Fuerte vs. waiting for Groovy: Groovy is supposed to have significant changes to filesystem layout to make it more FHS friendly. Based on my work with Fuerte, it's not too hard to beat Fuerte's core packages into FHS compliance, so maybe we can focus on getting the core stacks done for Fuerte and then once Groovy is out we upgrade the core in f18+ and start reviewing additional well-known stacks for groovy. 3) EPEL Should we spend a lot of time targeting el6 (and even el5) as we are packaging? A lot of research institutions seem to be running redhat, though I don't know how many IT departments rely on EPEL vs. the RH supported repos. My inclination is that if it's not too difficult, we should try to at least support el6; el5 might be a bit harder due to the lack of CMake 2.8 in the repositories. In the meantime, I will submit rosinstall, rosdep, and rospkg for review sometime this week since they're straightforward python packages which are required by the upstream source installation directions (I've already got vcstools reviewed and in Fedora). Rich [1] https://fedoraproject.org/wiki/SIGs/Robotics/ROS_Packaging [2] http://rmattes.fedorapeople.org/rospackages/

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

robotics February 2013