Use Process.spawn to start gui and server

[rgov]

🦟 Bug fix

Partially addresses #44 to improve the cross-compatibility of gz sim to spawn both server and GUI.

Summary

When gz sim is invoked without specifying the GUI -g or server -s, the cmdsim.rb script will fork itself twice, and each child process calls into a different entrypoint.

This doesn't work well on macOS, where it is generally unsupported to fork without exec. Instead, the script makes the user manually start the server and GUI processes separately.

This changes the script to, immediately after parsing options and noticing the absence of -g or -s flag, spawn gz sim -s and gz sim -g. This is a more cross-platform way to execute the GUI and server in subprocesses. It also reduces some code duplication.

Downsides include:

• The subcommands can output the same thing twice. A simple case is:

   $ gz sim --version                  
   Gazebo Sim, version 9.0.0
   Copyright (C) 2018 Open Source Robotics Foundation.
   Released under the Apache 2.0 License.
  
   Gazebo Sim, version 9.0.0
   Copyright (C) 2018 Open Source Robotics Foundation.
   Released under the Apache 2.0 License.
  

  Another example would be if some error happens when loading the library, it will be printed twice.

• On Windows, the GUI might immediately exit, so the parent will kill the server too. The user should manually specify -s.

• It might be incorrect in some pathological case to launch the children with gz sim, e.g., if the original command was executed by explicit executable path, and the first result for gz in the search path is not the same binary.

• When one child process exits, the other is killed by the parent. However, it seems the kill command always errors for me on macOS, I'm not sure why.

  /opt/homebrew/Cellar/gz-sim9/8.999.999-0-20231016/lib/ruby/gz/cmdsim9.rb:202:in
  `kill': No such process (Errno::ESRCH)
  

Checklist

• Signed all commits for DCO
• Added tests
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[rgov]

cc @srmainwaring -- I don't think this will quite work due to the drawbacks, but wondering what others' thoughts are.

It would probably work better to have a small shim binary that just accepts the arguments to runServer() and/or runGui() to execute, and then you could fork-and-exec (or spawn) and it would be happy.

[srmainwaring]

I don't think this will quite work due to the drawbacks, but wondering what others' thoughts are.

@rgov - I find launching the server and gui separately less of an issue than the side-effects you highlight. In fact I prefer to run the server and gui separately for most of my work. Often I'll need to restart the server (changing controller PIDs or other params that do not change the number of entities), the GUI I can leave running with whatever visualisations are required. It is also easier to trace what is going on in the console with verbose output when the server and gui outputs are not interleaved.

When using ROS launch scripts to bring up a more involved simulation the separation of server and gui is not an issue, just an extra line or so in the launch description.

[rgov]

Agreed the solution presented here has too many drawbacks. I prefer the lib host process idea, where Ruby just does command line parsing and then executes one or more binaries that expect a fixed set of arguments.

Consider that many tutorials are written with the assumption that gz sim launches both. It creates confusion to have these basic commands have different behaviors on different platforms. It doesn't help the situation to make every tutorial have to call out these idiosyncrasies.

(10,000 ft viewpoint: Gazebo and ROS both aim to be cross platform but in reality Linux support is leaps ahead. With the ease of WSL, Docker Desktop, and VMs these days, it probably would be both a better user experience and far less development effort if the projects focused on Linux.)

[srmainwaring]

it probably would be both a better user experience and far less development effort if the projects focused on Linux

Except that there is currently no VM that provides accelerated graphics for Gazebo on macs, and docker is a non-starter for graphics on macs as well. The performance of the M1 laptops running ROS 2 and Gazebo natively is very good. Example: the nav2 stack are scaling back the rendering of the turtlebot example in the migration away from Gazebo Classic because of performance issues. A M1 MacBook will run Gazabo Harmonic, nav2 and ArduPilot SITL at RTF >=1 - easily. So I think it's worth the effort.

[rgov]

I'm a vocal supporter of native software for macOS, so I'm with you that a native experience would be great. Unfortunately, in trying to run Gazebo Harmonic, I've hit many stumbling blocks (installation failures: osrf/homebrew-simulation#2549, freezing GUI: gazebosim/gz-gui#609, gz sim tutorial commands don't work as-is as in the intro tutorials, the "banana for scale" is all black, etc.).

I'm hoping to use ROS with Gazebo, that means installing ROS from source. And hopefully the needed rosdeps are installable on macOS---by my count about 247 are, vs 1096 for Ubuntu.

For me right now, a non-hardware accelerated VM would be lower friction. Even better, VMware Fusion supports graphics acceleration to Linux VMs on Apple silicon, and probably this is provided by Virtualization.framework?

On Apple Silicon, Fusion can deliver OpenGL 4.3 with blazing fast 3D hardware acceleration to arm-based Linux virtual machines with Linux kernel 5.19 or greater.

Docker for GUI apps indeed is not user friendly at all. The options I've explored are connecting into the container with VNC, and forwarding to XQuartz on the host. If you have graphics acceleration on the guest, you can add VirtualGL to improve performance. The multicast UDP favored by Gazebo also requires some workarounds.

At any rate, I'll close this because it was a bad solution, but I hope another solution will help remove this speed bump on macOS.

[srmainwaring]

@rgov - sorry to hear your experience running Gazebo on macOS has not been good. I build Gazebo from source and don't run into that many issue in daily use. I'm about on Discord if you need a hand getting set up (including ROS Humble).

[woensug-choi]

@rgov @srmainwaring I've managed to install ROS2 Jazzy and Gazebo Harmonic on MacOS (apple silicon)!
I've made a one-liner installation script at https://github.com/IOES-Lab/ROS2_Jazzy_MacOS_Native_AppleSilicon

Yes, gazebosim/gz-gui#609 does occur and gz sim building_robot.sdf from intro tutorials fails with Unable to find or download file. But as @srmainwaring metioned, it seems ok for daily tests. Much referenced from @srmainwaring! My student will spend time building your wave - sailboat simulator this summer! (much to port for Jazzy-Harmonic combinations).

I particularly wanted to use Mac natively because my sonar plugin (using NVIDIA CUDA now) can benefit from shared memory between CPU-GPU 👀

[rgov]

@woensug-choi Nice work. Do you think you could contribute some of your patches upstream to the osrf/homebrew-simulation tap?

Ideally this script provides a blueprint for improving the installation process on Mac but eventually we could just brew install gazebo and the core team at OSRF can build on it for future ROS/Gazebo releases.

[woensug-choi]

working on ros2/ros2_documentation#4550 (review) first :)