Gazebo | Ignition | Community
Ask Your Question
1

Are both a gazebo node and an ignition node needed for gazebo8?

asked 2017-12-18 17:58:48 -0500

asomerville gravatar image

I was looking through the migration document here:

https://bitbucket.org/osrf/gazebo/src...

And while it includes a lot of specific information, it doesn't provide much conceptual information. After reading into the code I'm coming to the conclusion that in places where you might historically only need a gazebo::transport::node and gazebo::transport::publisher we may now need a parallel ignition::transport::node and ignition::transport::publisher along side each which seems unfortunate (though perhaps only necessary in transition), but I can't find any specific information to corroborate what I think I've found via inspection.

Are both types of nodes and publishers needed for the time being?

Will gazebo eventually only use one or the other?

Is there another migration document which either guides people through the changed necessary in their code, or explains on a conceptual basis what has changed and will need updating?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2017-12-20 09:30:14 -0500

nkoenig gravatar image

updated 2017-12-20 15:20:45 -0500

asomerville gravatar image

Thanks for the question. A gazebo node and an ignition node are both not required for gazebo8, depending on your use case. The same is true for the upcoming gazebo9 release.

Ignition transport will become the future communication protocol used by Gazebo, but it's use is generally not mandatory and most of Gazebo8&9 still uses Gazebo's internal communication protocol.

There are a few places where Ignition Transport is used inside Gazebo8. One example is by the Plotting Widget. Unless you are customizing this widget, then this shouldn't affect you. Another example are VisualizationMarkers. In this case, you could need both an Ignition Node and a Gazebo Node if you are writing a custom plugin/application that needs both visualization markers and communication with other aspects of Gazebo.

The above two examples are new features, and the use of Ignition shouldn't break existing code. It will introduce a bit of a burden as we transition. This is unavoidable, and we are trying to make the impact as minimal as possible.

We are planning to replace Gazebo's communication protocol with Ignition, but this transition will use a tick-tock model. For example, any topic replacement will first have an optional ignition alternative (enabled via a command line argument). The optional ignition topic will then transition to the default, and the gazebo topic will become optional. Finally, the gazebo topic option will be removed. Each step will happen at major releases, which means a single topic replacement would take three years at minimum.

We are working on a migration guide, which should be published before the next Gazebo release in January 2018.

edit flag offensive delete link more

Comments

I needed ignition transport for joint_cmd topic connected to the JointController. In Gazebo8, publishing to old relative topic streams constant warnings suggesting fully scoped topic seen at physics/JointController.cc:392 switching the topic to fullyscoped doesn't work unless you also switch the transport since the other topic is ignition tranport. Would it make sense for me to file a ticket requesting a reduction in warning frequency, or is that the desired behavior?

asomerville gravatar imageasomerville ( 2017-12-20 15:27:05 -0500 )edit

Thanks. That message is designed to inform people that gazebo's transport mechanism will change to ignition transport for the joint_cmd topic. The message is a bit unclear. I made the change here: https://bitbucket.org/osrf/gazebo/commits/0ebd1e4ce7fc413dbeb83cacbc5cadf8398b9076. Sorry about lack of a PR, new years mistake.

nkoenig gravatar imagenkoenig ( 2018-01-02 09:31:20 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2017-12-18 17:58:48 -0500

Seen: 351 times

Last updated: Dec 20 '17