# PR2 head control segmentation fault

Hello !

I'm running PR2 in simulation with visual SLAM algorithm (in ROS electric), and a strange behaviour appears when I spawn the robot as his head falls :

When I did the simple_head tutorial, duplicate the point head node to create a raise head node that uses the lookAt method to set the head in the right direction. Everything compiled and worked well till yesterday. I changed a value in the call to lookAt to ajust the direction and compiled again, but now the node is segfaulting at launch. Investigating a bit more showed that the segfault is in instantiating the PointHeadClient in constructor of RobotHead class. I checked actionlib, controller messages, but they're built so they should be effective.

I think the problem may be correlated as I moved from boost 1.40 to 1.49 by copying files in boost_1_49_0/boost in /usr/include/boost as property tree are required by the visual SLAM I use.

Thanks, Erwan

EDIT : here is the code :

#include <ros/ros.h>

#include <actionlib/client/simple_action_client.h>

// Our Action interface type, provided as a typedef for convenience

{
private:

public:
//! Action client initialization
{
//Initialize the client for the Action interface to the head controller
//wait for head controller action server to come up
{
ROS_INFO("Waiting for the point_head_action server to come up");
}
}

{
}

//! Points the high-def camera frame at a point in a given frame
void lookAt(std::string frame_id, double x, double y, double z)
{
//the goal message we will be sending

//the target point, expressed in the requested frame
geometry_msgs::PointStamped point;
point.point.x = x; point.point.y = y; point.point.z = z;
goal.target = point;

//we are pointing the high-def camera frame
//(pointing_axis defaults to X-axis)
goal.pointing_frame = "high_def_frame";

//take at least 0.5 seconds to get there
goal.min_duration = ros::Duration(0.5);

//and go no faster than 1 rad/s
goal.max_velocity = 1.0;

//send the goal

//wait for it to get there (abort after 2 secs to prevent getting stuck)
}

//! Shake the head from left to right n times
{
int count = 0;
while (ros::ok() && ++count <= n )
{
//Looks at a point forward (x=5m), slightly left (y=1m), and 1.2m up

//Looks at a point forward (x=5m), slightly right (y=-1m), and 1.2m up
}
}
};

int main(int argc, char** argv)
{
//init the ROS node
ros::init(argc, argv, "robot_driver");

// The only difference in raisehead is that the previous line is replaced by :
}

edit retag close merge delete

Sort by » oldest newest most voted

Problem solved using boost 1.41.0 but I don't think it's a good solution. If someone can update this tutorial with recent informations, it may help keeping ROS usable.

BtW, version 1.50 of boost looks absolutely not compatible with electric.

EDIT : as having some header-only libraries (and others to be compiled), Boost header-only files must be placed in a folder that is parsed when the compiler look for libraries and headers. The path :

/usr/include/


is an acceptable place for that (I don't know Linux well enough, but I think boost comes with the recent distributions - at least of Ubuntu - so there'll be a folder called boost in this directory). You just have to copy the boost_1_xx_y/boost subdirectory content into /usr/include/boost folder. In my case, the upper code doesn't work with version 1.46 and more. As far as I know, it's a problem in the class instanciation. I need property_tree from boost to use the OpenRatSLAM implementation, that are available from boost 1.41, so I downgraded to that version. I think it's not a good solution as there are fixes in newer implementations of boost that are probably useful. Maybe tutorials would be revised to update the code with more up-to-date ROS classes and features. In my case, I'm only using a low importance program (raising head), but it's required to run RatSLAM (as it is visual SLAM).

more

So what did you do exactly? Even if it is a workaround, other people might benefit from it if you described it some more.

( 2012-07-05 20:40:32 -0500 )edit

The fact that Boost 1.50 is incompatible with electric shouldn't come as a surprise, see reps/rep-0003 for more information. 1.50 is more than 10 minor releases newer than what Electric was developed for / with. Incompatibilities expected.

( 2012-07-05 20:43:39 -0500 )edit

( 2012-07-05 23:15:35 -0500 )edit

Boost is not a pure header-only library. There are a bunch of .so files, including threads, regexp and filesystem. Since many ros libraries and nodes link against at least boost thread, it's always a bad idea to use different headers in an own project without recompiling whole ROS.

( 2012-07-05 23:36:21 -0500 )edit

Ok so you mean that maybe the problem comes from the fact that I updated the header files and not the compiled librairies (I had some troubles understanding how to install boost the first time I had a problem of property_tree) ? - updated my answer to be more precise.

( 2012-07-05 23:44:01 -0500 )edit

@Lorenz: certain parts of boost are header only, but you are right, some are not. And as you point out (and I did earlier), mixing and matching versions is not a good idea, no matter how small the version difference (major / minor versions).

( 2012-07-05 23:44:38 -0500 )edit

@Erwan R.: no, Lorenz is telling you that you cannot (in principle) mix different versions of Boost for use with ROS. The ROS packages are linked against a specific version of Boost, your nodes are then linked against ROS and against your newer version of Boost.

( 2012-07-05 23:46:30 -0500 )edit

@Erwan R.: it might be possible with header only libraries and taking some care with linking, but this is not trivial, and not a supported use case (I assume).

( 2012-07-05 23:49:47 -0500 )edit

I think the problem may be correlated as I moved from boost 1.40 to 1.49 by copying files in boost_1_49_0/boost in /usr/include/boost as property tree are required by the visual SLAM I use.

So you copied a set of headers from a Boost v1.49 distribution to /usr/include/boost on a system that originally came with v1.40?

Depending on what exactly is using those new headers, and how isolated they are (ie: do they depend on other bits of Boost which you didn't copy), mixing & matching two Boost versions might not be such a good idea.

Everything compiled and worked well till yesterday. I changed a value in the call to lookAt to ajust the direction and compiled again, but now the node is segfaulting at launch.

If you added the Boost v1.49 headers before recompiling your node, perhaps see if things start working again if you remove them and recompile? Segfaults are one possibility of having version(header) != version(library) for instance.

EDIT after the added answer and more info by @Erwan R.: See 'Using concurrently 2 versions of boost' on stackoverflow for some additional info on the problem. As I mentioned: it can be done, but probably requires quite some work.

more

I went back to v1.40 and the segfault disappeared, but I strongly need a boost version that supports property_tree for another algorithm. I'm gonna investigate v1.50 or degrade to a version that is compatible with this node and has property_tree. (sry for 4-times comment)

( 2012-07-05 03:18:22 -0500 )edit