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 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.