You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Despite launching the ros-gz turtlebot3 spawners, the gazebo environment has only robot spawned named "burger" although the name should be either robot1 or robot2. The issue has been found in the spawn_turtlebot3.launch.py in the turtlebot3_gazebo package. The issue is that there is no launch extension for adding custom names in this file. A solution could be to either modify this file and add the name as a launch argument, or use the spawn_tb3.launch.py in the nav2_minimal_tb3_sim package which already has this as an launch argument.
Spawned turtlebot3 rapidly changes its z position so its never visible on the map until the simulation is paused. EVen then, bringing it to the RMF floor model fails, as it continues to fall and rise (?) through the map, hence the turtlebot3 can't be kept static unlike the turtlebots that spawn through the RMF spawner. The potential root cause could be the same as point 1, but it needs to be investigated further.
Nav2 Servers not available when launching. I suspect that it may be due to some issues in the launch files, but I am unable to pinpoint the cause as of now. It could also be due to nav2 expecting non-namespaced topics, but further investigation is required.
Robot poses do not reflect correctly in gazebo, as the turtlbot is placed far away from where it was supposed to be placed. Perhaps, gazebo poses are based on odom poses rather than map poses found through /clicked_point. A potential solution here could be to use the single turtlebot3 simulation and check the odom data at different spawn points, but that would be in respect to initial pose which is why further investigation is required here as well.
Not exactly an issue, but running two navigation stacks and running gazebo on software rendering is extremely resource intensive. A potential solution could be running the gazebo simulation on one device, and the nav2 stacks on the other devices.
Turtlebot3 occasionally teleports to random locations on the rviz map when nav2 amcl or even slam is running in simulations. A potential cause of this would be severe odom drift or delocalization so the dead reckoning data might just be used to localize and hence teleport the turtlebot in a new area. This issue is also apparent in single robot gazebo simulations, and even in minimal tb3 sims like tb3 world and house.
Despite launching the ros-gz turtlebot3 spawners, the gazebo environment has only robot spawned named "burger" although the name should be either robot1 or robot2. The issue has been found in the spawn_turtlebot3.launch.py in the turtlebot3_gazebo package. The issue is that there is no launch extension for adding custom names in this file. A solution could be to either modify this file and add the name as a launch argument, or use the spawn_tb3.launch.py in the nav2_minimal_tb3_sim package which already has this as an launch argument.
Spawned turtlebot3 rapidly changes its z position so its never visible on the map until the simulation is paused. EVen then, bringing it to the RMF floor model fails, as it continues to fall and rise (?) through the map, hence the turtlebot3 can't be kept static unlike the turtlebots that spawn through the RMF spawner. The potential root cause could be the same as point 1, but it needs to be investigated further.
Nav2 Servers not available when launching. I suspect that it may be due to some issues in the launch files, but I am unable to pinpoint the cause as of now. It could also be due to nav2 expecting non-namespaced topics, but further investigation is required.
Robot poses do not reflect correctly in gazebo, as the turtlbot is placed far away from where it was supposed to be placed. Perhaps, gazebo poses are based on odom poses rather than map poses found through /clicked_point. A potential solution here could be to use the single turtlebot3 simulation and check the odom data at different spawn points, but that would be in respect to initial pose which is why further investigation is required here as well.
Not exactly an issue, but running two navigation stacks and running gazebo on software rendering is extremely resource intensive. A potential solution could be running the gazebo simulation on one device, and the nav2 stacks on the other devices.
Turtlebot3 occasionally teleports to random locations on the rviz map when nav2 amcl or even slam is running in simulations. A potential cause of this would be severe odom drift or delocalization so the dead reckoning data might just be used to localize and hence teleport the turtlebot in a new area. This issue is also apparent in single robot gazebo simulations, and even in minimal tb3 sims like tb3 world and house.