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

robot_localization tf tree changes from odom -> base to map -> base when using a custom particle filter

asked 2018-03-21 22:32:58 -0500

trixr4kdz gravatar image

updated 2018-03-26 17:21:04 -0500

Hello,

I have robot_localization setup to fuse IMU data from a flight controller with pose data from ORB-SLAM. I am also using gmapping to generate a 2D map. When I run my robot_localization node, my tf tree becomes odom -> base_link -> camera_link, which I think is what I'm supposed to get because right now I'm assuming that my camera is my base. However, I'm also trying to incorporate a particle filter into this setup. And when I try to run my particle filter, my tf tree changes to map -> base_link and I'm not sure why. I've been trying to find answers but I feel like a lot is going over my head.

In any case, here are the steps I did when I was using robot_localization and also use the particle filter:

  1. Go to a known fixed position (initial point).
  2. Run camera, ORB, robot_localization node, and gmapping. (At this point, my tf tree is odom -> base_link)
  3. Start mapping around and return to initial point when done.
  4. Save the map using map_server.
  5. Close gmapping.
  6. Launch the particle filter and range finders. (This is where my tf tree changes to map -> base_link while my odom frame seems to just float and is unconnected to anything).

Also here is the config file I use for my robot_localization node:

frequency: 50
sensor_timeout: 0.1
two_d_mode: true
transform_time_offset: 0.0
transform_timeout: 0.0
print_diagnostics: true
debug: false
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_link  # Defaults to "base_link" if unspecified
world_frame: odom           # Defaults to the value of odom_frame if unspecified

pose0: /orb/pose

pose0_config: [true,  true,  true,      # Position
               true,  true,  true,    # Orientation
               false,  false, false,     # Linear Velocity
               false,  false, false,      # Angular Velocity
               false,  false, false]     # Linear Acceleration   

pose0_queue_size: 2

pose0_nodelay: false

pose0_differential: false

pose0_relative: false

imu0: /mavros/imu/data

imu0_config: [true, true, true,    # Position
              true, true, true,     # Orientation
              false, false, false,    # Linear Velocity
              true, true, true,     # Angular Velocity
              true, true, true]     # Linear Acceleration              

imu0_nodelay: false
imu0_differential: true
imu0_relative: false
imu0_queue_size: 5
imu0_pose_rejection_threshold: 0.8                 # Note the difference in parameter names
imu0_twist_rejection_threshold: 0.8                #
imu0_linear_acceleration_rejection_threshold: 0.8  #

imu0_remove_gravitational_acceleration: false

use_control: true
stamped_control: false
control_timeout: 0.2
control_config: [true, false, false, false, false, true]
acceleration_limits: [1.3, 1.0, 0.0, 0.0, 0.0, 3.4]
deceleration_limits: [1.3, 1.0, 0.0, 0.0, 0.0, 4.5]
acceleration_gains: [0.8, 0.5, 0.0, 0.0, 0.0, 1.5]
deceleration_gains: [1.0, 0.7, 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.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 ...
(more)
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2018-03-22 03:37:19 -0500

tuandl gravatar image

updated 2018-03-26 06:34:47 -0500

My guess is that you are using AMCL pkg for your particle filtered localization?

EDIT1 to answer your comments

it seems like a lot is happening just to get the map->odom transform

This is correct. According to AMCL wiki: "During operation amcl estimates the transformation of the base frame (~base_frame_id) in respect to the global frame (~global_frame_id) but it only publishes the transform between the global frame and the odometry frame (~odom_frame_id).". This means amcl will correct the pose of base_link by adjusting map->odom transform. I took a closer look at AMCL and figured that my previous answer was wrong. I edited it. So back to your original question, could you edit your question by specifying you robot's setup?

is the map->odom->base transform something we can just use the tf robot_state_publisher package for

Maybe you are talking about robot_pose_ekf ?

EDIT2 answer to your new comments

@trixr4kdz sorry for the late reply, I have been caught up with my project for the last couple days.

a way we can also get the map->odom without having to do the same thing amcl is doing

Certainly, you could, but if you ask whether there is an available package then I don't know. IMO, there are 2 options:

1) consider open source your custom particle filer so everybody can have a look at what is going on. Without knowing what you are doing (for example: why your customer particle filter publishes map->base_link), it's really hard to help.

2) re-implement the part of AMCL that publish map->odom (from #L1351 to #L1418). This shouldn't be too hard (I know it is NOT easy) since you must have the whole transform: map->odom->base_link->laser_scan from you particle filter.

edit flag offensive delete link more

Comments

Sorry, I forgot to add that little detail. The particle filter we are using is based of this tutorial from the BFL package

trixr4kdz gravatar image trixr4kdz  ( 2018-03-22 03:42:50 -0500 )edit

So just to confirm, you are saying that the problem isn't with our use of the robot_localization package but with the particle filter not being a map->odom transform, correct?

trixr4kdz gravatar image trixr4kdz  ( 2018-03-22 03:46:06 -0500 )edit

Correct. I am not familiar with BFL but a quick look at #L242 make me think...

tuandl gravatar image tuandl  ( 2018-03-22 04:15:03 -0500 )edit
1

...BFL works in a similar manner of AMCL.

tuandl gravatar image tuandl  ( 2018-03-22 04:15:38 -0500 )edit

I see. Thank you very much for the help!

trixr4kdz gravatar image trixr4kdz  ( 2018-03-22 05:12:42 -0500 )edit

I was looking at the amcl code on github and it seems like a lot is happening just to get the map->odom transform. For our particular case, is the map->odom->base transform something we can just use the tf robot_state_publisher package for?

trixr4kdz gravatar image trixr4kdz  ( 2018-03-22 17:51:13 -0500 )edit

I edited my original post to add more details about our robot setup. Also apologies for the confusion, we are already using robot_localization to publish our odom->base transform, and I meant to ask if there's a way we can also get the map->odom without having to do the same thing amcl is doing.

trixr4kdz gravatar image trixr4kdz  ( 2018-03-23 19:51:46 -0500 )edit

I added our particle filter code at the very bottom, but I also put it here, which might be better for you to see: https://repl.it/@trixr4kdz/ParticleFi... . Lines 261-299 are our implementation of the AMCL code.

trixr4kdz gravatar image trixr4kdz  ( 2018-03-26 15:45:31 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2018-03-21 22:32:58 -0500

Seen: 562 times

Last updated: Mar 26 '18