TB4 doesn't move until you go and stand BEHIND!

[UdayWaveMark]

Robot Model

Turtlebot4 Standard

ROS distro

Jazzy

Networking Configuration

Discovery Server

OS

Ubuntu 24.04

Built from source or installed?

Installed

Package version

Using TurtleBot4 Standard I followed the instructions given in the TurtleBot UserManual Tutorials '4 Generating a Map to generate a map and '5 Navigation' to capture bunch of x, y coordinates (poses) in that map.

In the 'turtlebot4_python_tutorials' in the 'nav_through_poses.py' I've set initial and a couple of capture pose (goal_pose).

In 4 different terminal windows I issue the following commands in that order:

1. ros2 launch turtlebot4_navigation localization.launch.py map:=/home/udaywavemark/office3.yaml. (this launches the map i captured)
2. ros2 launch turtlebot4_navigation nav2.launch.py (launches the Nav2)
3. ros2 launch turtlebot4_viz view_navigation.launch.py (launches RViz to watch what's happening)
4. ros2 run turtlebot4_python_tutorials nav_through_poses (the sample code is modified to have my captured poses)

As soon as I issue the 4th command the robot moves for a fraction of second (or the wheels make the sound for a fraction of a second) and then nothing happens. Robot never moves after this.

In the RViz all the status show "active" in green. rosout is quiet.

Now, when I go and stand like one feet "BEHIND" the TB4, it starts moving and then it goes and stops at the FIRST spot specified in the 'goal_pose' array. As soon as it reaches that spot it STOPS. Now, once again I go and stand "BEHIND" the TB4 it start to move again and goes to the next spot specified in the 'goal_pose' array and so on and forth.

Here one thing to note is that...

• For the robot to move "there needs to be something less than one feet BEHIND it"
• The person or the object MUST be BEHIND the robot. Not in FRONT or its SIDEs

It acts as if it needs some kind of persuasion!

I'm using the sample code pretty much "AS IS" (since I found some problems with docking/undocking sequences I removed the code specific to that). I'm not sure what is going on here.

Any help would be very much appreciated.

Here is my 'nav_through_poses.py' code:

import rclpy
from turtlebot4_navigation.turtlebot4_navigator import TurtleBot4Directions, TurtleBot4Navigator

def main():
rclpy.init()

navigator = TurtleBot4Navigator()

# Start on dock
# if not navigator.getDockedStatus():
#     navigator.info('Docking before intialising pose')
#     navigator.dock()

# Set initial pose
initial_pose = navigator.getPoseStamped([-0.8854837417602539, -0.0904969573020935], TurtleBot4Directions.NORTH)
navigator.setInitialPose(initial_pose)

# Wait for Nav2
navigator.waitUntilNav2Active()

# Set goal poses
goal_pose = []
goal_pose.append(navigator.getPoseStamped([-1.2812573909759521, -7.930064678192139], TurtleBot4Directions.EAST))
goal_pose.append(navigator.getPoseStamped([1.340737223625183, 1.492254614830017], TurtleBot4Directions.NORTH))

# Undock
#navigator.undock()

# Navigate through poses
navigator.startThroughPoses(goal_pose)

# Finished navigating, dock
#navigator.dock()

rclpy.shutdown()

if name == 'main':
main()

Type of issue

Navigation (SLAM, Nav2 etc.)

Expected behaviour

Once map is launched and the coordinates are correct TB4 navigation should work.

Actual behaviour

TB4 never moves "unless someone go and stand BEHIND it".

Error messages

To Reproduce

1. Launch captured map
2. Launch Nav2
3. Launch RViz to view (this step is optional)
4. Run 'nav_through_poses'

Other notes

No response

[slowrunner]

@UdayWaveMark Until they add the Jazzy and Ubuntu 24.04 options to the troubleshooting template, you can choose something just like you did, finish and press submit, then go back and edit your troubleshooting issue, replacing the wrong answers with Jazzy and 24.04.

[UdayWaveMark]

@slowrunner Thank you for the suggestion (rather a hack!). I now have edited my original post with appropriate / relevant information and cleaned up the content.

[slowrunner]

@UdayWaveMark Can you post the Rviz2 display showing the base map with cost map, and the log from the navigation process.

Would like insight into what the bot is thinking.

My hypothesis of what you may be seeing: If the local or global planner cannot find a path to the goal due to "high cost" band where the bot is, adding a dynamic "obstacle" induces a higher priority "obstacle avoidance" plan that moves the bot out of the high cost band into a lower cost area which then allows the local planner to resume following the global plan.

A lot of the mapping and navigation demos on the net, are executing in fairly sterile environments. In my home environment with my former GoPi5Go-Dave robot running Humble, I had to decrease the inflation distance so that some free areas were available. That allowed navigation to create a plan, but the planner tried to minimize the travel cost by planning travel close to the walls. In my home there are lots of chairs, planters, end tables, you name it that suddenly become visible to the bot (with an obstacle cost envelope around them), as it executes the global plan. The bot is going great and then decides it needs to use the obstacle avoidance planner which often will turn toward the obstacle and then negotiate its escape before it can release planning back to the local/global planner to continue toward the goal. In some cases I could not give the bot a goal to the next room, I had to break the journey up into short "achievable" segments to prevent the planner from giving up and declaring failure.

I've managed to get the async SLAM mapping to succeed now with having chronyd running on the RPi5, so next step is to investigate navigation. I'm right behind you.

[UdayWaveMark]

@slowrunner ,

As a newbie (to ROS2 / TB4) lot of the stuff you mentioned is way over my head. But, except you I'm not getting any answers or help from anyone. Here I'm attaching the 'base map', 'cost map', and relevant log files.

When you have time please take a look and see whether your assumptions are correct or it is all together something else.

Tagging @RustyCPR , @smatarCPR to keep them in loop.

[UdayWaveMark]

Logs from: ros2 launch turtlebot4_navigation localization.launch.py map:=/home/udaywavemark/home1.yaml

localization_logs.txt

[UdayWaveMark]

Logs from: ros2 launch turtlebot4_navigation nav2.launch.py

nav2_logs.txt

[UdayWaveMark]

Logs from: ros2 launch turtlebot4_viz view_navigation.launch.py

rviz_logs.txt

[slowrunner]

Logs from: ros2 launch turtlebot4_navigation nav2.launch.py

I took a look, but Nav2 is so very complex - we're exploring this together. It is not what I guessed at.

The first thing I notice is that your rviz2 is not showing either a global cost map nor local costmap. (more on this in a bit)

The second thing I see are:

• local costmap "INFO" messages "Timed out waiting for transform from base_link to odom ... frame does not exist" but then it says "start"

• global costmap "INFO": "Timed out waiting for transform base_link to map...lookup would require extrapolation into the past.. request 1835.654 earliest data 1836.353" but then it says "start"

• I see a 3 pose goal and then

  • "WARN: Failed to create plan with tolerance of 0.5m"
  • "ERROR: ..Aborting"

It appears the global costmap plugin did not generate a costmap. The local costmap plugin did not generate a costmap. The planner could not plan a route since no costmaps are published.

The "extrapolation into the past" info msg may be related to Create3 clock not syncronized with the Pi clock - I am not sure about those kinds of issues.

• On your time server: What does sudo chronyc clients show under "Last" for client 192.168.186.2?

I don't know much about clock sync - my bot runs 24/7 and sometimes the sync clients Last shows "66m" meaning it has been over an hour since the Create3 asked for a clock sync, then the NTP packet number will increase by one and the "Last" value will start counting seconds again. There is not supposed to be very much drift in an hour - certainly not 0.7 seconds that your nav2 was timing out.

Also you might look in the Create3 log for ntpd issues. Mine just logged:

Feb 14 03:59:15 iRobot-883C456BE1E840DC89E64B28B4F75B53 user.notice ntpd: ntpd: reply from 192.168.186.3: delay 0.002065 is too high, ignoring

Which means the Create3 didn't want to sync to the time my RPi chrony time server was giving as the correct time. I don't know if that means the Create3 will get in sync eventually, or only if I reboot - like I said I don't know enough (yet - we learn by things not working, right?).

Another question - did you do the reset to clear out the WiFi connection? You want all ROS sensor topics only going across the USB-Ethernet connection, not some over the USB-C cable and some over WiFi.

SO.. BIG QUESTION - If you:

• launch localization (on the RPi) and
• launch navigation (on the RPi)
• launch the rviz (on your remote desktop/laptop)
• Do not launch your 'nav_through_poses'
• Click on Set Initial Pose and click on the point on the map where the robot really is, and drag for the arrow to point in the direction the robot is actually headed

Do you eventually see a global and local costmap in rviz2?
Should look something like these (from former robot - I haven't got my TB5-WaLI to run nav2 yet):

If no: attach the nav2 log
If yes:

• Click the goal button in rviz2 and
• click on a point that is within sight of the robot, in a white area (not a high cost area), and not behind any walls or obstructions.
• what happened?

p.s. > But, except you I'm not getting any answers or help from anyone.

Yeah but we're not paying the support personnel salaries either! I'm glad to have someone else playing with these fun toys.

[slowrunner]

@UdayWaveMark

The second screenshot

#541 (comment)

shows localization is working. That is good. I would have hoped to see a better match between the map and the Lidar on the wall that is farther away from the bot. The match looks good around the bot, but I am wondering how accurate your map is in that farther away area. That isn't affecting weather or not you get a costmap, but may affect navigating once we get your bot planning and executing the plan. If indeed that will become an issue, you may want to try mapping again going slow, turning as little as possible (go straight, turn slowly to new heading, or slow 180 and straight back), and perhaps watch for map completeness - then don't revisit an area you mapped so it doesn't remap the area with accumulated error.

Also if you have tile areas and carpeted areas, the map can get messed up a little in the transitions. Try to cross transitions at 90 degrees so the wheels do not slip and confuse the mapper.

[UdayWaveMark]

@slowrunner ,

Wow! there is a lot of feedback! Thank you very much. Couple of things...

I was running 'Localization' and 'Nav2' on my 'remote desktop / laptop'. Not from the RPi. Wondering whether this is the reason why rviz2 is not showing the local or global costmap? Today I will do as you suggested (run the Localization and Nav2 from RPi)

When I issue 'date' command on the 'remote laptop' and 'RPi' i get pretty much the same time (1 second difference that maybe because i've opened two terminals and switching from one to another to issue these commands).

I looked into the Create 3 logs and I believe the there is no (not significant) delay in the ntpd:

Another question - did you do the reset to clear out the WiFi connection? You want all ROS sensor topics only going across the USB-Ethernet connection, not some over the USB-C cable and some over WiFi.

I really don't understand this. What do you mean by it? How do i validate this? How can i configure it to channel this correct?

This shows localization is working.

I can't see the image you attached before the comment. So, I don't know what made you say that.

Today I will create a map of a very small area that doesn't involve any carpeting. Earlier I myself don't remember while creating the map whether I went slow, turned as little as possible etc., This time while mapping a small area I will just follow you suggestions and see whether that makes any difference.

One thing real quick... with my previous maps and logs (that I've added here), though you found lot of discrepancies, the robot managed to go to all the 3 poses (specified in the nav_through_poses). But for it to move "I had to go and stand behind it at every pose".

Yeah but we're not paying the support personnel salaries either!

I really thought Rusty and smatar are Clearpath Robotics folks.

[slowrunner]

I was running 'Localization' and 'Nav2' on my 'remote desktop / laptop'. Not from the RPi. Wondering whether this is the reason why rviz2 is not showing the local or global costmap? Today I will do as you suggested (run the Localization and Nav2 from RPi)

Another thing to try after starting localization and nav, before starting your nav_thru_poses is to drive the bot a short distance and see if the costmaps appear. Nav2 needs some synchronized sensor data and perhaps a little drive will kickstart it.

When I issue 'date' command on the 'remote laptop' and 'RPi' i get pretty much the same time (1 second difference that maybe because i've opened two terminals and switching from one to another to issue these commands).

Time sync and sensor data timestamp difference was 0.7 seconds total between the creat3 odom timestamp and the RPi lidar data timestamp so nav2 was rejecting the data. This whole timing stuff is hurting us. See other folks nav issues - same warnings in logs. Don’t know enough about this.

Another question - did you do the reset to clear out the WiFi connection? You want all ROS sensor topics only going across the USB-Ethernet connection, not some over the USB-C cable and some over WiFi.

I really don't understand this. What do you mean by it? How do i validate this? How can i configure it to channel this correct?

When you browse to Your_RPi_IP:8080/wifi. Is the network name and password empty?

This shows localization is working.

I can't see the image you attached before the comment. So, I don't know what made you say that.

I tried to fix that with a link to your screenshot

One thing real quick... with my previous maps and logs (that I've added here), though you found lot of discrepancies, the robot managed to go to all the 3 poses (specified in the nav_through_poses). But for it to move "I had to go and stand behind it at every pose".

Need log from that to know why that worked. Weirdness.

Yeah but we're not paying the support personnel salaries either!

I really thought Rusty and smatar are Clearpath Robotics folks.

They are. Robot companies have a really tough business model. They aren’t shipping millions of bots, the bots are more complex than the user-base is knowledgeable so any profit the investors might have hoped for has to be split with the support team costs. Bots have to be reasonable cost so folks will purchase but every purchaser will need quite a bit of hand holding. Support may be farmed out, or a portion of the time allocated from an employee with other responsibilities. Hopefully the user base eventually gets to having some experienced users that stick around to help noobs. Many times users are only “dropped in” for a semester, or move on to other adventures so the user knowledge and experience gets lost. Add to this the diversity of use cases ROS supports and we have to give the support team credit for whatever they muster. Oh, and the there is the annual release that forces new issues even for experienced users. I really feel for support. Tough position.

[slowrunner]

SO.. BIG QUESTION - If you:

• launch localization (on the RPi) and
• launch navigation (on the RPi)
• launch the rviz (on your remote desktop/laptop)
• Do not launch your 'nav_through_poses'
• Click on Set Initial Pose and click on the point on the map where the robot really is, and drag for the arrow to point in the direction the robot is actually headed

Do you eventually see a global and local costmap in rviz2?

I did this with TB5-WaLI and I do not get global or local costmaps, just like you. This is a problem and I do not know enough to diagnose why. We are going to need @hilary-luo or @SteveMacenski (the Nav2 "God") to assist us.

I'm going to put in a specific "Global and Local Costmap Not Generated" issue and see if we get some help. This very well could be time sync issue because I am seeing hints of that:
rviz2:

[rviz2-1] [INFO] [1739631433.536022906] [rviz2]: Waiting for the slam_toolbox node configuration.
[rviz2-1] [ERROR] [1739631436.458521413] [rviz2]: Lookup would require extrapolation into the future.  Requested time 1739631436.492285 but the latest data is at time 1739631436.455519, when looking up transform from frame [rplidar_link] to frame [map]
[rviz2-1] [INFO] [1739631438.537551702] [rviz2]: Waiting for the slam_toolbox node configuration.

and localization:

[lifecycle_manager-3] [INFO] [1739630715.152881752] [lifecycle_manager_localization]: Server amcl connected with bond.
[lifecycle_manager-3] [INFO] [1739630715.152976307] [lifecycle_manager_localization]: Managed nodes are active
[lifecycle_manager-3] [INFO] [1739630715.153001603] [lifecycle_manager_localization]: Creating bond timer...
[amcl-2] [INFO] [1739630724.893270177] [amcl]: Message Filter dropping message: frame 'rplidar_link' at time 1739630714.854 for reason 'the timestamp on the message is earlier than all the data in the transform cache'
[amcl-2] [INFO] [1739630756.856716732] [amcl]: initialPoseReceived
[amcl-2] [WARN] [1739630756.856900102] [amcl]: Failed to transform initial pose in time (Lookup would require extrapolation into the future.  Requested time 1739630756.796981 but the latest data is at time 1739630756.769780, when looking up transform from frame [odom] to frame [base_link])
[amcl-2] [INFO] [1739630756.856939343] [amcl]: Setting pose (0.000000): 6.844 -0.096 3.142

and nav2:

[lifecycle_manager-10] [INFO] [1739630757.201477050] [lifecycle_manager_navigation]: Activating planner_server
[planner_server-3] [INFO] [1739630757.202251809] [planner_server]: Activating
[planner_server-3] [INFO] [1739630757.202325124] [global_costmap.global_costmap]: Activating
[planner_server-3] [INFO] [1739630757.202348457] [global_costmap.global_costmap]: Checking transform
[planner_server-3] [INFO] [1739630757.202479216] [global_costmap.global_costmap]: Timed out waiting for transform from base_link to map to become available, tf error: Lookup would require extrapolation into the past.  Requested time 1739630757.106600 but the earliest data is at time 1739630757.825090, when looking up transform from frame [base_link] to frame [map]
[planner_server-3] [INFO] [1739630757.702501971] [global_costmap.global_costmap]: Timed out waiting for transform from base_link to map to become available, tf error: Lookup would require extrapolation into the past.  Requested time 1739630757.667665 but the earliest data is at time 1739630757.825090, when looking up transform from frame [base_link] to frame [map]
[planner_server-3] [INFO] [1739630758.202691875] [global_costmap.global_costmap]: start
[planner_server-3] [INFO] [1739630759.256948505] [planner_server]: Activating plugin GridBased of type NavfnPlanner
[planner_server-3] [INFO] [1739630759.267166481] [planner_server]: Creating bond (planner_server) to lifecycle manager.
[lifecycle_manager-10] [INFO] [1739630759.390589860] [lifecycle_manager_navigation]: Server planner_server connected with bond.

I do not know enough to determine what the Create3 clock difference from the chronyd on my RPi, but it may be, (looking strongly IMO), that we all are experiencing clock sync issues.