Ask Your Question

ekf_localization_node core dumping

asked 2015-05-22 06:48:25 -0500 gravatar image

updated 2015-05-22 12:02:50 -0500

Still setting up ekf_localization_node here -- I'm playing back and processing my bag, but getting this error, whether I run from a lauch file with params or with no params from rosrun,

$ rosrun robot_localization ekf_localization_node

ekf_localization_node: ../nptl/pthread_mutex_lock.c:350: __pthread_mutex_lock_full: Assertion `(-(e)) != 3 || !robust' failed.
Aborted (core dumped)

The error only occurs when by bag is playing, otherwise the node sits silently. There's no log file or rosout messages so I'm not sure how to locate the problem, any suggestions ?


System info: PARAMETERS * /rosdistro: indigo * /rosversion: 1.11.10 on Xubuntu 14.04 LTS.

Sample geometry/gps message,

  seq: 200
    secs: 1431535613
    nsecs: 57244062
  frame_id: ''
child_frame_id: ''
      x: -2.90984643623
      y: -3.69588956097
      z: -3.51702306711
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0
  covariance: [1.218219225942454, 0.006998948102184068, 0.17239271800594577, 0.0, 0.0, 0.0, 0.006998948102183846, 1.2159598403645349, 0.14679821372057594, 0.0, 0.0, 0.0, 0.17239271800594574, 0.14679821372057594, 4.825820933693012, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
      x: 0.0
      y: 0.0
      z: 0.0
      x: 0.0
      y: 0.0
      z: 0.0
  covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

Sample /imu message:

  seq: 105
    secs: 1431535415
    nsecs: 50663948
  frame_id: base_imu_link
  x: 0.026096916629
  y: -0.0692553241391
  z: -0.248199192676
  w: 0.96587774163
orientation_covariance: [0.0025, 0.0, 0.0, 0.0, 0.0025, 0.0, 0.0, 0.0, 0.0025]
  x: -0.09
  y: -0.04
  z: 0.02
angular_velocity_covariance: [0.02, 0.0, 0.0, 0.0, 0.02, 0.0, 0.0, 0.0, 0.02]
  x: 0.666884609375
  y: 0.117595390625
  z: 9.37468921875
linear_acceleration_covariance: [0.04, 0.0, 0.0, 0.0, 0.04, 0.0, 0.0, 0.0, 0.04]

Launch file,


  <node pkg="robot_localization" type="ekf_localization_node" output="screen"  name="ekf_localization_node">

   <param name="odom0" value="odometry/gps"/> 

   <param name="odom0_differential" value="false"/>

   <rosparam param="odom0_config">[true,  true,  false, 
                                    false,  false,  false,
                                    false,  false, false, 
                                    false, false, false,
                                    false, false, false]</rosparam>

   <param name="imu0" value="imu" />

   <rosparam param="imu0_config">[false,  false,  false,
                        false,  false,  true,
                        false,  false, false,
                        false, false, true,
                        true, false, false]</rosparam>

   <param name="imu0_differential" value="true"/>

   <param name="imu0_remove_gravitational_acceleration" value="true"/>



To try to isolate the cause, I tried recording my data into ...

edit retag flag offensive close merge delete


Can you share one of the bag files? Have you tried just using the IMU or just the GPS data? I'm interested in your frame-less GPS data, though that shouldn't cause it to crash. Also, did you compile from source? If so. which branch?

Tom Moore gravatar image Tom Moore  ( 2015-05-22 11:49:33 -0500 )edit

Hi Tom, great to see you here! I've put a (tiny) bag and my launch file here for you, The crash happens even if I have IMU only, or GPS only, or comment out both of them. I installed from apt-get gravatar image  ( 2015-05-22 12:18:38 -0500 )edit

still have same error after looking at the empty gps frames. My navsat_transform_node is taking its frame from my own command-based odometry node . This was sending empty frames so I filled them in, parent=odom_motor, child=base_link. odometry/gps now has the same parent but still empty child? gravatar image  ( 2015-05-22 13:30:19 -0500 )edit

Yeah, see my answer below. Let's first move away from the installed version and go to source for now. Then we can try to work through these issues one-at-a-time.

Tom Moore gravatar image Tom Moore  ( 2015-05-22 14:19:34 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2015-05-22 13:23:53 -0500

Tom Moore gravatar image

Ok, so a few things:

  1. I am unable to reproduce the behavior you describe with the latest source (which will hopefully be getting released imminently). The node starts just fine either way and doesn't crash. There could be an incompatibility between my node and an updated dependency in another package. Regardless, the error you're seeing involves threading, and I don't explicitly use threading anywhere, which means it likely is an interaction with a dependency.
  2. Your IMU is given in the base_imu_link, but you have not specified a transform from base_imu_link->base_link. See this section of the wiki.
  3. In your launch file, you are not measuring nearly enough variables. If you are operating in 2D, then set two_d_mode to true. Otherwise, you need to measure enough variables to keep your covariances from exploding. See this page. You might also try fusing your commanded velocities.
  4. You appear to have a transform from odom_motor_cmds to base_link, but it appears to be changing. If you have some node that is outputting motor commands to the robot, I would suggest issuing them as geometry_msgs/TwistWithCovarianceStamped messages. That way, you can fuse them with the state estimate.
edit flag offensive delete link more


Thanks Tom. I fixed base_imu_link and the error remains; and I'm already in two_d_mode. odom_motor_cmds computed by my own controller, I'll try switching that to TwistWithCovarianceStamped as the problem is something to do with tf. And try latest source. gravatar image  ( 2015-05-22 15:03:27 -0500 )edit

Seems to be working now I upgraded to latest source (2.1.7), thanks very much for the help Tom! gravatar image  ( 2015-05-24 10:06:17 -0500 )edit

Odd. 2.1.7 was the release you had already. You just compiled from source instead. Perhaps there was some strange build flag or incompatible dependency. Oh well. In any case, you should update to 2.2.0 (literally just released).

Tom Moore gravatar image Tom Moore  ( 2015-05-24 10:28:15 -0500 )edit

I'm cloning from git pasting the URL from github, this gives 2.1.7: but git checkout -b remotes/oriin/indigo-devel; git pull origin indigo-devel fxes package.xml (only) to 2.2.0. So maybe this /is/ 2.2.0 but package.xml isn't updated in master? gravatar image  ( 2015-05-24 11:39:43 -0500 )edit

(done a diff on the that clone and a clean clone with git clone -b indigo-devel
, the only difference is the version number string in package.xml, so looks like the master has 2.2.0 but with the old package.xml, saying its 2.1.7?) gravatar image  ( 2015-05-24 12:00:32 -0500 )edit

Yeah, I don't update the package.xml version until I do a release, so even though your package.xml version said 1.1.7, it was the most recent code.

Tom Moore gravatar image Tom Moore  ( 2015-05-24 12:16:58 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2015-05-22 06:48:25 -0500

Seen: 295 times

Last updated: May 22 '15