0
$\begingroup$

I'm working on an autonomous navigation setup with ROS2 Humble (Nav2 + robot_localization + AMCL) on Ubuntu 22.04, and my robot is moving incorrectly and losing localization after each goal.

Current problem

  • The TF chain is: map → odom → base_link → laser
  • odom appears stuck or starts with a large offset
  • When setting a 2D Initial Pose, map→odom aligns, but odom offset grows again with every Nav2 goal
  • The robot often rotates in place or drives the wrong way
  • /odometry/filtered topic exists but publishes nothing
  • /imu/data is not published yet (IMU data still handled inside Arduino)
  • Error repeats frequently: [controller_server]: Timed out waiting for transform from base_link to odometry_filtered

What already works

  • /odom from Arduino publishes correctly
  • TF base_link ↔ odom updates at ~20 Hz
  • Map and AMCL load properly
  • Nav2 planner executes goals (but robot moves erratically)
  • Verified TF frames (view_frames) – chain is correct but odom drifts.

Help needed

  • Why might /odometry/filtered never publish even when the EKF node is active and receiving /odom data?
  • Does it block entirely waiting for IMU data?
  • Should Nav2 consume /odometry/filtered topic only, or still reference /odom internally?
  • Are there recommended steps to stabilize TF alignments (map→odom→base_link) when EKF is not yet providing odometry?
  • Any advice on correctly fusing IMU + wheel odometry when the IMU data currently originates from an Arduino over serial?

ODOM TF OFFSET

RVIZ

Error log nav2

[amcl-6] [INFO] [1762908039.350175943] [amcl]: initialPoseReceived [amcl-6] [WARN] [1762908039.352822327] [amcl]: Failed to transform initial pose in time (Lookup would require extrapolation into the future. Requested time 1762908039.352522 but the latest data is at time 1762908039.311044, when looking up transform from frame [base_link] to frame [odom]) [amcl-6] [INFO] [1762908039.353091960] [amcl]: Setting pose (1762908039.353084): 2.435 0.128 -1.571 [bt_navigator-11] [INFO] [1762908079.260064423] [bt_navigator_custom]: Begin navigating from current location (2.42, 0.14) to (2.44, -0.70) [planner_server-7] [WARN] [1762908079.269018879] [planner_server]: No planners specified in action call. Server will use only plugin GridBased in server. This warning will appear once. [controller_server-8] [INFO] [1762908079.304848995] [controller_server]: Received a goal, begin computing control effort. [controller_server-8] [WARN] [1762908079.311599823] [controller_server]: No controller was specified in action call. Server will use only plugin loaded FollowPath . This warning will appear once. [controller_server-8] [WARN] [1762908079.314856619] [controller_server]: No goal checker was specified in parameter 'current_goal_checker'. Server will use only plugin loaded general_goal_checker . This warning will appear once. [controller_server-8] [WARN] [1762908079.817337185] [controller_server]: RegulatedPurePursuitController detected collision ahead! [controller_server-8] [WARN] [1762908079.918018317] [controller_server]: RegulatedPurePursuitController detected collision ahead! [controller_server-8] [WARN] [1762908080.717879299] [controller_server]: RegulatedPurePursuitController detected collision ahead! [controller_server-8] [WARN] [1762908082.317271682] [controller_server]: RegulatedPurePursuitController detected collision ahead! [controller_server-8] [WARN] [1762908082.417642504] [controller_server]: RegulatedPurePursuitController detected collision ahead! [controller_server-8] [WARN] [1762908082.517284895] [controller_server]: RegulatedPurePursuitController detected collision ahead! [controller_server-8] [WARN] [1762908082.617310408] [controller_server]: RegulatedPurePursuitController detected collision ahead! [controller_server-8] [ERROR] [1762908082.617695561] [controller_server]: Controller patience exceeded [controller_server-8] [WARN] [1762908082.618480346] [controller_server]: [follow_path] [ActionServer] Aborting handle. [bt_navigator-11] [WARN] [1762908082.631140396] [bt_navigator_custom]: [navigate_to_pose] [ActionServer] Aborting handle. [bt_navigator-11] [ERROR] [1762908082.631928983] [bt_navigator_custom]: Goal failed

Related files

https://github.com/lukeTec/tcc_robo_ros2/tree/master

look for ->

  • arduino -> comunicacao_serial.ino
  • robo_driver/robo_driver -> serial_node.py
  • meu_pacote_navegacao/config -> robot_localization.yaml
  • meu_pacote_navegacao/launch-> navegacao_sem_container.yaml
  • meu_pacote_navegacao/config -> nav2_params.yaml
  • meu_pacote_slam/launch -> rplidar.launch.py
Improve this question
$\endgroup$
4
  • $\begingroup$ robot_localization is something I’ve never worked with, so I can’t really help you much. What I can do, though, is point out a few things: 1) If you’re not publishing your IMU data, I don’t think there’s much reason to use robot_localization. From what I’ve seen, it’s usually used to fuse your wheel odometry with IMU data to get a more accurate odom estimate. You could technically still use robot_localization as a filter, but it wouldn’t really improve your estimate. Take this statement with a grain of salt, though. $\endgroup$ Commented Nov 12 at 14:51
  • 1
    $\begingroup$ 2) I can also point out some inconsistencies in your configuration. I don’t know if you just missed these details in your post, but be careful with this one: [controller_server]: Timed out waiting for transform from base_link to odometry_filtered That means that in your parameters you set the odometry frame as odometry_filtered, but based on what you said here: TF base_link ↔ odom updates at ~20 Hz You’re publishing a transform from odom -> base_link, not odom_filtered -> base_link. Keep in mind that topics and TFs are two separate things. $\endgroup$ Commented Nov 12 at 14:52
  • $\begingroup$ 3) Nav2 doesn’t care where the odometry data comes from, as long as it’s published using the standard the message type that it expects. You can either change the parameters of the Nav2 nodes you’re using that specify an odometry topic, or remap them in the launch file. I’ll leave it to you to look up how to do that, it’s not difficult at all. $\endgroup$ Commented Nov 12 at 14:53
  • $\begingroup$ Thank you again, @Defend your engagements made me think more about the set parameters, so I had this 'odometry/filtered' set on bt_navigator.yaml and all the rest were only "odom", so I did update right this time. Imu hadn't been published yet on serial_node.py and Arduino's firmware had "theta = 0" meaning wasn't reading the data by MPU neither publishing to serial. Another issue I've figured out when I upload it corrections on Arduino, one channel encoder's cable wasn't working, so I switch it. $\endgroup$ Commented Nov 14 at 1:11

1 Answer 1

Reset to default
0
$\begingroup$

Your lidar scan is rotated because your map->odom->base_link transform is not accurate.

I agree with above comments from @Defend - do not use /odometry/filtered when debugging this problem; configure nav2 to just use the /odom topic. Don't forget you also must publish the odom->base_link transform on /tf.

AMCL has a parameter called transform_timeout that you can increase while debugging, but this error indicates that the time-of-day on your rviz2 computer does not match the time-of-day on the robot closely enough.

Improve this answer
$\endgroup$

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.