Initial support to the new Gazebo

[ahcorde]

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	https://github.com/ros-planning/navigation2/issues/2997

---

Description of contribution in a few bullet points

Modified tb3_simulation_launch.py launch file to use the new Gazebo. It includes some new dependencies: gz_ros_bridge, gz_ros_sim and gz_ros2_control with diff_drive_controller and joint_state_broadcaster controllers

Test it

ros2 launch nav2_bringup tb3_simulation_launch.py use_gz:=True robot_sdf:=`ros2 pkg prefix nav2_bringup`/share/nav2_bringup/urdf/gz_turtlebot3_waffle.urdf world:=`ros2 pkg prefix nav2_bringup`/share/nav2_bringup/worlds/gz_world_only.model

ros2 launch nav2_bringup tb3_simulation_launch.py use_gz:=False headless:=False

[mergify[bot]]

@ahcorde, your PR has failed to build. Please check CI outputs and resolve issues. You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[SteveMacenski]

Thanks! The screen cap looks great :heart:

[mergify[bot]]

@ahcorde, your PR has failed to build. Please check CI outputs and resolve issues. You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[SteveMacenski]

Check CI for linting errors, I think when you adjusted the copyright you misformatted it a little

[SteveMacenski]

I want to have someone else take a look for me as well on this one since there's alot of small subtle things that could cause problems + I know someone that's been working with new-gazebo alot recently. @bperseghetti could you do the honors?

[ahcorde]

This one is fixed, odom frame is in the right place

[SteveMacenski]

This one is fixed, odom frame is in the right place

Huh?

[ahcorde]

This one is fixed, odom frame is in the right place

Huh?

it's weird, but this one is fixed, I'm trying to fix the other turtlebot3 model in the nav2_simple_commander package

[SteveMacenski]

Sorry, I read this one before the simple commander one :smile:

[SteveMacenski]

The min range cannot be zero? Why is that?

[ahcorde]

The min range cannot be zero? Why is that?

it's an OGRE(2) restriction:

what():  OGRE EXCEPTION(2:InvalidParametersException): Near clip distance must be greater than zero. in Frustum::setNearClipDistance at ./OgreMain/src/OgreFrustum.cpp (line 127)

[ahcorde]

I have a question related to the map -> odom transformation. As far as I understand this transformation is provided by the AMCL node and according to the Gazebo classic simulation the odom tf should be pretty close to the map tf. But when I simulate with the new Gazebo the tf is where the robot is initialized. is this correct ?

[SteveMacenski]

it's an OGRE(2) restriction:

That seems kind of bullshit, but I suppose that's not bullshit in our direct control :laughing:

I have a question related to the map -> odom transformation. As far as I understand this transformation is provided by the AMCL node and according to the Gazebo classic simulation the odom tf should be pretty close to the map tf. But when I simulate with the new Gazebo the tf is where the robot is initialized. is this correct ?

Where's the odom frame in that picture? Under the robot? Sorry its hard to tell white-on-white.

AMCL provides the map->odom transform, but the odom frame location should be initialized to zero on simulation start. Where it initializes is not of particular importance as long as everything is working OK. The fact though that its different from Gazebo Classic is suspicious but not inherently problematic. I'd question why it is that is the case, but its arbitrary. I'd echo the odom topic and see what the values are, if they're starting a non-zero values, that would be pretty annoying.

  frame_id: odom
child_frame_id: base_footprint
pose:
  pose:
    position:
      x: -1.9999463964725375
      y: -0.5000002369092722
      z: 0.008724293775146675

In gazebo classic, it looks like the odom frame starts at -2 -0.5 which is only used by the gazebo spawner for the robot location. I'm not sure how that's being fed to the odom system or if that's a quirk of the gazebo ros plugins

[SteveMacenski]

Is this broadly done now just pending Ben's review?

[SteveMacenski]

Also is this for new-Gazebo or Ignition? It was brought up in the WG this week that this might be ignition, which we don't plan to support in favor of new-gazebo (goddamn this naming is incredibly annoying to deal with) to just skip over the depreciated system and onto what's going to be developed / supported in the future

[Ryanf55]

Also is this for new-Gazebo or Ignition? It was brought up in the WG this week that this might be ignition, which we don't plan to support in favor of new-gazebo (goddamn this naming is incredibly annoying to deal with) to just skip over the depreciated system and onto what's going to be developed / supported in the future

Specifically, it was recommended that we use gazebo garden instead of gazebo ignition (gz prefix instead of ign)

[ahcorde]

this is all new Gazebo, we are using gz instead of ign. There is only one remaining thing: one key in rosdistro, ign_ros2_control which should be gz_ros2_control. I have already opened a PR to fix it

we can merge this PR and I will open a PR when it's merged or we can wait.

[SteveMacenski]

I don't think that's a blocker for this PR, but of course when that's handled a PR back here to update it would be appreciated.

@bperseghetti are you happy with the adjustments made?

[ahcorde]

is there any blocker to merge this PR? I would love to continue aading more support for the new Gazebo, same with the nav2_simple_commander PR

[SteveMacenski]

The blocker is me just testing it locally to sanity check things, but nothing technical should that work fine.

[SteveMacenski]

@ahcorde this does not appear to work. I think it assumes that the resource path has something set already

steve@mo:~/Documents/navigation2_ws$ ros2 launch nav2_bringup tb3_gz_simulation_launch.py
[INFO] [launch]: All log files can be found below /home/steve/.ros/log/2023-06-27-16-52-33-924904-mo-303524
[INFO] [launch]: Default logging verbosity is set to INFO
[ERROR] [launch]: Caught exception in launch (see debug for traceback): unsupported operand type(s) for +=: 'NoneType' and 'str'

[ahcorde]

@ahcorde this does not appear to work. I think it assumes that the resource path has something set already

steve@mo:~/Documents/navigation2_ws$ ros2 launch nav2_bringup tb3_gz_simulation_launch.py
[INFO] [launch]: All log files can be found below /home/steve/.ros/log/2023-06-27-16-52-33-924904-mo-303524
[INFO] [launch]: Default logging verbosity is set to INFO
[ERROR] [launch]: Caught exception in launch (see debug for traceback): unsupported operand type(s) for +=: 'NoneType' and 'str'

should be fixed here https://github.com/ros-planning/navigation2/pull/3634/commits/5a3e06c06aa39dcbbc34d7c4518a8e046c9b6b8d

[SteveMacenski]

Appears to work now, but a few questions:

What's with the camera view? Its warping the gazebo front-ends view alot and its very distracting.

I tried to close the gazebo window and got a super nasty trace which is not a good look

[ruby $(which ign) gazebo-9] Stack trace (most recent call last):
[ruby $(which ign) gazebo-9] #23   Object "[0xffffffffffffffff]", at 0xffffffffffffffff, in 
[ruby $(which ign) gazebo-9] #22   Object "ign gazebo -g", at 0x56176f0261c4, in _start
[ruby $(which ign) gazebo-9] #21   Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7ffba2829e3f, in __libc_start_main
[ruby $(which ign) gazebo-9] #20   Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7ffba2829d8f, in 
[ruby $(which ign) gazebo-9] #19   Object "ign gazebo -g", at 0x56176f02617e, in 
[ruby $(which ign) gazebo-9] #18   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7ffba2ca8e19, in ruby_run_node
[ruby $(which ign) gazebo-9] #17   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7ffba2ca5317, in 
[ruby $(which ign) gazebo-9] #16   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7ffba2e3a30c, in rb_vm_exec
[ruby $(which ign) gazebo-9] #15   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7ffba2e34c96, in 
[ruby $(which ign) gazebo-9] #14   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7ffba2e31fc5, in 
[ruby $(which ign) gazebo-9] #13   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7ffba2e2fc34, in 
[ruby $(which ign) gazebo-9] #12   Object "/usr/lib/x86_64-linux-gnu/ruby/3.0.0/fiddle.so", at 0x7ffba2a7544b, in 
[ruby $(which ign) gazebo-9] #11   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7ffba2dfd088, in rb_nogvl
[ruby $(which ign) gazebo-9] #10   Object "/usr/lib/x86_64-linux-gnu/ruby/3.0.0/fiddle.so", at 0x7ffba2a74d6b, in 
[ruby $(which ign) gazebo-9] #9    Object "/lib/x86_64-linux-gnu/libffi.so.8", at 0x7ffba2a35492, in 
[ruby $(which ign) gazebo-9] #8    Object "/lib/x86_64-linux-gnu/libffi.so.8", at 0x7ffba2a38e2d, in 
[ruby $(which ign) gazebo-9] #7    Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6-ign.so.6.11.0", at 0x7ffb9ec7386c, in runGui
[ruby $(which ign) gazebo-9] #6    Object "/lib/x86_64-linux-gnu/libignition-gazebo6-gui.so.6", at 0x7ffb9de889db, in ignition::gazebo::v6::gui::runGui(int&, char**, char const*, char const*, int, char const*)
[ruby $(which ign) gazebo-9] #5    Object "/lib/x86_64-linux-gnu/libignition-gui6.so.6", at 0x7ffb9db5a16c, in ignition::gui::Application::~Application()
[ruby $(which ign) gazebo-9] #4    Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7ffb9ccef923, in QObject::~QObject()
[ruby $(which ign) gazebo-9] #3    Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7ffb9cce4a6d, in QObjectPrivate::deleteChildren()
[ruby $(which ign) gazebo-9] #2    Object "/lib/x86_64-linux-gnu/libignition-gazebo6-gui.so.6", at 0x7ffb9de90e1c, in ignition::gazebo::v6::GuiRunner::~GuiRunner()
[ruby $(which ign) gazebo-9] #1    Object "/lib/x86_64-linux-gnu/libignition-gazebo6-gui.so.6", at 0x7ffb9de90e01, in ignition::gazebo::v6::GuiRunner::~GuiRunner()
[ruby $(which ign) gazebo-9] #0    Object "/lib/x86_64-linux-gnu/libignition-gazebo6-gui.so.6", at 0x7ffb9de9f63b, in void ignition::utils::detail::DefaultDelete<ignition::gazebo::v6::GuiRunner::Implementation>(ignition::gazebo::v6::GuiRunner::Implementation*)
[ruby $(which ign) gazebo-9] Segmentation fault (Address not mapped to object [0x7ffb53ad6f18])
[ruby $(which ign) gazebo-9] Segmentation fault (core dumped)

This simulation also uses ~45% more compute than Gazebo Classic which causes problems in navigation because its eating up so many resources that the controllers are unable to keep up with real-time performance. And that's without the front-end, with it, forget about it, it saturates my entire computer's resources. Is there something that can adjusted? At least in headless mode, it needs to not take up so many resources that on a run of the mill developer's laptop we can't effectively simulate the robot.

[ahcorde]

I will take look to the segfault.

I made some changes:

• Reduced the amount of loaded plugins
• Set the same camera view
• Reduced update frecuency in PosePublisher and gz_ros2_control

Let me know if these changes improve something

[SteveMacenski]

Definitely better, but still about ~30% heavier and makes the controller miss its generous schedule on my relatively powerful laptop. I would expect that this would cause issues for developers (including myself) at this performance level -- even headlessly.

[ahcorde]

I was talking with Gazebo team and we are investigating this. Meanwhile do you mind to try two things?

• Change ogre2 with ogre
• Reduce the number of laser samples

[SteveMacenski]

This is actually already an absurdly small number of laser samples. This is less than half of typical numbers.

I’ll test next time I’m in front of a computer

[SteveMacenski]

I don't see any notable difference changing the laser scan count and reducing it to 1/3 of before. The ogre change may have made a small difference, but not a night and day fix

[ahcorde]

@SteveMacenski I disabled shadows.

Disabling shadows also boosts the rendering FPS, especially when launching the simulation in CPU-only modes.

any improvements ?

[SteveMacenski]

I’m not rendering in the last experiment, just headless with the server only running - no front-end