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

robot_localization: "Global EKF" without absolute pose information

asked 2018-12-10 06:02:31 -0500

wiireless gravatar image

updated 2018-12-10 19:20:36 -0500

Hello there,

I am attempting the obtain accurate pose information from my "global ekf" (with map -> odom transform) in the event that my lidar stops functioning, which results in AMCL to stop publishing pose updates.

To give some context, I have two r_l nodes running. The first in "local mode" (odom -> base_link) and the second in "global mode" (map -> odom). My local EKF is providing me with splendid results (approximate error of <1m after travelling for 200m). Because of this, I do not see any reason why I would not be able to obtain similar results for the global EKF by using the same parameters. However, this is not the case. I have tried to run two instances of the r_l node with the exact same parameters, except for a difference in the world_frame parameter.

The configuration that I use for both EKFs are as follows:

frequency: 25
sensor_timeout: 0.1
two_d_mode: true
transform_time_offset: 0.0
transform_timeout: 0.0

print_diagnostics: true
debug: false
debug_out_file: /path/to/debug/file.txt

publish_tf: true
publish_acceleration: false

map_frame: map              # Defaults to "map" if unspecified
odom_frame: odom            # Defaults to "odom" if unspecified
base_link_frame: base_footprint  # Defaults to "base_link" if unspecified
world_frame: odom or map           # Defaults to the value of odom_frame if unspecified

odom0: /odom
odom0_config: [false,  false,  false,
               false, false, false,
               true, true, false,
               false, false, true,
               false, false, false]
odom0_queue_size: 2
odom0_nodelay: false
odom0_differential: false
odom0_relative: false

imu0: /imu
imu0_config: [false, false, false,
              false, false, false,
              false, false, false,
              false, false, true,
              false, false, false]
imu0_nodelay: false
imu0_differential: false
imu0_relative: true
imu0_queue_size: 5
imu0_remove_gravitational_acceleration: false

use_control: false
stamped_control: false
control_timeout: 0.2
control_config: [true, false, false, false, false, true]
acceleration_limits: [2.6, 0.0, 0.0, 0.0, 0.0, 6.8]
deceleration_limits: [2.6, 0.0, 0.0, 0.0, 0.0, 6.8]
acceleration_gains: [0.8, 0.0, 0.0, 0.0, 0.0, 0.9]
deceleration_gains: [1.0, 0.0, 0.0, 0.0, 0.0, 1.0]

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.01, 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.80, 0,     0,     0,    0,    0,    0,    0,    0,    0,
   0,    0,    0,    0,    0,    0,    0.550, 0,     0,    0,    0,    0,    0,    0,    0,
   0,    0,    0,    0,    0,    0,    0,     0.001, 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.01, 0 ...
(more)
edit retag flag offensive close merge delete

Comments

If you aren't providing your 'global ekf' with an absolute source of positioning (i.e., a pose estimate of base_link in the map frame) it isn't going to provide any information that the 'local ekf' isn't already providing.

stevejp gravatar image stevejp  ( 2018-12-10 07:57:31 -0500 )edit

I understand that. For my real use case, I am definitely fusing AMCL + IMU + Odom. However, I am interested in a scenario whereby my AMCL pose becomes unreliable and I would need to ignore its pose message for a set duration and in the meantime, only fuse IMU + odom messages.

wiireless gravatar image wiireless  ( 2018-12-10 08:26:10 -0500 )edit

Currently, my "global EKF" is not giving me the same performance as the "local EKF". whereby a simple rotating on the spot would already result is significant yaw error. What puzzles me is that the parameters that I use are exactly the same and thus I would be expecting to see the exact same result!

wiireless gravatar image wiireless  ( 2018-12-10 08:27:34 -0500 )edit

Can you post your launch file? Also confirm that the "odom_raw" frame id in your odom message is a typo (or that you are specifying the odom_raw frame in your EKF params)

stevejp gravatar image stevejp  ( 2018-12-10 09:19:11 -0500 )edit

odom_raw is not a typo. Because the /odom_filtered msg would have been published to the odom frame by the "local ekf, that would mean than both the original /odom and /odom_filtered msgs will belong to the odom frame, which sounds wrong to me. I have added the launch file to the question

wiireless gravatar image wiireless  ( 2018-12-10 19:18:21 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2019-01-29 05:25:05 -0500

Tom Moore gravatar image

This is interesting. Just so I understand, in this example, you are not using amcl at all, right? As in, was amcl running at the time? If so, was it configured to not publish its transform? If amcl is still publishing map->odom, that will conflict with the EKF. Also, in what frame are you visualizing that output?

Try this: with amcl off (and I mean not running at all), drive forwards for a few meters, then turn left 90 degrees, and then drive forwards again, turn 90 degrees, and drive forwards again. Stop there, and then give me the current output messages from both of your EKFs. They ought to be the same.

None of your data is being fused as pose data, so your odom_raw frame_id won't hurt anything. We're using the child_frame_id in that message, because we're only fusing velocity.

Finally, what is the base_footprint->imu transform?

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2018-12-10 06:02:31 -0500

Seen: 364 times

Last updated: Jan 29 '19