ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

move_base node dies - can't tell why

asked 2011-03-08 13:50:53 -0600

Pi Robot gravatar image

updated 2011-03-09 17:44:01 -0600

Eric Perko gravatar image

Hello ROS fans,

I am trying to get the navigation stack working with my new iRobot Create under Diamondback on Ubuntu 10.04. I am using the Brown irobot_create_2_1 package to drive the robot. I have successfully configured the navigation stack before for another robot under Cturtle so I thought it would be easy to transfer my parameter and launch files over to the Create. I am running the Master on the robot and RViz on my desktop. I have a Hokuyo laser scanner mounted on the Create. I can successfully view the robot and laser scan in RViz, and if I teleop the robot, I can watch it move in RViz. However when I run the following launch file, the move_base node dies within a few seconds.

<launch>
    <node pkg="move_base" type="move_base" respawn="false" name="move_base" outp
ut="screen">
        <rosparam file="$(find pi_kinectbot)/params/costmap_common_params.yaml" 
command="load" ns="global_costmap" />
        <rosparam file="$(find pi_kinectbot)/params/costmap_common_params.yaml" 
command="load" ns="local_costmap" />
        <rosparam file="$(find pi_kinectbot)/params/local_costmap_params.yaml" c
ommand="load" />
        <rosparam file="$(find pi_kinectbot)/params/global_costmap_params.yaml" 
command="load" />
        <rosparam file="$(find pi_kinectbot)/params/base_local_planner_params.ya
ml" command="load" />
   </node>
</launch>

The resulting log file is as follows:

[roscpp_internal] [2011-03-08 19:38:19,272] [thread 0xb681f740]: [DEBUG] UDPROS 
server listening on port [50340]
[roscpp_internal] [2011-03-08 19:38:19,312] [thread 0xb681f740]: [DEBUG] Started
 node [/move_base], pid [27330], bound on [192.168.1.6], xmlrpc port [55128], tc
pros port [48312], logging to [/home/patrick/.ros/log/37d28f70-49fc-11e0-b176-00
166f70860b/move_base-1.log], using [real] time
[roscpp_internal] [2011-03-08 19:38:19,317] [thread 0xb681f740]: [DEBUG] Publish
er update for [/tf]: http://192.168.1.6:60551/, http://192.168.1.6:35648/, http:
//192.168.1.6:49672/, http://192.168.1.6:41977/, http://192.168.1.6:39540/,  alr
eady have these connections: 
[roscpp_internal] [2011-03-08 19:38:19,317] [thread 0xb681f740]: [DEBUG] Began a
synchronous xmlrpc connection to [192.168.1.6:60551]
[roscpp_internal] [2011-03-08 19:38:19,317] [thread 0xb681f740]: [DEBUG] Began a
synchronous xmlrpc connection to [192.168.1.6:35648]
[roscpp_internal] [2011-03-08 19:38:19,318] [thread 0xb681f740]: [DEBUG] Began a
synchronous xmlrpc connection to [192.168.1.6:49672]
[roscpp_internal] [2011-03-08 19:38:19,318] [thread 0xb681f740]: [DEBUG] Began a
synchronous xmlrpc connection to [192.168.1.6:41977]
[roscpp_internal] [2011-03-08 19:38:19,318] [thread 0xb681f740]: [DEBUG] Began a
synchronous xmlrpc connection to [192.168.1.6:39540]
[roscpp_internal] [2011-03-08 19:38:19,326] [thread 0xb681f740]: [DEBUG] XML-RPC
 call [lookupService] returned an error (-1): [no provider]
[roscpp_internal] [2011-03-08 19:38:19,335] [thread 0xb681f740]: [DEBUG] XML-RPC
 call [searchParam] returned an error (-1): [Cannot find parameter [tf_prefix] i
n an upwards search]
[roscpp_internal] [2011-03-08 19:38:19,509] [thread 0xb601db70]: [DEBUG] Connect
ing via tcpros to topic [/tf] at host [192.168.1.6:59146]
[roscpp_internal] [2011-03-08 19:38:19,510] [thread 0xb601db70]: [DEBUG] Async c
onnect() in progress to [192.168.1.6:59146] on socket [17]
[roscpp_internal] [2011-03-08 19:38:19,510 ...
(more)
edit retag flag offensive close merge delete

Comments

Do you get any errors in the window that you launch in that might hint at why it dies? Also, have you tried running move_base in gdb? See http://www.ros.org/wiki/roslaunch/Tutorials/Roslaunch%20Nodes%20in%20Valgrind%20or%20GDB for how to launch a node in gdb from a launch file.
Eric Perko gravatar image Eric Perko  ( 2011-03-08 14:14:58 -0600 )edit
Thanks Eric. I have added the output from gdb to the end of my post above. Looks like it's related to the same issue I am having running openni_node: this is an SSE2 machine and openni_node fails with an Illegal Instruction error as well. Both move_base and openni_node run fine on a another machine that has SSE3 support.
Pi Robot gravatar image Pi Robot  ( 2011-03-09 12:46:40 -0600 )edit
Hmm... Can you try downloading and installing the nav stack and perception_pcl from source? I'm wondering if this is a problem where the debs are built with SSE3 by default (since I think cmake adds it if it is available and those beefy WG build machines prolly have it) but this isn't doc'd anywhere
Eric Perko gravatar image Eric Perko  ( 2011-03-09 12:53:38 -0600 )edit
Thanks Eric--that did it! I also had to rebuild my application package since apparently it somehow "caches" the location of the navigation and pcl packages from the last time it was built. In any event, it all works now on the SSE2 machine.
Pi Robot gravatar image Pi Robot  ( 2011-03-09 15:17:20 -0600 )edit
Just a note -- if you change the structure of your ROS setup or any overlays, you want to run 'rospack profile' to regenerate the package location cache --- this probably could have saved you having to rebuild.
fergs gravatar image fergs  ( 2011-03-12 15:46:15 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
2

answered 2011-03-09 15:35:28 -0600

Eric Perko gravatar image

The root problem here is that the Debian packages were automatically compiled with support for SSE3 (since the build farm machines do support SSE3), but the target machine doesn't support SSE3.

To fix this, you will have to overlay the offending stacks using the rosinstall tool or by checking them out from source onto your ROS_PACKAGE_PATH. Note that if you check them out onto your ROS_PACKAGE_PATH, the location of these new stacks must be ahead of the existing installation in /opt/ros so that rospack uses these overlaid versions. Run a rosmake --pre-clean after installation to ensure that all dependencies that you have checked out are rebuilt with the correct instructions for your environment. Also make sure to recompile any of your own packages that depend on the offending stacks, as they will need to be linked against the new overlaid packages instead of the existing SSE3 enabled versions in /opt/ros.

edit flag offensive delete link more

Comments

You may also want to run 'rospack profile' after creating your overlay so that rosrun and other ROS tools can find the new overlay.
fergs gravatar image fergs  ( 2011-03-12 15:47:14 -0600 )edit

Question Tools

1 follower

Stats

Asked: 2011-03-08 13:50:53 -0600

Seen: 2,606 times

Last updated: Apr 18 '11