Ask Your Question
0

Robot_Localization not publishing transform to odom

asked 2016-02-08 19:15:26 -0500

Wagner2x gravatar image

updated 2016-02-09 10:04:41 -0500

We are using robot_localization to filter some of our sensor outputs. We are running two instances of RL but the one that takes care of the transform from map to the odom frame is not publishing the transform. For the instance of RL that is responsible for the transform between the map frame to the odom frame the diagnostics say /odom/filtered: no events recorded.

here are our launch files:

<launch>

<node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_odom" clear_params="true">


  <param name="frequency" value="30"/>
  <param name="sensor_timeout" value="0.1"/>

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


  <param name="map_frame" value="map"/>
  <param name="odom_frame" value="odom"/>
  <param name="base_link_frame" value="base_link"/>
  <param name="world_frame" value="odom"/>

  <param name="transform_time_offset" value="0.0"/>

  <param name="odom0" value="/rtabmap/odom"/>
  <param name="imu0" value="/imu/data"/>

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


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

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

  <param name="odom0_relative" value="true"/>
  <param name="imu0_relative" value="true"/>

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

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


  <param name="odom0_queue_size" value="10"/>
  <param name="imu0_queue_size" value="10"/>

  <param name="odom0_pose_rejection_threshold" value="5"/>
  <param name="odom0_twist_rejection_threshold" value="1"/>
  <param name="imu0_pose_rejection_threshold" value="0.3"/>
  <param name="imu0_twist_rejection_threshold" value="0.1"/>
  <param name="imu0_linear_acceleration_rejection_threshold" value="0.1"/>

  <param name="debug"           value="false"/>
  <param name="debug_out_file"  value="debug_ekf_localization_odom.txt"/>

  <rosparam param="process_noise_covariance">[0.05, 0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                                              0,    0.05, 0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                                              0,    0,    0.06, 0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                                              0,    0,    0,    0.03, 0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                                              0,    0,    0,    0,    0.03, 0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                                              0,    0,    0,    0,    0,    0.06, 0,     0,     0,    0,    0,    0,    0,    0,    0,
                                              0,    0,    0,    0,    0,    0,    0.025, 0,     0,    0,    0,    0,    0,    0,    0,
                                              0,    0,    0,    0,    0,    0,    0,     0.025, 0,    0,    0,    0,    0,    0,    0,
                                              0,    0,    0,    0,    0,    0,    0,     0,     0.04, 0,    0,    0,    0,    0,    0,
                                              0,    0,    0,    0,    0,    0,    0,     0,     0,    0.01, 0,    0,    0,    0,    0,
                                              0,    0,    0,    0,    0,    0,    0,     0,     0,    0,    0.01, 0,    0,    0,    0,
                                              0,    0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0.02, 0,    0,    0,
                                              0,    0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0.01, 0,    0,
                                              0,    0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0.01, 0,
                                              0,    0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0.015]</rosparam>


       <rosparam param="initial_estimate_covariance">[1e-9, 0 ...
(more)
edit retag flag offensive close merge delete

Comments

The order of instances coming up won't make a difference. Can you post a sample message from each input to each filter instance?

Tom Moore gravatar image Tom Moore  ( 2016-02-09 09:33:54 -0500 )edit

Also, for readability, can you get rid of the comments in the launch files?

Tom Moore gravatar image Tom Moore  ( 2016-02-09 09:34:53 -0500 )edit

I updated the post. Is that what you were wanting? I posted images of the output of rtabmap visual odometrey and the imu sensor information being inputted into RL.

Wagner2x gravatar image Wagner2x  ( 2016-02-09 10:02:01 -0500 )edit

You can use yaml files for setting parameters.

Orhan gravatar image Orhan  ( 2016-02-11 09:16:31 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2016-02-11 08:24:34 -0500

Tom Moore gravatar image

updated 2016-03-01 12:36:59 -0500

Ok, lots of things:

  1. I don't see a remap statement in either instance. That means both instances are publishing to /odometry/filtered. You have two different state estimates going out over the same topic.
  2. The frame_id on the rtabmap data is odom, yet you are fusing it in both instances. That means that for the EKF instance where world_frame_id is map, it's going to transform the data from odom to map, but that is the very transform that instance is trying to produce. I would avoid that.
  3. You are fusing linear acceleration from your IMU, but you lack a velocity measurement.
  4. You have two_d_mode on, yet you are fusing Z, roll, and pitch in a few places. It doesn't hurt anything, but it's better to let them be false.

All that aside, though, I think you might not be using this correctly. Why do you need two instances? Your odom frame is meant to be continuous, yet rtabmap will almost certainly give you positions that jump around a small amount. Perhaps you should give me more information about what you're trying to do. As it is, your map EKF instance is probably interfering with the operation of rtabmap.

EDIT 1 in response to comments

It's not that the second instance is needed per se, but if you want to control your robot without it constantly changing direction when the pose jumps (and it will), you'll want to have two instances. For instance 1, fuse just the IMU and visual odometry data (just use the velocity). What is the LIDAR providing? I don't see that in your launch file.

My advice would be to start with the odom frame EKF, and add one sensor at a time. Make sure you are completely satisfied that it's behaving, then introduce another sensor. When you're done fusing all the continuous sensors into the odom instance, add the second map instance, and again, start with one sensor. Debugging these kinds of things gets very difficult when you have this many sensor sources, so it's critical to make sure each component is working and configured correctly.

edit flag offensive delete link more

Comments

Sorry for the delay. We are fusing a 2d lidar, visual odometry, IMU, and gps information. It was my understanding that since we were using the gps that we needed the second instance of RL.

Wagner2x gravatar image Wagner2x  ( 2016-02-15 19:45:02 -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

Stats

Asked: 2016-02-08 19:15:26 -0500

Seen: 1,199 times

Last updated: Mar 01 '16