0
$\begingroup$

Rosanswers logo

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 :

falling head http://anusite.free.fr/Documents/stageISIR/pr2_falling_head.png

When I did the [simple_head tutorial](www.ros.org/wiki/pr2_controllers/Tutorials/Moving the Head), 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.

Any advice is welcome :)

Thanks, Erwan

EDIT : here is the code :

#include <ros/ros.h>

#include <actionlib/client/simple_action_client.h>
#include <pr2_controllers_msgs/PointHeadAction.h>



// Our Action interface type, provided as a typedef for convenience
typedef actionlib::SimpleActionClient<pr2_controllers_msgs::PointHeadAction> PointHeadClient;

class RobotHead
{
 private:
 PointHeadClient* point_head_client_;

public:
//! Action client initialization 
 RobotHead()
{
  //Initialize the client for the Action interface to the head controller
  point_head_client_ = new PointHeadClient("/head_traj_controller/point_head_action", true);
 std::cout << point_head_client_ << std::endl;
 //wait for head controller action server to come up 
 while(!point_head_client_->waitForServer(ros::Duration(5.0)))
 {
  ROS_INFO("Waiting for the point_head_action server to come up");
  }
 }

~RobotHead()
{
   delete point_head_client_;
}

 //! 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
    pr2_controllers_msgs::PointHeadGoal goal;

    //the target point, expressed in the requested frame
     geometry_msgs::PointStamped point;
    point.header.frame_id = frame_id;
    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
   point_head_client_->sendGoal(goal);

   //wait for it to get there (abort after 2 secs to prevent getting stuck)
    point_head_client_->waitForResult(ros::Duration(2));
 }

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

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

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

  RobotHead head;
  head.shakeHead(3);
  // The only difference in raisehead is that the previous line is replaced by :
  // head.lookAt("base_link", 2.0, 0.0, 0.8);
}

Originally posted by Erwan R. on ROS Answers with karma: 697 on 2012-07-02

Post score: 0

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

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.


Originally posted by ipso with karma: 1416 on 2012-07-03

This answer was NOT ACCEPTED on the original site

Post score: 1


Original comments

Comment by Erwan R. on 2012-07-05:
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)

$\endgroup$
0
$\begingroup$

Rosanswers logo

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).


Originally posted by Erwan R. with karma: 697 on 2012-07-05

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by ipso on 2012-07-05:
So what did you do exactly? Even if it is a workaround, other people might benefit from it if you described it some more.

Comment by ipso on 2012-07-05:
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.

Comment by Erwan R. on 2012-07-05:
Answer improved ;)

Comment by Lorenz on 2012-07-05:
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.

Comment by Erwan R. on 2012-07-05:
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.

Comment by ipso on 2012-07-05:
@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).

Comment by ipso on 2012-07-05:
@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.

Comment by ipso on 2012-07-05:
@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).

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.