Docking fails with multiple TurtleBot4s

[WallerJonathan]

Robot Model

Turtlebot4 Lite

ROS distro

Humble

Networking Configuration

I do not know

OS

Ubuntu 22.04

Built from source or installed?

Installed

Package version

Most recent package version (updated today)

Type of issue

Navigation (SLAM, Nav2 etc.)

Expected behaviour

When running docking commands (from turtlebot4_navigation) on a second turtlebot in the simulations, it should dock correctly or identify if it is docked already.

It also will not connect to the second turtlebot.

Actual behaviour

The problem seems to be this block of code:

Start docked if not already
if not naviturt.getDockedStatus():
naviturt.info("Docking for start")
naviturt.dock()

The second turtlebot that is manually spawned, which starts docked, starts to spin (does not move laterally) until it fails the docking process.

In addition, it does not seem to be able to find the second turtlebot, even when the docking block is commented out.

Error messages

[INFO] [1715708891.541648342] [robot2.basic_navigator]: Docking before initialising pose
[INFO] [1715708891.542475943] [robot2.basic_navigator]: Docking...
[INFO] [1715708925.172902338] [robot2.basic_navigator]: Goal with failed with status code: None
[INFO] [1715708925.174651407] [robot2.basic_navigator]: Publishing Initial Pose
[INFO] [1715708927.225206005] [robot2.basic_navigator]: Setting initial pose
[INFO] [1715708927.226342431] [robot2.basic_navigator]: Publishing Initial Pose
[INFO] [1715708927.227725556] [robot2.basic_navigator]: Waiting for amcl_pose to be received
[INFO] [1715708927.229177251] [robot2.basic_navigator]: Setting initial pose
[INFO] [1715708927.230112375] [robot2.basic_navigator]: Publishing Initial Pose
[INFO] [1715708927.231118124] [robot2.basic_navigator]: Waiting for amcl_pose to be received
[INFO] [1715708927.232138761] [robot2.basic_navigator]: Setting initial pose
[INFO] [1715708927.232963335] [robot2.basic_navigator]: Publishing Initial Pose
[INFO] [1715708927.233806636] [robot2.basic_navigator]: Waiting for amcl_pose to be received

This is repeated forever and the turtlebot is never recognized

To Reproduce

1. Spin up a turtlebot in the simulator using ros2 launch turtlebot4_ignition_bringup turtlebot4_ignition.launch.py namespace:=robot1 x:=0.0 y:=1.0 model:=lite nav2:=true slam:=false localization:=true rviz:=true
2. Spawn a second turtlebot in the simulator using ros2 launch turtlebot4_ignition_bringup turtlebot4_spawn.launch.py namespace:=/robot2 x:=0.0 y:=0.0 model:=lite nav2:=true slam:=false localization:=true rviz:=true
3. Run something that uses docking navigation; I am running it like so: ros2 run my_nav my_nav_py_node --ros-args -r __ns:=/robot2
4. See the problem

Other notes

I know the problem is probably not the starting position (I start the second turtlebot at (0, 0) and it still does not work).

It works fine for the first turtlebot, although it is possible I am somehow messing up namespacing.

Any ideas help a bunch!
Thanks!

[WallerJonathan]

I have made some progress with finding the errors, but I was recommended to come back here.

Please take a look at this conversation first; it seems there is a namespacing issue having to do with Turtlebot4 specifically.

Thanks in advance @RustyCPR and @smatarCPR .

[WallerJonathan]

Hi there,

I just saw there was some activity here so I wanted to add a bit more to this.

My above comment still stands and there does seem to be a problem with the launch files (nav2.launch.py is the biggest culprit I have found). These problems persist outside and inside of the simulator.

I have found that using the package nav2_bringup and launching with the command ros2 launch nav2_bringup bringup_launch.py namespace:=/MY_NS map:=MY_MAP use_namespace:=true seems to solve the namespacing issues, but the local costmap cannot see dynamic obstacles which I believe has to do with #293. It makes sense why this would not automatically work (it is made for TB3), and I had to reroute some of the config files so it works better with TB4.

As an off topic note, I believe there might be some type of issue when using a physical network with multiple turtlebots. I am not sure if it strains the network (I am using a 5G high-bandwidth router, so I don't believe this is the sole problem), but I have been experiencing problems with time synchronization and responses failing to go through. The time sync problems seem to be much worse when I disconnect my network from the internet (please correct me if I am not supposed to do that!), so I have been messing around with chrony to try and set the reference time as my desktop. I won't go too far into it here as that is not the crux of this post, but it seems this is a problem others are experiencing as seen in #414 and #416.

Thanks for the help!

[hilary-luo]

@WallerJonathan We have not tested multi-robot simulation for full functionality at this point so as you go through this in parallel feel free to contribute back anything that you do find, whether it be software changes or a tutorial on how to do it. I cannot make any promises about the amount of time I will have to look into this particular use case at the moment.

I can contribute more information for the other things that you have mentioned. It is a known issue that multiple turtlebot4's in simple discovery can strain the network and the create3's. There are things you can do like making sure that the create3's are running the latest firmware and disabling diagnostics. I am not sure what exactly you mean by responses failing to go through. Ultimately the solution to this will be to update to discovery server when multi-robot is released (should be happening soon). You should not have any time sync issues in this configuration although it could take longer to get a sync. If you do have persistent time sync issues it could be that your PC is not synced properly (by default ubuntu will be syncing with the same internet source as the Turtlebot4).

As you seemed to get to, if you disconnect the network from the internet then you need to redirect the time sync to your own computer or server. This should be fairly straight forward to do, just allow requests on your device from the turtlebot4 IP addresses and then update the chrony file on the raspberry pi to reach out to your computer. You can then choose and either redirect the ntp conf on the create3 either to your computer or the raspberry pi.