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

Robot Localization Not Publishing odom->base_link

asked 2022-04-13 19:50:23 -0500

ahnikom gravatar image

Hello,

I have been working through the Nav2 first-Time Robot Setup example (https://navigation.ros.org/setup_guid...) and have run into an issue while implementing the code onto a physical diff drive platform in the "Setting Up Odometry" step.

The ekf publisher works fine when I am using the Gazebo simulation with plugins outlined in the tutorial, but when I try to use a similar process for the physical system (stripping out the gazebo simulation and replacing it with my own odometry publisher nodes), the odom-base_link transform stops being published by the robot localization EKF.

All necessary nodes show up fine in rqt_graph, and the odometry/filtered topic is being published.

I have searched around and all of the solutions that I can find online don't seem to lead me anywhere. Any advice is greatly appreciated.

Below is the EKF config file, and the launch file I'm using to launch the rviz + robot localization portion of the code (currently manually launching the nodes dealing with the physical hardware and reporting of odometry).

config file:

    ### ekf config file ###
ekf_filter_node:
    ros__parameters:
# The frequency, in Hz, at which the filter will output a position estimate. Note that the filter will not begin
# computation until it receives at least one message from one of theinputs. It will then run continuously at the
# frequency specified here, regardless of whether it receives more measurements. Defaults to 30 if unspecified.
        frequency: 30.0

# ekf_localization_node and ukf_localization_node both use a 3D omnidirectional motion model. If this parameter is
# set to true, no 3D information will be used in your state estimate. Use this if you are operating in a planar
# environment and want to ignore the effect of small variations in the ground plane that might otherwise be detected
# by, for example, an IMU. Defaults to false if unspecified.
        two_d_mode: true

# Whether to publish the acceleration state. Defaults to false if unspecified.
        publish_acceleration: true

# Whether to broadcast the transformation over the /tf topic. Defaultsto true if unspecified.
        publish_tf: true

# 1. Set the map_frame, odom_frame, and base_link frames to the appropriate frame names for your system.
#     1a. If your system does not have a map_frame, just remove it, and make sure "world_frame" is set to the value of odom_frame.
# 2. If you are fusing continuous position data such as wheel encoder odometry, visual odometry, or IMU data, set "world_frame"
#    to your odom_frame value. This is the default behavior for robot_localization's state estimation nodes.
# 3. If you are fusing global absolute position data that is subject to discrete jumps (e.g., GPS or position updates from landmark
#    observations) then:
#     3a. Set your "world_frame" to your map_frame value
#     3b. MAKE SURE something else is generating the odom->base_link transform. Note that this can even be another state estimation node
#         from robot_localization! However, that instance should *not* fuse the global data.
        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" ifunspecified
        world_frame: odom           # Defaults to the value ofodom_frame if unspecified ...
(more)
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2022-04-15 10:48:07 -0500

ahnikom gravatar image

The mistake was on my end while handling the header timestamp for the /bot/odom message.

In the node that generates the timestamped odom message, I had accidentally left the assignment of the header timestamp value commented out after I had been working to sort out a problem with timestamps and clock usage. I.E. the header was constantly timestamped at 0s 0ns. breaking the EKF node.

Thank you everyone who looked at this! Sorry that the issue was located squarely between the chair and the keyboard.

edit flag offensive delete link more

Question Tools

2 followers

Stats

Asked: 2022-04-13 19:50:23 -0500

Seen: 888 times

Last updated: Apr 15 '22