Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Deprecate and archive gz-launch #288

Open
iche033 opened this issue Feb 8, 2025 · 3 comments
Open

Proposal: Deprecate and archive gz-launch #288

iche033 opened this issue Feb 8, 2025 · 3 comments
Labels
Breaking change Breaks API, ABI or behavior. Must target unstable version.

Comments

@iche033
Copy link
Contributor

iche033 commented Feb 8, 2025

Background

gz-launch was designed to let users launch and manage processes and plugins using a command line tool and providing a xml configuration file. This was used in projects (like subt) to launch a gazebo server process, spawn robots into the simulation, and launch ROS (1) processes. However, as many of the tools and packages in modern Gazebo and ROS 2 are now mature, the functionalities offered by gz-launch can be found in other tools and packages, e.g. ROS 2 launch. One exception is gz-launch's websocket server plugin for running gz-web, which is still in use by users the community.

Proposal

  • Deprecate gz-launch9 in Gazebo Jetty and remove gz-launch from the list of gazebo packages in Gazebo K.
  • Port the websocket server plugin to gz-sim in Gazebo Jetty
    • To use the websocket server plugin with gz sim, users will now need to explicitly specify the plugin in their world SDF file
    • Note: moving the package to gz-sim means adds an extra dependency: libwebsockets-dev (and maybe more)

The main motivation for deprecating and removing gz-launch is to reduce maintenance effort.

Drawback

One nice feature of gz-launch is the ability to load and run gz plugins at run time after the gazebo server has started, i.e. users do not need to specify the plugin in the sdf world file in advance. Removing this package loses this functionality. This is something that we could consider adding to another gz package in the future.

@iche033 iche033 added the enhancement New feature or request label Feb 8, 2025
@iche033 iche033 changed the title Proposl: Deprecate and archive gz-launch Proposal: Deprecate and archive gz-launch Feb 8, 2025
@iche033 iche033 added Breaking change Breaks API, ABI or behavior. Must target unstable version. and removed enhancement New feature or request labels Feb 8, 2025
@peci1
Copy link
Contributor

peci1 commented Feb 10, 2025

Good move. I've always considered gz-launch a bit awkward, depending on all gz packages etc. Also, its process management never worked as reliably as roslaunch.

However, deprecating gz-launch before an alternative to the runtime plugin loading is provided seems to be a bit painful. Is something like gz plugin load planned?

Also, does this mean gazebo gets more intertwined with ROS, or will all standard Gazebo use-cases still be possible without ROS?

@iche033
Copy link
Contributor Author

iche033 commented Feb 11, 2025

Some notes from discussion in PMC meeting:

  • generally in favor of deprecating the package
  • Ok to migrate websocket server to gz-sim
    • consider changing libwebsocket-dev dep to header only library websocketpp later
  • Plugins here are special gz-launch plugins and not gz-sim systems. A migration path for users wanting to load plugins on the fly is to load gz-sim systems at run time by using the service: /world/<world_name?/entity/system/add.
    • we can probably provide a convenient cmd line tool like gz plugin load that helps to invoke the gz service

Next steps:

  • migrate websocket server to gz-sim
  • Update migration guide

@iche033
Copy link
Contributor Author

iche033 commented Feb 11, 2025

Also, does this mean gazebo gets more intertwined with ROS, or will all standard Gazebo use-cases still be possible without ROS?

I think all standard Gazebo use cases are still possible. The launch functionality can be replaced by pure python scripts if users do not wish to use ROS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking change Breaks API, ABI or behavior. Must target unstable version.
Projects
Status: Inbox
Development

No branches or pull requests

2 participants